In self managed networks with decentralized client realms a central DHCP server is not available. DDHCPD allows every realm to have its own server; preserving roaming features for the client, by maintaining a common consens on DHCP leases.
The implementation is flexible, meaning we do not prevent you from doing stupid stuff, but also allow you maximal adaption.
Usage: ddhcp [-h] [-d|-D] [-L] [-c CLT-IFACE|-S] [-i SRV-IFACE] [-t TENTATIVE-TIMEOUT] [-B BLOCK-TIMEOUT]
-h This usage information.
-c CLT-IFACE Interface on which requests from clients are handled
-i SRV-IFACE Interface on which different servers communicate
-S no client interface
-t TENTATIVE Time required for a block to be claimed
-N NETWORK/CIDR Network to announce and manage blocks in
-o CODE:LEN:P1. .. .Pn DHCP Option with code, len and #len chars in decimal
-b BLKSIZEPOW Block size as power of two
-B TIMEOUT Block claim timeout
-s SPARELEASES Amount of spare leases (max: 256)
-L Deactivate learning phase
-d Run in background and daemonize
-D Run in foreground and log to console (default)
-C CTRL_PATH Path to control socket
-H COMMAND Hook to call on events
-V Print build revision
-v Increase verbosity, may be specified multiple times
To build a production binary of DDHCPD run.
make clean all
To increase the default logging output additional CFLAGS can be provided:
CFLAGS="-D LOG_LEVEL_DEFAULT=5" make clean all
Additionally setting DEBUG=1 activates debug symbols:
DEBUG=1 CFLAGS="-D LOG_LEVEL_DEFAULT=5" make clean all
To reduce the binary size to the minimum run:
CFLAGS="-D LOG_LEVEL_LIMIT=0" make clean all
To collect statistics build with
CFLAGS="-D DDHCPD_STATISTICS" make clean all
Depending on the chosen variant the binary size may variate between 30KiB and 1MiB.
On a gluon node the command may look this:
ddhcpd -o "3:4:10.116.254.254" -o "1:4:255.255.128.0" -o "28:4:10.116.254.255" -N 10.116.224.0/20 -b 2 -s 1 -c br-client -i bat0
We are able to register DHCP options during startup but also during runtime. Using the ddhcpdctl binary, to e.g. add the standard gateway:
ddhcpdctl -o "3:4:10.116.254.253"
or a dedicated timeserver
ddhcpdctl -o "42:4:10.116.254.252"
Configured options can be removed with:
ddhcpdctl -r "42"
Be careful with this: as expressed above we do not save you from shooting yourself into your foot.
If you want to react to events, you can register an executable (binary or script) via the '-H' switch. On every event that executable will be called given a list of arguments:
Currently
lease
A new lease was handed out to the client indicated.
release
The indicated lease has been released back into the address pool.
Upcoming versions of DDHCPD may introduce further action keywords.
You can count the nodes in your network wich an active ddhcpd with
# ddhcpdctl -b | tail -n+10 | sed -e 's/\t\+/ /g' | cut -d ' ' -f 3 | sort -u | wc -l
The network-test script sets up a set of virtual interfaces which are composed of server and client interface pairs. Those are called srvX for daemons and cltX for clients inside of the main network namespace and server0 and client0 in the ''daemons'' network namespaces. All srvX interfaces are bridged in br-srv; enabling all daemons to communicate bidirectional.
Inside of the daemon's network namespace the client0 interface has the address 10.0.0.1/20. An IPv4 address is needed here, because the DHCP part of DDHCPD binds on this interface. It is the same address in every daemon namespace and since cltX interfaces are not bridged this is no problem. On the server0 interface we need no IPv4 address, because d2d communication is handled via IPv6 multicast/unicast on the local link.
You can setup a basic DDHCPD network testing environment by calling
# ./network-test net-init <number>
which creates a virtual network for
To start the (n-1)-th instance of DDHCPD in your test environment, use
# ./network-test srv-start <n> ./ddhcpd -t 3
The above also reduces the tentative timeout from 12 to 3 seconds to speed up testing.
After starting multiple instances, we generate DHCP requests against specific instances of DDHCPD by starting DHCP clients pointed to the cltX interfaces, i.e.
# dhclient -sf /dev/null -d -v clt0
for the first DDHCPD instance. To create multiple parallel running clients with different mac addresses, do:
# ./network-test clt-start <n>
To unconfigure the setup call:
# ./network-test net-stop
A simple testing routine incorporating all the above:
# ./network-test test
A maintained gluon integration can be found at:
https://github.com/sargon/gluon-sargon/tree/master