bug in DHCP client and/or DHCP server implementation

[Markus Baur]

Hi,
I just came across this interesting problem with Nortel voice-over-IP 
phones in our redundant two server  (dhcpd 3.0.1rc11 on Solaris8) setup. 
As far as I can tell from the release notes, the problem should also 
occur with 3.0.1rc12. I am not quite sure whose fault it is, but I 
believe both are at fault or at least could have avoided the deadlock.

Here is the gist of what happens (full version in the attached tcpdump 
output):

1.) Client broadcasts a DHCPDISCOVER

2.) Server1 doesn't reply because the client belongs to his peer (load 
balance to peer nscpdhcp)

3.) Server2 replies with a DHCPOFFER

4.) Client broadcasts a DHCPREQUEST

Q: Why does the client use broadcast here? But as far as I can tell this 
is still according to spec.

5.) Server1 replies with a DHCPNACK

Q: Why does server1 bother to answer when this is his peer's client and 
the DHCPREQUEST carries the peer's SID?

6.) Server2 replies with a DHCPACK

7.) Client sees the DHCPNACK and decides the given IP address is of no 
use and restarts

Q: Why doesn't the client ignore the NACK when it carries the wrong 
server's SID? The SIDs in the OFFER and the NACK do not match!

At this point I'm not really sure whose fault it is, but getting the 
Nortel code fixed will probably be difficult and won't be of immediate 
use as the phones need to establish a DHCP connection to get their 
firmware upgraded. So I'm thinking my best option will probably be to 
see if I can hack the server code to make the failover server not send 
out these NACK packets.

Any other ideas?

Thanks,
Markus





-- Attached file included as plaintext by Ecartis --
-- File: voip-probs.txt

20:48:01.661159 (tos 0x0, ttl 64, length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, length: 548
	Request, xid:0xac9be678, flags:0x8000
	  Client Ethernet Address: 00:60:38:dd:9f:36
	  Vendor-rfc1048:
	    DHCP:DISCOVER
	    MSZ:1456
	    VC:"Nortel-i2004-A^@"
	    PR:LT+RN+RB+SM+DG+VO+T128+T144+T157+T191+T251
20:48:01.663497 (tos 0x1,ECT(1), ttl 64, length: 328) 10.169.139.2.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, length: 300
	Reply, hops:2, xid:0xac9be678, flags:0x8000
	  Your IP: 10.169.139.84
	  Server IP: 10.169.8.6
	  Gateway IP: 10.169.139.2
	  Client Ethernet Address: 00:60:38:dd:9f:36
	  Vendor-rfc1048:
	    DHCP:OFFER
	    SID:10.169.8.6
	    LT:3600
	    RN:1800
	    RB:3150
	    SM:255.255.255.128
	    DG:10.169.139.1
20:48:01.671542 (tos 0x0, ttl 64, length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, length: 548
	Request, xid:0xac9be678, flags:0x8000
	  Client Ethernet Address: 00:60:38:dd:9f:36
	  Vendor-rfc1048:
	    DHCP:REQUEST
	    RQ:10.169.139.84
	    SID:10.169.8.6
	    MSZ:1456
	    VC:"Nortel-i2004-A^@"
	    PR:LT+RN+RB+SM+DG+VO+T128+T144+T157+T191+T251
20:48:01.673438 (tos 0x1,ECT(1), ttl 64, length: 328) 10.169.139.2.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, length: 300
	Reply, hops:2, xid:0xac9be678, flags:0x8000
	  Server IP: 10.169.9.6
	  Gateway IP: 10.169.139.2
	  Client Ethernet Address: 00:60:38:dd:9f:36
	  Vendor-rfc1048:
	    DHCP:NACK
	    SID:10.169.9.6
	    MSG:"requested address not available"
20:48:01.738418 (tos 0x1,ECT(1), ttl 64, length: 328) 10.169.139.2.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, length: 300
	Reply, hops:2, xid:0xac9be678, flags:0x8000
	  Your IP: 10.169.139.84
	  Server IP: 10.169.8.6
	  Gateway IP: 10.169.139.2
	  Client Ethernet Address: 00:60:38:dd:9f:36
	  Vendor-rfc1048:
	    DHCP:ACK
	    SID:10.169.8.6
	    LT:3600
	    RN:1800
	    RB:3150
	    SM:255.255.255.128
	    DG:10.169.139.1