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
DHCP no-TFTP
dnsmasq-dhcp: DHCP, IP range 192.168.0.10 -- 192.168.0.254, 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) 192.168.0.45 00:0e:91:08:1e:1c
/etc/dnsmasq.conf:
resolv-file=/etc/resolv.conf
dhcp-range=192.168.0.10,192.168.0.254,255.255.0.0,24h
dhcp-leasefile=/var/dnsmasq.leases
dhcp-option=3
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:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q1/001797.html
Since "dhcp-broadcast" is now a feature of dnsmasq.conf I tried adding:
dhcp-broadcast=bootp
but this didn't make any difference. I then tried:
dhcp-broadcast=#bootp
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;
dhcp-broadcast
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
192.168.0.45 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?
Cheers,
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
