[Dnsmasq-discuss] Missing DHCPNAKs

Tue Aug 23 14:33:23 BST 2005

Gyorgy Farkas wrote:
> On Monday 22 August 2005 02:50 pm, Simon Kelley wrote:
> 
>>Dan Shechter wrote:
>>
>>>Hi,
>>>I've been trying to use dnsmasq in a wireless access point (802.11
>>>a/b/g) environment.
>>>
>>>In these types of environments it is very common for:
>>>1. Clients to use windows machines
>>>2. Clients to roam in from a different wireless network.
>>>
>>>I'm encountering a scenario where DNSMASQ is receiving a DHCPREQUEST for
>>>renewal from
>>>A client which is "roaming" in from a previous network which is a
>>>network which
>>>DNSMASQ's configuration file has no pool for.
>>>
>>>There for DNSMASQ reports the error message from rfc2131.c:185:
>>>"no address range available for DHCP request..." and returns.
>>>
>>>Other wireless routers/access points are returning DHCPNAK messages in
>>>this situation.
>>
>>Dan, please could you send me (off list) a packet dump of a DHCPREQUEST
>>which provokes this behaviour? I have a fairly good idea what's
>>happening here, but I'd like to be sure I understand what's going on.
>>
> 
> 
> Excuse me for take part in your conversation.
> 
> 
> I can play that encountered "wireless" scenario on a "wired" environment too.
> Most probably this or something very similar can happen during that "timeout"
> 
> This is a Windows XP Home edition PC on its original network
> ---[eth0 router1 eth1 192.168.1.1]---[sw]---[WinXP 192.168.1.150]
> 
> The  *running*  Win XP PC with not expired lease is moved to another network
> intentionally, so it lost the original network connection.
> ---[eth0 router2 eth1 10.42.42.1]---[sw]---[WinXP 192.168.1.150]
> 
> 
> IF (the physical layer of) Windows detects this situation,
> THEN checks the network/DHCP server
> assuming that it's still located on the same network as before
> (does it try to re-connect or simply try to get its previous IP address ???)
> 
> (the first field is the time in seconds)
> 07.987503 arp who-has 192.168.1.1 tell 192.168.1.150
> 09.418483 arp who-has 192.168.1.1 tell 192.168.1.150
> 10.419617 arp who-has 192.168.1.1 tell 192.168.1.150
> 11.421779 192.168.1.150.68 > 255.255.255.255.67:  xid:0x3845ec4f DHCP:REQUEST
> 16.421833 192.168.1.150.68 > 255.255.255.255.67:  xid:0x3845ec4f DHCP:REQUEST
> 24.421851 192.168.1.150.68 > 255.255.255.255.67:  xid:0x3845ec4f DHCP:REQUEST
> 
> no reply *** Automatic Private IP Addressing (APIPA) in action ***
> 
> 40.746614 arp who-has 169.254.83.90 tell 169.254.83.90
> 40.746676 169.254.83.90 > 224.0.0.22: igmp
> 41.454582 169.254.83.90 > 224.0.0.22: igmp
> 41.721404 arp who-has 169.254.83.90 tell 169.254.83.90
> 42.721534 arp who-has 169.254.83.90 tell 169.254.83.90
> 43.730936 169.254.83.90 > 224.0.0.22: igmp
> 43.752229 169.254.83.90.1033 > 239.255.255.250.1900:  udp
> 43.756512 169.254.83.90 > 224.0.0.22: igmp
> 43.763163 169.254.83.90.1036 > 239.255.255.250.1900:  udp
> 43.798341 169.254.83.90.137 > 169.254.255.255.137:  NBT
> 44.457977 169.254.83.90 > 224.0.0.22: igmp
> 44.548344 169.254.83.90.137 > 169.254.255.255.137:  NBT
> 45.298687 169.254.83.90.137 > 169.254.255.255.137:  NBT
> (the above APIPA and NBT "session" can be much longer of course ;-)
> 
> the client continues to look for a DHCP server
> (sooner or later ;) now ... and every five minutes later on
> 
> 45.766976 0.0.0.0.68 > 255.255.255.255.67:  xid:0xbe585b50 DHCP:DISCOVER
> 45.769239 10.42.42.1.67 > 255.255.255.255.68:  xid:0xbe585b50 DHCP:OFFER
> 45.770378 0.0.0.0.68 > 255.255.255.255.67:  xid:0xbe585b50 DHCP:REQUEST
> 45.772886 10.42.42.1.67 > 255.255.255.255.68:  xid:0xbe585b50 DHCP:ACK
> 
> 46.053916 arp who-has 10.42.42.171 tell 10.42.42.171 (client)
> 46.722046 arp who-has 10.42.42.171 tell 10.42.42.171 (client)
> 
> ... and so on
> 
> ---[eth0 router2 eth1 10.42.42.1]---[sw]---[WinXP 10.42.42.171]
> 
> (router2 was an old P 90 mini Linux box with an "authoritative" dnsmasq-2.22)
> 
> ------------------------------------------------------------------------------
> 
> I think users quite easy avoid the above situation on wireless environment too
> if turn off their Windows XP PC (or launch an 'ipconfig /release' command)
> before move it to another network intentionally.
> 
> And - at the next start up - the Windows XP DHCP client will send  either
> 
> 0.0.0.0.68 > 255.255.255.255.67:  DISCOVER (if its lease has expired)  or
> 0.0.0.0.68 > 255.255.255.255.67:  REQUEST (if its lease hasn't expired)
> 
> instead of those
> 
> previous_IP_address.68 > 255.255.255.255.67:  REQUEST
> 
> ------------------------------------------------------------------------------
> 
> What about Dan's fix/patch ?  Well, I don't know really.
> 
> I think - maybe he has got a wireless DHCP server
> which can send NAK(s) to the all wireless neighbourhood too.
> 
> 

Gyorgy,

Thanks for this information, which confirms my current theory about 
what's going on. What I think happens is that loss of network carrier 
causes Win XP to move its DHCP client into REBINDING state (see RFC 2131 
for details of the DHCP state machine.) The DHCP REQUESTs sent in 
rebinding state include the clients current idea of its IP address in 
the ciaddr field, and dnsmasq uses this in preference to the physical 
interface the packet arrives on to determine where the machine is. (This 
is needed for machines which are not on the same subnet as the DHCP 
server, which use a DHCP relay: rfc2131 has a good discussion.)

For a machine which has just moved from another network, the ciaddr 
address will be on a network for which there is no DHCP range, hence 
dnsmasq will reject it with the "no address range" error, and never get 
around to sending a NAK.

Forcing the DHCP client into REBINDING state is rather odd, INIT-REBOOT 
would be more appropriate, and avoid this problem, but this is Microsoft 
we're discussing. If someone could grab the relevant packet, and send it 
to me I could easily check my theory.

Assuming I'm correct, the fix is easy, if a range-search on the ciaddr 
fails, fall back to range-search on the physical interface.

Cheers,

Simon.