TCP Handshake unexpected behaviour

asked 2024-09-04 07:09:15 +0000

LeeC
3 ●1 ●2

updated 2024-09-04 07:37:55 +0000

pcapng: https://drive.google.com/file/d/19H6-...

Hi, I am very new to learning about networking (studying my first university unit at the moment) and I am getting some unexpected results when trying to identify TCP and TLS handshaking frames. What I expected to see was TCP SYN->SYN ACK->ACK to TLS ClientHello->ServerHello->KeyExchange->FIN.

What I got was: Duplicate TCP handshake on incremented ports, Malformed packet, TCP ACKed unseen segment, Dup ACK, Previous segment not captured.

I have had trouble trying to find information on troubleshooting, likely due to my inexperience. My tutors couldn't explain what was causing the errors either.

Would really appreciate any insight into what's going on. Thankyou!

edit: To add I have tried multiple browsers(chrome+firefox), reinstalled Wireshark(using v4.4.0), flushed dns.

No.     Time           Source                Destination           Protocol Length Info
  1 0.000000       2001:8003:5133:6700:4582:92cd:d481:6143 2606:2800:21f:cb07:6820:80da:af6b:8b2c TCP      86     63223 → 443 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 WS=256 SACK_PERM

Frame 1: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface \Device\NPF_{9412F1C9-F358-417B-89CD-BC6023496F29}, id 0
Ethernet II, Src: MicroStarINT_56:34:d2 (2c:f0:5d:56:34:d2), Dst: TechnicolorD_a8:36:04 (d4:35:1d:a8:36:04)
Internet Protocol Version 6, Src: 2001:8003:5133:6700:4582:92cd:d481:6143, Dst: 2606:2800:21f:cb07:6820:80da:af6b:8b2c
Transmission Control Protocol, Src Port: 63223, Dst Port: 443, Seq: 0, Len: 0

No.     Time           Source                Destination           Protocol Length Info
      2 0.000173       2001:8003:5133:6700:4582:92cd:d481:6143 2606:2800:21f:cb07:6820:80da:af6b:8b2c TCP      86     63224 → 443 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 WS=256 SACK_PERM

Frame 2: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface \Device\NPF_{9412F1C9-F358-417B-89CD-BC6023496F29}, id 0
Ethernet II, Src: MicroStarINT_56:34:d2 (2c:f0:5d:56:34:d2), Dst: TechnicolorD_a8:36:04 (d4:35:1d:a8:36:04)
Internet Protocol Version 6, Src: 2001:8003:5133:6700:4582:92cd:d481:6143, Dst: 2606:2800:21f:cb07:6820:80da:af6b:8b2c

Transmission Control Protocol, Src Port: 63224, Dst Port: 443, Seq: 0, Len: 0

No.     Time           Source                Destination           Protocol Length Info
      3 0.159008       2606:2800:21f:cb07:6820:80da:af6b:8b2c 2001:8003:5133:6700:4582:92cd:d481:6143 TCP      86     443 → 63224 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1220 SACK_PERM WS=512

Frame 3: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface \Device\NPF_{9412F1C9-F358-417B-89CD-BC6023496F29}, id 0

Ethernet II, Src: TechnicolorD_a8:36:04 (d4:35:1d:a8:36:04), Dst: MicroStarINT_56:34:d2 (2c:f0:5d:56:34:d2)
Internet Protocol Version 6, Src: 2606:2800:21f:cb07:6820:80da:af6b:8b2c, Dst: 2001:8003:5133:6700:4582:92cd:d481:6143
Transmission Control Protocol, Src Port: 443, Dst Port: 63224, Seq: 0, Ack: 1, Len: 0

No.     Time           Source                Destination           Protocol Length Info
      4 ...

(more)

edit retag flag offensive close merge delete

Comments

How is the capture being made? Please provide details on client, internet access network technology being used, topology.

Jaap ( 2024-09-05 07:56:14 +0000 )edit

I can see the Malformed packet frames exceed the MSS agreed upon in the TCP handshake(packet list pane shows malformed packet length 2098, MSS 1220 ACK), Wireshark hints at 'TCP segmentation offload' in the details pane with payload length = 0. I'm trying to learn what this means.

LeeC ( 2024-09-05 08:03:23 +0000 )edit

How is the capture being made? Please provide details on client, internet access network technology being used, topology.

Windows 10 PC capturing on ethernet adapter, Wireshark v4.4.0 - display filter "ipv6.addr == 2606:2800:21f:cb07:6820:80da:af6b:8b2c", direct ethernet to Technicolor DJA0231 router LAN port, gateway and DNS managed by ISP Telstra Bigpond.

Traffic generated from Google Chrome Version 128.0.6613.115 entering example.com into address bar.

Please let me know if there's any further information needed.

LeeC ( 2024-09-05 08:09:24 +0000 )edit

Great info, helps a lot. And Sake nailed it, again :)

Jaap ( 2024-09-05 12:02:34 +0000 )edit

add a comment

answered 2024-09-05 09:41:45 +0000

SYN-bit

18496 ●9 ●331 ●255 https://SYN-b.it

What I got was: Duplicate TCP handshake on incremented ports

This is normal behavior of web browsers, they open multiple TCP connections at the same time to be able to request HTTP objects in parallel, even when not explicitly needed (in case the HTML file does not include any other elements)

Malformed packet

This is the first time I see this myself, but the expert info hints that this can be caused by TSO enabled NICs, so I looked at the IPv6 protocol preferences to see if there is a preference to ignore this. And there is. You can enable the option "Support packet-capture from IPv^ TSO-enabled hardware" in order for Wireshark to ignore this protocol error (there should never be a payload length field with value 0 if there is indeed IPv6 payload). With this setting on the TCP dissector will be called and all packet data will be dissected by Wireshark

TCP ACKed unseen segment

As the malformed packet does not get processed by the TCP dissector, it did not see the TCP data in it and therefor this ACK is ACKing data that has not been seen, hence the warning With the above option enabled, this warning goes away.

Dup ACK

This packet is really in the trace, not sure why without deep analysis. And even then, sometimes TCP stacks behave weird, so there might not be a logical explanation.

Previous segment not captured.

As the malformed packet does not get processed by the TCP dissector, it did not see the TCP data in it and therefor this segment follows that that was not seen by wireshark, triggering this warning. With the above option enabled, this warning goes away.

edit flag offensive delete link

Comments

You're a legend, thankyou for the brilliant explanation!

LeeC ( 2024-09-05 10:47:36 +0000 )edit

I'm guessing the resulting checksum errors are caused by trying to match the checksum of the original segment to the fragmented segment? I could turn this off in my network adapter settings right?

LeeC ( 2024-09-05 10:59:15 +0000 )edit

If you filter in ipv6.src == 2001:8003:5133:6700:4582:92cd:d481:6143, you can see that every packet has a bad checksum. Most of them do match the partial checksum, so they are not marked as bad. This is new behavior of Wireshark to me and IMHO is wrong, the checksum is still bad, even if it does match the partial checksum of the pseudo header. This is something to discuss and see if agree with the current implementation.

So I assume TCP segmentation offloading is also enabled on your NIC and you could turn this off to make sure the checksums of outgoing packets are calculated by the OS, and therefor should be correct when passing npcap to be captured.

SYN-bit ( 2024-09-05 11:28:28 +0000 )edit

I agree with your assertion. I have switched off TCP segmentation offloading now and will see how performance is affected. Thankyou again for your explanations.

LeeC ( 2024-09-05 11:40:34 +0000 )edit

add a comment

TCP Handshake unexpected behaviour

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

TCP Handshake unexpected behaviour edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

TCP Handshake unexpected behaviour