[Dnsmasq-discuss] Re: can wol mess up mac-based address-assigments?

[Simon Kelley]

pete.dawgg wrote:
> hello simon,
> any updates on this problem yet? (it's not going away by itself )-: )
> all clients are configured identically and are switched on and off
> roughly at the same time. some days only on or two get adresses from
> the "free" range, sometimes the whole "free" range is consumed.
> dnsmasq always logs that the preconfigured "address was previously
> declined" - but why? could it help to delete the clients' local
> /var/lib/dchpc/*-files?
> cheers
> pd
> 
> 
> 2008/7/21 pete. dawgg <pete.dawgg at googlemail.com>:
>> hello simon,
>> thx for the reply!
>>> Looking at your Gentoo post, the key may be in client-ids, which are the
>>> last item on the line in dnsmasq.leases. When clients provide client-ids,
>>> dnsmasq use that instead of the MAC address to identify the client, so if it
>>> provides different client-ids at different times, that will mess things up.
>> the clients are not configured to use client-ids; they are identical
>> except for the mac-address.
>>
>>> Are you using different DHCP clients at different points in the boot?
>> they clients only use one dhcp-client (there's nothing like netboot or
>> pxeboot); their os starts and at some point an initscript starts
>> dhcpcd
>>
>>> The long client-id comes from Gentoo's dhcpcd, the shorter ones which are
>>> 01:<mac address> come from other clients.
>> please look at the excerpt from dnsmasq.leases below; the line with
>> the long client id is from one client where i installed the latest
>> dhcpcd just to make sure it is not a problem of an outdated version.
>> all the clients should have addresses between 10.10.1.160 and
>> 10.10.1.178, 10.10.1.220-10.10.1.229 is the "free" range.
>>
>> i have changed the wakeonlan-script so that dnsmasq is off while the
>> wake-up-packets are sent but that did not change anything.
>>
>> excerpt from dnsmasq.leases:
>> ==========================================
>> 1216655173 00:19:d1:4d:84:da 10.10.1.225 zb-kibue-1 01:00:19:d1:4d:84:da
>> 1216655173 00:16:76:90:8b:cc 10.10.1.175 zb-krz-01
>> ff:65:74:68:30:00:01:00:01:10:11:57:35:00:16:76:90:8b:cc
>> 1216655176 00:16:76:5a:d4:5f 10.10.1.226 zb-int-01 01:00:16:76:5a:d4:5f
>> 1216655179 00:16:76:45:6b:30 10.10.1.227 zb-int-10 01:00:16:76:45:6b:30
>> 1216655180 00:16:76:dc:41:9a 10.10.1.165 zb-int-06 01:00:16:76:dc:41:9a
>>
>> ==========================================
>>
>> excerpt from syslog (client gets "wrong" address):
>> ==========================================
>> Jul 21 09:46:19 orbb dnsmasq[28477]: DHCPREQUEST(eth0) 10.10.1.229
>> 00:16:76:90:7b:62
>> Jul 21 09:46:19 orbb dnsmasq[28477]: DHCPACK(eth0) 10.10.1.229
>> 00:16:76:90:7b:62 zb-int-12
>> Jul 21 09:46:19 orbb dnsmasq[28477]: DHCPDECLINE(eth0) 10.10.1.229
>> 00:16:76:90:7b:62
>> Jul 21 09:46:19 orbb dnsmasq[28477]: not using configured address
>> 10.10.1.171 because it was previously declined
>> Jul 21 09:46:19 orbb dnsmasq[28477]: DHCPDISCOVER(eth0) 00:16:76:90:7b:62
>> Jul 21 09:46:19 orbb dnsmasq[28477]: DHCPOFFER(eth0) 10.10.1.221
>> 00:16:76:90:7b:62
>> Jul 21 09:46:19 orbb dnsmasq[28477]: not using configured address
>> 10.10.1.171 because it was previously declined
>> Jul 21 09:46:19 orbb dnsmasq[28477]: DHCPDISCOVER(eth0) 00:16:76:90:7b:62
>> Jul 21 09:46:19 orbb dnsmasq[28477]: DHCPOFFER(eth0) 10.10.1.221
>> 00:16:76:90:7b:62
>> ==========================================
>>
>> regards, pete
>>
> 
> 
> 
Sorry, this slipped off my Radar.

The DHCPDECLINE is coming from the DHCP client. Essentially, what
happening above is that dnsmasq offers the client 10.10.1.229 it accepts
it, and then rejects it with a DECLINE. This is very strange DHCP client
behaviour. Once the allocated  address has been declined, when the
client comes back and asks for an address, dnsmasq has to offer is a
different one. When it's doing dynamic allocation, that's easy, when a
client is nailed down to an address, all it can do is fall-back to a
dynamic address and log the message you see. (The effect has a time-out,
after 10 minutes or so, the original nailed down address will be
available again.)

Clients normally decline an address because they've done a probe and
found that the address is already in use. In your case, the client seems
to be both accepting, and then rejecting the address, so it's probably
badly broken and all bets are off as to what it thinks it's doing.

Executive summary: the DHCP client is screwy: look there for the problem.


Cheers,

Simon.