Re: [lwip-users] lwip lock

[Tazzari Davide]

I agree with you Kieran, but the problem is that I don't know where to look for.

I used the lwIP 1.3.2 port for avr32 and I didn't touch almost anything.

In one my long (and boring) previous post I have added the description of all the tasks that uses the lwIP with netconn api. I can reply it if you wish.

About other... I have looked for some timers and I have seen that in the lwip core there are a lot of them that I suppose correct. I said "I suppose" because I don't really know how to investigate.

Can you please suggest where to look for?

Test 1.
I have connected the device to my computer with a cross Ethernet cable so that I haven't any wireless, switch, ... in the middle.

The situation is pretty the same except the fact that the lock is harder to create. After a lot of F5 reload, everything locks while, in the normal situation, I need only 5-10 fast reload.

This could suggest the heavy traffic managed by the lwIP itself could interfere with the normal management. I don't know if it is really a timer; probably something related to the MAC itself but, as you said, at interrupt level. But I don't know where

What I have seen in this test is that the key is really the TCP_SEG: when there is at least an empty block there could be communication even if the lfree ram pointer is not in the top of the area, otherwise there is the lock.

About SYS_TIMEOUT: Everytime I ask a page (or at least a connection) a timeout is created. I have set 6 SYS_TIMEOUT. If I reload the page 5 times and wait, no error occurs. If 6 or more, the error counter is increased. This seems to have no relationship with the TCP_SEG. Anyway, after a lot of error, the lwIP continues to function. So, let's forget it for the moment.

Test 2:

I have put a Relais toggle in the web server task

WebServer task
...
    for (;;)
    {
        iRestartBinding = 0;
        pxHTTPListener = netconn_new( NETCONN_TCP );
        netconn_bind(pxHTTPListener, NULL, webHTTP_PORT );
        netconn_listen( pxHTTPListener );
        int iTimeout = 1000;

        //for( ; (iRestartBinding < 10) && (gucRestartWebServer == FALSE); iRestartBinding++)
        for( ; ; ) // <<-- for this test purpose; In the real case the above line is present
        {
            REL_TGL; // <<-- for this test purpose
            xLastFocusTime = xTaskGetTickCount();
            vTaskDelayUntil( &xLastFocusTime, xDelayLength );
            if (iGlobalWtdBomb == FALSE) // TRUE I am waiting for a WDT suicide
            {
                // Wait for a first connection.
                #if LWIP_SO_RCVTIMEO
                pxHTTPListener->recv_timeout = iTimeout;
                #endif

                pxNewConnection = netconn_accept(pxHTTPListener);
                if (xTaskCreate(WebServerAnswerTask,
                        ( signed portCHAR * ) "WebServerAnswer",
                        WEB_SERVER_STACK_SIZE,
                        pxNewConnection,
                        ethWEBSERVER_PRIORITY,
                        ( xTaskHandle * ) NULL ) != pdPASS)
                {
                   // Task not correctly created!!!
                   netconn_write( pxNewConnection, (char *) webHTTP_HTM_INTERNAL_ERROR, (u16_t) strlen( webHTTP_HTM_INTERNAL_ERROR ), NETCONN_COPY ); // error HTTP 500

                   netconn_close( pxNewConnection );
                   netconn_delete( pxNewConnection );
                }
                iRestartBinding = 0;
                iTimeout = 5000;           
            }
        }   // end acquisition loop
        gucRestartWebServer = FALSE;
        netconn_close(pxHTTPListener);
        while(netconn_delete(pxHTTPListener) != 0)
        {
            vTaskDelay(20);
        }
        pxHTTPListener = NULL;
    }
...

Result...
When I reload the page slowly everything is ok almost forever.
When I reload the page faster I see that both firefox and explorer process the TCP connection, the GET request and immediately after they send [RST, ACK] to close the connection except the last one that waits for the device answer. I suppose that, due to the fact the browser hasn't received any answer and the user requests a reload they would like only the last one to be processed.

Every netconn_accept (time out or not) I can hear the relais toggle. If I press F5 5 times I hear 5 toggle. That's what I expect.

Sometimes one toggle misses (5 press of F5, 4 toggle!). Exactly in this case, I lose a TCP_SEG block and a portion of mem area.

1 toggle lost means also that the netconn_accept doesn't recognize the connection and, from web server task point of view, I cannot see the problem.

Again, this happens if there are lots of requests (connection, GET, [RST,ACK] from browser, close connection) before a (connection, GET, answer, [RST,ACK], close connection).

Sometimes I have seen this transaction in the middle of a reload
(Firefox) Connection [SYN]
(device) Connection [SYN, ACK]
(Firefox) Connection [ACK]
(Firefox) GET request
(Firefox) [TCP Retransmission] of the GET request
(device) [ACK] of the HTTP
(Firefox) [RST, ACK]   without any answer form the device

It seems that this is one case of TCP_SEC lost. It is not easy to say because I don't know exactly when the loss happens and how I can relate it with the wireshark sniffing.

It seems also that the loss often (but not always) happens when a [TCP Retransmission] is present
Anyway, it seems there is something in the inner management of the [RST,ACK], the retransmission or something like that is probably not related to the code I have written.

How can I handle this? Where do I have to look for? I have no idea at the moment.
My milestone is that the lwIP port is correct but at this point I am not so sure. I still hope that I wrote the wrong piece of code but, as I have said, I have no idea where to look at.

I hope my new analysis can help

Best regards
Davide