[Dnsmasq-discuss] using DHCP with virtual interfaces

[Tom Metro]

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.

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?)

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?

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/