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

[Kieran Mansley]

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