[Bug 1001177] Redboot DHCP client race condition, XID, and retryproblems.

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001177

--- Comment #4 from Grant Edwards <grant.b.edwards@gmail.com> 2011-03-24 19:33:43 GMT ---
(In reply to comment #3)

>> - It's not clear to me in bootp_handler that this supports BOOTP
>>   even when CYGSEM_REDBOOT_NETWORKING_DHCP is enabled.  Can you
>>   confirm it does?
> 
> Off the top of my head, I don't think it does.

It does not.

>>   Just because CYGSEM_REDBOOT_NETWORKING_DHCP is enabled, shouldn't
>>   mean that we can't work with BOOTP any more. This may have been a
>>   problem in the previous code too.

I think that because of the promiscuous manner in which reply packets
are copied, the previous code would time-out in DHCP mode and then use
data from whatever BOOTP REPLY packet was last received (regardless of
XID or destination address).

> I don't know.  I've never tried it with a server that doesn't do
> DHCP.  Will a bootp-only server send a BOOTP RESPONSE in reply to a
> DHCP DISCOVER?

Apparently they will.  And the state machine ignores it.

I presume that the desired solution would be when waiting for an
OFFER, if you receive a BOOTP REPLY packet that doesn't have both a
DHCP cookie and a DHCP type field, you "fall back" to BOOTP mode and
terminate the transaction with whatever info you can glean from the
BOOTP REPLY packet?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.