Wireshark gets half of packets then other half?

asked 2022-02-18 17:10:14 +0000

alsyia gravatar image

Hi everyone,

I'm trying to understand why I get a huge number of out-of-order packets (up to 26%) on a specific connection.

This is a sample of a record: image description

What puzzles me is that it looks like packets are not, in fact, received out-of-order by the application. Let me explain!

  • #592: receiver (me) sends an ACK for 371 538 743.
  • #593: sender sends packet with SEQ 371 538 743. This packet is marked out-of-order, even if its SEQ number matches with the previous ACK. WS says next seq number will be 371 540 131.
  • #594: receiver sends ACK 371 541 519. At this point, it should have sent ACK 371 540 131, right?

In fact, packet with SEQ 371 540 131 has already been received, it's #583.

What I find reaaally weird, is that 371 540 131 is not in the SACK window. Why, if it has already been received? Shouldn't it have been there?

In fact, the whole thing looks like if WS got every other packets, and then the other half, while the application would have got them in order. This would be consistent with the application (a cURL) sending one ACK for every other packet, and the missing packets (those received first in the big black block) not being in SACK.

I can't figure out why this would happen... I know tcpdump doesn't necessarily get packets in the same order as the application, but so often? And only for this specific connection to this specific server? This is driving me mad ^^'


edit retag flag offensive close merge delete


What's your capture environment?

grahamb gravatar imagegrahamb ( 2022-02-19 11:18:50 +0000 )edit

I captured on several different devices (a Kubernetes pod, the underlying VM, an random VM, and my laptop) and consistently got the same pattern!

alsyia gravatar imagealsyia ( 2022-02-21 09:30:00 +0000 )edit