----- Original Message -----
Sent: Monday, April 18, 2011 5:18
PM
Subject: Re: [lwip-users] lwip lock
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
_______________________________________________
lwip-users mailing
list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users