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
