DHCP code in 2.0.4+

[Karl Auer]

On Tue, 2009-06-09 at 09:24 +0200, Alan DeKok wrote:
>   Umm.... no.  It means they protocol was designed from an incomplete
> problem statement, and an incomplete knowledge of the system.  That
> isn't good engineering practice.

Maybe - but it's the way a good many, in fact most, of the main
protocols we use today have become what they are. People do their best,
then the real world comes along and reminds them of all the things they
forgot. It's normal for stuff to need fixing.

This doesn't mean DHCP failover is a good protocol. There are enough
legitimate gripes to throw rocks at.

>   See earlier messages in this thread.  I (a) found a theoretical issue
> with the protocol, and (b) demonstrated it in a live system.

I missed it. What was it again?

>   Yes, it doesn't implement the various states that the ISC
> protocol uses.  However, those states are largely there because of
> implementation decisions, rather than theoretical analysis.

You do need quite a few states for leases, and you need some mechanism
for transitioning between those states in an orderly fashion, in a way
that does not invalidating the contract you have with your DHCP clients.

But these lease states aren't the same states as those used in the DHCP
failover protocol. Seems to me you don't need *any* of those, because
the servers simply do not have to communicate directly. They
"communicate", if at all, through changing state in a shared database.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/                  +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20090609/be9338ba/attachment.pgp>