I've a VMware machine with 2 servers. They have a heartbeat going. But then one server sends FIN, ACK and ends the connection. But it comes backwards in time ? What could be the reason for that ? asked 13 May ‘14, 05:09  lmdroke edited 17 May ‘14, 14:14  Guy Harris ♦♦ showing 5 of 13 show 8 more comments |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
Can you explain what ‘backwards in time’ means giving the timestamps of the packets in your post? The FIN occurs 138ms after the last ACK of the server…
I don’t think it’s 138 msec. I think it’s about 6 second searlier. 2.44.45 compared to 2.44.51.
These 2 servers are running on the same virtual machine. I am not sure how these logs are taken. I just got the results
Now that you say it … ;-) clearly back in time!
where (vm host or virtual machine) and how did you capture the data (wireshark, tcpdump, dumpcap, single interface, multiple interfaces)?
One of the machines 172.23.125.14 is running linux and TCPDUMP was used. The other machines 172.23.125.13, is a Windows server and here wireshark is used
So you had 2 traces and merged them into one? Or do you see the same phenomenon in two seperate/different traces, no matter where the trace was taken?
The problem is that the connection between the 2 servers is broken. I am rather new at this and I wonder why the way of tracing matters ? I mean, if I don’t trace, the connection still gets broken.
It matters a lot. Was the trace snippet you displayed above the result of a merged trace from the two different machines? ..or do you see the same results in the TCPDUMP trace and the Wireshark trace?
It matters to the “backwards in time” question. If the ACK was captured on one machine and the FIN+ACK was captured on another machine, perhaps the two machines clocks are out of sync, in which case you can’t meaningfully compare time stamps on packets from two different machines, and therefore it means that you can’t say that anything went backwards in time.
Note also that, even if the ACK and the FIN+ACK were captured on the same machine, if that machine’s clock were reset between the arrival or transmission time of the ACK and the FIN+ACK, it will make it look as if the FIN+ACK were sent before the ACK when, in fact, it was sent after the ACK.
Hi Guy,
How could I see if a clock is reset ? thanks
About all you can to in order to determine whether the clock was reset in the past is to check whatever system logs the machine has, if it logs time changes, to see whether the clock was set backwards.
Another think to look for would be if any NTP packets existed during that time in the trace. I would also try to find out from the person who took the capture(s) had any capture filters set. If they excluded traffic that might have been present, then you might not ever know.