On 26/11/13 10:45, Tom Isaacson wrote:
We have an embedded Linux device using udhcpc to get a DHCP IP address and a 
Wifi access point that provides it. Originally the WAP used udhcpc as well and 
this worked fine, but in order to add DNS support we replaced udhcpc with 
dnsmasq. This works fine when I connect a laptop running Windows 7 - I see 
Discover, Offer, Request, ACK and Inform in Wireshark. But on the Linux device 
I never get a DHCP address.

If I run `dnsmasq -d` on the WAP I get this result:

     dnsmasq: started, version 2.52 cachesize 150
     dnsmasq: compile time options: no-IPv6 GNU-getopt no-MMU no-DBus no-I18N 
     dnsmasq-dhcp: DHCP, IP range --, lease time 1d
     dnsmasq: failed to access /etc/resolv.conf: No such file or directory
     dnsmasq: read /etc/hosts - 2 addresses
     dnsmasq-dhcp: DHCPDISCOVER(br0) 00:0e:91:08:1e:1c
     dnsmasq-dhcp: DHCPOFFER(br0) 00:0e:91:08:1e:1c



which is the MAC address of the embedded Linux device. But on Wireshark I'm 
only seeing Discover - the DHCPOFFER doesn't appear.

I can only see one difference between the Discover from Windows 7 and udhcpc - 
from Windows 7 the Bootp flags are set to 0x8000 (Broadcast) whereas from 
udhcpc they're set to 0x0000 (Unicast). I searched around and found this post:
Since "dhcp-broadcast" is now a feature of dnsmasq.conf I tried adding:
but this didn't make any difference. I then tried:
and this appears to work (although I've only had time to test it once).

Can anyone explain what the problem is and what I've done to fix it? Why does 
#bootp work and not bootp? I'm nervous of any fix I don't understand!

"what I've done to fix it" is easy. The first thing you tried translates as "force broadcast mode when doing BOOTP". Since you're not doing BOOTP, it makes no difference. The second attempt says "force broadcast mode when NOT doing BOOTP" and unsurprisingly works better. Best, would probably be to make it unconditional;


As to why using broadcast works, but you never see an offer otherwise, then that's more difficult. When not doing broadcast, the DHCPOFFER has to be sent to an unconfigured host which can't reply to ARP requests. To make this work dnsmasq stuffs the MAC address, IP address, device triple into the ARP table "manually", so that when it sends the DHCPOFFER to the kernel can get it to the right place. My guess is that something is going wrong in that process, but since it's worked well for over a decade, I'm not sure what. Is there anything unusual about the network interface and routing configuration on the the server box?



Dnsmasq-discuss mailing list

Reply via email to