[Dnsmasq-discuss] Missing DHCPNAKs

Tue Aug 23 13:10:40 BST 2005

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.

Cheers,
George.

PS.
Please let me know if I'm wrong and/or there are some other potential reasons.