This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001177] Redboot DHCP client race condition, XID, and retryproblems.
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-bugs at ecos dot sourceware dot org
- Date: Thu, 24 Mar 2011 19:33:46 +0000
- Subject: [Bug 1001177] Redboot DHCP client race condition, XID, and retryproblems.
- Auto-submitted: auto-generated
- References: <bug-1001177-13@http.bugs.ecos.sourceware.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.