| 2008-09-02 14:09:13 |
Marques Johansson |
bug |
|
|
added bug |
| 2008-09-12 11:52:37 |
Timothy G. Rundle |
bug |
|
|
added attachment 'lscpi.txt' (lscpi.txt) |
| 2008-10-03 00:11:20 |
Marques Johansson |
bug |
|
|
added attachment 'dmesg' (dmesg from 2.6.26-5-generic (network functioning properly)) |
| 2008-10-03 00:21:14 |
Marques Johansson |
bug |
|
|
added attachment 'dmesg.1' (dmesg from 2.6.27-4-generic (some sites will not make connections)) |
| 2008-10-06 14:27:02 |
Marques Johansson |
description |
2.6.27 introduced a networking issue, leaving sites like youtube.com, and microsoft.com not working via the web browsers on one of my systems (but not others). This system, like the others, was upgraded from Hardy.
I am unable to transfer files from archive.ubuntu.com via apt (http) or lftp (ftp, not http). I can connect via ftp and traverse and list files/directories, but when I try to "get", the transfer stays at 0 bytes.
Likewise, if I do a naive "telnet youtube.com 80"
GET / HTTP/1.1
HOST: youtube.com
I get a response, but when the web browser (firefox,opera) attempts to load these sites they do not progress - the 'transferring' status stays fixed. Some web sites (google, yahoo) work fine though.
When I reboot this system back to the 2.6.26-5 kernel everything works as it should. I tried setting rp_filter=0 on all, eth0, and default (instead of the Ubuntu default 1), as I have seen this and ecn settings cause site specific problems. Those settings had no effect in this case.
I only have remote access to this system. I am able to remotely ssh into this box, but I could not scp a file to it. I was able to scp to this host from host on the same local network, however. I have tested this problem using both the wired ethernet adapter, and using a wireless adapter. The same problem existed in both configurations - some websites could be reached, while others could not.
The other Intrepid host on the same network did not have these connection issues. |
2.6.27 introduced a networking issue, leaving sites like youtube.com, and microsoft.com not working via the web browsers on one of my systems (but not others). This system, like the others, was upgraded from Hardy.
I am unable to transfer files from archive.ubuntu.com via apt (http) or lftp (ftp, not http). I can connect via ftp and traverse and list files/directories, but when I try to "get", the transfer stays at 0 bytes.
Likewise, if I do a naive "telnet youtube.com 80"
GET / HTTP/1.1
HOST: youtube.com
I get a response, but when the web browser (firefox,opera) attempts to load these sites they do not progress - the 'transferring' status stays fixed. Some web sites (google, yahoo) work fine though.
When I reboot this system back to the 2.6.26-5 kernel everything works as it should. I tried setting rp_filter=0 on all, eth0, and default (instead of the Ubuntu default 1), as I have seen this and ecn settings cause site specific problems. Those settings had no effect in this case.
I only have remote access to this system. I am able to remotely ssh into this box, but I could not scp a file to it. I was able to scp to this host from a host on the same local network, however. I have tested this problem using both the wired ethernet adapter, and using a wireless adapter. The same problem existed in both configurations - some websites could be reached, while others could not.
The other Intrepid host on the same network did not have these connection issues. |
|
| 2008-10-06 14:27:27 |
Marques Johansson |
title |
unable to visit some websites and ftpsites with 2.6.27-2 |
unable to visit some websites and ftpsites with 2.6.27 |
|
| 2008-10-12 23:03:28 |
Forest Bond |
bug |
|
|
added attachment 'wireshark.txt' (wireshark trace) |
| 2008-10-12 23:21:39 |
Forest Bond |
bug |
|
|
added attachment 'wireshark2.txt' (wireshark trace) |
| 2008-10-12 23:40:03 |
Forest Bond |
bug |
|
|
added attachment 'wireshark3.txt' (wireshark trace) |
| 2008-10-15 00:46:21 |
Forest Bond |
bug |
|
|
added attachment 'wireshark.pcap' (PCAP file) |
| 2008-10-15 00:47:11 |
Forest Bond |
bug |
|
|
added attachment 'wireshark2.pcap' (PCAP file) |
| 2008-10-15 00:48:08 |
Forest Bond |
bug |
|
|
added attachment 'wireshark3.pcap' (PCAP file) |
| 2008-10-15 00:48:29 |
Steve Langasek |
linux: status |
New |
Confirmed |
|
| 2008-10-15 00:48:29 |
Steve Langasek |
linux: importance |
Undecided |
High |
|
| 2008-10-15 00:48:29 |
Steve Langasek |
linux: statusexplanation |
|
Such a bug has a significant impact on the release so I'm confirming this for intrepid, but from the available information, I'm not sure that we're really looking at a kernel bug here. The wireshark traces available certainly seem to indicate a failure of the return traffic from the server to be received by the client, which I would expect to manifest much more dramatically if it were the result of a bug in the client stack.
I've requested full pcap traces, which may provide more information here. |
|
| 2008-10-16 09:24:11 |
Steve Langasek |
bug |
|
|
assigned to ubuntu-release-notes |
| 2008-10-16 22:30:21 |
Steve Langasek |
linux: status |
Confirmed |
Invalid |
|
| 2008-10-16 22:30:21 |
Steve Langasek |
linux: statusexplanation |
Such a bug has a significant impact on the release so I'm confirming this for intrepid, but from the available information, I'm not sure that we're really looking at a kernel bug here. The wireshark traces available certainly seem to indicate a failure of the return traffic from the server to be received by the client, which I would expect to manifest much more dramatically if it were the result of a bug in the client stack.
I've requested full pcap traces, which may provide more information here. |
Thanks for the feedback; marking this as invalid for the linux package, because this has been isolated as a router bug and not a bug in the Linux kernel. It is not generally appropriate to diverge from the upstream kernel over policy decisions in the IP stack, when the kernel is not actually buggy and the problem is with other routers that fail to correctly handle compliant TCP/IP traffic.
We will document in the release notes, so that users are informed of the problem and can follow a step-by-step process to change their kernel settings. |
|
| 2008-10-22 10:29:42 |
Colin Watson |
ubuntu-release-notes: status |
New |
Triaged |
|
| 2008-10-22 10:29:42 |
Colin Watson |
ubuntu-release-notes: assignee |
|
kamion |
|
| 2008-10-22 10:29:42 |
Colin Watson |
ubuntu-release-notes: importance |
Undecided |
Medium |
|
| 2008-10-22 10:29:42 |
Colin Watson |
ubuntu-release-notes: statusexplanation |
|
|
|
| 2008-10-22 11:15:12 |
Colin Watson |
ubuntu-release-notes: status |
Triaged |
Fix Released |
|
| 2008-10-22 11:15:12 |
Colin Watson |
ubuntu-release-notes: statusexplanation |
|
I've added this text to the release notes (wiki notation):
== TCP timestamps ==
Linux 2.6.27 now sets the timestamps option in TCP packets ([[http://www.ietf.org/rfc/rfc1323.txt|RFC 1323]]), an option dating from 1992 to improve performance over high-bandwidth-times-latency paths and to improve reliability over high-bandwidth paths, which was previously omitted by mistake.
However, this change appears to cause problems for some users, believed to be due to buggy routers between the user and the destination server (for example, this has been reported by several Verizon DSL users). If your Internet connection mostly appears to be working correctly, but you have problems connecting to certain sites, then try the following command: {{{
sudo sysctl -w net.ipv4.tcp_timestamps=0
}}}
This change will normally expire the next time you restart your computer. If it fixes the problem, then you can make the change permanent by running `sudo editor /etc/sysctl.conf` and adding the following line to the end of that file: {{{
net.ipv4.tcp_timestamps = 0
}}}
The real bug here is in your router (if you own one) or your ISP's routers. If a firmware upgrade is available for your router, follow your manufacturer's instructions to upgrade it. Otherwise, contact the support department of your router manufacturer or your ISP for further advice.
See [[https://launchpad.net/bugs/264019|bug #264019]], and thanks to [[http://wiki.mandriva.com/en/2009.0_Errata#TCP_timestamps|Mandriva]] for their clear documentation of this issue. |
|
| 2008-10-22 20:41:55 |
Steve Langasek |
bug |
|
|
assigned to linux |
| 2008-10-22 20:50:19 |
Steve Langasek |
ubuntu-release-notes: status |
Fix Released |
In Progress |
|
| 2008-10-22 20:50:19 |
Steve Langasek |
ubuntu-release-notes: statusexplanation |
I've added this text to the release notes (wiki notation):
== TCP timestamps ==
Linux 2.6.27 now sets the timestamps option in TCP packets ([[http://www.ietf.org/rfc/rfc1323.txt|RFC 1323]]), an option dating from 1992 to improve performance over high-bandwidth-times-latency paths and to improve reliability over high-bandwidth paths, which was previously omitted by mistake.
However, this change appears to cause problems for some users, believed to be due to buggy routers between the user and the destination server (for example, this has been reported by several Verizon DSL users). If your Internet connection mostly appears to be working correctly, but you have problems connecting to certain sites, then try the following command: {{{
sudo sysctl -w net.ipv4.tcp_timestamps=0
}}}
This change will normally expire the next time you restart your computer. If it fixes the problem, then you can make the change permanent by running `sudo editor /etc/sysctl.conf` and adding the following line to the end of that file: {{{
net.ipv4.tcp_timestamps = 0
}}}
The real bug here is in your router (if you own one) or your ISP's routers. If a firmware upgrade is available for your router, follow your manufacturer's instructions to upgrade it. Otherwise, contact the support department of your router manufacturer or your ISP for further advice.
See [[https://launchpad.net/bugs/264019|bug #264019]], and thanks to [[http://wiki.mandriva.com/en/2009.0_Errata#TCP_timestamps|Mandriva]] for their clear documentation of this issue. |
More information has become available about this issue via the duplicate bug #272896, including an upstream bug report where upstream discusses a fix to preserve interoperability with these devices without losing tcp timestamp support.
I'm reopening this bug report, we should update the release notes with this new info and hopefully we can also get this into intrepid in an SRU. |
|
| 2008-10-22 20:50:37 |
Steve Langasek |
ubuntu-release-notes: assignee |
kamion |
vorlon |
|
| 2008-10-22 20:50:37 |
Steve Langasek |
ubuntu-release-notes: statusexplanation |
More information has become available about this issue via the duplicate bug #272896, including an upstream bug report where upstream discusses a fix to preserve interoperability with these devices without losing tcp timestamp support.
I'm reopening this bug report, we should update the release notes with this new info and hopefully we can also get this into intrepid in an SRU. |
|
|
| 2008-10-22 20:50:55 |
Steve Langasek |
linux: status |
Invalid |
Triaged |
|
| 2008-10-22 20:50:55 |
Steve Langasek |
linux: statusexplanation |
Thanks for the feedback; marking this as invalid for the linux package, because this has been isolated as a router bug and not a bug in the Linux kernel. It is not generally appropriate to diverge from the upstream kernel over policy decisions in the IP stack, when the kernel is not actually buggy and the problem is with other routers that fail to correctly handle compliant TCP/IP traffic.
We will document in the release notes, so that users are informed of the problem and can follow a step-by-step process to change their kernel settings. |
|
|
| 2008-10-22 20:59:59 |
Bug Watch Updater |
linux: status |
Unknown |
Confirmed |
|
| 2008-10-22 22:53:47 |
Steve Langasek |
ubuntu-release-notes: status |
In Progress |
Fix Released |
|
| 2008-10-22 22:53:47 |
Steve Langasek |
ubuntu-release-notes: statusexplanation |
|
updated the release notes to mention that upstream is working on a fix. |
|
| 2008-10-23 15:21:15 |
Matt Zimmerman |
linux: milestone |
|
intrepid-updates |
|
| 2008-10-26 17:30:50 |
Bug Watch Updater |
linux: status |
Confirmed |
Fix Released |
|
| 2008-10-27 10:45:03 |
Colin Watson |
bug |
|
|
assigned to procps (Ubuntu) |
| 2008-10-27 10:45:50 |
Colin Watson |
procps: status |
New |
In Progress |
|
| 2008-10-27 10:45:50 |
Colin Watson |
procps: assignee |
|
kamion |
|
| 2008-10-27 10:45:50 |
Colin Watson |
procps: importance |
Undecided |
Critical |
|
| 2008-10-27 10:45:50 |
Colin Watson |
procps: statusexplanation |
|
Due to time constraints, it looks as if we're going to work around this in procps for 8.10. |
|
| 2008-10-27 10:45:50 |
Colin Watson |
procps: milestone |
|
ubuntu-8.10 |
|
| 2008-10-27 11:12:31 |
Launchpad Janitor |
procps: status |
In Progress |
Fix Released |
|
| 2008-10-27 13:42:18 |
Matt Zimmerman |
linux: importance |
High |
Medium |
|
| 2008-10-27 13:42:18 |
Matt Zimmerman |
linux: statusexplanation |
|
As the workaround is now in place, I'm lowering the importance of the kernel task to medium as it's no longer urgent. |
|
| 2008-10-27 15:05:08 |
Adam Buchbinder |
bug |
|
|
assigned to linux (Mandriva) |
| 2008-10-28 11:42:04 |
Bug Watch Updater |
linux: status |
Unknown |
Invalid |
|
| 2008-10-29 16:34:50 |
Tim Gardner |
linux: status |
Triaged |
Fix Committed |
|
| 2008-10-29 16:34:50 |
Tim Gardner |
linux: assignee |
|
timg-tpi |
|
| 2008-10-29 16:34:50 |
Tim Gardner |
linux: importance |
Medium |
High |
|
| 2008-10-29 16:34:50 |
Tim Gardner |
linux: statusexplanation |
As the workaround is now in place, I'm lowering the importance of the kernel task to medium as it's no longer urgent. |
Intrepid - tcp: Restore ordering of TCP options for the sake of inter-operability |
|
| 2008-10-30 00:06:22 |
Steve Langasek |
ubuntu-release-notes: status |
Fix Released |
Confirmed |
|
| 2008-10-30 00:06:22 |
Steve Langasek |
ubuntu-release-notes: statusexplanation |
updated the release notes to mention that upstream is working on a fix. |
|
|
| 2008-10-30 08:38:54 |
Steve Langasek |
ubuntu-release-notes: status |
Confirmed |
Invalid |
|
| 2008-10-30 08:38:54 |
Steve Langasek |
ubuntu-release-notes: statusexplanation |
|
the decision has been made to release this as a security update immediately post-release, so a separate release notes entry is not warranted. |
|
| 2008-10-30 14:58:08 |
Pete Graner |
linux: status |
Fix Committed |
Fix Released |
|
| 2008-10-30 14:58:08 |
Pete Graner |
linux: statusexplanation |
Intrepid - tcp: Restore ordering of TCP options for the sake of inter-operability |
linux (2.6.27-7.15) intrepid-security; urgency=low
[ Upstream Kernel Changes ]
* tcp: Restore ordering of TCP options for the sake of inter-operability
- LP: #264019
-- Tim Gardner <tim.gardner@canonical.com> Mon, 27 Oct 2008 19:28:06 -0600
|
|
| 2008-11-02 21:41:27 |
Dean Holland |
bug |
|
|
added attachment '2.6.27-issue.pcap' (2.6.27-issue.pcap) |
| 2008-11-02 21:42:11 |
Dean Holland |
bug |
|
|
added attachment '2.6.24-working.pcap' (2.6.24-working.pcap) |
| 2008-11-03 14:24:53 |
Matt Zimmerman |
title |
unable to visit some websites and ftpsites with 2.6.27 |
TCP option ordering in 2.6.27 is not interoperable wi9th some network equipment |
|
| 2008-11-03 14:25:03 |
Matt Zimmerman |
title |
TCP option ordering in 2.6.27 is not interoperable wi9th some network equipment |
TCP option ordering in 2.6.27 is not interoperable with some network equipment |
|
| 2009-01-20 16:04:04 |
romesh |
linux: bugtargetdisplayname |
linux (Ubuntu) |
autorun4linuxcd (Ubuntu) |
|
| 2009-01-20 16:04:04 |
romesh |
linux: bugtargetname |
linux (Ubuntu) |
autorun4linuxcd (Ubuntu) |
|
| 2009-01-20 16:04:04 |
romesh |
linux: statusexplanation |
|
|
|
| 2009-01-20 16:04:04 |
romesh |
linux: title |
Bug #264019 in linux (Ubuntu): "TCP option ordering in 2.6.27 is not interoperable with some network equipment" |
Bug #264019 in autorun4linuxcd (Ubuntu): "TCP option ordering in 2.6.27 is not interoperable with some network equipment" |
|
| 2009-06-27 04:25:20 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/karmic/procps |
|
| 2009-06-27 04:32:07 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-branches/ubuntu/intrepid/procps/intrepid-security |
|
| 2009-08-28 21:28:23 |
O.Chr.Jensen |
linux: status |
Fix Released |
In Progress |
|
| 2009-08-28 21:53:15 |
Steve Langasek |
linux: status |
In Progress |
Fix Released |
|
| 2011-02-14 15:24:36 |
Bug Watch Updater |
linux (Mandriva): importance |
Unknown |
High |
|
