Re: [lwip-users] Problem with lwip 1.3.2

[FreeRTOS Info]

Into the land of guessing and speculation here, but here goes:

1) Your network driver is failing under load.  Are you checking the
error bits in the MAC status register, clearing them, and recovering
from errors?  If the network interrupts stop, then there are no packets
being received, and lwIP will do nothing because there is nothing for it
to do.

2) You have your MAC in promiscuous mode.  Otherwise, it would make no
difference if you were behind a hub or a switch.  Turning promiscuous
mode off will mask, although not cure or fix, the issue.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





On 12/09/2011 10:25, Magnus S wrote:
> Hello,
> I have some experienced problems when using lwip 1.3.2.
> 
> We have been using our embedded system successfully for a while, but we
> have now performed load tests/stress tests,
> and we have discovered that in certain circumstances the system
> misbehaves, or hangs completely.
> 
> Our system connects to a server periodically, and exchanges some data.
> In the tests, a 1 minute period has been used, so the system has been
> connecting to the server once a minute.
> 
> We have investigated how well the device handles unrelated ethernet
> traffic, so we have connected the device to an
> old hub instead of a switch, which means that the PHY/MAC receives all
> the data present on the ethernet.
> 
> In the test two Linux machines were used, connected to the same hub as
> our device.
> One of the Linux PC:s acted as a web client, and the other as a web server.
> a 6 MB file was repetedly downloaded to the client, with a 1 second
> delay between each download.
> This means that the ethernet will be completely saturated for a few
> seconds, and then almost idle for one second.
> 
> With this setup, the device will connect once a minute and this normally
> succeeds for a few minutes or so.
> But after a while (normally less than 10 minutes), the system starts to
> misbehave, and hangs completely.
> 
> If a switch is used instead of a hub, the problem is not seem, the
> system works as expected.
> 
> We have investigated the problem cause, and have found that the
> application hangs on the following line in the lwip source code:
> tcpip.c, function tcpip_apimsg():
>     sys_arch_sem_wait(apimsg->msg.conn->op_completed, 0);
> 
> This call will never return, and the task will hang forever.
> 
> It seems as something should trigger the semaphore "op_completed", but
> this never happens.
> 
> What could be the cause of this problem?
> 
> We believe that the problem happens when the ethernet is saturated, and
> lwip fails to send an ethernet packet.
> 
> The error handling routines should handle this gracefully, but it seems
> as this case is not handled properly.
> 
> Do you have any suggestions for how this should be solved? Has anyone
> else experienced something similar?
> 
>  
> 
> Regards
> 
> /Magnus
> 
>  
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users