[En-Nut-Discussion] FW: TCP sockets stuck in closing state
Coleman Brumley
cbrumley at polarsoft.biz
Thu May 7 02:49:44 CEST 2015
> The socket dump code is a function I created that gets called
periodically. It
> gets executed every 20 seconds from one my threads.
>
> Yes, as you point out, it almost seems as though the SM thread stops
> processing some of the sockets in the list.
>
> 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