This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

TCP DUPs on virtually every SSL package, but not on regular TCP. Where to look?

0

Hi,

What would cause TCP DUP's (and spurious retransmissions, fast retransmissions, a cpl up to a dozen) to be received from random SSL-enabled webservers on virtually every package, WHILE REGULAR TCP/IP (non-TLS) doesn't generate any DUP's? Zero. If the latter would be the case, I would just have a faulty router or a low level networking issue (hardware/IP stack). I fail to see how this only concerns SSL traffic, it clogs up a nice view in Wireshark with all the DUPs.

asked 13 Feb '16, 03:59

boiiingg's gravatar image

boiiingg
2335
accept rate: 0%

have you tried deduplicating your capture? See https://blog.packet-foo.com/2015/03/tcp-analysis-and-the-five-tuple/ for more info why.

(13 Feb '16, 05:30) Jasper ♦♦

(Thanks for https://blog.packet-foo.com/2015/03/tcp-analysis-and-the-five-tuple/)

Some issues I noticed:

  1. TCP DUPs all have the same Seq.no's but after testing with editcap and hexdec comparing I noticed they are not truly unique.
  2. The difference in DUPS only lies in the IPv4 Identification field (2 bytes) and as a result the Header checksum (2 bytes). This is systematic.
  3. Frequent errors in the expert window are: "Duplicate ACKs", "out-of-order" and "previous segment not captured"

Just a shot in the dark... I wonder if Wireshark somehow tricked, seeing these packages as DUP ACKs.

Are these issues typical for a SPAN VLAN monitoring port at the ISP?

Anything else that would explain change of the ID-field in the IPv4 header while the rest of the datagram is untouched?

(15 Feb '16, 00:41) boiiingg

Anything else that would explain change of the ID-field in the IPv4 header while the rest of the datagram is untouched?

The difference in IP ID field means that the "duplicates" have been really sent by the sending machine and haven't occurred due to properties of the capturing method.

Are these issues typical for a SPAN VLAN monitoring port at the ISP?

If you SPAN the whole VLAN and do not / can not set additional filtering on the switch, you basically get a duplicate of each and every packet because you get one copy of the packet when it enters the switch and another copy of the same packet when it leaves the switch, so it would not explain, even if the IP ID fields would not differ, why the DUPs only exist for the SSL traffic. (There are exceptions related to total traffic volume vs. the monitoring port bandwidth and to broadcast/multicast packets, but that's a different story).

So I'd vote for the SSL stack to be responsible.

(15 Feb '16, 00:54) sindy

I thought the SPAN VLAN would be a bit fat fetched ... I am going to run some more tests using a different SSL stack. Despite having a very popular system (Linux 3.16.0-4) with openssl 1.0.1k-3+deb8u1). Will need to reinstall the OS anyway in a cpl of days.

(15 Feb '16, 00:59) boiiingg

One Answer:

0

If it's only SSL/TLS it could be a security device interfering with SSL/TLS like a firewall. However, without access to a capture file it's hard to say more than that!

Regards
Kurt

answered 13 Feb '16, 04:26

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%