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

[Stefan Hax]

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