Public bug reported: 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. ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: amd64 apport-bug wily -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1536861 Title: Simultaneous TCP Open does not work correctly Status in linux package in Ubuntu: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1536861/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
