invalid DISCOVER packet - update

[Duane Cox]

David,

Thanks for the reply, I have been waiting patiently :)


> 'peer holds all free leases' is a bit overloaded.  It can mean that
> the server has no leases in its free state to allocate to the client.

Yes, I see that it is somewhat vauge at times....

> But it can also mean that the client was not allowed access to any
> of the available leases ("allow" or "deny" statements).
>
> In your case, since the same config file minus failover nets an offer,
> I think you can focus on the obvious case.  But it's still a bit strange
> since your clients should be advancing the 'secs' BOOTP header field,
> this should disable LBA (load balancing), and so the other server
> should be happy to offer.
>
> So you are probably in some new and wonderful corner case.

Well at this time my problem seems to have mysteriously vanished.
I think my problem must have stimmed from a deny statement.
I did have a deny in the pool "deny known-clients" but had the client
commented out...
Perhapse I didn't "restart" the server after commenting it out, but could
sware I did...
At any rate, the DHCP server is responding to the DISCOVER now.

> What version?

3.0.5

> There have been many bugs that could introduce a synchronization
> failure in failover peers...all the known ones were repaired as
> of 3.0.5, although 3.1.0a1 added at least one new one we still
> haven't tracked down (or maybe it's an old one we just never
> saw before).

To complicate matters, our relay agent (embedded system) still doesn't like
the DISCOVER.
After I submitted a case and opened a ticket, their response was...

"The discover packet from the router is 28 bytes longer than normal. The
[embedded device] checks the length of the discover packet, if it is longer
the packet is discarded. I have asked engineering if the code can be
modified to accept the longer DHCP discover packet."

David, I wasn't aware there was a set length, or in this case "normal"
length, for dhcp packets.  Am I missing something here?