[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lwip-users] TCP client side problems using netconn api
From: |
Ben Bobbitt |
Subject: |
RE: [lwip-users] TCP client side problems using netconn api |
Date: |
Wed, 15 Apr 2009 09:02:32 -0400 |
As I say, I'm no TCP expert, but this sequence is always the last connection
that works, and it is hosed after. All other connections end with a different
sequence in that FIN,ACK ACK between the server and client. Something about it
is not correct, or at least deviates from the norm in such a way as to screw
things up. The server starts resending FIN, ACKs a few seconds after the 4
way exchange, and the client ( the LWIP part) ignores them for a while (10 sec
or so ) before sending his own FIN, ACKs and the series never seems to get
caught up and resolved.
There does seem to be an outstanding bug in 1.3.0 regarding tcp sequence
numbers, but I don't know if it is related to this or not.
________________________________________
From: address@hidden address@hidden On Behalf Of Kieran Mansley address@hidden
Sent: Wednesday, April 15, 2009 3:41 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] TCP client side problems using netconn api
On Wed, 2009-04-15 at 00:10 -0400, Ben Bobbitt wrote:
> In a connection that isn’t going away properly – and results in a
> system that I can’t get usable without a reset:
>
>
>
> Server FIN, ACK seq 433 ack 70
>
> Client ACK seq 70 ack 433 < - note the ack # is ==
> seq prior
>
> Client FIN, ACK seq 70 ack 434
>
> Server ACK seq 434 ack 71
I'm not sure what your problem is, but it's not the ACKs in the above
sequence: the "Client FIN, ACK" acknowledges the "Server FIN, ACK" even
though the "Client ACK" on its own didn't.
As you're able to get a wireshark capture of the problem I'd be
interested to take a look at the pcap.
Kieran
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users