Hi, I captured some packets on a load balancer and somehow the network time is negative. Also the sequence number is jumping all of a sudden. What could be a possible reason for that? Thanks!! asked 27 Sep '16, 06:36 vondutch9 |
Hi, I captured some packets on a load balancer and somehow the network time is negative. Also the sequence number is jumping all of a sudden. What could be a possible reason for that? Thanks!! asked 27 Sep '16, 06:36 vondutch9 |
How was the capture made on the load balancer? How is the setting for the time column? What is the expression for the seq column? What is the expression of the NSeq column? What is the expression for the Ack column.
The load balancer provides an interface to capture tcpdump trace. Time is just time. Seq is tcp.seq, NSeq is tcp.nxtseq and ack is tcp.ack.
Did you capture more than one interface. Try the cli tool reordercap.
"Time is just time." Wireshark has a number of settings for the Time column, including "Seconds since beginning of capture," "Seconds since previous captured packet," and "Seconds since previous displayed packet. You should not see negative times (as in, time of day), but you can see negative delta times.
The most common reason for negative delta times is capturing simultaneously on multiple interfaces. As Christian_R says, you can use the reordercap tool to put the packets in proper order.
You can even see negative "time since beginning of capture" times for frames whose absolute timestamp indicates an earlier time than that of the first frame in the file.
Using reordercap is the right thing to do if you trust the timestamps provided by the load balancer and only suspect that its capturing interface delivers the packets from different source interfaces in groups. To check that, you may stay in the GUI Wireshark and click the "time" column in the packet list pane to make Wireshark sort the packets by timestamp value, and see whether related packets captured at different source interfaces appear in logical sequence. But bear in mind that Wireshark's TCP analysis continues to work according to the frame sequence numbers, not the timestamps. So if this quick test confirms that the timestamps can be trusted, you have to use reordercap to sort the packets chronologically so that the TCP analysis could work correctly.