kernel-packages team mailing list archive

Thread
Date
[Bug 1536861] [NEW] Simultaneous TCP Open does not work correctly

To: kernel-packages@xxxxxxxxxxxxxxxxxxx
From: Sam Kumar <samkumar99@xxxxxxxxx>
Date: Fri, 22 Jan 2016 01:27:27 -0000
Reply-to: Bug 1536861 <1536861@xxxxxxxxxxxxxxxxxx>
Sender: bounces@xxxxxxxxxxxxx
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
Follow ups

[Bug 1536861] Re: Simultaneous TCP Open does not work correctly
From: Christopher M. Penalver, 2016-02-16
[Bug 1536861] Re: Simultaneous TCP Open does not work correctly
From: Sam Kumar, 2016-02-16
[Bug 1536861] Re: Simultaneous TCP Open does not work correctly
From: Christopher M. Penalver, 2016-01-31
[Bug 1536861] Re: Simultaneous TCP Open does not work correctly
From: Joseph Salisbury, 2016-01-22
[Bug 1536861] Status changed to Confirmed
From: Brad Figg, 2016-01-22