[Dnsmasq-discuss] dhcp-script, add|del|old ...and maybe load,
simon at thekelleys.org.uk
Thu Aug 21 14:53:27 BST 2008
Eric Thibodeau wrote:
>> 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.
No, it gets called when an existing lease record changes (and for all
existing leases when dnsmasq starts up) (for extra info, see my reply to
>> 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).
Ok, that means there's not bug in dnsmasq.
>> 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 `
As I recall, the reasoning was that the userclass info could not always
be provided, so it was restricted to appear only when it would always be
available, during the DISCOVER/OFFER etc phase.
>> 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?
No, my thinking was that the lease-change script could be called with
arguments like "offer" and "ack" when DHCP protocol interactions take
place. That would be a fair bit of extra code to do, so it would have to
be demonstrably useful.
More information about the Dnsmasq-discuss