(RADIATOR) Incorrect implementation of DHCP DISCOVER

Ian ian at gallowit.com
Thu Jun 23 06:25:56 CDT 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We use AddressAllocatorDHCP to obtain ip address's from ISC DHCP servers
configured in a failover/load balanced pair. We came across a bug in the
DHCP server that meant we failed to obtain an ip address. One of the
suggested work arounds was to set load balance max seconds to a low
number (3 seconds) and in theory this would allow the primary server to
offer an address. However, this will only work if the client is
implementing the secs bootp header field correctly. According to the
specifications an initial request should contain 0 and subsequent
retransmissions should increment this value by the time since the first
request.

Looking into the code for AddressAllocatorDHCP I can see that this is
not the case. DHCP.pm sets the secs field to 0 in assemble_packet each
time it is called. I think there should be a check here to see if the
secs field has been passed by the caller.

This is only half the story however, as AddressAllocatorDHCP only calls
build_dhcpdiscover once subsequent retransmissions use the saved packet.
I think that build_dhcpdiscover should be re-invoked before
retransmission including an updated secs value.

Any comment?

Cheers,
Ian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFCupxEzR2KhuAWJ/gRArEnAJ94GoIMM3WmBPiT1ZTogywileQHcQCfe14z
faIQT9s0XXabo3S4RAsYPnE=
=cCkr
-----END PGP SIGNATURE-----

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list