throttled traffic/slow dns with ath5k (AR2413 wireless card) +WPA(2) with netgear wgr614

ON the affected machine:
:~$ lsb_release -rd
Description: Ubuntu 11.04
Release: 11.04
:~$ firefox -v
Mozilla Firefox 4.0.1
:~$ chromium-browser -v
:~$ chromium-browser --version
Chromium 11.0.696.68 Ubuntu 11.04
:~$ epiphany
epiphany epiphany-browser
:~$ epiphany
epiphany epiphany-browser
:~$ epiphany-browser -v
Failed to parse arguments: Unknown option -v
:~$ epiphany-browser --version
GNOME Web Browser 2.30.6

On the 10.10 server with no problem present:
:~$ uname -a
Linux 2.6.35.13-mine #1 SMP Fri May 6 00:20:57 CDT 2011 x86_64 GNU/Linux
:~$ lsb_release -rd
Description: Ubuntu 10.04.2 LTS
Release: 10.04

:~$ firefox -v;epiphany-browser --version;konqueror --version
Mozilla Firefox 4.0.1
GNOME Web Browser 2.30.2
Qt: 4.6.2
KDE Development Platform: 4.4.5 (KDE 4.4.5)
Konqueror: 4.4.5 (KDE 4.4.5)

Forgot to mention that on the machine in question 11.04 was upgraded from 10.10. The latter did not have these problems then.

Got a fix. Well, it seems to have been a dns lookup problem. Here;s what I did:
edit the /etc/nsswitch.conf file and have the following line as follows:
hosts: files dns mdsn4#mdns4_minimal [NOTFOUND=return] dns
Apparently, the "hosts: files mdns4_minimal [NOTFOUND=return] dns" prevent dns lookup of firefox and chromium from functioning properly, while all text browsers and epiphany + anything else are doing alright.
It is an interesting behavior, since my 10.04 system has the old "hosts: files mdns4_minimal [NOTFOUND=return] dns" -no issue whatsoever.
So I will have to change the bug description now.

The fix works on (at least):
uname -a
Linux 3.0.0-rc2-mine #2 SMP Wed Jun 8 13:45:01 CDT 2011 i686 i686 i386
GNU/Linux

There must have been a collision between the dns capabilities of some browser and the upgraded system. I am not sure how to capture the culprit.

After the last update of firefox it started to misbehave again:
firefox:i386 (4.0.1+build1+nobinonly-0ubuntu0.11.04.3, 5.0+build1+nobinonly-0ubuntu0.11.04.1), firefox-gnome-support:i386 (4.0.1+build1+nobinonly-0ubuntu0.11.04.3, 5.0+build1+nobinonly-0ubuntu0.11.04.1)

Even the google.com website takes awhile to load, actually, the google logo image. firefox constantly says "Waiting for google.com (or other websites)".

I can now see that both chromium and epiphany are a little faster than firefox.
These do not compare to text browsers though and my lucid browsers.

FYI, chromium-browser is the correct package. chromium is something else.

Gabe, it doesn't make it faster, thanks for the correction, though :)
What seems to be helping here is adding the "options single-request" in the /etc/resolv.conf
Wat is an enigma again, only chromium-browser, firefox, epiphany suffer from it, not text browser, nor everything else that uses dns.

Well, it got a little annoying. I did a few tests with two types of configurations in /etc/nsswitch.conf
1) it is either
hosts: files mdns4_minimal [NOTFOUND=return] dns
or 2)
hosts: files dns

I also have the following in the /etc/resolv.conf :

#long lookup
options single-request
# Generated by NetworkManager
nameserver 192.168.1.1
#long lookup
options timeout:1

Sometimes even a simple google search can hang up for a while. However, one of the slowest sites I noticed is cnews.ru . I am attaching tcpdumps below.
The command "tcpdump -n -i wlan0 port 53" is used here. First with
1) hosts: files mdns4_minimal [NOTFOUND=return] dns

With the option "hosts: files dns " in /etc/nsswitch.conf things seem to get better, however as before I still cannot get cnews.ru to load as in the previous case with both firefox and epiphany-browser . As far as the chromium-browser is concerned, it mostly loads never finishing though. The dumps are given below.

The tcpdump Ubuntu 10.10 where slow lookups never occur. The freshly upgraded firefox 7 takes a fraction of a second to load the notorious cnews.ru. Amazing! The dumps are attached below as well .

"tcpdump Ubuntu 10.10 where slow lookups never occur" should be "tcpdump LTS Ubuntu 10.04 where slow lookups never occur"

Yeah, this is not really an issue with the browers as all three of them use different technologies throughout the application. So I guess the candidate cause lowest in the stack would be the TCP stack in the kernel.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 788274

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

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

Herald, I can't think of anything rather than the way the said browsers communicate with the dns. Since they all keep printing "waiting for..." There shouldn't be anything in the kernel, because nothing else seems to be affected.

Recently I also noticed that I am not seeing the issue when I am on the ethernet connection. From time to time it may also be working OK when on wireless with ath5k driver - go figure. If it is the driver issue, it is still very strange to me.

So while on the wired connection the problem seems to go away. Most of the applications are not affected at all to be able to blame the wireless. I checked the configs for the both interfaces. They are identical.

I came to the conclusion that this issue is related to ath5k driver with AR2413 wireless chip communicating with the Netgear WGR614 router via WPA2 protocol. The wireless chip here does matter, since I have another notebook (ubuntu 10.10, on 2.6.35* kernel, ath5k with a different chip though) that does not have the said problems.

Discovered that ssh and rsync also suffer from the throttled traffic when run wirelessly. In fact, rsyncing both from and to the affected machine stalls, as well as sshing to it. That only happens while on the wireless connection. We are talking about the aforementioned Netgear's LAN in all the cases.

I downloaded a 1 year old 2.6.35 kernel. It seemed to be better, however, sshing to the machine would also freeze in the middle of the session.

This is very weird taking good numbers from the connection speed test ( testmy.net ) into account makes it more weird.

Not sure what to do next. My nest suspicion would the combination the wireless card, router and the WAP2 authentication protocol. I will try turning the latter off and or trying other ones.

--
Sent with mutt, composed in gnu emacs
Please do not send me Microsoft Office/Apple iWork documents. Send OpenDocument instead! http://fsf.org/campaigns/opendocument

Attaching the lspci -vv dump below.
--

ath5k on ar2413 wireless card. Slow firefox/chromium-browser and such dns lookups. rsync/ssh sessions also get stalled ALL the time

Catching up with the last comment: The versions of the kernel affected range from the last 3.1.0 custom built from Linus' git source to the 2.6.38 ubuntu generic flavor and might even go as far as up to 2.6.35.14 (where the ssh also stalled).

Just checked my router with WAP2-aes, WAP, WEP and without any authentication. The only usable case was the latter, as far as the ssh freeze is concerned and browsing in firefox.
--

What is also worth pointing out is the fact that ssh problems seem only to exist when sshing TO the affected machine wirelessly with any of the protocols WPE/WAP. Sshing FROM the machine has no issues.
And yet again, only ssh (to)/rsync (through ssh), image capable web browsing seem to suffer from it. However, text browsing, mutt(through TSL and SMTP), apt, wget network speed test - all seem to NOT care at all.
--

apport information

apport information

As an addition to the list of troubled apps I have also TRAMP, the Emacs remote access client. When I try using it to access to/from the affected laptop (via WPA/WEP) it hangs most of the time on both machines, until I kill the ssh process TRAMP had spawned.

--

gene, thank you for reporting this and helping make Ubuntu better. This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]