Hi, I have a software who dumps data from a remote controller. The dump is made though a tcp connection that is not stable; my software is telling me "communication stopped" after 5-6 seconds
I run Wireshark to understand what was going on, but I'm not able to spot the reason behind this. All I see in the pcap trace is that when the connection ends, I have a general error "tcp previous segment not captured".
my software runs in a hyperV machine. for tests I tried to install the software on my computer and the connection never stops.
I uploaded the trace here http://www.cloudshark.org/captures/c256982bb42d
Can anyone help?
asked 24 Jul '12, 02:24
The server 22.214.171.124 is not following the TCP RFC. In closing the session the FIN should come from the next expected sequence number and when the FIN gets ACKed, it should send an ACK that acknowledges one phantom byte. However, the server is sending the FIN with a sequence number that already incorporates the phantom byte. This is not correct and the client correctly sends a duplicate ACK asking for a packet with the correct sequence number.
So either, there is indeed one byte of data being sent and the packet got lost. Or the TCP stack of the server has a bug in it.
answered 24 Jul '12, 03:22
"tcp previous segment not captured" is an expert message created by Wireshark when it didn't see a packet that should have been in the trace; this warning was previously called "tcp previous segment lost". It basically means that either the packet really wasn't seen on the wire (which would be a packet loss) or Wireshark wasn't capturing "fast enough" to record the packet even though it had been on the wire.
I looked at your trace file and it looks like the device with the IP 126.96.36.199 behaves a little strange - is this some embedded device with a rudimentary stack implementation? It sends packet 136 with a sequence number that is one byte too high to be valid, so that the FIN-ACK-FIN-ACK sequence doesn't work as it should. I think the TCP stack of the node with the IP 188.8.131.52 is doing the session shutdown wrong, but I may be mistaken. I doubt that there really is a missing packet - my guess is that it is just a bad sequence number calculation that is giving you trouble.
Anyway, this protocol looks pretty problematic when run over high latency links. It is constantly exchanging small packets with push flags, which leads to quickly adding up the round trip times since it is basically a serialized communication. 137 packets in 13 seconds isn't going to win any throughput championships - but then again maximizing throughput is probably not an issue for this communication I guess.
answered 24 Jul '12, 03:28
But you say:
This does not match the capture file. The client actively closes the connection after ~ 12 seconds (Frame: 134). So, why does your software say "communication stopped" after 5-6 seconds? Maybe there is a another problem with the application.
Does that mean, you have constant data flow for more than a few seconds in that case? If so, then the problem is not a network problem, as the client actively closed the connection in your capture sample.