This is just a bugfix release over 1.5.0; details are in the changelog.
staticDHCPd 1.5.0 is now available for download.
For anyone curious, the changelog can be found on the Google Code project site.
1.5.x expansions are done,
1.6.x will be built, featuring a semi-stateful view into address-assignment, through a simple table design: the IP/subnet/serial key assigned to a MAC will be grouped with an expiration timestamp, allowing for an unreliable view of which hosts currently have “leases” (hosts that simply asked for configuration data, without an IP, will be tracked, too, with a special typecode). For DHCPv4 clients, this will be largely informational, enabling only the addition of
LEASEQUERY support, but when
v2 is implemented for DHCPv6, it will allow for server-initiated
RECONFIGURE events, as described in section
19 of RFC 3315, which are pretty important, given the nature of the networks staticDHCPd is intended to serve.
This new subsystem will be configurable, using options like
enable_reconfigure; if not enabled, the corresponding tracking mechanisms will not be used, for performance reasons. The data will also be storable in a local SQLite database, instead of the standard storage (this also allows for a second database if using SQLite already, to allow for better thread concurrency), to avoid a second remote access hit, when speed really matters.
While on the subject of performance, non-crucial data, like the list of clients remaining to be reconfigured and temporarily blacklisted MACs, may be stored in an in-memory SQLite database, rather than Python data-structures: this should save memory at a slight cost of speed; tests and stats will be necessary to decide whether the trade-off is worthwhile, though.
1.5.0 will be published as previously described, I’ll continue extending it through
1.5.x, which will involve a revised logging engine, favouring deferred unattended writes to disk (to simplify forensics without impacting performance), a prettier web interface (though the information presented will remain about the same), and a few more runtime config options, including, if feasible, the ability to reload config options on the fly.
I’ve received a request to add DHCPv6 support to staticDHCPd. Lacking any reason to say no, I said yes, so
v2 won’t be about moving to Python 3.0 (though I expect that the code will branch quite soon after this addition is complete), but rather about adding IPv6 support for those of you who actually need it.
My first step will be to finally add native PostgreSQL support, using psycopg, since it seems to have emerged as the dominant library since the last time I looked. This will finish
1.5.0 and mark the end of the
1.x line, save for any necessary bugfixes.
DHCPv6 support will be introduced by forking
libpydhcpserver (the library that evolved from Mathieu Ignacio’s pydhcplib) into
libpydhcpserver6, which may or may not be a full rewrite (if it can inherit from the old codebase, it will, but chances are it can’t, due to fundamental differences between option encodings and packet structure). Both libraries will be present in the new product, and IPv4 support will work alongside IPv6 support in the same process, to the fullest extent possible.
If anyone can recommend consumer-grade hardware that runs IPv6 (home routers, for example), I’d appreciate it, since all I’ll have to test with will be ISC-based VMs, due to a lack of physical routing fabric. (I’d like my tests to be as representative of reality as possible)
staticDHCPd 1.5.0 isn’t ready to be officially released yet, but all of the new features are ready to be played with and everything has been documented. You can use the preview version by checking out the current SVN trunk; post feedback or open issues if you find any bugs.
1.5.0’s proper release will follow development of unit tests and a reasonable soak period, since it reflects a lot of changes to the underlying code.
1.4.1 just adds the ability to pass bytes instead of the special RFC objects for the options added with 1.4.0. In case efficiency really, really matters.
staticDHCPd 1.4.0 is now out, and it brings with it a large number of new features, many of which nobody will ever use! But adding them was a necessary step since every known relevant option and feature is now supported. (If something was missed, let us know)
From the changelog:
- Added support for RFC2610 (options 78 and 79)
- Added support for RFC2937 (option 117)
- Added support for RFC3046 (option 82)
- Added support for RFC3361 (option 120)
- Added support for RFC3396 (long options)
- Added support for RFC4174 (option 83)
- Added BETA support for RFC4388 (LEASEQUERY)
- Added support for specification of options by number
- Rebuilt support for RFC3397 (option 119), with the caveat that the compression algorithm it describes was omitted
It offers a large number of new features over 1.2.0, inspired by needs that have arisen over the past several days:
- Support for DHCPDECLINE and DHCPRELEASE events
- Diagnostic features to help find misconfigured clients in networks, particularly those that would interfere with normal operation of a network or a dynamic DHCP server
- Improvements to how event-messages are formatted, making it easier to read through the event-log
- Less-memory-intense caching logic without sacrificing speed
- AUTHORITATIVE mode, which allows unknown MACs to be NAKed, rather than ignored, fixing an incompatibility with some vendors’ non-RFC-compliant relays
- Support for having logfiles written to disk with the current timestamp as a suffix, simplifying the process of creating status snapshots