Re: [lwip-users] bug report: TCP and ARP queueing probably clashes

[Paul C]

Hi Leon,

I meant Jason's patch. I hadnt read your followup at the time I posted.
Now I have read your latest queueing bug report. I havent followed the
logic of Jason's patch. I'm not sure if the issue I have is the same
as Jason's, similar or not related at all.

One thing I am wondering about is the tcp close condition. My
application has a tcp connection open to a PC, the PC sends a 
FIN, the lwip code does its thing to close the connection. 
How should my LWIP application handle restarting the 
connection?  Using CALLBACK API!

My Original code
    tcp_new()
    Allocate state variable
    Set all the callbacks
   .....
    tcp_online
      tcp_writes to connection
    application runs
    TCP CLOSE
    set call backs to NULL
    tcp_close
    deallocate state variable

My current "trial" code
    tcp_new()
....
    tcp_online { Now create state variable set callbacks.)
     tcp_writes
    application runs

    TCP CLOSE
    tcp_close {dont touch the callbacks - deallocate state variable)

Now there is one more wrinkle. Our application sends UDP packets
to search for hosts. From the udp replies it opens a tcp connection
Once we have a tcp_connection we are still trying to connect to our 
prefered host (if the connection is not to it). In the case of the 
non prefered host we close the current connection and open a new 
connection to the prefered host connection. As you can see there
are opportunties for application to screw things up as well!

The problem appears when the PC application decides that there 
is not enough activity on the connection so closes it. The LWIP 
application immediately closes the old connection and starts 
searching for a new connection. The tcp_online callback does 
a number of tcp writes, it is this chain (or queue?) of initial 
pbufs that I think heads into the Bermuda Triangle. Mostly it 
works OK, (translation everytime you sit at the PC trying damm 
hard to screw things up it works, some time after you have gone 
home it locks up) 

Now that I have written this down I think that the arp 
state must be in the "STABLE" state (we have received a
UDP packet from the host when we open the connection)
so there should be no ARP queueing when this pbuf 
lossage happens. Can anyone suggest where my pbufs 
go to?

Thanks

Paul 

PS I accidently tabbed and hit return on the send before.





On Sat, 25 Dec 2004 15:22:43 +0100, "Leon Woestenberg"
<address@hidden> said:
> Hello all,
> 
> thanks to Bo-Er reporting on the lwip-users mailing list, I suspect the 
> Ethernet ARP queueing
> code clashes with the TCP queueing code, and as such this is a bug in 
> the current HEAD code.
> 
> Summary:
> 
> lwIP used a 'zero-copy' strategy on outgoing packets, however, it was 
> changed to 'copy-on-demand'
> strategy to cope with packet obufs referencing volatile application
> memory.
> 
> This strategy *probably* clashes with the TCP queueing code, if both 
> queues adapt the packet
> pbuf chain.
> 
> Temporary solution:
> 
> For applications where TCP connections are involved, please disable 
> ETHARP_QUEUEING.
> 
> For applications that do not use TCP, enabling ETHARP_QUEUEING should 
> work 100% stable.
> 
> I will file a bug report, and in the meantime try to get a full 
> understanding of the TCP protocol
> implementation for unACKed/unsent queueing to see if, and how to solve 
> this properly.
> 
> One solution would be to queue UDP traffic only in ARP, however the
> current
> internal API will not allow this in a clean way.
> 
> Regards,
> 
> Leon Woestenberg.
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users