lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Problem with lwip 1.3.2


From: Magnus S
Subject: [lwip-users] Problem with lwip 1.3.2
Date: Mon, 12 Sep 2011 11:25:20 +0200

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

 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]