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

[David Empson]

"Ben Bobbitt" <address@hidden> wrote:
> I'm still searching for a cause behind this odd tcp behavior.
>
> I've simplified my thread as much as possible to eliminate any possible 
> contention for resources.
>
> If I'm using the API incorrectly, I'd sure appreciate someone pointing it 
> out.  I have been unable to find any
> examples of tcp client side code using the api.  I'm using lwIP 1.30 
> running under freertos in the atmel
> software framework.
>
> I am still seeing the ack / sequence number issue when the connection is 
> closing.  I can get through 3 -4
> iterations of connect, exchange data (http), disconnect, before this 
> problem occurs.  It seems to be unrecoverable.
>
> As I described below, the FIN ACK from the server side does not get the 
> proper ack / seq in the ACK response
> from the LWIP client.  The server initiates the close after the HTTP 
> response.
>
> In searching for any answers to this I came across some other emails to 
> the user group that mentioned sequence
> number issues, but I have no idea if that is related to what I'm seeing.

I'm not particularly familiar with this part of the LWIP code, from from 
having a look through the LWIP source code, the bit which is responsible for 
incremening the "ack" sequence number upon receiving a FIN is on line 1088 
of src/core/tcp_in.c (as of the CVS-head version).

This is deep in the middle of the tcp_receive() function.

Here is an extract of the relevant bit of code:

       tcplen = TCP_TCPLEN(&inseg);

       /* 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;
       }

What appears to be happening in your case is that this code is not 
triggering correctly, but only some of the time.

There are three possible explanations which occur to me.

(a) This code is never being reached.

The whole lot is inside an "if (tcplen > 0)" block which starts back on line 
959. I can't see anything wrong with that part of the logic - earlier in the 
function, tcplen should be correctly set to be the data length of the 
packet, plus one if the packet has either the SYN or FIN flag set.

(b) Something is wrong with inseg, resulting in TCP_TCPLEN() returning the 
wrong length. I don't know enough to follow through this bit, but from a 
quick glance, this seems most suspect - if inseg somehow didn't have a valid 
copy of the TCP flags, then TCP_TCPLEN() wouldn't detect the FIN and would 
return the length as zero. This would produce your observed behaviour.

(c) Something has gone wrong with the TCP state machine and it has jumped 
straight into CLOSE_WAIT despite not having done the complete FIN/ACK 
handshake. Not likely, given the behaviour otherwise seems correct.

Is it possible for you to debug the code and investigate exactly what is 
happening around this part of the code, on the occasion where the close 
isn't finishing correctly? In particular, look at inseg and whether its 
associated tcphdr has a valid copy of the saved flags with FIN set.

It is possible that something in LWIP is interacting with the way in which 
you are using the API, but I haven't use netconn() and can't comment on 
that.