Re: [lwip-users] Resource starvation

[Yoav Nissim]

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.


Thanks,

Yoav.



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