Hello Everyone,
I'm running a dhcp server on CentOS 4.4. It's providing IPs and remote booting for a number of thin clients.
I've recently had problems rebooting a few thin clients. Here is the error I've been seeing:
Jan 16 14:16:45 at01 dhcpd: DHCPRELEASE from 00:40:63:e5:71:4f specified requested-address. Jan 16 14:16:45 at01 dhcpd: DHCPRELEASE of 10.1.1.150 from 00:40:63:e5:71:4f via eth0 (not found)
Depending on the thin client, the MAC and the IP changes. Otherwise, the errors are all the same.
The effect on the thin client end is that it doesn't get an IP, and so it doesn't boot. The usual remedy is to unplug/plug-in the cat5 cable at the thin client, or to move the thin client to another network drop.
This has me thinking there's a problem with the cat5 cabling (the office is going through a major renovation). But, I'm not 100% that is the case. It could be a problem with the dhcp server.
I don't have easy access to that office - it's remote, and I'm only out there once every few months. It's why I want to make sure it's not a software problem first.
At the moment I have no clue what's going on. My searching with google hasn't turned up anything useful.
I'd appreciate any comments/suggestions.
Regards,
Ranbir
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Kanwar Ranbir Sandhu Sent: Tuesday, January 16, 2007 2:28 PM To: CentOS mailing list Subject: [CentOS] dhcpd errors
Hello Everyone,
I'm running a dhcp server on CentOS 4.4. It's providing IPs and remote booting for a number of thin clients.
I've recently had problems rebooting a few thin clients. Here is the error I've been seeing:
Jan 16 14:16:45 at01 dhcpd: DHCPRELEASE from 00:40:63:e5:71:4f specified requested-address. Jan 16 14:16:45 at01 dhcpd: DHCPRELEASE of 10.1.1.150 from 00:40:63:e5:71:4f via eth0 (not found)
Depending on the thin client, the MAC and the IP changes. Otherwise, the errors are all the same.
The effect on the thin client end is that it doesn't get an IP, and so it doesn't boot. The usual remedy is to unplug/plug-in the cat5 cable at the thin client, or to move the thin client to another network drop.
This has me thinking there's a problem with the cat5 cabling (the office is going through a major renovation). But, I'm not 100% that is the case. It could be a problem with the dhcp server.
I don't have easy access to that office - it's remote, and I'm only out there once every few months. It's why I want to make sure it's not a software problem first.
At the moment I have no clue what's going on. My searching with google hasn't turned up anything useful.
I'd appreciate any comments/suggestions.
If you are using Cisco switches make sure that you have "spanning-tree portfast" set for each PC/thinclient port, otherwise the spanning-tree protocol negotiation phase might step on the DHCP offers.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
On Tue, 2007-01-16 at 14:36 -0500, Ross S. W. Walker wrote:
If you are using Cisco switches make sure that you have "spanning-tree portfast" set for each PC/thinclient port, otherwise the spanning-tree protocol negotiation phase might step on the DHCP offers.
Ah, yes, the infamous spanning-tree problem. That stupid thing has driven quite a few people nuts. In my case it's not so simple. The switches aren't by Cisco, and they're unmanaged.
Also, everything was working flawlessly before - I don't know what's changed besides the new cabling.
I wonder if it could be a routing problem. I'll have to look into it more.
Regards,
Ranbir
Kanwar Ranbir Sandhu spake the following on 1/16/2007 1:41 PM:
On Tue, 2007-01-16 at 14:36 -0500, Ross S. W. Walker wrote:
If you are using Cisco switches make sure that you have "spanning-tree portfast" set for each PC/thinclient port, otherwise the spanning-tree protocol negotiation phase might step on the DHCP offers.
Ah, yes, the infamous spanning-tree problem. That stupid thing has driven quite a few people nuts. In my case it's not so simple. The switches aren't by Cisco, and they're unmanaged.
Also, everything was working flawlessly before - I don't know what's changed besides the new cabling.
I wonder if it could be a routing problem. I'll have to look into it more.
Regards,
Ranbir
I had a similar problem with some unmanaged switches and some cabling. I had to pull the power on all the switches and re-plug them in. The moving around of stuff must have corrupted their mac caches.
On Tue, 2007-01-16 at 15:25 -0800, Scott Silva wrote:
I had a similar problem with some unmanaged switches and some cabling. I had to pull the power on all the switches and re-plug them in. The moving around of stuff must have corrupted their mac caches.
Thanks for the suggestion, but it didn't work. I've got some pretty irate users now - understandable really.
I'm using Thinstation 2.1.3 to boot the thin clients. This appears to work flawlessly. I've been testing Thinstation 2.2, and I've noticed that when I boot a thin client with the test Thinstation 2.2. images, the thin client won't get an IP on the second reboot. It seems like Thinstation 2.2 is triggering something - I just don't know what.
It doesn't make sense. I don't know why the PXE boot would fail after a successful reboot. I still haven't found what this means:
dhcpd: DHCPRELEASE of 10.1.1.155 from 00:40:63:e5:77:1a via eth0 (not found)
More trouble shooting...
Regards,
Ranbir
It doesn't make sense. I don't know why the PXE boot would fail after a successful reboot. I still haven't found what this means:
dhcpd: DHCPRELEASE of 10.1.1.155 from 00:40:63:e5:77:1a via eth0 (not found)
More trouble shooting...
Could you provide us with your dhcpd.conf file (minus any sensitive info)? It may be something in the config.
On Wed, 2007-01-17 at 10:46 -0500, Jim Perrin wrote:
It doesn't make sense. I don't know why the PXE boot would fail after a successful reboot. I still haven't found what this means:
dhcpd: DHCPRELEASE of 10.1.1.155 from 00:40:63:e5:77:1a via eth0 (not found)
More trouble shooting...
Could you provide us with your dhcpd.conf file (minus any sensitive info)? It may be something in the config.
Sure. Here it is (I don't know if that's going to be legible after it's posted):
ddns-update-style none; default-lease-time 8640; # 6 days max-lease-time 8640; one-lease-per-client true; option option-128 code 128 = string; option option-129 code 129 = text;
subnet 10.1.1.0 netmask 255.255.255.0 { range 10.1.1.170 10.1.1.180; next-server 10.1.1.240; option subnet-mask 255.255.255.0; option broadcast-address 10.1.1.255; option routers 10.1.1.254; option domain-name "blah.blah"; option domain-name-servers 10.1.1.240; #option ntp-servers 10.1.1.240;
if substring (option vendor-class-identifier, 0, 9) = "PXEClient" { filename "ts-2.1.3/pxelinux.0"; #filename "ts-2.2/pxelinux.0"; } #else if substring (option vendor-class-identifier, 0, 9) = "Etherboot" { # #filename "ts-2.1.3/thinstation.nbi"; # filename "ts-2.2/thinstation.nbi"; # }
host ws001 { hardware ethernet 00:40:63:E5:71:4F; fixed-address 10.1.1.150; } host ws002 { hardware ethernet 00:40:63:E5:75:8C; fixed-address 10.1.1.151; } host ws003 { hardware ethernet 00:40:63:E5:75:8E; fixed-address 10.1.1.152; } host ws004 { hardware ethernet 00:40:63:E5:76:E7; fixed-address 10.1.1.154; } host ws005 { hardware ethernet 00:40:63:E5:77:1A; fixed-address 10.1.1.155; } host ws006 { hardware ethernet 00:40:63:E5:73:FE; fixed-address 10.1.1.156; } host ws007 { hardware ethernet 00:40:63:E5:74:06; fixed-address 10.1.1.157; } host ws008 { hardware ethernet 00:40:63:E5:75:39; fixed-address 10.1.1.158; } host ws009 { hardware ethernet 00:40:63:E5:76:4A; fixed-address 10.1.1.159; } }
After posting this, I wonder if the "one-lease-per-client" parameter is the cause of the problem.
Regards,
Ranbir
On Wed, 2007-01-17 at 11:04 -0500, Jim Perrin wrote:
After posting this, I wonder if the "one-lease-per-client" parameter is the cause of the problem.
I believe that is the cause for the release not found message you're getting, yes.
Success! Removed the line and the thin clients have rebooted properly multiple times now. Thinstation 2.2 is working great.
I didn't think anything was wrong with the dhcpd.conf file. I went over it numerous times, but it all looked fine. Only after posting it here did I suspect the "one-lease-per-client" option. I'm still curious why it was okay before.
Anyway, thanks for the help Jim, and everyone else.
Regards,
Ranbir
-
Jim Perrin -
Kanwar Ranbir Sandhu -
Ross S. W. Walker -
Scott Silva