TCP uses wrong MTU/MSS size for IPv6

[Roland Bless]

TCP uses an MSS of 1440 although the IPv6 MTU size is set to 1280 by auto configuration (router advertisements). This worked well under gutsy so far, but now TCP connections fail because PMTU discovery does not work from the other end correctly (probably due to tunnel ingress).
TCP must not use a value larger than the MTU

During SYN-Handshake my hardy system sends:
Transmission Control Protocol, Src Port: 47070 (47070), Dst Port: http (80), Seq: 0, Len: 0
    Source port: 47070 (47070)
    Destination port: http (80)
    Sequence number: 0 (relative sequence number)
    Header length: 40 bytes
    Flags: 0x02 (SYN)
    Window size: 5760
    Checksum: 0xc4b5 [correct]
    Options: (20 bytes)
        Maximum segment size: 1440 bytes
        SACK permitted
        Timestamps: TSval 58913848, TSecr 0
        NOP
        Window scale: 7 (multiply by 128)

Although:
net.ipv6.conf.eth0.mtu = 1280

ip -6 r s default
default via fe80::207:e9ff:fe23:e706 dev eth0 proto kernel metric 1024 expires 407sec mtu 1280 advmss 1440 hoplimit 64

advmss is obviously wrong

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Neil Munro (neilmunro-deactivatedaccount)]

The Intrepid Ibex 8.10 Beta release was most recently announced - http://www.ubuntu.com/testing/intrepid/beta . It contains the 2.6.27 Ubuntu kernel. It would be great if you could test and verify if this is still an issue. The status is being set to Incomplete until we receive further feedback. Thanks.

[clerum (cody-lerum)]

Seeing same/similar issue. While doing SSH or SCP to a Hardy x64 install (Linux hardy 2.6.24-21-server #1 SMP Mon Aug 25 17:28:54 UTC 2008 x86_64 GNU/Linux)

What I am seeing via a TCP dump on the server is that it is sending packets up to 2954 bytes. The MTU on the interface is standard and set at 1500 bytes.

root@hardy:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0c:29:f6:ae:12
          inet addr:208.85.x.x Bcast:208.85.x.x Mask:255.255.255.240
          inet6 addr: x:x:0:4::54/64 Scope:Global
          inet6 addr: fe80::20c:29ff:fef6:ae12/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:505026 errors:0 dropped:0 overruns:0 frame:0
          TX packets:434987 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:243051539 (231.7 MB) TX bytes:285760463 (272.5 MB)
          Base address:0x1070 Memory:f4820000-f4840000

[clerum (cody-lerum)]

Tested under ibex beta. Same issue

root@ibex:~# uname -a
Linux ibex 2.6.27-7-server #1 SMP Wed Oct 22 02:10:40 UTC 2008 x86_64 GNU/Linux
root@ibex:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:0c:29:4d:1e:0c
          inet addr:208.85.x.x Bcast:208.85.x.x Mask:255.255.255.224
          inet6 addr: x:x:0:2::14/64 Scope:Global
          inet6 addr: fe80::20c:29ff:fe4d:1e0c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:4824 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14772 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:485532 (485.5 KB) TX bytes:18416410 (18.4 MB)

[clerum (cody-lerum)]

Acutally under IBEX it appears to be even larger. the packets go up to 15914 in size....on a 1500 byte MTU link

[clerum (cody-lerum)]

root@ibex:~# ip -6 r s default
default via x:x:0:2::1 dev eth0 metric 1 mtu 1500 advmss 1440 hoplimit 4294967295

[clerum (cody-lerum)]

Still exists under the full release of IBEX

[clerum (cody-lerum)]

While I cannot assist with coding a fix I can help with responsive to testing.

Please let me know if you need further debugs, or want me to try a patch.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Roland Bless (roland-bless)]

Clerum, for me it works under 8.10 (Kubuntu) actually.

The problem exists only after bringing up the interface, e.g., ifdown eth0 followed by
ifup eth0 results in ip -6 r s default
default via xyz dev eth0 proto kernel metric 1024 expires 527sec mtu 1280 advmss 1440 hoplimit 64
but removing the default route
ip -6 r del default
and waiting some seconds on the unsolicited router advertisements (announcing 1280 due
to IPv6 tunnel) re-adds the default route correctly.
ip -6 r s default
default via xyz dev eth0 proto kernel metric 1024 expires 538sec mtu 1280 advmss 1220 hoplimit 64
 I use this as a workaround. Furthermore, the problem didn't exist in the same kernel version under debian, so it seemed to be ubuntu specific.

[clerum (cody-lerum)]

Ronald, are you seeing the same large packet MTU's?

root@hardy:~# ip -6 r s default
default via 2607:f3d0:0:4::1 dev eth0 metric 1 expires -1183414sec mtu 1500 advmss 1440 hoplimit 4294967295

What appears to be happening to me is that programs (scp, ftp) are using the MTU from Lo0 for ipv6 packets. Thus I get packets with sizes much larger then MTU

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:1070 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1070 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:79968 (78.0 KB) TX bytes:79968 (78.0 KB)

[clerum (cody-lerum)]

Also the boxes in question are LTS boxes on vmware so moving to 8.10 isn't an option at this point.

[Roland Bless (roland-bless)]

clerum wrote:
> Also the boxes in question are LTS boxes on vmware so moving to 8.10
> isn't an option at this point.

That's correct. Since 8.04 is LTS, one should release a fix for it.
What is observed, however, was an advertised MSS of 1440 by TCP
not anything larger. Is your communication happening locally
within your machine (e.g., between host and vmware boxes?).
Did you Wireshark/TCPDUMP your TCP connection setups?

Regards,
 Roland

[clerum (cody-lerum)]

The issue is between host and vmware boxes....not guest to guest.

There is a wireshark attached and you can see the boxes are sending packets much larger than the interfaces MTU (15914 bytes)

See ipv6-filtered.pcap

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[clerum (cody-lerum)]

This issue doesn't appear in 9.10

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]