[Bug 1000062] New: redboot tcp reset dubious

[bugzilla at ecoscentric dot com]

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.