On 13/2/2011 20:38, goldsi...@gmx.de wrote:
> Yoav Nissim wrote:
>> I've opened a ticket for this issue on savannah, and have a few
>> problematic points left.
> Great!
>> 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.
> I would have thought the code for this is already present in
> netif_set_ipaddr()? I just would have moved this code to a more
> generic function so that it aborts all PCBs which are using the
> netif's IP address as their local address (only if the address is
> changed, listening PCBs can silently be corrected, I guess). Aborting
> these PCBs leads to ERR_ABRT for the upper levels. PCBs using the ANY
> address can live on.
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.
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?
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...
>> 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.
> The old PPP code was really broken regarding multithreading. The
> modifications that were necessary include that *none* of the PPP
> functions may be called from any other thread than the tcpip_thread
> (or the main loop for NO_SYS==1). The single exception here is
> pppInProc(), which can be called from another thread if
> PPP_INPROC_MULTITHREADED==1 (the reason for this is that it would
> otherwise be quite unperformant since we would call into tcpip_thread
> for every byte vs. every packet).
>
> I'm sorry the change here hasn't been clear, but this is just how lwIP
> works, and the way it was before, it wasn't really thread-safe.
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()?
>
> Simon
>
> _______________________________________________
> lwip-users mailing list
> lwip-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
--
Yoav Nissim
Software Engineer, Software Tools Division
Jungo Software Technologies
Email: yo...@jungo.com
Web: http://www.jungo.com
Phone: +972-74-7212138
Fax: +972-74-7212122
Mobile: +972-54-2271315
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users