Re: [lwip-users] Bug of ARP?

[Paul C]

Hi list Members,

This sounds like the problem I have been seeing. I am still trying to
set a set up where I can
get the start conditions so I can get debugging. 

Basically I have lwip tcp connected to a server. The server sends a Fin.
LWIP closes that connection
and starts a new connection to the same server. LWIP ends up in s state
where only 1 pbuf is available
(the remaining pbufs are somehow permanently commited and never get
released) so ping works, but any 
attempts to connect to the tcp echo on lwip fail, or when the
application tries to send data it fails. 

The hardest part is getting LWIP into this state, i have never caught it
with LWIP_DEBUG
turned on, and I have a hard time getting it to happen when I'm ready
for it.

I am using CVS HEAD (1.1.0RC) and Callback API. My problem could be
caused by a race condition 
in my application code, LWIP seems robust enough. What do people think
of this patch? I wont be 
able to try it for 2 weeks.

Thanks

Paul Clarke


On Fri, 24 Dec 2004 18:05:17 +0800, "Wei Bo-Er (Jason)"
<address@hidden> said:
> 
>I found this problem since I have met  it as starting TCP connecting. The 
>sequence number of first packet of >three-way handshake was changed before TCP
>got remote ack and then it failed to establish tcp connection. Of course, it 
>only occurs as ETHARP_QUEUEING=1.
> 
>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. 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. 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.
>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.
> 
>In pbuf.c
>828    struct pbuf *
>829    pbuf_take(struct pbuf *p)
>.....
>
>841    -  pbuf_free(p);
>.....
>868    /* remove linkage from original pbuf */
>869    - p->next = NULL;
>......
>901    /* p->flags != PBUF_FLAG_REF */
>902     } else {
>           + pbuf_ref(p);
>903     LWIP_DEBUGF(PBUF_DEBUG | DBG_TRACE | 1, ("pbuf_take: skipping pbuf not 
>of type PBUF_REF\n"));
>904     }
> 
>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. 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.
>Regards,
> 
>Bo-Er