[En-Nut-Discussion] TCP sockets stuck in closing state

[Coleman Brumley]

After trying many great suggestions, nothing is working. After increasing
the TCP FSM stack size to 1024, I have multiple (7) sockets permanently
stuck in the CLOSING state:

00209D2C 0.0.0.0:80
        0.0.0.0:0 -->LISTEN
0020ADC4 0.0.0.0:80
        0.0.0.0:0 -->LISTEN
0020BD04 0.0.0.0:80
        0.0.0.0:0 -->LISTEN
0020B36C 0.0.0.0:80
        0.0.0.0:0 -->LISTEN
0020B0FC 0.0.0.0:80
        0.0.0.0:0 -->LISTEN
0020B8E4 0.0.0.0:80
        0.0.0.0:0 -->LISTEN
0020B7F4 192.168.3.76:80
        192.168.3.10:56395 -->CLOSING, WTO=1000, RTO=1000 TWTO=0
0020B4C0 192.168.3.76:80
        192.168.3.10:56381 -->CLOSING, WTO=1000, RTO=1000 TWTO=0
0020ACBC 192.168.3.76:80
        192.168.3.10:56092 -->CLOSING, WTO=1000, RTO=1000 TWTO=0
0020A458 192.168.3.76:80
        192.168.3.10:56093 -->CLOSING, WTO=1000, RTO=1000 TWTO=0
0020A7E8 192.168.3.76:80
        192.168.3.10:56082 -->CLOSING, WTO=1000, RTO=1000 TWTO=0
0020B26C 192.168.3.76:80
        192.168.3.10:56079 -->CLOSING, WTO=1000, RTO=1000 TWTO=0
0020ABFC 192.168.3.76:80
        192.168.3.10:56080 -->CLOSING, WTO=1000, RTO=1000 TWTO=0

WTO is the sock_write_to; RTO is the sock_read_to; and TWTO is the socket
time wait. 

At this point, I'm willing to even just put and force the socket into
TIME_WAIT whenever it enters the closing state, but will that cause
additional problems? Does anyone have a suggestion on how to even do that
and where in tcpsm.c? My incorrect assumption was that NutTcpStateClosing
gets called from the FSM thread for each socket that's in the closing state,
but that doesn't appear to be the case at all, as the sockets that are the
closing state never appear in the NutTcpStateClosing function. 

I'm not a TCP FSM guru, obviously, so you can see why this incredibly
frustrating. 

Coleman

> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of Coleman Brumley
> Sent: Wednesday, May 06, 2015 9:27 AM
> To: 'Ethernut User Chat (English)'
> Subject: Re: [En-Nut-Discussion] TCP sockets stuck in closing state
> 
> Is there no timeout in the CLOSING state that will force it to TIME_WAIT
if no
> ACK is received?
> 
> That seems to be the issue for me, at least.
> 
> Coleman
> 
> > -----Original Message-----
> > From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> > bounces at egnite.de] On Behalf Of Henrik Maier
> > Sent: Tuesday, May 05, 2015 8:01 PM
> > To: Ethernut User Chat (English)
> > Subject: Re: [En-Nut-Discussion] TCP sockets stuck in closing state
> >
> > Hi,
> >
> > I also added a similar fix, my code below.
> > It's the same code like the previous post plus the added tiny
> > connection
> fix,
> > refer to http://lists.egnite.de/pipermail/en-nut-discussion/2010-
> > January/011657.html
> >
> >
> > int NutTcpStateActiveOpenEvent(TCPSOCKET * sock) {
> >      /*
> >       * Switch state to SYN_SENT. This will
> >       * transmit a SYN packet.
> >       */
> >      NutTcpStateChange(sock, TCPS_SYN_SENT);
> >
> >      /*
> >       * Block application.
> >       */
> > 	 if(sock->so_state == TCPS_SYN_SENT)
> > //HM+: Apply read t/o also to connect
> > #if !defined(ENABLE_CONNECT_TIMEOUT)
> > 		NutEventWait(&sock->so_ac_tq, 0);
> > #else
> > 	 {
> > 	    if (NutEventWait(&sock->so_ac_tq, sock->so_read_to))
> >              return -1;
> > 	 }
> > #endif
> > //HM-
> >
> > //HM+: Tiny connection fix
> > //    if (sock->so_state != TCPS_ESTABLISHED)
> >      if ((sock->so_state != TCPS_ESTABLISHED) && (sock->so_state !=
> > TCPS_CLOSE_WAIT))
> > //HM-
> >          return -1;
> >
> >      return 0;
> > }
> >
> >
> > Cheers
> >
> > Henrik
> >
> >
> > On 5/05/2015 11:59 PM, Stefan Hax wrote:
> > > Hi,
> > >
> > > This is what I did to fix this issue in 'tcpsm.c':
> > >
> > > int NutTcpStateActiveOpenEvent(TCPSOCKET * sock) {
> > >      /*
> > >       * Switch state to SYN_SENT. This will
> > >       * transmit a SYN packet.
> > >       */
> > >      NutTcpStateChange(sock, TCPS_SYN_SENT);
> > >
> > >      /*
> > >       * Block application.
> > >       */
> > >      if(sock->so_state == TCPS_SYN_SENT) {
> > >          //NutEventWait(&sock->so_ac_tq, 0);
> > >          if( NutEventWait(&sock->so_ac_tq, sock->so_write_to) ) { //
> > > added the write T.O. to the blocking ... so we are not stuck here
> forever!!
> > >              return -1;
> > >          }
> > >      }
> > >
> > >
> > >      if (sock->so_state != TCPS_ESTABLISHED && sock->so_state !=
> > > TCPS_CLOSE_WAIT)
> > >          return -1;
> > >
> > >      return 0;
> > > }
> > >
> > > Hope this helps,
> > >
> > > Stefan Hax.
> > >
> > >
> > >
> > > On 2015-05-05 9:40 AM, Uwe Bonnes wrote:
> > >>>>>>> "Coleman" == Coleman Brumley <cbrumley at polarsoft.biz>
> writes:
> > >>      Coleman> Sorry, that should have said "is there no timeout for
> > >> the ACK
> > >>      Coleman> in the CLOSING state".
> > >>
> > >> Hello,
> > >>
> > >> I can feel your pain, but I am no TCP expert. Hopefully somebody
> > >> knowledgeable will drop into this discussion...
> > >>
> > >> Bye
> > >
> > > _______________________________________________
> > > http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> > >
> >
> > _______________________________________________
> > http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion