Re: [lwip-users] Resource starvation

[Yoav Nissim]

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)

          sio_read_abort(pppControl[pd].fd);


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


Yoav.



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.
>
>
> AFAICT:
>
> 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