[Top][All Lists]

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

Re: [lwip-users] Resource starvation

From: Yoav Nissim
Subject: Re: [lwip-users] Resource starvation
Date: Sun, 13 Feb 2011 19:27:23 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4

Thanks Simon.

I've opened a ticket for this issue on savannah, and have a few
problematic points left.

1. Could you give some feedback as to how we should process each of the
PCB queues? (e.g retiring a PCB but leaving it to be cleaned up later
vs. calling the upper layer with an error such as ERR_ABRT). We're not
sure what the correct behaviour should be for each of the PCB types/states.

2. I believe this modification has exposed another problem: We get an
ASSERT when our PPP link is disconnected while packets are being
actively transferred.

It seems that a call to pppClose() drills down directly to sifdown()
which calls netif_set_down() and netif_remove().

Looking back at older lwIP PPP code, pppClose() and pppHup() were
protected with tcpip_callback(). If I understand correctly, these are
external APIs and should still therefore have this protection.

The removal of tcpip_callback() protection is noted in the change log as
an initial PPP version for NO_SYS==1.



On 31/1/2011 21:18, Simon Goldschmidt wrote:

> Honestly, I haven't thought too much about removing netifs since I regarded 
> them quite static in embedded systems. However, I guess when removing a 
> netif, we should have to do the same as when we change a local IP address 
> (unless maybe a user wants to exchange netifs?)...
> Simon
> Yoav Nissim <address@hidden> wrote:
>> Hello All,
>> We have encountered a problem when removing netif's and would like to
>> confirm the issue, and discuss ways of resolving it.
>> We are working with 1.4.0 rc1.
>> The problem:
>> We have many situations in which network interfaces are brought down
>> [and back up again], during normal processing of application (sockets)
>> traffic.
>> This also happens implicitly every time a PPP connection is disconnected
>> [and connected] as well.
>> We've found that after several such iterations, lwIP will have consumed
>> its pbuf pool or its tcp_seg pool, and not recover.
>> Looking through the code showed that there are no paths that inform ip,
>> tcp, or layers above that they cannot communicate anymore, and that they
>> should clean up their state.
>> These connections seem to continue living, hogging resources until none
>> are left.
>> Could anyone confirm that this is indeed an issue?
>> The only "fix" we have found for now, lies in netif_set_ipaddr.
>> According to
>> http://mail.gnu.org/archive/html/lwip-users/2003-03/msg00118.html, this
>> function has code that cleans up active TCP PCBs that are bound to the
>> interface's address.
>> When netif_remove() is called, we call netif_set_ipaddr with IPADDR_ANY
>> to have the relevant TCP connections removed.
>> This raises several questions:
>> 1. Is there a reason netif_remove() does not have such code?
>> 2. Assuming netif_remove() should have it, should netif_set_down() use
>> it as well?
>> 3. Are there any other components that have to have their state cleaned
>> up (IP, ARP, DNS, UDP, etc)?
>> 4. Assuming netif_remove() requires this cleanup, is this the right way
>> to do it or is there a better way?
>> 5. What do we do with the listening PCBs? in netif_set_ipaddr, their
>> bound addresses are simply changed to the new interface IP address. In
>> netif_remove() they should probably be disposed of.
>> Appreciate your input,
>> Yoav.
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/lwip-users
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users

Yoav Nissim
Software Engineer, Software Tools Division
Jungo Software Technologies
Email: address@hidden
Web: http://www.jungo.com
Phone: +972-74-7212138
Fax: +972-74-7212122
Mobile: +972-54-2271315

reply via email to

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