** Changed in: ltsp (Ubuntu)
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/505916
Title:
UDHCPC not fetching lease from Windows DHCP server
To manage
Fix committed in http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-
trunk/revision/1779
** Changed in: ltsp (Ubuntu)
Status: Incomplete = Fix Committed
--
UDHCPC not fetching lease from Windows DHCP server
https://bugs.launchpad.net/bugs/505916
You received this bug notification
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
** Branch linked: lp:debian/sid/ltsp
--
UDHCPC not fetching lease from Windows DHCP server
https://bugs.launchpad.net/bugs/505916
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Changing to incomplete, the -C change will be committed if feedback
comes from both sides that it solves the problem.
** Changed in: ltsp (Ubuntu)
Status: Confirmed = Incomplete
--
UDHCPC not fetching lease from Windows DHCP server
https://bugs.launchpad.net/bugs/505916
You received this
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.
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
--
UDHCPC not fetching lease from Windows DHCP server
https://bugs.launchpad.net/bugs/505916
You received this bug notification because you are a
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
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
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?
--
UDHCPC not
I've filed LP #563056 which I suppose would be a better solution to this
problem.
--
UDHCPC not fetching lease from Windows DHCP server
https://bugs.launchpad.net/bugs/505916
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
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
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,
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
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
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.
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
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
--
UDHCPC not fetching lease from Windows DHCP server
https://bugs.launchpad.net/bugs/505916
You received this bug
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.
--
UDHCPC
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
20 matches
Mail list logo
