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

Coleman Brumley cbrumley at polarsoft.biz
Thu May 7 02:49:17 CEST 2015


> Interestingly, in the fsm thread, the code does this:
> 
>   while (nb) {
>                 ih = (IPHDR *) nb->nb_nw.vp;
>                 th = (TCPHDR *) nb->nb_tp.vp;
>                 sock = NutTcpFindSocket(th->th_dport, th->th_sport,
ih->ip_src);
> #ifdef NUTDEBUG
>                 if (__tcp_trf)
>                     NutDumpTcpHeader(__tcp_trs, " IN", sock, nb); #endif
>                 nbx = nb->nb_next;
>                 if (sock) {
>                     NutTcpInputOptions(sock, nb);
>                     NutTcpStateProcess(sock, nb);
>                 }
> 
> Note the use of NutTcpFindSocket. I guess I would have expected it to
simply
> loop through the sockets list. And run NutTcpStateProcess accordingly.
> Hmmm.
> 
> Looking into NutTcpFindSocket, it also seems to not deal with sockets in
the
> TCPS_CLOSING state. Even more interesting!
> 
> After lunch, I will look into this further. This has some bite to it.
Especially
> given that the debug code in NutTcpStateProcess which shows the "stuck"
> sockets never seem to be handled in NutTcpStateProcess!
> 
> Coleman
> 
> > -----Original Message-----
> > From: Stefan Hax [mailto:stefan at escherlogic.com]
> > Sent: Wednesday, May 06, 2015 12:08 PM
> > To: cbrumley at polarsoft.biz; Ethernut User Chat (English)
> > Subject: Re: [En-Nut-Discussion] TCP sockets stuck in closing state
> >
> > Where have you placed this debug code or is this a function you wrote
> > that steps through the linked-list of sockets?  It almost looks like
> > the SM thread doesn't get to run because of a busy loop somewhere.
> >
> > Stefan.
> >
> > On 2015-05-06 11:31 AM, Coleman Brumley wrote:
> > > 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
> > > _______________________________________________
> > > http://lists.egnite.de/mailman/listinfo/en-nut-discussion




More information about the En-Nut-Discussion mailing list