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  GlobalS |
3 Answers:
The server 82.117.201.86 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  SYN-bit ♦♦ |
"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 82.117.201.86 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 82.117.201.86 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  Jasper ♦♦ |
I second what @SYN-bit and @Jasper said about the FIN behaviour of the server. 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. You say:
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. Regards answered 24 Jul '12, 03:54  Kurt Knochner ♦ edited 03 Aug '12, 02:37 SYN-bit ♦♦ Thanks for the asnwer. The capture file is recording only one stop. I didn't start the communication for this pcap because the output is always the same. The communication always ends when wireshark tells me "segment lost". Yes, if I move the server locally (2 ms latency) the data flow is constant. This afternoon I'm planning to move the server on vmware rather than hyperV to see if it helps (24 Jul '12, 04:38) GlobalS
Without the client closing the connection (FIN)? If so, it's a problem within the application (maybe latency, as Jasper mentioned) and not the network, because in your sample capture the client closes the connection actively. The sole purpose of that is to end the communication, so there should'nt be any error message ("communication stopped") if the client voluntarily ends the communication. But that's just speculation. With the information provided so far, it's hard to come to a conclusion. There are two questions open:
(24 Jul '12, 04:47) Kurt Knochner ♦ Hello, just for information, we upgraded the firmware on the router and everything works fine. Unfortunately the router is a black box and I can't tell what setting changed. That is why we are switching to a better one :) (02 Aug '12, 14:23) GlobalS O.K. now I'm curious :-). Did you upgrade the "internet router" between 10.8.0.24 (client) and 81.117.201.86 (server)? If so, that would be kind of "interesting". As I mentioned, the client closes the connection actively and only then we see the bad FIN behaviour of the server (or maybe the router, interfering in the connection?). If the client stopped closing the connetion after the firmware upgrade (you mentioned that also for the case where the server was placed on the LAN), that would be kind of "strange" :-) (03 Aug '12, 01:10) Kurt Knochner ♦ |
Thanks you for your answers! The server at 81.117.201.86 is an access control controller (the device that open the door automatically with a smart card, just to understand) and it records the entrance and exits. On 10.8.0.24 we have the software that collect the data and let us see who's going in and out.
Unfortunately I cannot change any setting on the controller; So as I understood correctly the only possibility here is to move the receiving server closer to the controller?
[converted to a comment to keep the Q&A nature going]
No, moving receiving server and controller closer to each other will probably not help. Your problem is that the access control controller most likely runs a faulty TCP stack implementation, which means you need the vendor of that device to update it.
Hello, just for information, we upgraded the firmware on the router and everything works fine now. Unfortunately the router is a black box and I can't tell what setting changed. That is why we are switching to a better one :)