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 <[email protected]> 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 >> [email protected] >> http://lists.nongnu.org/mailman/listinfo/lwip-users > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > -- Yoav Nissim Software Engineer, Software Tools Division Jungo Software Technologies Email: [email protected] Web: http://www.jungo.com Phone: +972-74-7212138 Fax: +972-74-7212122 Mobile: +972-54-2271315 _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
