Win NT DHCP server & Linux dhcp client.

Win NT DHCP server & Linux dhcp client.

Post by Steve Snitil » Fri, 04 Sep 1998 04:00:00

I've ran into an interesting situation trying to use the DHCP client
that comes with Redhat 5.1 and the NT4.0 dhcp server. Whenever I reboot
my linux box the eventlog on the DHCP server records the issue of a NACK
for the previously assigned IP address. Even though the linux box
received the NACK it would keep the actual IP and the lease would stay
valid on the DHCP server. Oddly enough I noticed this after reading the
event log of a different NT machine which had several stop errors
stating that the requested IP address could not be assigned even though
there was still a lease on the DHCP server for the NT box and the
address had stayed the same for the past several months.

Today I decided to place a sniffer on the machines and see what is
actually happening. Unfortunately the NT machine didn't have a problem
and everything went as it should with the transaction and there were no
NACK's. I tried the same thing with the Linux box and came up with
different results:

The Linux box requested the same address it already had a lease for and
received a NACK. Netmon reported that the field option was invalid.

The options it used were:
Requested Address = nnn.nnn.nnn.nnn
Message Type = DHCP Request
Maximum DHCP Message Size = (Legnth: 2) 02 24
Parameter Request List = (Legnth: 8) 01 03 06 0c 0f 1c 2a 28
Client Class information = (Legnth: 17) 3C 11 4C 69 6E 75 78 20 32 2E 30
2E 33 34 20 69 35 38 36 (<.Linux.2.0.34.i586)

The Linux box sent out a Discover packet with the same Parameter's,
Message size, and Vendor information. The next packet the linux box sent
out had the exzact same options with a different IP that the server
suggested and the addition of a lease expiration data and server
identifer. The packet was label as malformed becuase of the field option
and no nack was sent.

So here's what I trying to find out... Does the NT dhcp server support
the Client Class information option? If not is this at all related to
the NACK's that are being issued for no appearent reason? Does anyone
have any hypothesis about why the pattern suddenly occured and then
dissapeared on the NT box and looks to be displaying the same
unreliability on the Linux Box?

Any help in figuring this one out would be greately appreciated,