uguu.ca

staticDHCPd 2.0.0 documentation now live

Closing in on the week-of-July-21st 2.0.0 rc1 release, documentation for staticDHCPd has been compiled and published.

• libpydhcpserver
• staticDHCPd

Getting 1080p working via Intel i915 (Haswell 4600) -> HDMI -> VGA -> TV

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

PING in pure Python

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’

staticDHCPd-2.0.0-beta-9

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.

staticDHCPd-2.0.0-beta-8

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.

staticDHCPd-2.0.0-beta-6

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.

staticDHCPd 2.0.0-beta-4^H5^H7

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.

staticDHCPd 2.0.0-beta-3

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.

staticDHCPd 2.0.0-beta-1

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!

Only two things left beofre staticDHCPd 2.0.0-rc1

First, of course, is the stats module. That should be pretty simple now, except for the cool part I want to add, but even that should only take about an hour.

Second is updating the documentation.

It’s very close now. Unfortunately, I’ll probably have to leave it alone for tonight, but have something I finished while in transit.