Wireshark-users: Re: [Wireshark-users] A little help with a connection issue required
From: Hansang Bae <hbae@xxxxxxxxxx>
Date: Mon, 07 Apr 2008 08:28:53 -0400
Weninger, Mark wrote:
My colleague and I are troubleshooting an issue that has us scratching our heads. Here is how our system is setup.
Our host application is configured as a TCP server listening on port 1001.
The Client device is configured as a TCP client configured to connect to the host application on port 1001. Once the device makes a socket connection the host application will send a string containing ‘CONNECT’ to indicate to the client that the connection is made.

The Client device, upon power-up, continually sends status updates every 2 seconds.

Here’s the problem.

When the host application is bounced the client’s status updates do not reach the host application. The wireshark captures show that, what I consider, a properly formed TCP packet is sent from the client device to the host PC. The host PC replies with a TCP acknowledgement that has a very large ACK value of 429496xxxx. This causes retransmissions and the host PC still responds with an incorrect ACK, this continues indefinitely. The strange thing is that the ‘CONNECT’ message gets successfully sent from the host application to the device, only the messages from the device are not making through to the application. So the socket connection does get made.


Mark, I'll second Sake's comment about screen shots.

When your server is recycled, it should not be accepting new tcp connections as if they were valid tcp connections. They are not since your application is not maintaining tcp state information when it's recycled. While any application can use any number for ISN (initial sequence number), the fact that your app replies with a number close to the 2^32 boundary is a little interesting. But as Sake mentioned, if you turn off relative sequence numbers (edit, preference, Protocols, tcp, relative sequence numbers and window scaling) you may see that it always behaves this way. Or - more likely - this is a way of handling error condition (which isn't the right way to do it, BTW)

The issue, based on your description, is that your application is sending a CONNECT message w/o initiating the three way tcp handshake. And to make it worse, the application response as if the connection is a valid one.

If you get a tcp packet out of the blue, the valid response should be a RST packet.

--

Thanks,
Hansang