[Top][All Lists]
[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: |
Sun, 26 Dec 2004 17:01:28 +0100 |
User-agent: |
Mozilla Thunderbird 0.7.1 (Windows/20040626) |
Hello Bo-Er,
Wei Bo-Er (Jason) wrote:
> As you said, I made some mistakes in my patch. For TCP, it seems never
> to use a pbuf which has PBUF_FLAG_REF been set in its flag.
Correctly.
p = pbuf_take(p) will do *nothing* on a chain without REF type pbufs.
This is OK.
> But this kind of pbuf
> is always used as using UDP and I think it realy will meet the problem
> I mentioned in previous mail.
This I have to investigate, I have only looked at TCP now.
> Besides that, TCP will lose some packets which is chained
> in the unacked segments list, since pbuf_take doesn't make a copy as
> PBUF_FLAG_REF is not set and ARP will free its queue packets after
> sending them out.
But is *does* call pbuf_ref() so that the packets will *not* get freed()
on the first call to pbuf_free().
> 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.
> Therefore, I made a new fix which is shown as follows.
> 902 } else {
> + pbuf_ref(p);
> 903 LWIP_DEBUGF(PBUF_DEBUG | DBG_TRACE | 1, ("pbuf_take: skipping pbuf
> not of type PBUF_REF\n"));
> 904 }
pbuf_ref() is already called in either the etharp.c code (for the first
packet entering an empty queue) or in the
pbuf_queue() code (for subsequent entries). We should not have to
reference it here also.
Regards,
Leon.