[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, 20 Feb 2011 11:32:59 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4

Just a follow up -

Our PPP code seems to be working fine for some time now after the
modifications discussed below:

1. Calling all PPP APIs by using tcpip_callback()  [actually
tcpip_callback_with_block() as non blocking]

2. Removed the pppRecvWakeup() call from pppSigHup()

3. Added a conditional to pppRecvWakeup() -

      if (pppControl[pd].openFlag)


I will submit a bug in savannah soon, and check original ppp code as well.


On 15/2/2011 12:31, Yoav Nissim wrote:

> Hi Simon.
> We've changed our code to call pppSigHup and pppClose using a
> tcpip_callback.
> This caused a crash in a specific scenario when our serial port is
> disconnected.
> I believe this is a result of a bug in PPP code:
> pppLinkTerminated is always called after lcp phase is set to PHASE_DEAD.
> In it, the pppInput thread is "released" by calling pppRecvWakeup, the
> application callback is called with PPPERR_PROTOCOL, and openFlag is set
> to 0.
> Since PPP does not manage the sio_fd (it simply receives an open handle
> and does not close it), there must be a point in which PPP lets me know
> I can have my sio_fd back. This point AFAICT is when my link_status_cb
> is called with PPPERR_PROTOCOL.
> The problem (the crash actually) occurs because both pppClose and pppHup
> call pppRecvWakeup AFTER calling pppLinkTerminated. Since I release my
> resources on pppLinkTerminated, the call to pppRecvWakeup references a
> nonexistent sio_fd object.
> 1. pppHup does not need to call pppRecvWakeup at all.
> 2. pppRecvWakeup (in the flow of ppClose()) should check openFlag before
> using the sio_fd. [It may not be needed at all, but I really don't know
> enough about ppp close flow to tell]
> Could you please confirm or correct these?
> Thanks,
> Yoav.
> On 13/2/2011 23:28, Simon Goldschmidt wrote:
>> Yoav Nissim <address@hidden> wrote:
>>> The code in netif_set_ipaddr() does not handle bound PCBs and time_wait
>>> PCBs. The listening PCBs in set_ipaddr() simply have their address
>>> changed, but in our case we need to clean them up.
>> Oh, right.
>>> The active PCBs are taken care of by tcp_abort(). This leaves:
>>> 1. time_wait PCBs which I believe can simply be removed.
>>> 2. listening PCBs which cannot be processed by tcp_abort() - how do I
>>> clean them up?
>> I think they do have an err callback, but I'll have to check the sources...
>>> 3. bound PCBs - I am not sure if I can call tcp_abort() on these, or
>>> whether I would manually call TCP_EVENT_ERR(errf, errf_arg, ERR_ABRT),
>>> and then have them removed. An application may be taken by surprise here...
>> Calling tcp_abort is correct. In fact, netif_set_ipaddr already does this.
>>> Not a problem. I just need to be sure I understand - this means that all
>>> the functions in ppp.h under the "PUBLIC FUNCTIONS" comment [namely
>>> pppOverSerialOpen, pppClose and pppSigHup] must be called using
>>> tcpip_callback()?
>> Again, I have to check that in the sources but I guess the answer is yes, 
>> since every net if driver in lwIP has to do it that way, and PPP is 
>> essentially a netif driver to lwIP.
>> Simon
>> _______________________________________________
>> 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]