LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 10-31-2002, 01:56 PM   #1
bwilliam79
LQ Newbie
 
Registered: Oct 2002
Location: Springfield, MO
Distribution: SUSE
Posts: 12

Rep: Reputation: 0
Question DHCP lease unavailable


Has anoyone come across the issue where your DHCP server makes an offer, but when the DHCPREQUEST is received, the server says the lease is unavailable? I am having problems with my DHCP server doing this very thing, and I am fairly certain what the problem is, just not how to fix it.

When the client sends the DHCPDISCOVER, it sends an option 43 (vendor-encapsulated-options), and my DHCP server reads this field to determine the machine type (using a class statement). The server responds with a DHCPOFFER, to which the client responds with a DHCPREQUEST, however, in this request, it doesn't send the option 43, so it can't be matched to the correct class. This causes the DHCP server to reject the request. The lease is written to the dhcpd.leases file after the offer is made, so I am not sure how to make this work.

Attached is my dhcpd.conf

allow booting;
allow bootp;

ddns-update-style interim;

class "TEST" {
match if (substring(option vendor-encapsulated-options, 2, 4) = 34:36:39:34);
}

subnet 192.168.0.0 netmask 255.255.255.0 {

authoritative;

option routers 192.168.0.1;
option subnet-mask 255.255.255.0;
option broadcast-address 255.255.255.1;

option nis-domain "test.com";
option domain-name "test.com";
option domain-name-servers 192.168.0.1;

option time-offset -6; # Central Standard Time
option ntp-servers 192.168.0.1;
option netbios-name-servers 192.168.0.1;

pool {
allow members of "TEST";
range 192.168.0.1 192.168.0.10;
default-lease-time 300;
max-lease-time 300;
next-server 192.168.0.1;
filename "pxelinux.0";
}

pool {
allow unknown clients;
range 192.168.0.11 192.168.0.20;
default-lease-time 21600;
max-lease-time 43200;
}
}
 
Old 11-05-2002, 07:41 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,118
Blog Entries: 54

Rep: Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785
Haven't got any experience with that, are dhcpd and client same (protocol) version?
Isn't the match sposed to be
"match if substring(option vendor-encapsulated-options, 2, 4) = 34:36:39:34;"?
Also you're using the 2nd to 4th first chars, have you tried a wider string, like 0,9?
Else as an alternative, could a match against, say hardware, do the same?
 
Old 11-05-2002, 07:57 AM   #3
bwilliam79
LQ Newbie
 
Registered: Oct 2002
Location: Springfield, MO
Distribution: SUSE
Posts: 12

Original Poster
Rep: Reputation: 0
The string I am using to match those four characters/numbers is working correctly. The problem is that the client doesn't send that same information in the DHCPREQUEST, so the server doesn't match those same four characters, thus causing the server to reject the offer. The client is running a PXE boot client. It's in the boot ROM. Unfortunately, I can't do much to change the way it works. I don't understand why the DHCP server isn't matching the transaction ID or hardware address with what it wrote to the dhcpd.conf file when it sent the DHCPOFFER. Even worse is that I had a system board failure that trashed my linux box, so I have to get it rebuilt before I can even continue. Thanks for the reply.
 
Old 11-05-2002, 08:06 AM   #4
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,118
Blog Entries: 54

Rep: Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785
Ok, but wouldn't it then be easier to match the string "PXE Client" as described in the thinclient/bootp/like that howto's?
 
Old 11-05-2002, 08:32 AM   #5
bwilliam79
LQ Newbie
 
Registered: Oct 2002
Location: Springfield, MO
Distribution: SUSE
Posts: 12

Original Poster
Rep: Reputation: 0
Yes, it would, but there will be multiple types of clients doing PXE booting, and I want these specific clients to get a different bootstrap.
 
Old 11-05-2002, 09:55 AM   #6
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,118
Blog Entries: 54

Rep: Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785
4.2.2.8. Set vendor_class_identifier
Set the vendor-class-identifier field to PXEClient in the dhcp answer. If this field is not set properly, the PXE client will ignore the answer !
Maybe wide off the mark, but could this explain why it doesn't send back a reply with VCI in it?

Last edited by unSpawn; 11-05-2002 at 09:58 AM.
 
Old 11-05-2002, 10:07 AM   #7
bwilliam79
LQ Newbie
 
Registered: Oct 2002
Location: Springfield, MO
Distribution: SUSE
Posts: 12

Original Poster
Rep: Reputation: 0
The client sends the VCI regardless. Both the DHCPDISCOVER and DHCPREQUEST contain the PXEClient string, but so does every other PXE Client broadcasting DHCPDISCOVER and DHCPREQUEST. The only thing that sets these devices apart from the others is the vendor encapsulated options which are only sent in the DHCPDISCOVER.
 
Old 11-05-2002, 10:56 AM   #8
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,118
Blog Entries: 54

Rep: Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785Reputation: 2785
Thnx for the clarification. I'll shut up now :-]
 
Old 11-05-2002, 11:03 AM   #9
bwilliam79
LQ Newbie
 
Registered: Oct 2002
Location: Springfield, MO
Distribution: SUSE
Posts: 12

Original Poster
Rep: Reputation: 0
I appreciate your help, and I am more than open to suggestions. It seems to me it's a bug in ISC's DHCP server. The server makes the offer to the client, then retracts the offer just because the client doesn't send the same message the second time. I understand why it's failing, but I don't understand why it doesn't look at the dhcpd.leases to see that it just offered that IP address to that MAC address.
 
Old 01-31-2008, 05:37 AM   #10
riccabarg
LQ Newbie
 
Registered: Jan 2008
Posts: 1

Rep: Reputation: 0
Hi everybody, I'm hitting the same problem described in this thread. Maybe in the meantime somebody get the resolution?

Thanks,
Riccardo
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Cannot obtain DHCP lease TroelsSmit Linux - Newbie 24 06-18-2005 03:32 AM
DHCP Lease Delete! kofi Linux - Networking 2 07-29-2004 07:00 PM
dhcp not obtaining lease on Slackware 10 juxstapose Linux - Networking 2 07-23-2004 07:04 PM
Renewing DHCP Lease JimKyle Linux - Networking 10 07-18-2004 06:54 PM
dhcp - get new IP when lease renewed chrisnewey Linux - Networking 0 03-30-2004 05:41 AM


All times are GMT -5. The time now is 01:48 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration