kernel-packages team mailing list archive

[Sam Kumar <samkumar99@xxxxxxxxx>]

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.

** Tags added: kernel-bug-exists-upstream

** Changed in: linux (Ubuntu)
       Status: Incomplete => Confirmed

-- 
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