This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RedBoot sends continuous ACKS in TIME_WAIT state.


On Mon, Mar 26, 2001 at 09:57:15PM -0500, Mark Salter wrote:
> >>>>> Grant Edwards writes:

> > Following __tcp_close() on a socket, the RedBoot TCP stack
> > exchanges a continuous stream of ACKs with my Linux box.  The
> > RedBoot socket is in the TIME_WAIT state.  Do we really want to
> > send out ACKs in TIME_WAIT state?
> 
> For some reason, RedBoot is performing and active close. 

I should have mentioned that I've added password authentication
for incoming telnet connections.  If authentication fails,
RedBoot does an active close.  [At the last minute it was
decided that allowing unauthenticated telnet connections was
too big a security hole.]

> When I wrote the tcp stack, it was for a gdb stub which was
> always going to keep the connection open for as long as the
> other end wanted, so I don't think active closes have ever
> been tested.

My version of RedBoot is suffering from a moderate case of
feature creep.  What started out as a fairly straight-forward
port of RedBoot now supports the regular serial/telnet/TFTP
stuff (with not-quite-working password authentication on
telnet), an entirely unrelated TCP protocol used to download
applications, and an HDLC over MAC layer Ethernet protocol also
used to download applications. 

"They" have also decided that it has to support accessing a
non-local TFTP server (and therefore needs to use DHCP to get a
netmask).  I also need to impliment a "terse" mode so that
it's easier to do serial console commands programatically.

Perhaps RedBoot isn't the ideal choice with the current set
of requirements, but we're too far down the road to turn back
now.  :)

> There is probably a bug in that part of the tcp stack.

After I looked through the sources more I noticed that my
password hack was the only active close.

> On the other hand, RedBoot should not be doing an active close
> in the first place.

It didn't until today.  ;)

What I can't figure out is why the Linux stack is ACKing the
ACKs sent by RedBoot.  According to my copy of Stevens, the
Linux stack should be in the LAST_ACK state: upon receipt of an
ACK it is supposed to send nothing and transition to CLOSED.

I couldn't really tell from Stevens if a server in the
TIME_WAIT state is supposed to ACK incoming ACKs or not.

What's the down side of changing the RedBoot stack to not ACK
incoming ACKs?

-- 
Grant Edwards
grante@visi.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]