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

TCP 3 way handshake data in third message

0

Hi,

I have both a Linux and a Windows application. Both behave in the same way when a client connects to a server. I have WIRESHARK captures where it is clear to see that both applications perform the 3 way handshake but add some data (24 bytes in case if Linux, 16 bytes in case of Windows). The sixteen bytes I see being included from the windows side are fairly logical: immediately after getting confirmation of the connection I send a 16 byte message (CASyncSocket::OnConnect event). Its exactly those 16 bytes I see. From the Linux side I recognize some of the bytes (for example: the port number the client will use/has connected to) but I can't find where it sends that info.

My most important question though is: is sending extra data along with the final ACK a usual thing to do? It does not seem to do any harm as everything works but I am still curious.

asked 05 Sep '14, 07:37

fd9750's gravatar image

fd9750
11112
accept rate: 0%


2 Answers:

0

This might be "tcp fast open" handshakes.
Does cat /proc/sys/net/ipv4/tcp_fastopen show a 1 on your linux?
Can you post a sample to cloudshark.org?

answered 05 Sep '14, 08:35

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

such a useful link,thanks mrEEde for sharing this link.

(05 Sep '14, 10:11) kishan pandey

0

Ok, in the mean time everything has become clear:

1) Waiting for a short period before returning the third ACK is apparently common practice on both the Windows and the Linux TCP/IP stacks. If you send data shortly after connecting (getting the second SYN/ACK message) it just rides along in the packet with the required third ACK. If you don't send data fast enough the third ACK gets sent in a separate package without data.

2) The 24 byte block that gets sent by the Linux side turns out to be application specific and was hidden in the example code I used to implement my own code. The "hiding" was caused by the fact that every other send action was done using the Linux "write" function while the one that sent the 24 bytes was done by means of the Linux "send" function. That one performs a write operation directly to the socket instead of going via the file descriptor used by the "write" function.

answered 08 Sep '14, 23:44

fd9750's gravatar image

fd9750
11112
accept rate: 0%