[Dnsmasq-discuss] using DHCP with virtual interfaces

[Simon Kelley]

Tom Metro wrote:
> I'm trying to obtain an address via DHCP (from Dnsmasq 2.45-1~bpo40+1 on 
> Debian) for a virtual interface on an Ubuntu server. This is failing to 
> work due a bug in ifconfig (see 
> https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/351378 ) and I've 
> been trying to hack around the problem using an alternate DHCP client, 
> udhcpc (instead of dhcp3's dhclient). When I invoke it, I get:
> 
> # udhcpc --hostname=indianpoint --interface=eth0:0
> udhcpc (v0.9.9-pre) started
> SIOCSIFFLAGS: Cannot assign requested address
> Sending discover...
> Sending select for 192.168.0.203...
> Received DHCP NAK
> Received a NAK: address reserved
> Sending discover...
> Sending select for 192.168.0.203...
> Received DHCP NAK
> [...etc...]
> 
> (The SIOCSIFFLAGS is produced by udhcpc's deconfig script which tries to 
> pass an address of 0.0.0.0 to ifconfig, which triggers the above 
> mentioned bug, but I believe it is harmless here and can be ignored.)
> 
> In a Dnsmasq config file I have:
> dhcp-host=mythtv,192.168.0.203,infinite
> 
> which works fine to obtain an address for the primary interface on the 
> Ubuntu server. My expectation was that when Dnsmasq was presented with 
> an alternate hostname it would not match the above rule, and instead 
> issue a new IP address from the dynamic pool.

I'm pretty sure that this is an instance of 
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/327703

There's an explanation of the bug there.
> 
> When that failed to work, I tried adding an explicit rule for the 
> alternate host name:
> dhcp-host=indianpoint,192.168.0.204,infinite
> 
> and got the same result. I also tried specifying a client ID instead of 
> and in addition to a hostname, with the same result.
> 
> I haven't confirmed with a packet sniffer that udhcpc is actually 
> sending the hostname, but I've sifted through the source, and it does 
> appear to be including the hostname as an option in the DHCPDISCOVER 
> packet.
> 
> It's then getting back a DHCPOFFER from Dnsmasq containing the IP 
> address already assigned to the primary interface. udhcpc then takes the 
> given address, puts it into a DHCPREQUEST, and gets back a DHCPNAK from 
> Dnsmasq saying the address is reserved. And then the cycle repeats...
> 
> On the server running Dnsmasq, this is logged (slightly edited):
> 
> dnsmasq[26456]: DHCPDISCOVER(eth0) 00:04:...:d1:33
> dnsmasq[26456]: DHCPOFFER(eth0) 192.168.0.203 00:04:...:d1:33
> dnsmasq[26456]: DHCPREQUEST(eth0) 192.168.0.203 00:04:...:d1:33
> dnsmasq[26456]: DHCPNAK(eth0) 192.168.0.203 00:04:...:d1:33 address 
> reserved
> 

> (On a side note, it'd be great if Dnsmasq's logging could be enhanced to 
> include some of the identifying information supplied by the client, an 
> indication of what rule Dnsmasq used to determine the assigned IP 
> address, and an indication of whether Dnsmasq is receiving or sending 
> the packets. Perhaps there's a debug mode that provides this?)

log-dhcp will dump a lot of extra information. DHCPOFFER, DHCPACK and 
DHCPNAK are _sent_ by dnsmasq, every other packet type is sent by the 
client.

> 
> So I'm wondering if having the MAC address for the client in Dnsmasq's 
> cache results in a short circuit behavior, bypassing the normal rules 
> for determining what IP address gets assigned.
> 
> I see there are a couple of FAQ entries that discuss how a client ID can 
> be used to override the default assignment that would occur via MAC 
> address, so it seems it ought to work as I was expecting.
> 
> I'm also wondering if it is correct for Dnsmasq to be handing out a 
> reserved address in an offer packet. Understandable when a client 
> reboots after a crash, Dnsmasq will get a DHCPDISCOVER from a machine 
> with an active lease, and its desirable to hand it back the same IP 
> address. But then how does it recognize that the address is still 
> reserved elsewhere? Is it probing the network? Is it because he 
> host/client identifier didn't match?

You've spotted the essence of the problem, it's not appropriate.

It would be great if you could test

http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.48test9.tar.gz

and check that this fixes things. That's a source tarball, if you'd 
rather have a Debian package, give me a shout.


Cheers,

Simon.


> 
>  -Tom
>