UDHCPC not fetching lease from Windows DHCP server

Can you please provide more details (windows server version, ubuntu version, ltsp version)

I had an issue, with my setup that used a windows dhcp server, where it would receive random tftp timeouts.

The issue was that the thin clients were trying to use the windows dhcp server for their tftp server, instead of the ltsp server.

The final fix was to setup ProxyDHCP, found the guide here: https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP

Hi

I'm running Ubuntu 9.10 with all the latest updates (LTSP version 5.1.90-0ubuntu3), using a Windows 2003 RC1 server as the DHCP.

Ubuntu 8.10 and 9.04 worked fine with the Windows DHCP server, upgraded to 9.10 and it couldn't even fetch an IP address from the Windows DHCP server.

robanon,

Can you try it with a non-blank but specified ID, like: -c "LTSP-i386"

I would like to see us use the client ID to identify LTSP clients to the DHCP server

-Gadi

In my case, it was completely impossible to get a DHCP lease - not even the first (and only) terminal. The context is a large network with (I suppose) Windows DHCP servers. It took me a while to get to the solution indicated in the bug report.

Removing -c '' from the script solves the problem. Now I tested -c "LTSP-i386" and found that it works, too.

While talking about client ID, I would like to draw your attention to a line above the udhcpc call:

clientid_param=${clientid:+"-r $clientid"}

What I dislike is the inconsistency that the kernel command-line parameter "clientid" is used for udhcpc parameter "Request IP address".

-Kai

> clientid_param=${clientid:+"-r $clientid"}
> What I dislike is the inconsistency that the kernel command-line parameter "clientid" is used for udhcpc parameter "Request IP address".

Why do you dislike that?
That was put there intentionally, to allow people with DHCP problems to specify either an empty client id, or PXEClient, or MSFT5.0, or LTSP-i386 or whatever else their specific environment required.
The clientid was later on forced to '' to avoid duplicate leases (one for PXE and one for udhcpc).

I believe that clientid_param should be put to use again, i.e. make clientid="''" by default, but allow it to be overriden by a kernel command line parameter, so that by default we avoid duplicate leases, but people with Windows DHCP servers can set clientid="MSFT5.0" in pxelinux.cfg/default so that they get the same lease as in Windows.

A fix for this was committed in http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/1698
clientid continues to be empty by default,
but it's now possible to specify a different clientid from the kernel command line in pxelinux.cfg/default.

It'd be nice if all affected sides can verify that this works for them.

Kai, I just saw what you said, thanks, it was a bug, but I removed that part of the code as now clientid is always specified, even if empty.

Hi Gadi

I've changed the UDHCP client ID to "LTSP-i386" and the LTSP clients continued to work.

My concern with making the client ID a kernel parameter is that its very unlikely that anyone would think to have to add an ID to the kernel parameters in order to be able to boot their Ubuntu thin clients from a Windows DHCP server.

My guess is that unless this change is very well documented it will cause many hours of frustration for the unlucky people that happen have Windows DHCP servers.

Regards,
Robert

Hi Gadi,

I share Robert's concerns. In fact, it took me hours to find out why udhcpc is normally working but not with LTSP. IMO, most DHCP setups rely on MAC address only, and udhcpc is working fine here unless forced to send an empty ID.

After trying to find out what the client ID is good for, I don't see the point of specifying an empty client ID as default. Clients are required to have unique IDs. (It's interesting to see that my clients are working now although they are sending the same ID.)

-Kai

This bug was fixed in the package ltsp - 5.2.1-0ubuntu1

---------------
ltsp (5.2.1-0ubuntu1) lucid; urgency=low

  * New upstream bugfix release (5.2.1)
   * Fix plymouth and VT switch in Ubuntu
   * Reduce and improve VT switching
   * Disable LOCALDEV for fat clients
   * Fix ConsoleKit/PolicyKit support for Fat clients
   * Don't quote the clientid in udhcp (fix Windows DHCP)
   * Fix VT switching (LP: #533964)
   * Set HOME and SHELL env variables for shell sessions
   * Allow clientid for udhcpc to be passed as parameter (LP: #505916)
   * Fix call to unavailable functions in init scripts
   * Quiet down the scripts output and improve readability
   * Fix /etc/mtab so mountall doesn't complain
   * Hide reboot and shutdown menus for Fat clients
   * Fix screensaver for Fat clients
   * Cleanup ltsp-update-sshkeys usage
   * Properly separate tftppath in ltsp_nbd (LP: #238010)
 -- Stephane Graber <email address hidden> Sun, 14 Mar 2010 10:38:40 -0400

I tried using a cisco 876 router as the DHCP server today and had the same problem, so I had to use the clientid kernel parameter to work around it.

Isn't there any other way to prevent dhcp3-server from assigning 2 leases per client, so that we can drop the clientid='' hack?

I've filed LP #563056 which I suppose would be a better solution to this problem.

Reopening, because setting clientid in pxelinux.cfg/default is not an acceptable solution. The DHCP RFC states that the clientid should be unique on the local network, and not doing so causes serious problems with certain RFC-compliant dhcp servers.

The current udhcp package is ancient (>5 years old) and doesn't have the necessary "--clientid-none" switch .
The udhcp codebase has been moved to busybox. That newer udhcpc does have the --clientid-none switch (line 165 in http://git.busybox.net/busybox/tree/networking/udhcp/dhcpc.c?h=1_16_stable&id=53283adb24765a7afb4d6298661c3c1a8d6f5601)

So as soon as that new udhcp package lands in Ubuntu (https://bugs.launchpad.net/ubuntu/+source/udhcp/+bug/566845), we can drop --clientid completely and start using -C instead, which should be a proper solution to this bug report.

I found with ltsp-server version 5.2.1-0ubuntu9 on Ubuntu 10.4 I still needed to remove the "-c" option because when the clientid was specified as a kernel parameter the client did receive an IP address but was not able to connect to the nbd-server?

To rebuild the initrd RAMDISK imagine I needed to use the -H (newc) option to cpio otherwise the image would not load.

False alarm, the client being unable to connect to the NBD server was actually related to this problem:

https://bugs.launchpad.net/ltsp/+bug/589034

The new udhcp package that supports the -C (no client identifier) switch landed in Maverick, and it can also be installed in Lucid without modifications.

So it'd be nice if both affected sides (=the ones using the Windows DHCP server and the ones using dhcp3-server) tried the following solution. If it works for everyone, it could then be committed upstream.
(I'm not using udhcpc at all so I can't test myself, I'm just trying to help in finding a correct solution for this bug).

 * Download and install the new udhcpc .deb from the "Builds" section in this page:
https://launchpad.net/ubuntu/+source/busybox/1:1.15.3-1ubuntu1
For example, for i386 chroots the necessary file is
https://launchpad.net/ubuntu/+source/busybox/1:1.15.3-1ubuntu1/+build/1858801/+files/udhcpc_1.15.3-1ubuntu1_all.deb
(I've also uploaded it to https://launchpad.net/~alkisg/+archive/ppa if someone prefers installing from a ppa instead).

 * In /opt/ltsp/i386/usr/share/initramfs-tools/scripts/init-premount/udhcp, change the following line:
        if udhcpc -n -c "$clientid" -s /tmp/dhcp-script.sh -i $i $hostname_param $ip_param >/dev/null 2>&1; then
to
        if udhcpc -n -C -s /tmp/dhcp-script.sh -i $i $hostname_param $ip_param >/dev/null 2>&1; then

* Then, run
        sudo chroot /opt/ltsp/i386 update-initramfs -u && sudo ltsp-update-kernels
reboot the client and see if the problem is solved.

Changing to incomplete, the -C change will be committed if feedback comes from both sides that it solves the problem.

Helped me out with dhcpd + ltsp 5. I actually updated to maverick, applied changes and voila! Now even clients that never booted (realtek network cards) boot up fine. The dhcp server is the one embedded in PFSense. Before that it would fail discover 2-3 times or even stopped trying at 4 or 5.

So yes, this fix works wonders.

Fix committed in http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/1779