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

Coleman Brumley cbrumley at polarsoft.biz
Wed May 6 18:07:50 CEST 2015


I added the following code to the TCP FSM in NutTcpStateProcess:

case TCPS_CLOSING:
	sock->so_time_wait++;
	if(sock->so_time_wait>3000){
		 printf("Super long time in closing!\n");
		 sock->so_time_wait = 0;
		 NutTcpStateChange(sock, TCPS_TIME_WAIT);  
	}
        	NutTcpStateClosing(sock, flags, th, nb);

And modified NutTcpStateFinWait1 to not explicitly clear so_time_wait:
if (sock->so_state == TCPS_FIN_WAIT_2){
	sock->so_time_wait = 0;
            NutTcpStateChange(sock, TCPS_TIME_WAIT);
        }
        else{
            NutTcpStateChange(sock, TCPS_CLOSING);
      }

Still not luck. In my socket dump function, I see:
12:06:07 05-06-2015:
Heap Availble=22248
0020AAB4 0.0.0.0:80
        0.0.0.0:0 -->LISTEN
00209E24 0.0.0.0:80
        0.0.0.0:0 -->LISTEN
0020B448 0.0.0.0:80
        0.0.0.0:0 -->LISTEN
0020B0B0 0.0.0.0:80
        0.0.0.0:0 -->LISTEN
0020ADB4 0.0.0.0:80
        0.0.0.0:0 -->LISTEN
00209A24 0.0.0.0:80
        0.0.0.0:0 -->LISTEN
0020AC00 192.168.3.76:80
        192.168.3.10:57556 -->CLOSING, WTO=1000, RTO=1000 TWTO=0
0020AFF8 192.168.3.76:80
        192.168.3.10:57335 -->CLOSING, WTO=1000, RTO=1000 TWTO=0

The time_wait counter never increases! Something is seriously wrong here. I
would have expected that if a socket is in TCPS_CLOSING, it MUST pass
through the TCPS_CLOSING state in NutTcpStateProcess, no?


Coleman

> -----Original Message-----
> From: Coleman Brumley [mailto:cbrumley at polarsoft.biz]
> Sent: Wednesday, May 06, 2015 11:32 AM
> To: cbrumley at polarsoft.biz; 'Ethernut User Chat (English)'
> Subject: RE: [En-Nut-Discussion] TCP sockets stuck in closing state
> 
> 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




More information about the En-Nut-Discussion mailing list