This is the mail archive of the
ecos-bugs@sources.redhat.com
mailing list for the eCos project.
[Bug 1000062] New: redboot tcp reset dubious
- From: bugzilla at ecoscentric dot com
- To: ecos-bugs at sources dot redhat dot com
- Date: Wed, 10 Dec 2003 03:17:37 +0000 (GMT)
- Subject: [Bug 1000062] New: redboot tcp reset dubious
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000062
Summary: redboot tcp reset dubious
Product: eCos
Version: 2.0
Platform: ebsa285 (Intel EBSA285 StrongARM board)
OS/Version: All
Status: NEW
Severity: normal
Priority: normal
Component: RedBoot
AssignedTo: jifl@ecoscentric.com
ReportedBy: jifl@ecoscentric.com
QAContact: ecos-bugs@sources.redhat.com
Courtesy of the test farm I found an issue that needs much more thorough
investigation, but I haven't got the time right now to give attention to it; so
this is more a placeholder for future work hence assigning to myself first.
The problem appears to be when a connection to redboot on port 9000 is already
established, and the board (in this case an ebsa) is power cycled. I don't know
if someone else has to then connect in first or what, but the old existing
connection never gets a RST, even if more data is sent down.
I've two guesses: one guess is that because of the simple nature of the stack,
if someone connects in after the reset even though there's an existing stale
connection that should be RSTed, then since redboot operates fairly
deterministically, it doesn't notice and only pays attention to the fact the
socket is already in an ESTABLISHED state. And so it never sends a RST. I don't
think this is likely though as superficially redboot does check e.g. the source
port.
My second guess is that it's "simply" a bug in the RST code.... one time when I
connected I saw $T packets pointing at an address inside redboot (the ROM
region). Unfortunately I didn't have a linker map for the image. Obviously this
is the send_reset() function in redboot's src/net/tcp.c.
More investigation clearly required I'm afraid.
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.