lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Bug of ARP?


From: Leon Woestenberg
Subject: Re: [lwip-users] Bug of ARP?
Date: Fri, 24 Dec 2004 13:24:20 +0100

Hello Jason,


On Fri, 2004-12-24 at 11:05, Wei Bo-Er (Jason) wrote:
>  
> According to above situation, we should not make original packets be
> freed before they are queued in ARP queue and after they are sent out
> from ARP queue. 

True. That's why the reference counter of the original packets must be
incremented when the packet is held in the unacked list. Apparantly,
this is not done (but I have not looked into this, I hate guessing).

> Therefore, I made a new fix which is shown as follows.
>  
> In pbuf.c

> Just like you said, it may not be suitable to modifiy pbuf_take to
> resolve this problem. Or we could say that ARP queueing should not use
> pbuf_take to make a copy
> of the original packet.
>
The semantics of the API say that the caller can safely free any packets
that were send() through lwIP. So, the queue *must* either reference
the original packet (so that the caller free() will not de-allocate
the packet), or it must copy referencing pbufs.

Also, we do not want the upper layers to be adapted to implement
low-level queueing.

>  Just for easy modifing and understanding, I decided to make a
> modification in pbuf_take. You could make modification in another
> place instead
> of pbuf_take since I am not sure where is the suitable one.
>  
> Maybe I am missing something again. Please let me know on the list.
> 
You are not missing something. As you say, pbuf is not the right place
to deal with this. If you decide to deal with it there, expect problems
in the future.

It is not just not proper engineering to fix things in the wrong place.
In the long term, it will cost you more than doing a proper fix now.

I might have time to look over the TCP retransmission queueing during
holidays, but do not count on it.

Regards,

Leon Woestenberg.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]