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: [email protected] [[email protected]] On Behalf Of Kieran Mansley [[email protected]] 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 [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
