DHCP Request Cycle can get caught in infinite loop

FYI, the stop/delete/start process worked -- lease was renewed properly. For anyone following along, in a terminal, type:

$ sudo /etc/init.d/dnsmasq stop
$ sudo nano /var/lib/misc/dnsmasq.leases
   (or whatever command you want to use to modify your lease file -- find the line with the old lease, delete it, then save the file)
$ sudo /etc/init.d/dnsmasq start

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

* Is this reproducible?
* If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

I think the way it occurred was that I had a dual-boot machine (WinXP/Ubuntu 8.04) that had originally signed up for the lease under Windows, then was shut off and booted into Linux, where it couldn't connect, then booted back into Windows, where I observed the issue while diagnosing.

The option had not yet been set to instruct Windows machines to drop the lease when shutting down, so it may simply have been that the lease was still active. It does not seem to be happening now -- booting in either mode gets the desired assignment.

I don't really want to attempt to reproduce it since I have everything working the way I want it to now, but I wanted to report this since the DHCP dialogue seemed strange. If I find a way to reproduce it, I will report back.

FYI -- I'm seeing a repeat of this behavior under slightly different circumstances. In this case, I have a machine that was set up with Ubuntu 8.04 and was issued a lease. I rebooted the machine with an install disk for another distribution (it's Fluxbuntu 7.10 RC, which uses the 'alternate' text-based install type). When the installation gets to network autoconfiguration, it fails, and I see the same DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPNAK cycle as described originally.

Once again, there is an existing entry in the leases file associated with the MAC address for this machine's network card, which seems to be part of the problem. Perhaps it's the combination of parameters I've fed to dnsmasq?

The conf file has an entry:

  dhcp-host=foo

which, as I understand it, tells it to check /etc/hosts to get a standard IP assignment. In /etc/hosts, there's:

 192.168.X.X foo

only with real numbers instead of Xs, obviously. Currently in the leases file, there's a line:

  1234411797 11:22:33:44:55:66 192.168.X.X foo *

only with the real MAC address and IP, obviously.

I have a hunch that the cause is something like this:

 1. dnsmasq gets DHCPDISCOVER packet
 2. dnsmasq looks at originating MAC and checks leases file to see if it's in there
 3. dnsmasq finds line with same MAC and issues DHCPOFFER with associated IP address from lease file
 4. client does what's expected and makes DHCPREQUEST with that IP
 5. dnsmasq now takes a look at the client's machine name, and sees that the requested address is "reserved" for that name per /etc/hosts
 6. dnsmasq replies with DHCPNAK because doesn't realize it just sent out that address as available

It should be relatively easy to replicate this by obtaining a lease, changing hostname, then requesting a new lease.

I'm not the programmer (or even *a* programmer), but the best way to fix this would seem to be to not make the DHCPOFFER of an IP address in the /etc/hosts mappings unless the DHCP client's machine name is the one associated with it.

Let me know if I can do any further testing or provide additional information.

Yes, I wouldn't be surprised if your hunch was correct. That's a rather unusual combination of parameters :)

Simon Kelley here: I'm the principal author of dnsmasq.

I have a couple of questions for FactTech:

1) Was the text message in the DHCPNAK log entry the same as the initial reporter's ("address reserved")?
2) Is there any other dhcp-host line in the dnsmasq configuration which might apply to the host in question?

If you can reproduce the bug easily, I'd really like to see the result of turning on "log-dhcp" in dnsmasq.conf

Cheers,

Simon.

I think I've deduced what is happening here. The combination of the dhcp-host line and the /etc/hosts entry generates the equivalent of

dhcp-host=name,192.168.X.X

When you run Ubuntu, the DHCP requests send the name, so dnsmasq find and uses this line, and all is good.

When the machine was rebooted with the install disk, the name is not sent. At DISCOVER time, the 192.168.X.X address gets offered, because that machine (based on MAC address) already has a lease on the that address. At REQUEST time, the address is disallowed, becasue it's been set as a static address for another machine (remember, no name to match the dhcp-host line.)

This hasn't been seen often, because most people nail down static addresses using the MAC address.

Given that, this should be fairly easy to fix: I believe that

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

will do the trick.

Cheers,

Simon.

Thanks Simon ! I guess we'll wait for the 2.48 release, then :)

2.48 release is now available and includes the fix for this bug.

Cheers,

Simon.

Simon:
Good news. Do you plan to push that release to Debian soon ?

Thierry Carrez wrote:
> Simon:
> Good news. Do you plan to push that release to Debian soon ?
>

It went last night, so should be in unstable very soon, if not already.

Cheers,

Simon.

2.48-2 is in Karmic