tcpdump overlapping packets

asked 2023-09-30 08:33:13 +0000

Hello everyone,

I am making some 30 seconds tcp measurements and I'm capturing the packets using tcpdump. When I open the pcap-file I notice that packet 11709 was captured at time 7.557846 seconds after tcpdump start whereas packet 11710 was captured after 188.463532 seconds. This can not be true as my measuremets is only 30 seconds long and I'm really capturing only the traffic between my server and my client. On the other side packet 12445 has a time of 188.935306 seconds whereas packet 12446 the time of 8.031106 seconds. Do you have any Idea what the problem could be?

the pcap file: https://drive.google.com/file/d/1cUmX...

edit retag flag offensive close merge delete

Comments

The file is not available for download. Suggest you make access 'Public' for others to look at.

Bob Jones ( 2023-09-30 11:26:13 +0000 )edit

Are you reading the file on an other machine than where it was captured?
Is the time correct when you read the file on the capture machine itself with tcpdump -n -ttttt -r file?

This sounds like a big endian / little endian swap. ( https://wiki.wireshark.org/Developmen... )

André ( 2023-09-30 12:06:36 +0000 )edit

here is the new link, I hope this time will work https://drive.google.com/file/d/1cUmX...

klaklajdi ( 2023-09-30 12:53:16 +0000 )edit

@Andre I capture the pcap file on an other device using the following command: tcpdump -n -i eno1 -w server.pcap -s 66 "tcp port 5201"

then I import this file via SSH to my computer

klaklajdi ( 2023-09-30 12:59:17 +0000 )edit

Is the outputted time correct when you run this command on the 'other device'?

tcpdump -#n -ttttt -r server.pcap | grep ^117[01]

André ( 2023-09-30 13:25:30 +0000 )edit

actually not as I only record 30 seconds long and it shows me a jump of 3 Minutes

11709 00:00:07.557846 IP 130.75.73.70.5201 > 80.187.113.171.21571: Flags [P.], seq 40544001:40549793, ack 38, win 4, options [nop,nop,TS val 2304235511 ecr 983608947], length 5792

11710 00:03:08.463532 IP 130.75.73.70.5201 > 80.187.113.171.21571: Flags [P.], seq 40549793:40555585, ack 38, win 4, options [nop,nop,TS val 2304235511 ecr 983608947], length 5792

and then:

12445 00:03:08.935306 IP 80.187.113.171.21571 > 130.75.73.70.5201: Flags [.], ack 43141713, win 24576, options [nop,nop,TS val 983609423 ecr 2304235953], length 0

12446 00:00:08.031106 IP 130.75.73.70.5201 > 80.187.113.171.21571: Flags [P.], seq 43374841:43383529, ack 38, win 4 ...(more)

klaklajdi ( 2023-09-30 13:34:48 +0000 )edit

Could it be as simple as a time change on the capturing system? System time gets pushed out by 3min, then gets corrected?

Bob Jones ( 2023-09-30 14:39:56 +0000 )edit

add a comment

answered 2023-09-30 14:07:13 +0000

Jim Young
196 ●16 ●4

For some reason the 'Timestamp sec' values for frames 11710 through frame 12445 inclusive jumps forward in time by about 180 seconds, starting with a 'Timestamp sec' of 1695314795 for frame 12445 and ending with a 'Timestamp sec' of 1695314796 relative to the rest of the packet capture where the 'Timestamp sec' value for frame 11709 is 1695314614, the 'Timestamp sec' value for frame 12446 is 1695314615. This appears to be some type of defect on the capturing machine.

edit flag offensive delete link

Comments

totally agree here. If you open Statistics /TCP Stream Graph/tcptrace you will see, that this can not be true! You see a lot of retransmissions too. As we don't see any dupAcks I would say, the trace itself can not be trusted. On the other hand, your trace command is not optimized. As tcpdump is using by default only 2Mbyte of capture buffer, the capture buffer is to small (peak speed is about 39Mbit/s - not that much). Additionally, it seems, you are using TSO and may LSO. (Segmentation offload to the NIC) which is default on today. As you recording on the sender side, you only see, what the stack sends to the NIC and not what is leaving the system. My recommendation: 0) never -s after 66 bytes. This is too small. Even Wireshark cant decode the Window Size Scaling. Use 80 bytes instead! 1) Trace ...(more)

Henrik ( 2023-10-01 11:32:44 +0000 )edit

add a comment

tcpdump overlapping packets

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

tcpdump overlapping packets edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

tcpdump overlapping packets