Ask Your Question

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:

edit retag flag offensive close merge delete


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

Bob Jones gravatar imageBob 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. ( )

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

here is the new link, I hope this time will work

klaklajdi gravatar imageklaklajdi ( 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 gravatar imageklaklajdi ( 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é gravatar imageAndré ( 2023-09-30 13:25:30 +0000 )edit

1 Answer

Sort by » oldest newest most voted

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

Jim Young gravatar image

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 more


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 gravatar imageHenrik ( 2023-10-01 11:32:44 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


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

Seen: 273 times

Last updated: Sep 30 '23