RE: [lwip-users] TCP client side problems using netconn api

[Ben Bobbitt]

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