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

[Simon Kelley]

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
Richard)


>> 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.

OK.
>> 
>> 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.

Cheers,

Simon.