Simultaneous TCP Open does not work correctly

[Sam Kumar]

Hello,
I did an experiment to try out a TCP simultaneous open situation, where two TCP endpoints simultaneously initiate TCP connections to one another. Looking at RFC 793, Figure 8 (https://tools.ietf.org/html/rfc793#section-3.4), both sides should exchange a SYN and then a SYN-ACK, for a total of four exchanged segments.

Instead, I see that both sides exchange a SYN, SYN-ACK, and then another ACK, for a total of 6 exchanged segments. I would expect to not see the additional ACK after the SYN-ACK. I have attached output from Wireshark for details.

The way that I carried out the experiment is that I executed the following commands:
$ sudo tc qdisc add dev lo root netem delay 150ms
This adds a 150ms delay on the loopback interface so it's possible to simulate a simultaneous SYN. [I got this idea from a Stack Overflow Post, http://stackoverflow.com/questions/2231283/tcp-two-sides-trying-to-connect-simultaneously].

Then, I ran the following two commands, from two separate terminals, within close succession:
$ netcat -p 32068 127.0.0.1 32067
$ netcat -p 32067 127.0.0.1 32068

I then saw the two extra ACKs on Wireshark.

In case it's more convenient, I repeated the experiment using tcpdump and have reproduced the output below:

$ sudo tcpdump -i lo
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
[ I have omitted some extraneous segments here. ]
17:23:46.280963 IP localhost.32067 > localhost.32068: Flags [S], seq 19001790, win 43690, options [mss 65495,sackOK,TS val 957590 ecr 0,nop,wscale 7], length 0
17:23:46.412935 IP localhost.32068 > localhost.32067: Flags [S], seq 2415847777, win 43690, options [mss 65495,sackOK,TS val 957623 ecr 0,nop,wscale 7], length 0
17:23:46.431022 IP localhost.32068 > localhost.32067: Flags [S.], seq 2415847777, ack 19001791, win 43690, options [mss 65495,sackOK,TS val 957628 ecr 957590,nop,wscale 7], length 0
17:23:46.562968 IP localhost.32067 > localhost.32068: Flags [S.], seq 19001790, ack 2415847778, win 43690, options [mss 65495,sackOK,TS val 957661 ecr 957623,nop,wscale 7], length 0
17:23:46.581065 IP localhost.32067 > localhost.32068: Flags [.], ack 1, win 342, options [nop,nop,TS val 957665 ecr 957623], length 0
17:23:46.713070 IP localhost.32068 > localhost.32067: Flags [.], ack 1, win 342, options [nop,nop,TS val 957698 ecr 957590], length 0

I would expect the output to be:
17:23:46.280963 IP localhost.32067 > localhost.32068: Flags [S], seq 19001790, win 43690, options [mss 65495,sackOK,TS val 957590 ecr 0,nop,wscale 7], length 0
17:23:46.412935 IP localhost.32068 > localhost.32067: Flags [S], seq 2415847777, win 43690, options [mss 65495,sackOK,TS val 957623 ecr 0,nop,wscale 7], length 0
17:23:46.431022 IP localhost.32068 > localhost.32067: Flags [S.], seq 2415847777, ack 19001791, win 43690, options [mss 65495,sackOK,TS val 957628 ecr 957590,nop,wscale 7], length 0
17:23:46.562968 IP localhost.32067 > localhost.32068: Flags [S.], seq 19001790, ack 2415847778, win 43690, options [mss 65495,sackOK,TS val 957661 ecr 957623,nop,wscale 7], length 0
At which point the connection should be established.

Please consider the output above, and the attached wireshark output. I believe that this is a bug in the Linux TCP stack (though I haven't gotten a chance to look at the source code myself to verify that the bug is indeed there).

Sam Kumar

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: linux-image-4.2.0-25-generic 4.2.0-25.30
ProcVersionSignature: Ubuntu 4.2.0-25.30-generic 4.2.6
Uname: Linux 4.2.0-25-generic x86_64
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: sam 1940 F.... pulseaudio
 /dev/snd/controlC1: sam 1940 F.... pulseaudio
CurrentDesktop: Unity
Date: Thu Jan 21 17:20:24 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-02-09 (346 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
MachineType: Dell Inc. Inspiron 5749
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-25-generic.efi.signed root=UUID=59b816e8-0ee9-4d42-a6aa-3372bc4de55f ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.2.0-25-generic N/A
 linux-backports-modules-4.2.0-25-generic N/A
 linux-firmware 1.149.3
SourcePackage: linux
UpgradeStatus: Upgraded to wily on 2015-10-23 (90 days ago)
dmi.bios.date: 11/04/2014
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A01
dmi.board.name: 092VC0
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: Not Specified
dmi.modalias: dmi:bvnDellInc.:bvrA01:bd11/04/2014:svnDellInc.:pnInspiron5749:pvrA01:rvnDellInc.:rn092VC0:rvrA00:cvnDellInc.:ct8:cvrNotSpecified:
dmi.product.name: Inspiron 5749
dmi.product.version: A01
dmi.sys.vendor: Dell Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.4 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-wily

[Sam Kumar (samkumar99)]

I finally got around to testing this issue with an upstream kernel. I used the latest version, 4.5.0-040500rc4-generic. The bug still exists in that version of the kernel.

Sorry it took so long for me to get around to this; I'm a college student and I've been really busy with classes for the past few weeks.