Internet / Network delays or pauses continuously

[Jason Harman]

I was originally subscribing to the [Bug 313218] Re: IPV6 causes slow internet access thread but that has devolved.

I am not sure if what problem I am having is an IPV6 error but the Internet since Alpha 5 now pauses (no activity, not even with router) for a minute or so and then allows full connectivity for a few minutes before repeating the cycle (I attach a picture of network activity taken from my Azureus statistics window).

Here is also some ping data from between myself and the router noticing the pause in the middle.

64 bytes from 192.168.0.1: icmp_seq=160 ttl=64 time=4.56 ms
64 bytes from 192.168.0.1: icmp_seq=161 ttl=64 time=18.4 ms
64 bytes from 192.168.0.1: icmp_seq=162 ttl=64 time=7.68 ms
64 bytes from 192.168.0.1: icmp_seq=163 ttl=64 time=14.3 ms
64 bytes from 192.168.0.1: icmp_seq=164 ttl=64 time=302 ms
64 bytes from 192.168.0.1: icmp_seq=165 ttl=64 time=125 ms
64 bytes from 192.168.0.1: icmp_seq=208 ttl=64 time=5855 ms
64 bytes from 192.168.0.1: icmp_seq=209 ttl=64 time=4847 ms
64 bytes from 192.168.0.1: icmp_seq=210 ttl=64 time=3841 ms
64 bytes from 192.168.0.1: icmp_seq=211 ttl=64 time=2833 ms
64 bytes from 192.168.0.1: icmp_seq=212 ttl=64 time=1825 ms
64 bytes from 192.168.0.1: icmp_seq=213 ttl=64 time=818 ms
64 bytes from 192.168.0.1: icmp_seq=214 ttl=64 time=0.445 ms
64 bytes from 192.168.0.1: icmp_seq=215 ttl=64 time=0.294 ms
64 bytes from 192.168.0.1: icmp_seq=216 ttl=64 time=0.316 ms
64 bytes from 192.168.0.1: icmp_seq=217 ttl=64 time=0.503 ms
64 bytes from 192.168.0.1: icmp_seq=218 ttl=64 time=0.576 ms
64 bytes from 192.168.0.1: icmp_seq=219 ttl=64 time=0.694 ms
--- 192.168.0.1 ping statistics ---
219 packets transmitted, 130 received, 40% packet loss, time 218627ms
rtt min/avg/max/mdev = 0.294/181.210/5855.511/802.607 ms, pipe 6

Here is the data from ifconfig:
eth0 Link encap:Ethernet HWaddr 00:1d:7d:00:04:59
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
          Interrupt:250 Base address:0x4000

eth0:avahi Link encap:Ethernet HWaddr 00:1d:7d:00:04:59
          inet addr:169.254.2.229 Bcast:169.254.255.255 Mask:255.255.0.0
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          Interrupt:250 Base address:0x4000

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:568123 errors:0 dropped:0 overruns:0 frame:0
          TX packets:568123 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:399491755 (399.4 MB) TX bytes:399491755 (399.4 MB)

wlan1 Link encap:Ethernet HWaddr 00:22:b0:cc:b2:46
          inet addr:192.168.0.199 Bcast:192.168.0.255 Mask:255.255.255.0
          inet6 addr: fe80::222:b0ff:fecc:b246/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:65878 errors:0 dropped:0 overruns:0 frame:0
          TX packets:66178 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:64713966 (64.7 MB) TX bytes:30849735 (30.8 MB)

wmaster0 Link encap:UNSPEC HWaddr 00-22-B0-CC-B2-46-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

[Jason Harman (apollyon-direct)]

I think I've narrowed this bug down to the ath9k driver that was included in the 2.6.27 or 2.6.28 kernel. This issue does not affect all hardware configurations. I am using the Athereos 5008 chip on a DWA-552 PCI Wireless N adapter.

[Jason Harman (apollyon-direct)]

Fixed this issue using new wireless-compat drivers from: http://wireless.kernel.org/en/users/Download

I believe the ath9k driver in the kernel still has issues which should be remedied.

[Slobodan Simić (slsimic)]

I can confirm this annoying behaviour of wireless interface. Altough, module loaded at my laptop is ath5k but still, I have the same symptoms. Seems like it is something wrong with the driver for atheros cards. :(

[apedic (apedic-netsystemsa)]

I've resolved installing wicd.

[Jamin W. Collins (jcollins)]

As Slobodan Simic indicated I'm seeing similar behaviour with the current karmic beta and ath5k.

$ uname -a
Linux odin 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux

$ lspci -v | grep -i atheros
03:00.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01)

64 bytes from 192.168.10.1: icmp_seq=28 ttl=64 time=1.06 ms
64 bytes from 192.168.10.1: icmp_seq=29 ttl=64 time=4.19 ms
64 bytes from 192.168.10.1: icmp_seq=30 ttl=64 time=1.81 ms
64 bytes from 192.168.10.1: icmp_seq=31 ttl=64 time=0.791 ms
64 bytes from 192.168.10.1: icmp_seq=32 ttl=64 time=1.33 ms
64 bytes from 192.168.10.1: icmp_seq=33 ttl=64 time=0.795 ms
64 bytes from 192.168.10.1: icmp_seq=34 ttl=64 time=6752 ms
64 bytes from 192.168.10.1: icmp_seq=35 ttl=64 time=5751 ms
64 bytes from 192.168.10.1: icmp_seq=36 ttl=64 time=4739 ms
64 bytes from 192.168.10.1: icmp_seq=37 ttl=64 time=3736 ms
64 bytes from 192.168.10.1: icmp_seq=38 ttl=64 time=2734 ms
64 bytes from 192.168.10.1: icmp_seq=39 ttl=64 time=1735 ms
64 bytes from 192.168.10.1: icmp_seq=40 ttl=64 time=721 ms
64 bytes from 192.168.10.1: icmp_seq=41 ttl=64 time=0.864 ms
64 bytes from 192.168.10.1: icmp_seq=42 ttl=64 time=0.821 ms
64 bytes from 192.168.10.1: icmp_seq=43 ttl=64 time=8.04 ms

[Jamin W. Collins (jcollins)]

Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
   Subdevices: 2/2
   Subdevice #0: subdevice #0
   Subdevice #1: subdevice #1
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/pcmC0D0p: jcollins 3144 F...m pulseaudio
 /dev/snd/controlC0: jcollins 3144 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xfe220000 irq 17'
   Mixer name : 'Analog Devices AD1984'
   Components : 'HDA:11d41984,17aa20bb,00100400'
   Controls : 29
   Simple ctrls : 18
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: linux (not installed)
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: root=UUID=66cf90ad-d4ec-4ec1-afb0-3fc3b17e3141 ro vga=0x37d quiet splash crashkernel=384M-2G:64M,2G-:128M
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
RelatedPackageVersions:
 linux-backports-modules-2.6.31-14-generic N/A
 linux-firmware 1.24
Uname: Linux 2.6.31-14-generic x86_64
UserGroups: adm admin cdrom dialout fuse kqemu kvm libvirtd lpadmin plugdev pulse-access sambashare
WpaSupplicantLog:

dmi.bios.date: 02/20/2008
dmi.bios.vendor: LENOVO
dmi.bios.version: 7LETB2WW (2.12 )
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr7LETB2WW(2.12):bd02/20/2008:svnLENOVO:pn:pvrThinkPadT61p:rvnLENOVO:rn:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.version: ThinkPad T61p
dmi.sys.vendor: LENOVO

[Jeremy Foshee (jeremyfoshee)]

Hi Jason,

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

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 337488

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.

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

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