July 26th, 2014 by Neil Tallim
staticDHCPd 2.0.0 is finally in rc1 status!
Anything in the 2.0.0 branch from r774+ now needs to be tested and the checklist will be tracked on the GoogleCode page. If, after two weeks, no issues are reported, an “rc1″ source package will be published, and if that goes for another two weeks without issues, 2.0.0 will be considered stable and Debian packages and RPMs will be prepared.
At this point, no new features will be added until the system is stable (but please submit ideas to the issue-tracker anyway). Any non-bugfix commits will be things to prepare for the Debian/RPM packages or minor formatting tweaks.
July 6th, 2014 by Neil Tallim
Closing in on the week-of-July-21st 2.0.0 rc1 release, documentation for staticDHCPd has been compiled and published.
January 25th, 2014 by Neil Tallim
For a project I recently started, I needed to build a semi-dedicated system. To make the cost a little more palatable, I planned to make it double as an HTPC (and maybe, in time, a Steam Box).
The TV I opted to use had its HDMI circuitry burn out late last year, so, as a workaround, I’ve been using an HDMI-to-VGA converter (HD2V04; does HDCP), which has been flawless with a PS3, but failed horribly when working with a device that actually wanted to trust EDID values, rather than just forcing its own fixed profiles, as a game console would.
Specifically, all EDID would enumerate was the VESA core-set and 1366×768, none of which looked good or even scaled properly on my display.
Adding definitions to xorg.conf repeatedly failed with “no mode of this name”, even when the mappings all appeared to check out. Using cvt and xrandr just resulted in unsupported video modes, making that seem like a dead-end, too. And i915.modeset=0 just made my DPI, which xorg.conf also failed to override, painfully wrong, to the point that there wasn’t enough detail to fonts to make out much of anything.
Ultimately, after lots of experimentation, I found a working configuration. The information below should work on most distributions, but have only been tested on Kubuntu 13.10.
First, you should try cvt 1920 1080 (using appropriate values), because, if it works, you’ll save yourself a bit of time. If not, then, like me, you can look for an appropriate modeline from the MythTV Modeline Database.
Once you have values, you’ll need to register them so xrandr will know what “1920×1080″ means: xrandr --newmode "1920x1080" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
Then bind the new mode to the output you’re using: xrandr --addmode HDMI3 1920x1080 (you can find the name of your output, HDMI3 in my case, by running xrandr without arguments)
Finally, set the mode and refresh-rate to see if it works: xrandr --output HDMI3 --mode "1920x1080" --rate 60
If it doesn’t, you can set another mode, even if you can’t see your screen, by typing xrandr --output HDMI3 --mode "1024x768" --rate 60, which is almost certain to exist. (You can see all modes by typing xrandr without arguments)
Once you have a working value, you can make it permanent on-login by putting it in ~/.xprofile, which is executed as a series of instructions like any other script. I added a shebang and made the file executable for testing purposes, but this is probably not necessary.
#!/bin/sh
xrandr --newmode "1920x1080" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
xrandr --addmode HDMI3 1920x1080
xrandr --output HDMI3 --mode "1920x1080" --rate 60
October 1st, 2013 by Neil Tallim
For work, I had need of running ping from a Python context in a memory-limited environment. Python was a given, parsing subprocess output is ugly, variable payload-sizes were required, and potentially many hosts would need to be pinged in parallel.
Seems like a great job for fping, but distributing external binaries is kinda tricky with this setup, so I did it in Python. (The other Python PING implementations, all of which seem to be derivatives of python-ping, either didn’t meet my basic needs, had more procedural namespace-bleed than I’d prefer to see, tried to do too much (requiring workaround logic to just do what’s actually needed), didn’t handle errors, or were GPL-licensed, which is unfortunately not something of which this process can make use)
The code, which is public domain, is available after the break.
Continue reading ‘PING in pure Python’
September 27th, 2013 by Neil Tallim
beta-8 is now live, with the following compelling reasons to upgrade:
- qtag support for the broadcast-bit situation
- Support for “extra” columns from your database to
loadDHCPPacket()
- Intuitive data-type conversion for setOption() and getOption() for those of you who’d rather pass strings and ints than lists of bytes
- While not in the release itself, documentation is now about 5% complete, and with the templates defined, it should ramp up quickly, so closing in on rc1
This release needs more testing than any that have come before, but it’s also likely to be less stable than beta-8, because it includes a complete refactoring of DHCPPacket and some other cross-code-reaching changes. It’s almost safe to use beta-8 in controlled production contexts, but beta-9 is only for those brave and willing to tell me what’s broken.
The release is available at downloads page. As before, its changelog is in a transitive state and can be viewed in-source: staticDHCPd, libpydhcpserver.
Of extreme importance to those of you who’ve been testing the 2.0.0-beta series is that this WILL break your loadDHCPPacket() function, if you’ve defined one: definition is now supplied, rather than subnet, serial, and client_ip. To deal with this, replace those three fields (they’re sequential) with definition and access the values as definition.subnet, definition.serial, definition.ip.
September 16th, 2013 by Neil Tallim
So it’s been a while, and I don’t remember why there was no post announcing beta-7, but beta-8 is now live, sporting the following new features:
- Support for clients that cannot handle broadcast OFFERs, which are few, but can be found in embedded systems; in issue 15′s history, this was identified as a problem with the broadcast-bit
- Persistent and local-file-instead-of-memory caching options
- Support for arbitrary config-file locations, via
--config or the STATICDHCPD_CONF_PATH environment variable
The broadcast-bit feature owes a lot to Ken Mitchell, for providing feedback and extensive testing throughout the process. Thanks to corecode#dragonflybsd@efnet, too, for helping to clarify BSD networking philosophy and enable selection of a fallback cross-platform solution for L2 packet-injection.
There’s also Debian-packaging infrastructure in the repository, because that’s coming once past the RC phase. Right now, the focus is on the documentation rewrite, which should be all that remains. Feature-requests are still welcome, but try to hold off on them if you want a stable release sooner than later.
You can, as always, grab this release from its downloads page. Its changelog is in a transitive state and can be viewed in-source: staticDHCPd, libpydhcpserver.
June 22nd, 2013 by Neil Tallim
Cooper Lee identified an issue in which non-existent MACs would lead to an error when their definition, which was None, was asked for an ip attribute. This should no longer happen and went unnoticed by me ever since 2.0.0-beta-1 because I’d been using the dynamism module in my test environment, which masked the problem by always returning a full definition. I now have multiple testing servers to avoid another issue like this.
June 21st, 2013 by Neil Tallim
This is a minor update, addressing a circular reference discovered by Vladimir Shencov, in which importing from staticdhcpdlib.databases during the config phase (the recommended method of defining custom databases) would prevent the server from starting. Imports should now come from staticdhcpdlib.databases.generic.
If you are using the dynamism module, you’ll need to make that change near the top of the file. Nothing else needs to be modified, though.
beta-4 only half-addressed the issue; beta-5 should deal with it properly. Sorry about that.
And beta-5 missed another reference-point. beta-7, using a fix devised by Vladimir, should have it dealt with for real. For really real.
June 19th, 2013 by Neil Tallim
This should be the last time I modify the codebase in any significant way. I wanted to clean up libpydhcpserver and that’s now done, so please grab a copy of the most recent release, test it, and let me know about any issues.
I’ll try to work through a little bit of the documentation updates each day and if I get through everything with no new problems being reported, I’ll consider it stable.
March 28th, 2013 by Neil Tallim
It’s out.
I still need to revise all of the comments/inline documentation before I’ll be ready to call it a release-candidate, but I don’t anticipate adding any features or making any significant code-changes before that.
Head to GoogleCode and grab a copy. Play with it and report any issues.
In the meantime, here’s what the stats module provides:
Yay, stats!
