On 18.03.2011 01:18, Grant Edwards wrote:
What I'm having problems with is the DHCP implementation in the
Redboot bootloader. Redboot has it's own stripped-down polled-mode
network "stack" and implementations of things like BOOTP/DHCP client,
Telnet server, and TFTP client.
Redboot's "DHCP" code started out as purely a BOOTP client, and it
looks like when DHCP was added a few obscure failure modes were
overlooked.
Ok, I was not paying enough attention. Sorry.
Yes, I remember seeing similar problems in RedBoot DHCP client over a
year ago. It's not exactly production quality code (to put it mildly).
Looking at some old stuff I see following major problems:
1. The race. Any received BOOTREPLY packages are copied into internal
buffer before they are verified to be valid and destined to us. A
BOOTREPLY package sent to somebody else will overwrite our current
package. Lines 92-97 need to be moved 10 lines lower, after verification
code. This may not fix all problems, but it should fix the race that you
described.
2. The retry counter counts remaining retry attempts. I vaguely recall
that it does not work. Mostly because it doesn't really care - line 232
always tops up the "remaining retries" counter even if the last attempt
failed, causing a neverending loop. There used to be a similar
assignment before 234 but I don't see it in current cvs.
I have forgotten the details by now so don't take this as reliable
information.
Other, minor issues are:
3. DHCP transaction ID (XID) is not unique. If you start up multiple
devices simultaneously, it will create a mess.
4. XID is not verified. It accepts any response it gets, as long as MAC
address matches.
--
Kind regards,
Tarmo Kuuse
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss