Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
help needed filing a bug
-
- Posts: 8
- Joined: 2007-03-03 20:22
help needed filing a bug
I need a linux expert to help me determine which Debian package to file a bug against. This problem beats the hell out of me.
Here is the problem: There are some web sites from which etch cannot get an HTTP response (even though almost every other OS can get a response).
Here is one such site:
http://www.ureg.ohio-state.edu/ourweb/online.html
(This is a website for a major public US university, and the site is used by tens of thousands of students.)
If you try to get to it using Windows XP or Ubuntu 6.06 or Debian sarge, it works fine. If you try with etch, you receive no response. To be more specific, the HTTP client resolves the host, establishes a connection, and sends an HTTP request, but then receives no response. Clients on other OSs receive the response "HTTP/1.1 200 OK".
This is not a browser problem. It is the same whether you use Iceweasel, Opera, Epiphany, lynx, or even wget.
Also, it is not a DNS problem because the etch machines can ping the server just fine.
I really need to figure out which package is causing the problem.
I filed bug #412940 in 'general', but I don't think anyone will pay attention to it unless I can file the bug against a particular package.
Please help!
Here is the problem: There are some web sites from which etch cannot get an HTTP response (even though almost every other OS can get a response).
Here is one such site:
http://www.ureg.ohio-state.edu/ourweb/online.html
(This is a website for a major public US university, and the site is used by tens of thousands of students.)
If you try to get to it using Windows XP or Ubuntu 6.06 or Debian sarge, it works fine. If you try with etch, you receive no response. To be more specific, the HTTP client resolves the host, establishes a connection, and sends an HTTP request, but then receives no response. Clients on other OSs receive the response "HTTP/1.1 200 OK".
This is not a browser problem. It is the same whether you use Iceweasel, Opera, Epiphany, lynx, or even wget.
Also, it is not a DNS problem because the etch machines can ping the server just fine.
I really need to figure out which package is causing the problem.
I filed bug #412940 in 'general', but I don't think anyone will pay attention to it unless I can file the bug against a particular package.
Please help!
-
- Posts: 8
- Joined: 2007-03-03 20:22
follow-up
By the way, this bug is pretty new. I think it started some time in February. I think some update to etch must have created it.
Anyway, here is a list of packages I upgraded during the relevant time period. (This list comes from /var/log/dpkg.log. I have included only the packages that I think could possibly have caused the problem.)
2007-02-08 00:15:15 upgrade bsdutils 1:2.12r-15 1:2.12r-16
2007-02-08 00:15:25 upgrade libc6-amd64 2.3.6.ds1-8 2.3.6.ds1-10
2007-02-08 00:15:27 upgrade libc6-dev 2.3.6.ds1-8 2.3.6.ds1-10
2007-02-08 00:15:27 upgrade libc6 2.3.6.ds1-8 2.3.6.ds1-10
2007-02-08 00:15:37 upgrade sysvinit 2.86.ds1-36 2.86.ds1-38
2007-02-08 00:15:42 upgrade util-linux 2.12r-15 2.12r-16
2007-02-08 00:15:48 upgrade sysvinit-utils 2.86.ds1-36 2.86.ds1-38
2007-02-08 00:15:58 upgrade initscripts 2.86.ds1-36 2.86.ds1-38
2007-02-08 00:16:03 upgrade sysv-rc 2.86.ds1-36 2.86.ds1-38
2007-02-08 00:16:08 upgrade netbase 4.28 4.29
2007-02-08 00:16:22 upgrade libnss3-0d 1.8.0.8-1 1.8.0.9-1
2007-02-15 18:56:22 upgrade libc6-amd64 2.3.6.ds1-10 2.3.6.ds1-11
2007-02-15 18:56:23 upgrade linux-kernel-headers 2.6.18-6 2.6.18-7
2007-02-15 18:56:24 upgrade libc6-dev 2.3.6.ds1-10 2.3.6.ds1-11
2007-02-15 18:56:24 upgrade libc6 2.3.6.ds1-10 2.3.6.ds1-11
2007-02-15 18:56:37 upgrade iputils-ping 3:20020927-4 3:20020927-6
Anyway, here is a list of packages I upgraded during the relevant time period. (This list comes from /var/log/dpkg.log. I have included only the packages that I think could possibly have caused the problem.)
2007-02-08 00:15:15 upgrade bsdutils 1:2.12r-15 1:2.12r-16
2007-02-08 00:15:25 upgrade libc6-amd64 2.3.6.ds1-8 2.3.6.ds1-10
2007-02-08 00:15:27 upgrade libc6-dev 2.3.6.ds1-8 2.3.6.ds1-10
2007-02-08 00:15:27 upgrade libc6 2.3.6.ds1-8 2.3.6.ds1-10
2007-02-08 00:15:37 upgrade sysvinit 2.86.ds1-36 2.86.ds1-38
2007-02-08 00:15:42 upgrade util-linux 2.12r-15 2.12r-16
2007-02-08 00:15:48 upgrade sysvinit-utils 2.86.ds1-36 2.86.ds1-38
2007-02-08 00:15:58 upgrade initscripts 2.86.ds1-36 2.86.ds1-38
2007-02-08 00:16:03 upgrade sysv-rc 2.86.ds1-36 2.86.ds1-38
2007-02-08 00:16:08 upgrade netbase 4.28 4.29
2007-02-08 00:16:22 upgrade libnss3-0d 1.8.0.8-1 1.8.0.9-1
2007-02-15 18:56:22 upgrade libc6-amd64 2.3.6.ds1-10 2.3.6.ds1-11
2007-02-15 18:56:23 upgrade linux-kernel-headers 2.6.18-6 2.6.18-7
2007-02-15 18:56:24 upgrade libc6-dev 2.3.6.ds1-10 2.3.6.ds1-11
2007-02-15 18:56:24 upgrade libc6 2.3.6.ds1-10 2.3.6.ds1-11
2007-02-15 18:56:37 upgrade iputils-ping 3:20020927-4 3:20020927-6
Doesn't respond at all on my Etch install or my Vista install...
Can't even telnet to port 80 on and of the 3 IPs that hostname resolves to... problem is on their end in my opinion
Can't even telnet to port 80 on and of the 3 IPs that hostname resolves to... problem is on their end in my opinion
I also tried scanning from my servers in Florida... 80 is filtered on all 3 IPs, problem is definitely on their end.etch:~$ nmap -P0 -p 80 128.146.64.141 128.146.64.142 128.146.64.143
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2007-03-03 16:07 EST
Interesting ports on es-n1.ureg.ohio-state.edu (128.146.64.141):
PORT STATE SERVICE
80/tcp filtered http
Interesting ports on es-n2.ureg.ohio-state.edu (128.146.64.142):
PORT STATE SERVICE
80/tcp filtered http
Interesting ports on es-n5.ureg.ohio-state.edu (128.146.64.143):
PORT STATE SERVICE
80/tcp filtered http
Nmap finished: 3 IP addresses (3 hosts up) scanned in 12.058 seconds
-
- Posts: 8
- Joined: 2007-03-03 20:22
site is reachable for me
I'm surprised it doesn't respond to your Vista install.
I can still get the page using sarge:
It doesn't look to me like 80 is filtered on 128.146.64.104.
Where are you getting those other IPs?
I can still get the page using sarge:
Code: Select all
(sarge) $ wget http://www.ureg.ohio-state.edu/ourweb/online.html
--16:12:24-- http://www.ureg.ohio-state.edu/ourweb/online.html
=> `online.html'
Resolving www.ureg.ohio-state.edu... 128.146.64.104
Connecting to www.ureg.ohio-state.edu[128.146.64.104]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17,686 [text/html]
100%[==============================================>] 17,686 105.96K/s
16:12:24 (105.34 KB/s) - `online.html' saved [17686/17686]
Where are you getting those other IPs?
-
- Posts: 8
- Joined: 2007-03-03 20:22
Hey Optional, you resolved the wrong hostname. Port 80 is not filtered on the host in question.
Code: Select all
$ nmap -p 80 www.ureg.ohio-state.edu
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2007-03-03 16:44 EST
Interesting ports on www.ureg.ohio-state.edu (128.146.64.104):
PORT STATE SERVICE
80/tcp open http
Nmap finished: 1 IP address (1 host up) scanned in 0.418 seconds
-
- Posts: 8
- Joined: 2007-03-03 20:22
I am surprised to hear that it works for someone with etch. Do you have all updates installed? On etch I can't get it with Opera 9.01.works fine for me, opera 9.10 etch
I started a thread about this at Linux Forums and had a poll to find out whether any etch users could get the site. No one was able to.
http://www.linuxforums.org/forum/debian ... oblem.html
-
- Posts: 8
- Joined: 2007-03-03 20:22
hmmm....
So, my claim is this:Works fine for me using Iceweasel on Etch (64-bit)
If you are running a fully updated x86 (i.e., 32-bit) etch system, then you cannot load the web page at the following URL:
http://www.ureg.ohio-state.edu/ourweb/online.html
If anyone is a counterexample to this, I would certainly like to know!
Otherwise, it seems like a bug.
(By the way, I am pretty sure that this will be a problem also for users of Ubuntu 'feisty fawn' Herd 4 on x86.)
Just did an apt-get upgrade just now, and the site works fine stillsamething22 wrote: I am surprised to hear that it works for someone with etch. Do you have all updates installed?
i do have my own kernel, and not a stock one, however this issue is more of a network issue (and moreover probably a dns issue, maybe even on their side)
there is one issue I have with the new 'way of doing things' in etch, specifically with udev; sometimes on a boot, the network interface isn't brought up and I have to manually bring it up
check so your network interface is up
Eagles may soar, but weasels don't get sucked into jet engines...
-
- Posts: 8
- Joined: 2007-03-03 20:22
baffled.
So, I switched over to 32-bit and tried it there, as well ... Works fine.
Etch 32-bit ... Iceweasel
Just did an apt-get upgrade just now, and the site works fine still
i do have my own kernel, and not a stock one, however this issue is more of a network issue (and moreover probably a dns issue, maybe even on their side)
Thanks for the responses.
I am completely baffled then. When I brought this up at Linux Forums, a lot of etch users were unable to reach the web site. See here:
http://www.linuxforums.org/forum/debian ... oblem.html
So, as it stands, here are my weird facts:
- Using my 32-bit etch installation (fully updated, using kernel 2.6.18-4-k7), I cannot get an HTTP response, though I can resolve it, ping it, etc.
- Using an i386 Ubuntu 'feisty fawn' Herd 4 live CD I have the exact same symptoms.
- Using an old i386 Ubuntu 'dapper drake' live CD I can get the site just fine as well.
All this on the same computer.
Furthermore, using a sarge machine on my network (with the same /etc/resolv.conf file), I can get the site just fine as well.
If it is a DNS problem, it is not simply a name resolving issue. I can resolve the hostname just fine. What other kind of DNS issue could it be then? Something having to do with Bind?
If it is an issue on the server end, it is a weird issue there, too. What kind of server issue would make it so that the web server responded to some operating systems and not others?
Your thoughts are appreciated.
I don'thave an answer, but I do have what may be a similar problem. I can not access this website: http://linux-wless.passys.nl/
I know the site is up and I know that some people can get to it, and some can not. I believe there is something wrong on their end, but that doesn't explain why I can't access it. My best theory at this point is that my firewall is somehow blocking it, but that is not really based on knowledge.
I know the site is up and I know that some people can get to it, and some can not. I believe there is something wrong on their end, but that doesn't explain why I can't access it. My best theory at this point is that my firewall is somehow blocking it, but that is not really based on knowledge.
Debian-Lenny/Sid 32/64
Desktop: Generic Core 2 Duo, EVGA 680i, Nvidia
Laptop: Generic Intel SIS/AC97
Desktop: Generic Core 2 Duo, EVGA 680i, Nvidia
Laptop: Generic Intel SIS/AC97
It may not be a Debian/kernel problem at all! My guess would be that you should upgrade the firmware in your DSL router/modem... I had a similar problem in my Linksys WAG200G, and a firmware update solved it.
I would have replied sooner if you had brought this problem up in one of the regular forums, like Hardware or Installation...
I would have replied sooner if you had brought this problem up in one of the regular forums, like Hardware or Installation...
it loads well to me (2.6.18-4-686, etch fully upgraded)
it maybe the infamous aggressive tcp scaling issue, exposed also in the realease notes for etch
http://www.debian.org/releases/etch/amd ... on.en.html
try to disable tcp window scaling as root
and try now to load the site
it maybe the infamous aggressive tcp scaling issue, exposed also in the realease notes for etch
http://www.debian.org/releases/etch/amd ... on.en.html
try to disable tcp window scaling as root
Code: Select all
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
-
- Posts: 8
- Joined: 2007-03-03 20:22
explanation / workaround
Recently I found out what is going on with this bug.
The problem has to do with larger default buffer sizes for TCP window scaling in recent Linux kernel versions. If there is an improperly configured router between you and the server you're trying to reach, it will create a bottleneck and you'll get no data from the server. The long and the short of it is that it is not a Linux bug.
Here are some better, more detailed explanations:
http://inodes.org/blog/2006/09/06/tcp-w ... rnel-2617/
http://kerneltrap.org/node/6723
The solution I have used (and I've had to do it again whenever I've updated my kernel) is to change the values in /proc/sys/net/ipv4/tcp_wmem and /proc/sys/net/ipv4/tcp_rmem. The new values should be "4096 16384 131072" and "4096 87380 174760" respectively. This sets the window scaling buffer back to its earlier/smaller size.
The problem has to do with larger default buffer sizes for TCP window scaling in recent Linux kernel versions. If there is an improperly configured router between you and the server you're trying to reach, it will create a bottleneck and you'll get no data from the server. The long and the short of it is that it is not a Linux bug.
Here are some better, more detailed explanations:
http://inodes.org/blog/2006/09/06/tcp-w ... rnel-2617/
http://kerneltrap.org/node/6723
The solution I have used (and I've had to do it again whenever I've updated my kernel) is to change the values in /proc/sys/net/ipv4/tcp_wmem and /proc/sys/net/ipv4/tcp_rmem. The new values should be "4096 16384 131072" and "4096 87380 174760" respectively. This sets the window scaling buffer back to its earlier/smaller size.