[Dnsmasq-discuss] dhclient makes repeated queries to dnsmasq when running on multiple interfaces

Simon Kelley simon at thekelleys.org.uk
Thu Aug 2 21:17:40 BST 2012


On 02/08/12 19:50, Chris Wilson wrote:
> Hi all,
>
> I'm forwarding this query here as well, as it's about a poor interaction
> between dhclient and dnsmasq, and there may be a bug in dnsmasq
> (replying to the wrong IP address for DHCP queries). Has anyone seen
> this before or can help me to solve the problem?
>
> Cheers, Chris.
>
> ---------- Forwarded message ----------
> Date: Thu, 2 Aug 2012 18:55:51 +0200 (CAT)
> From: Chris Wilson <chris at aptivate.org>
> To: dhcp-bugs at isc.org
> Subject: dhclient makes repeated queries when running on multiple
> interfaces
>
> Dear sirs,
>
> I'm writing to inquire about the status of your bug #19604, as
> unfortunately you do not have a public bug tracker that I can check.
>
> It was mentioned on this Fedora ticket:
> https://bugzilla.redhat.com/show_bug.cgi?id=469258 where David Cantrell
> wrote "Sadly, no, but I will post any updates from ISC here." That was
> three years ago.
>
> This bug appears also to be present in dhclient 3.1.3
> (dhcp3-client-2ubuntu3.3), the version in Ubuntu 10.04 (Lucid) LTS. It's
> noticeable that when I have a laptop connected using both wired and
> wireless interfaces, both configured by DHCP using Network Manager, it
> send the wireless DHCP query out of the wired interface:
>
> 16:53:03.995187 44:87:fc:0b:22:08 > 00:00:24:cd:fe:be, ethertype IPv4
> (0x0800), length 342: 192.168.128.125.68 > 192.168.128.1.67: BOOTP/DHCP,
> Request from 74:f0:6d:68:49:de, length 300
>
> Note: 44:87:fc:0b:22:08 and 192.168.128.125 are the addresses of eth0,
> the wired interface, while 74:f0:6d:68:49:de and 192.168.128.170 are the
> wireless interface:
>
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
> link/ether 44:87:fc:0b:22:08 brd ff:ff:ff:ff:ff:ff
> inet 192.168.128.125/22 brd 192.168.131.255 scope global eth0
> inet6 fe80::4687:fcff:fe0b:2208/64 scope link
> valid_lft forever preferred_lft forever
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
> link/ether 74:f0:6d:68:49:de brd ff:ff:ff:ff:ff:ff
> inet 192.168.128.170/22 brd 192.168.131.255 scope global wlan0
> inet6 fe80::76f0:6dff:fe68:49de/64 scope link
> valid_lft forever preferred_lft forever
>
> Now dnsmasq finds an existing lease and replies to the address of the
> owner of that lease, instead of the IP address that the request was sent
> from, but still using the interface and destination MAC address that the
> request was received on. I'm not sure if that's a bug, and the reason
> why dhclient appears to ignore the reply?
>
> Aug 2 16:53:03 ipad2 dnsmasq-dhcp[2003]: DHCPREQUEST(br1)
> 192.168.128.170 74:f0:6d:68:49:de
>
> Aug 2 16:53:03 ipad2 dnsmasq-dhcp[2003]: DHCPACK(br1) 192.168.128.170
> 74:f0:6d:68:49:de classmate
>
> 16:53:04.102038 00:00:24:cd:fe:be > 44:87:fc:0b:22:08, ethertype IPv4
> (0x0800), length 357: 192.168.128.1.67 > 192.168.128.170.68: BOOTP/DHCP,
> Reply, length 315
>
> Anyway, it appears that dhclient receives and ignores this reply, and
> sends another request 10-20 seconds later:
>

>
> Is there anything you need to help debug this problem further?
>

The most useful thing would be a complete description of the network 
configuration of all the actors. Are the wired and wireless interfaces 
on different networks or part of the same broadcast domain? What else is 
on that network or networks? Specifically, is there any chance that 
anything is running a DHCP relay?

  16:53:03.995187 44:87:fc:0b:22:08 > 00:00:24:cd:fe:be, ethertype IPv4
 > (0x0800), length 342: 192.168.128.125.68 > 192.168.128.1.67: 
BOOTP/DHCP, Request from 74:f0:6d:68:49:de, length 300

Rather looks like there may have been a relay involved.

What is running dnsmasq? What is the configuration of the br1 interface 
that dnsmasq is seeing requests on? Do requests from both the wired and 
wireless interfaces come that way?

Using tcdump -s 0 -w <filename> to grab complete packet dumps rather 
than the unhelpful tcpdump synopses will help too. (Probably best to 
send the capture file direct to me as an attachment, rather than posting 
it to the list.)

Any relevant dnsmasq --dhcp-host configs would be useful.


Cheers,

Simon.





More information about the Dnsmasq-discuss mailing list