This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

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's gravatar image

GlobalS
0112
accept rate: 0%


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.

permanent link

answered 24 Jul '12, 03:22

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

"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.

permanent link

answered 24 Jul '12, 03:28

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

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]

(24 Jul '12, 03:49) GlobalS

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.

(24 Jul '12, 03:57) Jasper ♦♦

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 :)

(02 Aug '12, 14:23) GlobalS

I second what @SYN-bit and @Jasper said about the FIN behaviour of the server.

But you say:

my software is telling me "communication stopped" after 5-6 seconds

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:

for tests I tried to install the software on my computer and the connection never stops.

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
Kurt

permanent link

answered 24 Jul '12, 03:54

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 03 Aug '12, 02:37

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245

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

Yes, if I move the server locally (2 ms latency) the data flow is constant.

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:

  1. Why does the client close the TCP connection in one case and why not in the other case (2ms latency)?
  2. Does the client report the error message ("communication stopped") as a result of the FIN behaviour of the server, or is that just something that happens anyway, after the client application decided to close the connection. In that case the FIN behaviour (as bad as it is) would be unrelated to your problem.
(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 ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×752
×7

question asked: 24 Jul '12, 02:24

question was seen: 109,931 times

last updated: 03 Aug '12, 02:37

p​o​w​e​r​e​d by O​S​Q​A