Cannot connect to router/server/proxy with bad TCP Wscale implementation

Not an Ubuntu bug though.
Broken router and tcp_windows_scaling on
Don't know why it works with dapper, tcp_windows_scaling should be on too.

Bug #59331 is back...

Can confirm this behaviour in Feisty. Only occurs on one of the Uni subnets I use, and only with Feisty (not Dapper or Edgy). Was fixed as per Bug #59331, or by installing Firestarter, presumably because Firestarter uses the iptables rule:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

I also have problems with feisty.

Please disable the TCP window stuff. It only gives Ubuntu bad reputation.

The problem is still present in Gusty. There is a simple workaround posted here (http://ubuntuforums.org/showthread.php?t=383390) and this bug is also reported in Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401435). For user who are aware of this problem solution is very simple, but for new ones I may be a real pain in the neck, especially when Ubuntu hangs during installation while trying to download packages.

My proposal is to turn off tcp_window_scaling feature or add tcp_wmem and tcp_rmem workaround during installation process. It could be also possible to automatically turn this feature on when there is a problem with Internet connection during installation process. We could also create some kind of tip message, which will appear when connection is impossible.

I really think we should think something out because this problem has a very negative influence from the outset on potential new Ubuntu users. The worst part of it is that, if you can't connect to the Internet you are unable to find a solution.

As far as routers are concerned I got across this problem on my Linksys WRT54GS v.4. I thought that it is pure linksys firmware problem that is not ready for enabling window scaling as defined in RFC1323, but the problem is still present while using DD-WRT v24 RC-2 (09/04/07) std.

Confirmed it still seems to be an issue when installing from alternate.

Linux jojo 2.6.22-14-generic #1 SMP Wed Oct 10 06:00:47 GMT 2007 i686 GNU/Linux

confirmation based on tests, which were done on 2 separate computers

I can confirm this on dialup that the above url does not resolve but does exactly what u say. I'm using Gutsy of course.

I also believe that the workaround to this bug must be enabled by default.

For those who are not familiar with this bugs, here are very good read :
http://lwn.net/Articles/92727/
http://inodes.org/blog/2006/09/06/tcp-window-scaling-and-kernel-2617/

And a workaround patch :
http://oss.sgi.com/archives/netdev/2004-07/msg00142.html

As discussed at Bug 209359, this bug also affects Hardy

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
OR
echo 4096 65536 65536 > /proc/sys/net/ipv4/tcp_rmem
wcho 4096 65536 65536 > /proc/sys/net/ipv4/tcp_wmem
OR
ip route add $THEIR_IP/32 via $MY_GATEWAY window 65535
OR
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

did not resolve my problem.

http://www.priberam.pt/dlpo/ or translate.live.com are examples of sites that i can't load.

I have a WBMR-G125 (Wireless-G 125* High Speed Broadband ADSL2+ Modem Router)
I already report this issue to buffalo.

In the mean time,
could you give me some directives in order to debug my problem?

Please try

=================
vi /etc/sysctl.conf

add the following two lines

net.ipv4.tcp_wmem = 4096 16384 131072
net.ipv4.tcp_rmem = 4096 87380 174760

save and reset sysctl

sysctl -p
===================

After configure kernel parameters as you had tell
sysctl -p
kernel.printk = 4 4 1 7
kernel.maps_protect = 1
fs.inotify.max_user_watches = 524288
vm.mmap_min_addr = 65536
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_wmem = 4096 16384 131072
net.ipv4.tcp_rmem = 4096 87380 174760
I still can't load none of the referred pages.

The page
http://www.ureg.ohio-state.edu/ourweb/online.html
referred above load correctly.

At my LAN only pcs with msw xp surf correctly the web.
Ubuntu, gentoo and msw vista have this issue.

Follow wireshark (ethereal) log files of a failed connection using wget to try retrieve skydrive.live.com
Relevant frames: 1-42

(Follow in plain text and also a wireshark/tcpdump file to open with the appropriate tools.)

Hope you can help me debug this network issue

$ cat /proc/sys/net/ipv4/tcp_rmem
4096 87380 174760
$ cat /proc/sys/net/ipv4/tcp_wmem
4096 16384 131072
$ cat /proc/sys/net/ipv4/tcp_window_scaling
0

Follow wireshark (ethereal) log files of a failed connection using wget to try retrieve skydrive.live.com
Relevant frames: 1-42
Follow also current ipv4 configs.

(Log files, follow in plain text and also in wireshark/tcpdump format to open with the appropriate tools.)

Hope you can help me debug this network issue

The two lines below solved my problem. THANK YOU!

On Thu, Apr 17, 2008 at 11:58 PM, Jojo <email address hidden> wrote:

> Please try
>
> =================
> vi /etc/sysctl.conf
>
> add the following two lines
>
> net.ipv4.tcp_wmem = 4096 16384 131072
> net.ipv4.tcp_rmem = 4096 87380 174760
>
>
> save and reset sysctl
>
> sysctl -p
> ===================
>
> --
> Cannot connect to router/server/proxy with bad TCP Wscale implementation
> https://bugs.launchpad.net/bugs/89160
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in Source Package "linux" in Ubuntu: Confirmed
> Status in Source Package "linux-source-2.6.20" in Ubuntu: Triaged
> Status in Source Package "linux-source-2.6.22" in Ubuntu: Confirmed
>
> Bug description:
> >From some particular web servers, a machine running feisty cannot get an
> HTTP response. However, machines running most other OSs can get an HTTP
> response. (However, the problem appears to affect Debian etch also.)
>
> How to reproduce the problem:
>
> Use wget or any web browser to try to retrieve the file from this URL:
> http://www.ureg.ohio-state.edu/ourweb/online.html
>
> The client resolves the host, establishes a connection, and sends an HTTP
> request. However, it receives no response. However, a client on other OSs
> besides feisty will receive a response. In fact, a machine running dapper
> can get an HTTP response just fine.
>
> Here is the output from wget:
>
> *****begin transcript*****
> ubuntu@ubuntu:~$ wget -d http://www.ureg.ohio-state.edu/ourweb/online.html
> DEBUG output created by Wget 1.10.2 on linux-gnu.
>
> --08:32:45-- http://www.ureg.ohio-state.edu/ourweb/online.html
> => `online.html'
> Resolving www.ureg.ohio-state.edu... 128.146.64.104
> Caching www.ureg.ohio-state.edu => 128.146.64.104
> Connecting to www.ureg.ohio-state.edu|128.146.64.104|:80... connected.
> Created socket 3.
> Releasing 0x08093848 (new refcount 1).
>
> ---request begin---
> GET /ourweb/online.html HTTP/1.0
> User-Agent: Wget/1.10.2
> Accept: */*
> Host: www.ureg.ohio-state.edu
> Connection: Keep-Alive
>
> ---request end---
> HTTP request sent, awaiting response... Read error (Connection reset by
> peer) in headers.
> Closed fd 3
> *****end transcript*****
>
>
> Now here is the output from a machine running Debian sarge:
>
> ******begin transcript*****
> [sarge machine]$ wget -d http://www.ureg.ohio-state.edu/ourweb/online.html
> DEBUG output created by Wget 1.9.1 on linux-gnu.
>
> --21:41:41-- http://www.ureg.ohio-state.edu/ourweb/online.html
> => `online.html'
> Resolving www.ureg.ohio-state.edu... 128.146.64.104
> Caching www.ureg.ohio-state.edu => 128.146.64.104
> Connecting to www.ureg.ohio-state.edu[128.146.64.104]:80... connected.
> Created socket 3.
> Releasing 0x80a60d0 (new refcount 1).
> ---request begin---
> GET /ourweb/online.html HTTP/1.0
> User-Agent: Wget/1.9.1
> Host: www.ureg.ohio-state.edu
> Accept: */*
> Connection: Keep-Alive
>
> ---request end---
> HTTP request sent, awaiting response... HTTP/1.1 200 OK
> Content-Length: 17686
> Content-Type: text/html
> Last-Modified: Fri, 15 Sep 2006 12:22:14 GMT
> Accept-...

Well, my problem was solved with a "reset".
What I can say...

Follow in attachment the last email I sent.

My problem was solved when I

edited /etc/sysctl.conf

and added the following two lines

net.ipv4.tcp_wmem = 4096 16384 131072
net.ipv4.tcp_rmem = 4096 87380 174760

This seems a little geeky, and I would hope that the Ubuntu developers
somehow address this issue in future releases. (It wasn't a problem in
7.04; appeared in 7.10 and continued in the 8.04 (beta).)

On Tue, Apr 22, 2008 at 5:49 PM, linovski <email address hidden> wrote:

> Well, my problem was solved with a "reset".
> What I can say...
>
> Follow in attachment the last email I sent.
>
>
> ** Attachment added: "email-to-buffalo.txt"
> http://launchpadlibrarian.net/13831413/email-to-buffalo.txt
>
> --
> Cannot connect to router/server/proxy with bad TCP Wscale implementation
> https://bugs.launchpad.net/bugs/89160
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in Source Package "linux" in Ubuntu: Confirmed
> Status in Source Package "linux-source-2.6.20" in Ubuntu: Triaged
> Status in Source Package "linux-source-2.6.22" in Ubuntu: Confirmed
>
> Bug description:
> >From some particular web servers, a machine running feisty cannot get an
> HTTP response. However, machines running most other OSs can get an HTTP
> response. (However, the problem appears to affect Debian etch also.)
>
> How to reproduce the problem:
>
> Use wget or any web browser to try to retrieve the file from this URL:
> http://www.ureg.ohio-state.edu/ourweb/online.html
>
> The client resolves the host, establishes a connection, and sends an HTTP
> request. However, it receives no response. However, a client on other OSs
> besides feisty will receive a response. In fact, a machine running dapper
> can get an HTTP response just fine.
>
> Here is the output from wget:
>
> *****begin transcript*****
> ubuntu@ubuntu:~$ wget -d http://www.ureg.ohio-state.edu/ourweb/online.html
> DEBUG output created by Wget 1.10.2 on linux-gnu.
>
> --08:32:45-- http://www.ureg.ohio-state.edu/ourweb/online.html
> => `online.html'
> Resolving www.ureg.ohio-state.edu... 128.146.64.104
> Caching www.ureg.ohio-state.edu => 128.146.64.104
> Connecting to www.ureg.ohio-state.edu|128.146.64.104|:80... connected.
> Created socket 3.
> Releasing 0x08093848 (new refcount 1).
>
> ---request begin---
> GET /ourweb/online.html HTTP/1.0
> User-Agent: Wget/1.10.2
> Accept: */*
> Host: www.ureg.ohio-state.edu
> Connection: Keep-Alive
>
> ---request end---
> HTTP request sent, awaiting response... Read error (Connection reset by
> peer) in headers.
> Closed fd 3
> *****end transcript*****
>
>
> Now here is the output from a machine running Debian sarge:
>
> ******begin transcript*****
> [sarge machine]$ wget -d http://www.ureg.ohio-state.edu/ourweb/online.html
> DEBUG output created by Wget 1.9.1 on linux-gnu.
>
> --21:41:41-- http://www.ureg.ohio-state.edu/ourweb/online.html
> => `online.html'
> Resolving www.ureg.ohio-state.edu... 128.146.64.104
> Caching www.ureg.ohio-state.edu => 128.146.64.104
> Connecting to www.ureg.ohio-state.edu[128.146.64.104]:80... connected.
> Created socket 3.
> Releasing 0x80a60d0 (new refcount 1).
> ---request begin---
> GET...

the error remains into ubuntu 8.04 amd64 2 yearssssssssssss!!! with the same shit! again to edit /etc/sysctl.conf
to include this line
net.ipv4.tcp_window_scaling=0. I´M SICK!

Adding the lines

net.ipv4.tcp_wmem = 4096 16384 131072
net.ipv4.tcp_rmem = 4096 87380 174760
net.ipv4.tcp_window_scaling=0

and doing a sysctl -p
doesn't work for me.

Ubuntu 8.04, upgraded from previous release.

Same problem running Vista Basic OS...Can not surf or use email after Inside Windows installation with ADSL modem and router attached. Also on Ubuntu boot some white screen stuff where it should be black. Acer AMD Athalon with ATI graphics card.

This bug is not new and -from what i gather- stricty speaking it is not a
bug of linux (or Vista) it is a bug with cheap (read crappy) modems/routers,
such as my D-Link DSL-502T. It would be nice if they provided us with a
firmware upgrade that supports window scaling.

2008/8/20 Bug Watch Updater <email address hidden>

> ** Changed in: linux (Debian)
> Status: Unknown => New
>
> --
> Cannot connect to router/server/proxy with bad TCP Wscale implementation
> https://bugs.launchpad.net/bugs/89160
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

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.

> This bug is not new and -from what i gather- stricty speaking it is not a
> bug of linux (or Vista) it is a bug with cheap (read crappy) modems/routers,
> such as my D-Link DSL-502T. It would be nice if they provided us with a
> firmware upgrade that supports window scaling.

Ubuntu 8.04 LTS (Hardy) Live-CD works fine with my D-Link router. At the same time, Ubuntu 8.10 Intrepid fails to connect to, for instance, the LiveJournal website. Workarounds with sysctl.conf suggested above do not help.

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

I confirm this bug for the latest Intrepid version with the linux-image-2.6.27-7-generic package installed.

I tried to use the Firestarter application as suggested above, and it worked for me. Then, I saved its configuration files, purged Firestarter, restarted my system, and started to execute the commands from its /etc/firestarter/sysctl-tuning script in sequence, at each step checking "wget livejournal.com" to work. Executing the first two commands "echo 0 > /proc/sys/net/ipv4/ip_forward" and "echo 0 > /proc/sys/net/ipv4/conf/all/log_martians" did not help, since "wget livejournal.com" was still hanging. The third command, "echo 0 > /proc/sys/net/ipv4/tcp_timestamps", made "wget livejournal.com" working fine.

So I have written the only one command "net.ipv4.tcp_timestamps = 0" in my /etc/sysctl.conf file and am having the full internet connection, not a connection just to its part limited by google.com and some other sites.

I'm suggesting this workaround for this bug until Ubuntu's Linux kernel configuration is corrected - I'm using the latest Ubuntu Intrepid version updated now and this bug is being reproduced here.

The 18 month support period for Feisty Fawn 7.04 has reached it's end of life - http://www.ubuntu.com/news/ubuntu-7.04-end-of-life . As a result we are closing the linux-source-2.6.20 task. However, this will remain open against the actively developed kernel. Thanks.

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.

The 18 month support period for Gutsy Gibbon 7.10 has reached its end of life -
http://www.ubuntu.com/news/ubuntu-7.10-eol . As a result, we are closing the
linux-source-2.6.22 kernel task. It would be helpful if you could test the
new Jaunty Jackalope 9.04 release and confirm if this issue remains -
http://www.ubuntu.com/getubuntu/releasenotes/904overview. If the issue still exists with the Jaunty
release, please update this report by changing the Status of the "linux (Ubuntu)"
task from "Incomplete" to "New". Also please be sure to run the command below
which will automatically gather and attach updated debug information to this
report. Thanks in advance.

apport-collect -p linux-image-2.6.28-11-generic 89160

This bug still exists in Jaunty

@Lionel

Ok, please run this command from a Jaunty terminal:

apport-collect -p linux-image-2.6.28-11-generic 89160

Thanks in advance.

Sergio > unfortunately, apport-collect doesn't work behind a proxy

I have had the same problem here.
I do not know when it started exactly (it wasn't the when I first installed Ubuntu but suddenly some websites (like google maps) started to display half maps. Then I was able to pinpoint to a problem with wireshark.
First I added the line "net.ipv4.tcp_window_scaling = 0" to sysctl. the was better but not gone. Then I also added net.ipv4.tcp_wmem = 4096 16384 131072 and net.ipv4.tcp_rmem = 4096 87380 174760. Now all is forking fine again.

If it helps I can put requested info below, just let me know what I can do.

What is of more interest was that Wireshark saw tcp checksum errors. The exact message was
"Checksum: 0xaa59 [incorrect, should be 0x2035 (maybe caused by "TCP checksum offload"?)".

That is gone now.

Well,

Having a second look it seems it is not completely gone (actually, the https connection to this website still shows the checksum errors but at least the problem is now not noticeable any more

Architecture: i386
DistroRelease: Ubuntu 9.04
HibernationDevice: RESUME=UUID=cc639f69-900c-4987-abfa-939dd52e00a0
MachineType: LENOVO 87445BU
Package: linux-image-2.6.28-13-generic 2.6.28-13.44
PackageArchitecture: i386
ProcCmdLine: root=UUID=ad54ce11-12db-4e6d-afbc-0afe94972907 ro quiet splash acpi_sleep=s3_bios,s3_mode resume=UUID=cc639f69-900c-4987-abfa-939dd52e00a0
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.28-13.44-generic
Uname: Linux 2.6.28-13-generic i686
UserGroups: adm admin audio cdrom dialout dip disk floppy fuse kqemu kvm libvirtd lpadmin plugdev sambashare scanner src video www-data

I have noticed this problem for a few months and finally tracked down this bug report. Doing "echo 4096 65536 65536 > /proc/sys/net/ipv4/tcp_rmem" did resolve it for me. Please let me know if there is any thing else you need.

Still present in karmik alpha 2 live cd.
As said above, the problem is not in Linux/Ubuntu, but in some routers. However for a novice, this is a big problem, difficult to understand, and is perceived as a Linux/Ubuntu bug. A workaround would be very useful.

I has been solved by me.
After checking my firewall I noticed it was complaining about a syn flood when I was unable to connect to a website. In my setup at home this firewall is not really needed so I turned it off. All the problems are gone since that moment.
So, obviously Ubuntu makes my firewall thinks there is a synflood where it is just a normal TCP attempt. Next step is to check why my firewall is blocking this, but since it is build into my DSL modem, managed by my telecom provider it will be hard to correct this (my modem is a Siemens SX552 WLAN dsl modem).

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.