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

see more comments

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

Your Answer

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

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