Bill Aitken wrote:
>
> We have a wireless segment connected of our firewall, with dnsmasq
> configured to provide DHCP addresses to the wireless clients. We've
> configured DHCP as authoritative in order to ensure clients connecting
> always get one of our addresses. However, when a client connects with
> an IP from another source DNSmasq simply shuts down with no errors in
> the log, other than martian and "wrong network" errors:
>
> martian source 192.168.2.1 from 192.168.2.100,
> on dev eth1
>
> then:
>
> Mar 14 08:52:31 taygate kernel: [53210378.550000] ll header:
> ff:ff:ff:ff:ff:ff:00:05:4e:4b:77:fd:08:06
> Mar 14 08:52:34 taygate dnsmasq[16784]: DHCPREQUEST(eth1)
> 192.168.2.100 00:05:4e:4b:77:fd
> Mar 14 08:52:34 taygate dnsmasq[16784]: DHCPNAK(eth1) 192.168.2.100
> 00:05:4e:4b:77:fd wrong network
> Mar 14 08:53:25 taygate monit[11990]: 'dnsmasq' process is not running
>
> If I give myself a manual address, then remove the authoritive directive
> I receive an address correctly.
>
> Has anyone came across this issue before?
>
Out-of-band, it turns out that this is Ubuntu 6.06 LTS and therefore
dnsmasq version 2.25. The changelog for dnsmasq 2.26 includes:
Fixed crash when attempting to send a DHCP NAK to a host
which believes it has a lease on an unknown
network. Thanks to Lutz Pressler for the bug report and
patch.
I'm 99% certain that this is the problem you are seeing. The martian
messages are a red-herring. DHCP messages from a host which believes it
is on another network are, by definition, martians. Most people don't
have the correct logging enabled to see those messages.
I guess the simplest solution is to upgrade dnsmasq, alternatively you
could file a bug with Ubuntu and have them backport the fix.
Cheers,
Simon.
