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

[Ben Bobbitt]

All,

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.


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)




Here is my thread that uses the tcp connection:


  httpbuffer = (char*)malloc(MAXHTTPRESPLEN);
  if(httpbuffer == 0)
  {
    return;
  }

  IP4_ADDR(&server_addr,ipoctet[0],ipoctet[1],ipoctet[2],ipoctet[3]);

  strcpy(httpbuffer,"GET /target.html HTTP/1.1\r\nHost: 
192.168.0.103\r\nConnection: close\r\n\r\n");
  pxWebConnection = 0;
  while(!abort)
  {
      vTaskDelayUntil( &xLastFocusTime, xDelayLength*5 );

      while(!pxWebConnection)  // create a netconn
      {
        vTaskDelayUntil( &xLastFocusTime, xDelayLength );
        pxWebConnection = netconn_new(NETCONN_TCP);
      }
      // initiate TCP connection to target
      err = netconn_connect(pxWebConnection,&server_addr,80);
      if(err != 0)
      {
        portNOP();
        continue;
      }
      err = 
netconn_write(pxWebConnection,httpbuffer,strlen(httpbuffer),NETCONN_COPY);
      if(err != 0)
      {
        portNOP();
        continue;
      }
      while((pxWebBuffer = netconn_recv(pxWebConnection)) != 0)
      {
        if(pxWebBuffer < 0)
        {
          portNOP();
          continue;
        }
      }

      err = netconn_disconnect(pxWebConnection);
      err = netconn_close(pxWebConnection);
      while(netconn_delete(pxWebConnection) != 0)
      {
        vTaskDelayUntil( &xLastFocusTime, xDelayLength );
      }
      pxWebConnection = 0;
      netbuf_delete(pxWebBuffer);
  }



Bear in mind that I've cut out pretty much everything useful in an effort to 
focus on the connection itself.  The nops are just there as breakpoints for the 
debugger.

I have tried both with and without the netconn_disconnect(). I have tried 
moving the netconn_new() outside of the while() loop and reusing the same 
netconn instance - that results in the connection not getting closed.

I'm running out of ideas to try to narrow this down, so any insights would be 
appreciated.

-Ben



-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Ben Bobbitt
Sent: Wednesday, April 15, 2009 9:37 PM
To: Mailing list for lwIP users
Subject: RE: [lwip-users] TCP client side problems using netconn api


Here's the pcap file from wireshark.  If you look, you can see a few successful 
tcp sessions that close without issue and then in frame 158 you'll see the ack 
sequence issue and the resulting FIN, ACK retries repeatedly from the server.

In capturing this for you, I notice that I did not correctly report that the 
Client FIN, ACK is also the wrong (?) seq number, not as I wrote below, but:

Server  FIN, ACK   seq 433 ack 70
Client   ACK       seq 70  ack 433     < - note the ack # is == seq prior
Client   FIN, ACK  seq 70  ack 433 <--- this seq is still 433
Server ACK         seq 434 ack 71

The client (lwIP ) is the .106 IP, the server (apache on linux) .103





-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Kieran Mansley
Sent: Wednesday, April 15, 2009 2:41 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] TCP client side problems using netconn api

On Wed, 2009-04-15 at 00:10 -0400, Ben Bobbitt wrote:
> In a connection that isn’t going away properly – and results in a
> system that I can’t get usable without a reset:
>
>
>
> Server  FIN, ACK   seq 433 ack 70
>
> Client   ACK            seq 70   ack 433     < - note the ack # is ==
> seq prior
>
> Client   FIN, ACK  seq 70  ack 434
>
> Server ACK           seq 434 ack 71

I'm not sure what your problem is, but it's not the ACKs in the above
sequence: the "Client FIN, ACK" acknowledges the "Server FIN, ACK" even though 
the "Client ACK" on its own didn't.

As you're able to get a wireshark capture of the problem I'd be interested to 
take a look at the pcap.

Kieran



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users