[ECOS] RedBoot TCP socket stays in TIME_WAIT state forever.

[ECOS] RedBoot TCP socket stays in TIME_WAIT state forever.

[Grant Edwards]

When I close a TCP socket in RedBoot, the socket gets stuck in
the TIME_WAIT state forever.  Here is the sequence of events:

 1) call __tcp_close() which transitions to _FIN_WAIT_1

 2) the TCP stack sends a FIN

 3) the TCP stack receives a FIN+ACK

 4) the TCP stack transitions to _TIME_WAIT and sends and ACK 

Then it just sits there forever in the _TIME_WAIT state. Well
perhaps not forever, but 1) I've waited several hours and it
never changed, and 2) after studying the source code, I can't
see any way for it to exit that state.

AFAICT, the only way to get out of _TIME_WAIT state is if
somebody called tcp_send() while in that state so that a timer
gets set with the do_close() callback.

How would tcp_send() ever get called once we've hit step 4)
above?  Everything's been ACKed so there is no reason for the
stack itself to ever try to send anything, and calling
__tcp_write() in the application code is just going to return
immediately becuase the socket isn't in a valid state for
calling write().

Shouldn't the 1s/2m timer be set when the socket transitions to
the _TIME_WAIT state?

FWIW, here's the BSP_LOG output:

------------------------------8<------------------------------
SYN from 192.168.2.4:48331 (seq a352dcb8)
tcp_send: state[2] flags[SA] ack[a352dcb9] data[0].
_SYN_RCVD timer cancel.
ACK received - connection established
Rcvd tcp ACK 1

tcp data: seq[a352dcb9] len[27].
tcp data: pkt[7e9138] len[27].
tcp_send: state[4] flags[PA] ack[a352dcd4] data[10].
Rcvd tcp ACK b
seq advance 10
tcp data: seq[a352dcd4] len[0].
tcp_read: read 27 bytes. pkt[7e9138] freed.
tcp_read: no more data.
tcp_send: state[4] flags[PA] ack[a352dcd4] data[27].
Rcvd tcp ACK 26
seq advance 27
tcp data: seq[a352dcd4] len[0].
Rcvd tcp ACK 26

tcp data: seq[a352dcd4] len[6].
tcp data: pkt[7e9138] len[6].
tcp_read: read 6 bytes. pkt[7e9138] freed.
tcp_read: no more data.
__tcp_close: going to _FIN_WAIT_1
tcp_send: state[7] flags[FA] ack[a352dcda] data[0].
tcp free_rxlist.
Rcvd tcp ACK 27
seq advance 0
_FIN_WAIT_1 --> _TIME_WAIT
------------------------------8<------------------------------

-- 
Grant Edwards                   grante             Yow!  There's a SALE on
                                  at               STRETCH SOCKS down at the
                               visi.com            "7-11"!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: RedBoot TCP socket stays in TIME_WAIT state forever.

[Grant Edwards]

On 2006-04-05, Grant Edwards <grante@visi.com> wrote:

> AFAICT, the only way to get out of _TIME_WAIT state is if
> somebody called tcp_send() while in that state so that a timer
> gets set with the do_close() callback.
>
> How would tcp_send() ever get called once we've hit step 4)
> above?  Everything's been ACKed so there is no reason for the
> stack itself to ever try to send anything, and calling
> __tcp_write() in the application code is just going to return
> immediately becuase the socket isn't in a valid state for
> calling write().
>
> Shouldn't the 1s/2m timer be set when the socket transitions to
> the _TIME_WAIT state?

Moving __timer_set(&s->timer, s->reuse ? 1000 : 120000, do_close, s)
to the places where the state transitions to _TIME_WAIT seems to 
have fixed the problem.

-- 
Grant Edwards                   grante             Yow!  I am NOT a nut....
                                  at               
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: RedBoot TCP socket stays in TIME_WAIT state forever.

[Gary Thomas]

On Wed, 2006-04-05 at 03:39 +0000, Grant Edwards wrote:
> On 2006-04-05, Grant Edwards <grante@visi.com> wrote:
> 
> > AFAICT, the only way to get out of _TIME_WAIT state is if
> > somebody called tcp_send() while in that state so that a timer
> > gets set with the do_close() callback.
> >
> > How would tcp_send() ever get called once we've hit step 4)
> > above?  Everything's been ACKed so there is no reason for the
> > stack itself to ever try to send anything, and calling
> > __tcp_write() in the application code is just going to return
> > immediately becuase the socket isn't in a valid state for
> > calling write().
> >
> > Shouldn't the 1s/2m timer be set when the socket transitions to
> > the _TIME_WAIT state?
> 
> Moving __timer_set(&s->timer, s->reuse ? 1000 : 120000, do_close, s)
> to the places where the state transitions to _TIME_WAIT seems to 
> have fixed the problem.

Would you like to propose an actual patch for this, please?

Also, do you have a test case (or way to show the problem)?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: RedBoot TCP socket stays in TIME_WAIT state forever.

[Grant Edwards]

>>> AFAICT, the only way to get out of _TIME_WAIT state is if
>>> somebody called tcp_send() while in that state so that a timer
>>> gets set with the do_close() callback.
>>>
>>> How would tcp_send() ever get called once we've hit step 4)
>>> above?  Everything's been ACKed so there is no reason for the
>>> stack itself to ever try to send anything, and calling
>>> __tcp_write() in the application code is just going to return
>>> immediately becuase the socket isn't in a valid state for
>>> calling write().
>>>
>>> Shouldn't the 1s/2m timer be set when the socket transitions to
>>> the _TIME_WAIT state?
>> 
>> Moving __timer_set(&s->timer, s->reuse ? 1000 : 120000, do_close, s)
>> to the places where the state transitions to _TIME_WAIT seems to 
>> have fixed the problem.
> 
> Would you like to propose an actual patch for this, please?

Yes, it's on my list of things to do.

> Also, do you have a test case (or way to show the problem)?

I suppose I could add an "exit" command to RedBoot's telnet
server that would demonstrate the problem.

-- 
Grant Edwards
grante@visi.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss