[Dnsmasq-discuss] dhcp-script, add|del|old ...and maybe load, DNSMASQ_USER_CLASSn, etc.

Eric Thibodeau kyron at neuralbs.com
Wed Aug 20 22:56:04 BST 2008


Correction and comments below:

Simon Kelley wrote:
> Eric Thibodeau wrote:
>> Hello,
>>
>>    I've been (ab)using dnsmasq for quite a while and I am now 
>> attempting to use dhcp-script callbacks to pull information from 
>> booting machines. The context is a clustering environment where nodes 
>> are PXE booted, NFS root mounted and dhcpcd is used as such to send 
>> in the number of detected CPUs:
>>
>> dhcpcd --renew --persistent --userclass=$(c=0; for i in 
>> /sys/devices/system/cpu/cpu[0-9]*; do ((c++)); done; echo $c) eth0
>>
>>    I add in --renew to force dhcpcd to send a request, it's not 
>> required per say. the `$(c=0; for i in 
>> /sys/devices/system/cpu/cpu[0-9]*; do ((c++)); done; echo $c)` 
>> translates to 2 . Here is a trace of the execution for a node that 
>> was already booted and is part of the dnsmasq's cache:
>>
>> master ~ # dnsmasq -d
>> dnsmasq: started, version 2.45 cachesize 150
>> dnsmasq: compile time options: IPv6 GNU-getopt no-ISC-leasefile 
>> no-DBus I18N TFTP
>> dnsmasq: DHCP, IP range 10.0.0.2 -- 10.0.0.254, lease time 12h
>> dnsmasq: TFTP root is /tftproot
>> dnsmasq: ignoring nameserver 127.0.0.1 - local interface
>> dnsmasq: reading /etc/dnsmasq-resolv.conf
>> dnsmasq: using nameserver 192.168.1.2#53
>> dnsmasq: read /etc/hosts - 2 addresses
>> ====================
>> /root/node-manager called with old 00:0c:29:41:b5:7a 10.0.0.162 
>> node162 and DNSMASQ_USER_CLASS0 ==
>> ====================
>> dnsmasq: DHCPREQUEST(eth1) 10.0.0.162 00:0c:29:41:b5:7a
>> dnsmasq: DHCPACK(eth1) 10.0.0.162 00:0c:29:41:b5:7a node162
>> ====================
>> /root/node-manager called with old 00:0c:29:41:b5:7a 10.0.0.162 
>> node162 and DNSMASQ_USER_CLASS0 ==
>> ====================
>> dnsmasq: DHCPREQUEST(eth1) 10.0.0.162 00:0c:29:41:b5:7a
>> dnsmasq: DHCPACK(eth1) 10.0.0.162 00:0c:29:41:b5:7a node162
>> dnsmasq: DHCPREQUEST(eth1) 10.0.0.162 00:0c:29:41:b5:7a
>> dnsmasq: DHCPACK(eth1) 10.0.0.162 00:0c:29:41:b5:7a node162
>>
>> My interpretation (node-manager is the dhcp-script):
>> * start dnsmasq -d
>> - node-manager is called on startup with old, with 
>> DNSMASQ_USER_CLASS0 null, as expected
>>
>> * on node162, call dhcpcd - dhcpcd --renew...
>> - node-manager is called but DNSMASQ_USER_CLASS0 is empty...that 
>> wasn't expected.
>> Note: Roy Marples was nice enough to confirm with Wireshark that the 
>> userclass is _always_ sent by dhcpcd
>>
>> * on node162, call dhcpcd - dhcpcd --renew... (again)
>> - This time, the script isn't called at all
>> * on node162, call dhcpcd - dhcpcd --renew... (and again)
>> - This time, the script isn't called either
>>
>> I can understand that 'excessive' dhcp requests can trigger a DOS 
>> prevention mechanism and not call dhcp-script. But this is neither 
>> documented nor controllable.
>>
>> Now here is another trace booting a node that was never booted before 
>> (add):
>>
>> dnsmasq: DHCPDISCOVER(eth1) 00:0c:29:8e:50:fa
>> dnsmasq: DHCPOFFER(eth1) 10.0.0.249 00:0c:29:8e:50:fa
>> dnsmasq: DHCPDISCOVER(eth1) 00:0c:29:8e:50:fa
>> dnsmasq: DHCPOFFER(eth1) 10.0.0.249 00:0c:29:8e:50:fa
>> dnsmasq: DHCPREQUEST(eth1) 10.0.0.249 00:0c:29:8e:50:fa
>> dnsmasq: DHCPACK(eth1) 10.0.0.249 00:0c:29:8e:50:fa
>> ====================
>> /root/node-manager called with add 00:0c:29:8e:50:fa 10.0.0.249 and 
>> DNSMASQ_USER_CLASS0 ==
>> ====================
>> dnsmasq: TFTP sent /tftproot/pxelinux.0 to 10.0.0.249
>> dnsmasq: TFTP error 0 TFTP Aborted received from 10.0.0.249
>> dnsmasq: TFTP failed sending /tftproot/pxelinux.0 to 10.0.0.249
>> dnsmasq: TFTP sent /tftproot/pxelinux.0 to 10.0.0.249
>> dnsmasq: TFTP sent /tftproot/pxelinux.cfg/default to 10.0.0.249
>> dnsmasq: TFTP sent /tftproot/nfsroot/x86_64/boot/kernel to 10.0.0.249
>> dnsmasq: DHCPDISCOVER(eth1) 00:0c:29:8e:50:fa
>> dnsmasq: DHCPOFFER(eth1) 10.0.0.249 00:0c:29:8e:50:fa
>> dnsmasq: DHCPREQUEST(eth1) 10.0.0.249 00:0c:29:8e:50:fa
>> dnsmasq: DHCPACK(eth1) 10.0.0.249 00:0c:29:8e:50:fa
>> dnsmasq: DHCPDISCOVER(eth1) 00:0c:29:8e:50:fa
>> dnsmasq: DHCPOFFER(eth1) 10.0.0.249 00:0c:29:8e:50:fa
>> dnsmasq: DHCPREQUEST(eth1) 10.0.0.249 00:0c:29:8e:50:fa
>> dnsmasq: DHCPACK(eth1) 10.0.0.249 00:0c:29:8e:50:fa node249
>>
>> I would like it to be all clean and only request an IP adderss once 
>> but this doesn't seem feasible for the moment since the sequence is 
>> kernel-dhcpc -- (something-dhcp...can't figure out where that second 
>> request comes from) -- dhcpcd caled from rc scripts
>>
>> So here is my wishlist:
>>
>> - add a keyword (load?) to the add, del, old list so one can 
>> differentiate between dnsmasq loading and subsequent DHCPREQUESTs 
>> with 'old'. I could cope with the 'old' key being also called at 
>> dnsmasq startup but the *USER_CLASSn not being set threw me off.
>> - provide the means to _always_ call the dhcp-script
>> - always pass on the userclass down to the script on 'old|add' 
>> (obviously implies the load key gets added).
>>
>> Don't hesitate to hit me in the generally right direction if I am 
>> totally off on my usage of these tools or to ask for details.
>
> A few comments, in no particular order.
>
> The dhcp script communicates changes to the lease _database_ not 
> individual DHCP interactions with a host. It's as designed that it 
> doesn't get called when a lease is renewed.
Then I guess this is a misinterpretation on my part on the "old" key, I 
thought it would be called each time there was interaction between a 
host and the server.
> The userclass info is not always available, as you saw. If you want to 
> use it, you'll probably need to implement a parallel database which 
> has IP address as primary key and stores the userclass information. 
> The userclass will always be provided when a lease is created, but not 
> later.
Actually, I was _also_ calling dhcpcd incorrectly (or rather, 
misinterpreting the --renew option) and this was causing me to end up 
with dhcpcd initialized with an empty userclass, which would stick for 
the life of dhcpcd. Once corrected with the initial dhcpcd called 
correctly with the userclass data, the information _is_ sent through to 
dnsmasq. What I have noticed is that the userclass is passwd down _only_ 
when the DISCOVER/OFFER/REQUEST/ACK is encountered, which is the case 3 
times within the boot process because a client ends up using 3 
different/independent clients (PXE, kernel and dhcpcd).
>
> The trace where you don't see userclass information even during a 
> DISCOVER/OFFER/REQUEST/ACK sequence may well be a bug. What version of 
> dhcpcd are you using? I'll do some tests.
Those cases aren't a bug, they are the cases where it's PXE and the 
kernel requesting an address.
>
> There's no DOS prevention code in the script-calling system.
Then I could not figure out why dnsmasq wasn't calling the dhcp-script 
upon repeated calls of `dhcpcd -n ... eth0 `
>
> It may be sensible to provide raw DHCP events to the script if people 
> can use them.
I now have a setup where I can use wireshark and have recorded 
exchanges, is this the type of trace you're referring to?
>
> CHeers,
>
> Simon.
Thanks!

Eric



More information about the Dnsmasq-discuss mailing list