TCP Dup ACK Question

asked 2018-01-31 22:51:41 +0000

Pikey
1

updated 2018-02-01 07:18:01 +0000

13742 ●711 ●115

Packet capture running on a mirrored switchport, capturing all traffic on all VLAN in both directions. Packet capture shows a lot of TCP Dup ACK's. Could the packet capture being set up to capture traffic in both directions be causing this?

74079   24.614726   10.xx.xx.xx 10.xx.xx.xx TCP 78  [TCP Dup ACK 74061#4] 42900 → 80 [ACK] Seq=151 Ack=155475 Win=79680 Len=0 TSval=283933383 TSecr=1104610497 SLE=156923 SRE=161267
74080   24.614727   10.xx.xx.xx 10.xx.xx.xx TCP 78  [TCP Dup ACK 74061#5] 42900 → 80 [ACK] Seq=151 Ack=155475 Win=79680 Len=0 TSval=283933383 TSecr=1104610497 SLE=156923 SRE=161267
74081   24.614727   10.xx.xx.xx 10.xx.xx.xx TCP 78  [TCP Dup ACK 74061#6] 42900 → 80 [ACK] Seq=151 Ack=155475 Win=79680 Len=0 TSval=283933383 TSecr=1104610497 SLE=156923 SRE=162715
74082   24.614728   10.xx.xx.xx 10.xx.xx.xx TCP 78  [TCP Dup ACK 74061#7] 42900 → 80 [ACK] Seq=151 Ack=155475 Win=79680 Len=0 TSval=283933383 TSecr=1104610497 SLE=156923 SRE=162715

Thanks

answered 2018-02-01 11:32:48 +0000

Christian_R

2059 ●11 ●73 ●51 http://crnetpackets.com

From the screenshot it seems to be a duplicated frame. Maybe due to a network failure or capture failure. Hard to tell with nothing more than that screenshot.

If they are red herings due to a capture setup, then you can try to deduplicate the frames by using the cli editcap tool. Which comes with wireshark.

editcap -d  infile outfile

edit flag offensive delete link

Comments

While mirroring both directions of the whole VLAN intrinsically causes packet duplication in the capture (each packet is mirrored once when entering the switch through one port and once when leaving it through another one), such cause of duplicate ACK would mean just a single duplicate ACK per each "real" packet. However, you can see that here you have at least seven Dup ACKs referring to the same original packet (74061).

But when you look at the SLE and SRE values which differ between duplicates 4 and 5 at one hand and duplicates 6 and 7 at the other, I'm afraid that what you have captured is a case where there is a gap in received data and advanced TCP transmission control is active. So the ACK values indicate the last byte of data received continuously while the SLE and SRE values indicate which data have already been received ...(more)

sindy ( 2018-02-01 20:30:25 +0000 )edit

@sindy has pointed it out right.please use the editcap command to deduplicate the capture errors of Dup#5 and Dup#7

Christian_R ( 2018-02-02 07:06:37 +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.

TCP Dup ACK Question

1 Answer

Comments

Your Answer

Question Tools

Stats

TCP Dup ACK Question edit

1 Answer

Comments

Your Answer

Question Tools

Stats

TCP Dup ACK Question