[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: |
Thu, 23 Apr 2009 09:43:41 -0400 |
Hi Kieran,
Yes, I'll be spending some time with this over the next few days, and I'll let
you know how it goes.
Thanks for taking the time to look into it from your side.
________________________________________
From: address@hidden address@hidden On Behalf Of Kieran Mansley address@hidden
Sent: Thursday, April 23, 2009 4:22 AM
To: Mailing list for lwIP users
Subject: RE: [lwip-users] TCP client side problems using netconn api
On Mon, 2009-04-20 at 22:55 -0400, Ben Bobbitt wrote:
> All,
>
> I'm still searching for a cause behind this odd tcp behavior.
>
> Server FIN ACK seq 70 ack 305
> Client ACK seq 70 ack 305 <- this should be ack 306 (at least, it
> always is when the connection closes properly)
> Client FIN ACK seq 70 ack 305 <- or this should be
> Server ACK seq 71 ack 306
>
> Server FIN ACK seq 71 ack 305
> Server FIN ACK seq 71 ack 305
> Client ACK seq 70 ack 305 ( duplicate ack)
>
While looking into another bug I spotted some code in
src/core/tcp_in.c:tcp_receive() - around line 1090 in CVS head:
/* First received FIN will be ACKed +1, on any successive
(duplicate)
* FINs we are already in CLOSE_WAIT and have already done +1.
*/
if (pcb->state != CLOSE_WAIT) {
pcb->rcv_nxt += tcplen;
}
This looks a bit fishy to me, and I don't think it will be necessary. I
don't think it is causing your problem, but it may be preventing the
stack from recovering from the bug when it gets subsequent FINs.
Could you try replacing with:
pcb->rcv_nxt = seqno + tcplen;
If that works, I'd still like to get to the bottom of how it got into
this state in the first place.
Thanks
Kieran
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users