network-manager fails periodically , on backgound networks scan?

[HaZeX]

Binary package hint: network-manager

1) The release
Ubuntu version: Ubuntu 9.04 Jaunty Release: 9.04 64 BITS

2) The version of the package you are using
Package affected : network-manager 0.7.1~rc4.1.cf199a964-0ubuntu2

3) What you expected to happen
 Estable connection.
 If I kill NetworkManager and connect manually to the network using iwconfig , the problem dissapear.

4)What happened instead

Frecuently signal gets interrupted, but not complety disconnected.
I guess it is related with the background network scanning but not sure. I can notice while copying files on local network, watchins streaming movies or with the ping command.
Approximatly each 90-120 seconds , a 5-8 seconds lag is generated.

 --> Hardware :
Dell Wireless card 1515
Atheros AR928X chipset

  #lspci | grep Atheros
   06:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)

--> Drivers :
Im not sure. Clean Ubuntu 9.04 installation detected my card, but could not connect to networks until I installed linux-backports-modules-jaunty-generic .

  #$ lsmod | grep ath9k
   ath9k 311092 0
   lbm_cw_mac80211 259000 1 ath9k
   led_class 13064 1 ath9k
   lbm_cw_cfg80211 85048 2 ath9k,lbm_cw_mac80211

More information:
---------------------------------------------------

->>If I kill NetworkManager and connect manually to the network using iwconfig , THE PROBLEM DISAPPEAR.

#ping 192.168.0.1 ( my gateway )
64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=1.75 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=1.82 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=1.46 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=1.60 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=6802 ms **Here it is the problem
64 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=5803 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=4803 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=3803 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=64 time=2803 ms
64 bytes from 192.168.0.1: icmp_seq=21 ttl=64 time=1803 ms
64 bytes from 192.168.0.1: icmp_seq=22 ttl=64 time=803 ms
64 bytes from 192.168.0.1: icmp_seq=23 ttl=64 time=1.72 ms
64 bytes from 192.168.0.1: icmp_seq=24 ttl=64 time=1.69 ms
64 bytes from 192.168.0.1: icmp_seq=25 ttl=64 time=1.72 ms ** Everything keep normal, but afther 90-120 seconds, the 8 seconds lag happens again, and always like that.

#tail -n0 -f /var/log/syslog

NetworkManager: <debug> [1241785845.002524] periodic_update(): Roamed from BSSID 00:80:5A:4B:89:43 (rosquilla) to (none) ((none))
May 8 14:30:46 xps kernel: [ 2896.176696] wlan0: beacon loss from AP ffff88015e8cfac0 - sending probe request
May 8 14:30:51 xps NetworkManager: <debug> [1241785851.001653] periodic_update(): Roamed from BSSID (none) ((none)) to 00:80:5A:4B:89:43 (rosquilla)
May 8 14:32:45 xps NetworkManager: <debug> [1241785965.004390] periodic_update(): Roamed from BSSID 00:80:5A:4B:89:43 (rosquilla) to (none) ((none))
May 8 14:32:46 xps kernel: [ 3016.169028] wlan0: beacon loss from AP ffff88015e8cfac0 - sending probe request
May 8 14:32:51 xps NetworkManager: <debug> [1241785971.001949] periodic_update(): Roamed from BSSID (none) ((none)) to 00:80:5A:4B:89:43 (rosquilla)

* Note : The delay with the ping command and the syslog events happen at same time.

If i can add any adicional info please tell me what commands to writte or a link with some help and i will post it.

(Is my first bug report, if im forgetting to add something or not reporting properly please tell me )

Thanks in advanced.

[HaZeX (kiv00)]

I found other bug that seems related to mine.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/350221

They say that the problem is with mac80211 and no network manager and that will be solved in Karmic.

If thats is true, how can be possible that I dont have the problem if I am connected using iwconfig instead of network-manager?

[Erik Meitner (e.meitner)]

Try this and see if you get the same result:
$ while : ; do iwconfig ath0|grep 'Freq' ;sleep 1; done

I get:
...snip...
          Mode:Managed Frequency:2.432 GHz Access Point: 00:22:57:53:DB:80
          Mode:Managed Frequency:2.442 GHz Access Point: 00:22:57:53:DB:80
          Mode:Managed Frequency:5.18 GHz Access Point: 00:22:57:53:DB:80
          Mode:Managed Frequency:5.26 GHz Access Point: 00:22:57:53:DB:80
          Mode:Managed Frequency:5.5 GHz Access Point: 00:22:57:53:DB:80
          Mode:Managed Frequency:5.58 GHz Access Point: 00:22:57:53:DB:80
          Mode:Managed Frequency:5.68 GHz Access Point: 00:22:57:53:DB:80
          Mode:Managed Frequency:5.785 GHz Access Point: 00:22:57:53:DB:80
          Mode:Managed Frequency:2.432 GHz Access Point: 00:22:57:53:DB:80
          Mode:Managed Frequency:2.432 GHz Access Point: 00:22:57:53:DB:80
...snip...

The frequencies indicate that this is an 802.11n scan. I suspect it is being initiated by wpa_supplicant because running wpa_supplicant with the '-ddd' option provides this at the same time the 802.11n scan happens:

Setting scan request: 0 sec 0 usec
Starting AP scan (broadcast SSID)
Scan requested (ret=0) - scan timeout 30 seconds
RTM_NEWLINK: operstate=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'ath0' added
Wireless event: cmd=0x8b19 len=8
Received 1764 bytes of scan results (5 BSSes)
CTRL-EVENT-SCAN-RESULTS
Selecting BSS from priority group 0
Try to find WPA-enabled AP
0: 00:22:57:53:db:80 ssid='MyNet' wpa_ie_len=22 rsn_ie_len=20 caps=0x11
   selected based on RSN IE
   selected WPA AP 00:22:57:53:db:80 ssid='MyNet'
Already associated with the selected AP.

To have the wireless cut out for 6-7 seconds is really painfull...

linux-backports-modules-2.6.28-12-generic(2.6.28-12.13)
linux-image-2.6.28-12-generic(2.6.28-12.43)
linux-restricted-modules-2.6.28-12-generic(2.6.28-12.16)

$ modinfo ath9k
filename: /lib/modules/2.6.28-12-generic/updates/ath9k.ko
license: Dual BSD/GPL
description: Support for Atheros 802.11n wireless LAN cards.
author: Atheros Communications
srcversion: B066EA404154EA4DD8862D0
...
depends: lbm_cw-cfg80211,lbm_cw-mac80211,led-class
vermagic: 2.6.28-12-generic SMP mod_unload modversions 586
...

[HaZeX (kiv00)]

Thanks for your help.
With the following command i get the same resaults than you.

$ while : ; do iwconfig ath0|grep 'Freq' ;sleep 1; done

Mode:Managed Frequency:2.442 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:2.442 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:2.442 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:2.442 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:2.442 GHz Access Point: xx:xx:xx:xx:xx:xx

###but shudenly.... and at same time than the lag spikes :

Mode:Managed Frequency:2.442 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:5.26 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:5.5 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:5.58 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:5.68 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:5.785 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:2.442 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:2.442 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:2.442 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:2.442 GHz Access Point: xx:xx:xx:xx:xx:xx
Mode:Managed Frequency:2.442 GHz Access Point: xx:xx:xx:xx:xx:xx

 I hope this info can help.

 Have any one tryed if using iwconfig instead of network manager whould make the network works properly? it is working for me as a temporal workarround, i dont get lag spikes on this way.

[Luis R. Rodriguez (mcgrof)]

Please try lbm (linux-backport-mdules) or compat-wireless:

http://wireless.kernel.org/en/users/Download

[HaZeX (kiv00)]

I have installed linux backport modules by :
$sudo apt-get install linux-backports-modules-jaunty

After rebooting the problem was still there while using NetworkManager.
As i said previously, if i connect using Iwconfig instead of network-manager, i dont have the problem.

Thanks in advanced for any help.

[Wagner Volanin (volanin)]

I also have this problem and it's very annoying.
Every 2 minutes exactly, the wireless network stalls because network-manager performs a network scan.
In some drivers (like the atheros ath9k) this causes the network to completely stall from 1 to 5 seconds.

This bug is already known upstream and there is a bug report in the redhat bugzilla as well:

Upstream Bug Report:
http://bugzilla.gnome.org/show_bug.cgi?id=513820

Redhat Bugzilla Report:
https://bugzilla.redhat.com/show_bug.cgi?id=490493

I have created is a workaround patch that disables scanning if your device is already connected to a network.
This patch is based on a suggestion from Christer Weinigel in the Redhat Bugzilla report, but it's not the ideal solution.
Of course, by using it you won't have an updated network list while connected, but your network won't stall.

I also have compiled packages of network-manager for jaunty using the attached patch:
https://launchpad.net/~volanin/+archive/ppa

In old versions of Network Manager there existed an option to enable/disable scanning, but it was removed.
Related bug report about optional scanning:
http://bugzilla.gnome.org/show_bug.cgi?id=165933

[HaZeX (kiv00)]

Thanks for the patch, it's working fine for me. I've just installed the compiled package. This workaround is going to be really usefull for me.
Thanks again!

[Luis R. Rodriguez (mcgrof)]

On Sun, Jul 19, 2009 at 7:53 PM, HaZeX<email address hidden> wrote:
> Thanks for the patch, it's working fine for me.   I've just installed the compiled package.  This workaround is going to be really usefull for me.
> Thanks again!

That will break roaming capabilities. The right way to solve this is
to spread out scanning evenly and going back to the home channel after
a few channel scans during a wide scan. Such work is being done
upstream but it'll take while for users to get it unless using
something like compat-wireless. Such patches are not yet merged by may
soon be.

  Luis

[Wagner Volanin (volanin)]

I agree Luis, this is really not the right way to do it.
The patch is just a workaround.

Although I am already using ath9k from compat-wireless-2009-07-18, and the problem persists.
Pehaps the right way would also be to only perform a network scan when the network is idle.
But that is beyond my patching capabilities.
;-)

[Luis R. Rodriguez (mcgrof)]

On Mon, Jul 20, 2009 at 1:09 PM, Wagner
Volanin<email address hidden> wrote:
> I agree Luis, this is really not the right way to do it.
> The patch is just a workaround.
>
> Although I am already using ath9k from compat-wireless-2009-07-18, and the problem persists.
> Pehaps the right way would also be to only perform a network scan when the network is idle.
> But that is beyond my patching capabilities.
> ;-)

To help resolve this please consider testing these patches:

http://marc.info/?l=linux-wireless&m=124773508125767&w=2

 Luis

[Luis R. Rodriguez (mcgrof)]

On Mon, Jul 20, 2009 at 1:09 PM, Wagner
Volanin<email address hidden> wrote:
> I agree Luis, this is really not the right way to do it.
> The patch is just a workaround.
>
> Although I am already using ath9k from compat-wireless-2009-07-18, and the problem persists.
> Pehaps the right way would also be to only perform a network scan when the network is idle.
> But that is beyond my patching capabilities.
> ;-)

I should mention the scan patches were merged onto wireless-testing.
You may want to try the latest compat-wireless:

http://wireless.kernel.org/en/users/Download/

You can also now use scripts/driver-select to pick only the driver you need.

  Luis

[Luis R. Rodriguez (mcgrof)]

this bug report should be closed as its for an older kernel and in
older kernels this is just the way this works. If you want to take
advantage of bg scanning enhancements it is outside the scope of the
older kernels, and you *can* use newer kernels/drivers if you so
choose. If you see issues with that then it is not an issue for a
relevant bug report to launchpad or anything like that. Since you
would be using bleeding edge if you see issues with the new scan
method you can just explain the issues you see on linux-wireless.

  Luis

On Fri, Aug 7, 2009 at 12:20 PM, Bug Watch
Updater<email address hidden> wrote:
> ** Changed in: network-manager (Fedora)
>       Status: Unknown => Confirmed
>
> --
> network-manager fails periodically , on backgound networks scan?
> https://bugs.launchpad.net/bugs/373680
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Matthew (jonespm-umich)]

Great patch, Wagner! Was having this 1-4 second pause problem every few minutes for the past few days since I installed linux. Was also been having this same problem (though didn't seem as often) in windows ever since I bought this laptop. I was blaming it on the router/internet, though it's probably the same problem. Thanks!

[bitinerant (bitinerant)]

After installing linux-backports-modules-wireless-karmic-generic a few days ago I began experiencing periodic pauses lasting several seconds, making working in ssh very cumbersome. Doing a 'ping 192.168.1.1' at the same time as 'tail -f /var/log/syslog' makes the pauses obvious and displays 'wpa_supplicant[1330]: CTRL-EVENT-SCAN-RESULTS in syslog at the end of every pause. Atheros AR5418, kernel 2.6.31-16-generic. Is this the same bug?

[Massimo Mund (qos)]

Yes. I guess it is.

My wifi is fine, with the patch (this is essential) of Wagner Volanin and i am using self-compiled wifi drivers from http://linuxwireless.org/ (not essential, but more stable).

[Bremner (paullinden)]

Quoting bitinerant <email address hidden>:My problem is more connected to the
failure of network manager and possibly the graphics not supporting mozilla
artwork USA in the opening window,My home network is pinging efficiently in
terminal but I can not connect to the web.I have had error messages during the
download of karmic which may be the ultimate cause and I have downloaded it on
several occasions both directly through update manager and via another
comp via
cd.In any case I shall waite untill I receive the official CD and try that
live.
If that fails, I will stick with 9.04 which works fine.

> After installing linux-backports-modules-wireless-karmic-generic a few
> days ago I began experiencing periodic pauses lasting several seconds,
> making working in ssh very cumbersome. Doing a 'ping 192.168.1.1' at
> the same time as 'tail -f /var/log/syslog' makes the pauses obvious and
> displays 'wpa_supplicant[1330]: CTRL-EVENT-SCAN-RESULTS in syslog at the
> end of every pause. Atheros AR5418, kernel 2.6.31-16-generic. Is this
> the same bug?
>
> --
> network-manager fails periodically , on backgound networks scan?
> https://bugs.launchpad.net/bugs/373680
> You received this bug notification because you are subscribed to
> NetworkManager.
>
> Status in NetworkManager: Confirmed
> Status in ?network-manager? package in Ubuntu: New
> Status in ?network-manager? package in Fedora: Invalid
>
> Bug description:
> Binary package hint: network-manager
>
> 1) The release
> Ubuntu version: Ubuntu 9.04 Jaunty Release: 9.04 64 BITS
>
> 2) The version of the package you are using
> Package affected : network-manager 0.7.1~rc4.1.cf199a964-0ubuntu2
>
>
> 3) What you expected to happen
> Estable connection.
> If I kill NetworkManager and connect manually to the network using
> iwconfig , the problem dissapear.
>
> 4)What happened instead
>
> Frecuently signal gets interrupted, but not complety disconnected.
> I guess it is related with the background network scanning but not
> sure. I can notice while copying files on local network, watchins
> streaming movies or with the ping command.
> Approximatly each 90-120 seconds , a 5-8 seconds lag is generated.
>
>
> --> Hardware :
> Dell Wireless card 1515
> Atheros AR928X chipset
>
> #lspci | grep Atheros
> 06:00.0 Network controller: Atheros Communications Inc. AR928X
> Wireless Network Adapter (PCI-Express) (rev 01)
>
> --> Drivers :
> Im not sure. Clean Ubuntu 9.04 installation detected my card,
> but could not connect to networks until I installed
> linux-backports-modules-jaunty-generic .
>
> #$ lsmod | grep ath9k
> ath9k 311092 0
> lbm_cw_mac80211 259000 1 ath9k
> led_class 13064 1 ath9k
> lbm_cw_cfg80211 85048 2 ath9k,lbm_cw_mac80211
>
>
>
> More information:
> ---------------------------------------------------
>
> ->>If I kill NetworkManager and connect manually to the network using
> iwconfig , THE PROBLEM DISAPPEAR.
>
> #ping 192.168.0.1 ( my gateway )
> 64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=1.75 ms
> 64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=1.82 ms
> 64 bytes from 192.168.0...

[HaZeX (kiv00)]

Luis R, i dont agree with your words:
  "this bug report should be closed as its for an older kernel and in
   older kernels this is just the way this works. If you want to take
   advantage of bg scanning enhancements it is outside the scope of the
   older kernels"

Im using the latest official ubuntu release and is still affeceted by this bug.

The only 3 workarrounds i have found:

Use Wagner Volanin patch for Network-manager
or
Remove network-manager and connect manually to the networks.
or
Using an alternative software like WICD to manage the networks.

I hope it can be solve in the next release of Ubuntu, tell me if i can help testing something to solve the bug.

Thanks.

HaZeX

[Luis R. Rodriguez (mcgrof)]

On Tue, Dec 15, 2009 at 2:42 AM, HaZeX <email address hidden> wrote:
> Luis R, i dont agree with your words:
>  "this bug report should be closed as its for an older kernel and in
>   older kernels this is just the way this works. If you want to take
>   advantage of bg scanning enhancements it is outside the scope of the
>   older kernels"
>
> Im using the latest official ubuntu release and is still affeceted by
> this bug.
>
> The only 3 workarrounds i have found:
>
> Use Wagner Volanin  patch for Network-manager
> or
> Remove network-manager and connect manually to the networks.
> or
> Using an alternative software like WICD to manage the networks.
>
> I hope it can be solve in the next release of Ubuntu, tell me if i can
> help testing something to solve the bug.

You missed my point, the point was that background scans do go off
channel for however long it takes a card to scan all the channels it
supports. This doesn't affect only ath9k, it affects all cards and the
proper solution would be to do a scan on each channel and then go back
to the home channel for a while. Do this until you've completed the
entire scan. This is addressed in a later kernel and therefore since
the change is considerably large such a change cannot go into the
stable kernel that Ubuntu ships.

I encourage you to try to become familiar with the upstream kernel bug
propagation life cycle so you can better understand how real critical
fixes get merged into the Linux kernel stable releases and how
implementation changes (like this one) won't go into stable release
but instead into a next kernel release.

http://wireless.kernel.org/en/users/Documentation/Fix_Propagation

There are indeed some mixing fixes for ath9k on 2.6.31 though, see:

http://bombadil.infradead.org/~mcgrof/patches/ath9k/fixes-not-in-2.6.31-for-ath9k.txt

these unfortunately did not get propagated into the 2.6.31.y stable
releases yet, but must be handled on a case by case basis. But since
each release for Ubuntu is made every 6 months and since 9.10 release
is not a long term support release you are likely better off just
installing something like linux-backport-modules to get the 2.6.32
wireless subsystem to cure your fixes for now.

I am not sure but lets say all ath9k 2.6.31 fixes eventually get
merged into the next 2.6.31.y, it may or may not mean Ubuntu 9.10's
2.6.31 latest kernel will get those updates, depends likely on the
severity and the kernel package policy for Ubuntu.

Hope this better helps understand what I meant.

  Luis

[Tomas Pospisek (tpo-deb)]

This bug means that SIP over wireless is just scantily
useful under Karmic. It means a period of 5 seconds
of stuttering every 2 minutes. Quite embarrassing
when phoning with someone.

The patched NetworkManager from Wagner Volanin [1]
mentioned in comment #6 [2] in this thread works very
well. Thanks!
*t

[1] https://launchpad.net/~volanin/+archive/ppa/+packages
[2] https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/373680/comments/6

[Salvatore Giambrone (salvatoregx)]

my system is affected by the same bug and use Ubuntu 9.10

[Julien (ju+)]

Same problem here on a brand new lucid lynx : ping raises every 2 minutes when using wireless.

System info :

2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010 x86_64 GNU/Linux
0b:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)
cfg80211 148386 3 iwlagn,iwlcore,mac80211

Wagner, could you please release a lucid package including your patch ?

[Luis R. Rodriguez (mcgrof)]

On Mon, Apr 26, 2010 at 8:05 AM, Julien Couret <email address hidden> wrote:
> Same problem here on a brand new lucid lynx : ping raises every 2
> minutes when using wireless.
>
> System info :
>
> 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010 x86_64 GNU/Linux
> 0b:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)
> cfg80211              148386  3 iwlagn,iwlcore,mac80211
>
> Wagner, could you please release a lucid package including your patch ?

Lucid uses 2.6.32 and the background scanning which I described
earlier is part of 2.6.32 so you should be OK on Lucid.

$ git describe --contains 142b9f5074dc0d09dc0025739ad437723d7bf527
v2.6.32-rc1~703^2~506^2~36

I would not recommend disabling scanning unless you let the user save
that as a preference as otherwise you would not be able to pick APs
while you move around. Eventually the supplicant will get roaming
support and you will need bg scans for this.

  Luis

[Wagner Volanin (volanin)]

As I already stated, I completely agree with Luis that my patch is not a solution; it is just a simple (and hacky) workaround. The background scanning implemented in Lucid 2.6.32 kernel is the correct approach to this problem. I have not tested Lucid yet as I am waiting for the final version to be released, but this old patch applied almost cleanly to Lucid version of network-manager, so I am making the patched packages available for those having problems, such as Julien.

As explained before, this patch disables the scanning for available networks while you are connected, in order to avoid network stalls from happening every 2 minutes while the scanning is taking place. If your wireless network is already working fine, you don't need these packages.

The packages are available in my PPA as usual:
https://launchpad.net/~volanin/+archive/ppa

[Robert (roband)]

Network scanning seems to have improved in 2.6.32, but it's unfortunately still noticeable to me.

I'm currently running linux 2.6.32-22-generic in Lucid and when streaming audio to a remote pulseaudio server I get stuttering audio every two minutes. The stuttering lasts for about four seconds.

The ath9k driver is used for this WLAN card:
01:07.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)

NetworkManager version:
0.8-0ubuntu3

[hurie (hurie83)]

Had the same problem, I am using Ubuntu 10.04 at MBP 4.1

azhar@logos:~$ uname -a
Linux logos 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC 2010 i686 GNU/Linux
azhar@logos:~$ sudo dmidecode -s system-product-name
[sudo] password for azhar:
MacBookPro4,1

Applying Wagner Volanin patch and network manager stop having "hiccup", thanks Volanin.

[Julien (ju+)]

I'm sorry Luis but I don't understand what you mean by "The background scanning implemented in Lucid 2.6.32 kernel is the correct approach to this problem. ". Today, the problem is still there with those kernels (see Robert and hurie previous comments).

I understand that Wagner's fix is just a temporary hack and may change normal roaming behaviors but this is the only way to have a stable ping with wireless and network manager on lucid. So, does anyone have a status for this bug ?

[Robert (roband)]

I believe the current status of this bug is that we're waiting for the upstream bug to be fixed (https://bugzilla.gnome.org/show_bug.cgi?id=513820). There is a fix being worked on there.

Keep an eye on that bug's progress to see what's going on.

[Julien (ju+)]

Yes, I found it just after my last comment ;)

Thanks.

[Tomas Pospisek (tpo-deb)]

Since the 2.6.32 kernel doesn't work on my machine (#584866) I still need to run the old *.31 kernel and thus Network Manager's behaveour still breaks VoIP.

It's now been 2 years that Network Manager assumes it's smarter than the user and refuses to integrate any knobs that would let him tweak its behaveour to make NM really useable.

Attached is a graph of the ping intervals before and after installation of Wagner Volanin's NM package.

Thanks again Wagner Volanin!

[Tomas Pospisek (tpo-deb)]

And here's after installing Wagner Volanin's NM.

[SpiderTex (spider-tex)]

Question, and I appologise if this is not the right way to address this!

Bug 356807 says that it is a duplicate for this one (373680), however, I do not experience any latency in my network, but my log is spammed with rt_ioctl_giwscan messages every 2 minutes

I got rid of those by removing -DDBG parameter in the make file.

I can see that there is a relation to the network scanning every 2 minutes and the entry of the rt_ioctl_.... message in the log. But when reading the comments here, it seems that the messages in the log are dependent on how the chipset reacts to the root cause (every 2 minutes network scan)

Wouldn't it make sense to uncouple the two bug numbers?

I'm on kernel 2.6.32-24-generic
using ralink rt3572sta chipset (this happens with drivers v2.3.0.0 and the latest v2.4.0.1)

[sylvain bannier (bannier)]

I had the same issue. (intel BG2200 wireless + lucid)

What worked for me (at least for 15 minutes) :
- install Wagner Volanin's patch (thanks)
- install linux-backports-modules-wireless-lucid-generic

[NKjoep (nkjoep)]

is the Wagner Volanin patch compatible with ubuntu 10.04?

[wouter bolsterlee (wbolster)]

You should probably fill in the BSSID of your wireless network access point into NM's connection details dialog. This disabled the periodic background scanning, and solved the problem for me.

[John Bruno (jbalaska)]

I have been plagued with this problem since installing a Linksys WUSB600N (Ralink 2870 Chipset). I had hoped upgrading to Lucid would help, but the problem persists.
Currently at:
Linux AMD64X4-Ubuntu 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:58:24 UTC 2010 x86_64 GNU/Linux

I do almost constant FTP downloading from my 100Mbit dedicated server, and having my connection dropout for 3 to 5 seconds every 2 minuets really adds up and is quite annoying. I tried Wicd and that works ok, except if my connection goes down then it uses 100% CPU and I'm unable to kill it. Adding the BSSID of my router (D-Link DIR-655) did not help in my case.

Thank you Wagner Volanin very much for the patched NM it works perfectly.

Hopefully we can get a fix for this bug in Maverick.

Thanks!

[Joke de Buhr (joke)]

Still the same problem in Maverick.

[Robert (roband)]

Actually, this is fixed in Maverick, but network scanning isn't disabled by default.

No disable network scanning you need to explicitly set BSSID for your access points in NetworkManager. The BSSID is the MAC address of your access point (get it by running iwconfig when connected to your access point).

This behaviour is described in the upstream bug here:
https://bugzilla.gnome.org/show_bug.cgi?id=513820#c21

[John Bruno (jbalaska)]

I can confirm that while adding the BSSID in Lucid did not stop scanning "for me", It does in fact stop scanning in Maverick!

Great Implementation of a stop scanning fix. If you need to scan ssid's leave the BSSID field blank, if you need to disable scanning, add the BSSID. Nice!

[Mathieu Trudel-Lapierre (cyphermox)]

Great, assigning this to myself as yet another bug to consider for a possible SRU for Lucid. This still involves cherry-picking http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=NM_0_8&id=080ee1f2dbf0b55d63ec8629dbbd31f11aab52b9 and careful testing, so I'll first prepare a package. Marking as Triaged since there's an obvious fix.

[Luis R. Rodriguez (mcgrof)]

On Tue, Oct 12, 2010 at 8:11 PM, Mathieu Trudel <email address hidden> wrote:
> Great, assigning this to myself as yet another bug to consider for a
> possible SRU for Lucid. This still involves cherry-picking
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=NM_0_8&id=080ee1f2dbf0b55d63ec8629dbbd31f11aab52b9
> and careful testing, so I'll first prepare a package. Marking as Triaged
> since there's an obvious fix.

The real fix is not to disable scanning for a BSS once you are
associated, if you disable scanning for a BSS then you won't be able
to roam in a corporate environment. You want to roam to be able to
make a smooth transition from one AP to another on the same ESS. We
allow for this in mac80211 and the proposed "solution" on this thread
is no fix at all, its only something that should be considered if you
are certain the AP is singular. If the AP is singular then sure, it
makes no sense to scan and not sure if this is something that should
be specified as a toggle when configuring wireless settings for the
first time or if wpa_supplicant should pick this up on its own.

Most Linux distributions today use Network Manager and do a background
scan every 60 seconds when you are associated. It does this to feed to
wpa_supplicant new data from the BSSes around you so wpa_supplicant
can roam if it finds you are closer to another BSS with a better
signal. Network Manager should not be triggering a scan every 60
seconds, instead it should be triggering a scan if the current BSS has
hit an RSSI for the BSS below a certain threshold or a large specific
period of time has elapsed. The kernel and wpa_supplicant has support
for this now, look at using the bgscan module on wpa_supplicant.

This needs to be addressed in Network Manager. Linux distributions
would also need to switch to using nl80211, the new event (RSSI going
below a certain threshold) is only available using nl80211. Using
nl80211 is what should be used today.

For an example of a Linux distribution doing the right thing with
regards to background scanning you can look at ChromeOS, it uses a
fork of conmann they made, flimflam, flimflam uses the bgscan module.

  Luis

[Luis R. Rodriguez (mcgrof)]

On Wed, Oct 13, 2010 at 11:06 AM, Luis R. Rodriguez <email address hidden> wrote:
> On Tue, Oct 12, 2010 at 8:11 PM, Mathieu Trudel <email address hidden> wrote:
>> Great, assigning this to myself as yet another bug to consider for a
>> possible SRU for Lucid. This still involves cherry-picking
>> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=NM_0_8&id=080ee1f2dbf0b55d63ec8629dbbd31f11aab52b9
>> and careful testing, so I'll first prepare a package. Marking as Triaged
>> since there's an obvious fix.
>
> The real fix is not to disable scanning for a BSS once you are
> associated, if you disable scanning for a BSS then you won't be able
> to roam in a corporate environment. You want to roam to be able to
> make a smooth transition from one AP to another on the same ESS. We
> allow for this in mac80211 and the proposed "solution" on this thread
> is no fix at all, its only something that should be considered if you
> are certain the AP is singular. If the AP is singular then sure, it
> makes no sense to scan and not sure if this is something that should
> be specified as a toggle when configuring wireless settings for the
> first time or if wpa_supplicant should pick this up on its own.
>
> Most Linux distributions today use Network Manager and do a background
> scan every 60 seconds when you are associated. It does this to feed to
> wpa_supplicant new data from the BSSes around you so wpa_supplicant
> can roam if it finds you are closer to another BSS with a better
> signal. Network Manager should not be triggering a scan every 60
> seconds, instead it should be triggering a scan if the current BSS has
> hit an RSSI for the BSS below a certain threshold or a large specific
> period of time has elapsed. The kernel and wpa_supplicant has support
> for this now, look at using the bgscan module on wpa_supplicant.
>
> This needs to be addressed in Network Manager. Linux distributions
> would also need to switch to using nl80211, the new event (RSSI going
> below a certain threshold) is only available using nl80211. Using
> nl80211 is what should be used today.
>
> For an example of a Linux distribution doing the right thing with
> regards to background scanning you can look at ChromeOS, it uses a
> fork of conmann they made, flimflam, flimflam uses the bgscan module.

Also, consider that if you disable scanning the scan list will be old
anyway, so even if your AP is singular you may want to scan, but
definitely I agree it should not be every 60 seconds. How often? Not
sure, this should be taken up on the linux-wireless mailing list.

 Luis

[Jeremy Visser (jeremy-visser)]

Luis R. Rodriguez said:
> The real fix is not to disable scanning for a BSS once you are
> associated, if you disable scanning for a BSS then you won't be able
> to roam in a corporate environment.

If I hardcode the BSSID in, how am I going to roam anyway?

[Luis R. Rodriguez (mcgrof)]

On Wed, Oct 13, 2010 at 2:14 PM, Jeremy Visser <email address hidden> wrote:
> Luis R. Rodriguez said:
>> The real fix is not to disable scanning for a BSS once you are
>> associated, if you disable scanning for a BSS then you won't be able
>> to roam in a corporate environment.
>
> If I hardcode the BSSID in, how am I going to roam anyway?

You should re-read my posts, be sure to read about the sections I note
about a singular AP.

  Luis

[jcglt (jcjglt)]

I'm currently running linux 2.6.32-25-generic in Lucid after reverting from 2.6.32-26 which was awfully unsteady : a disconnexion of Wifi every 2 minutes. Things have improved coming back to -25 but are still not perfect. I tried also wicd without results.
The ath5k driver is used for this WLAN card with Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01).
I replaced "network-manager 0.8-0ubuntu3" by "network-manager 0.8-0ubuntu3+volanin1" and things have really improved : the wifi connexion looks like rock-steady now. I agree that I lost some roaming ability (in fact I think that if I reboot in a new place, network-manager will scan the area and I will have to choose a network and stick to it, true or false ?).
I consider there is a very serious bug here and a wifi connexion which stops every 2 or 3 minutes, to automatically reconnect sometimes after a few seconds, other times (as with 2.6.32-26) stay during minutes unconnected, some other times having to reboot the computer !!! is not acceptable.

Many thanks to Wagner Volanin for is patch which I will use until a lasting fix is found for "network-manager"

[Gustavo Noronha Silva (kov)]

I have this same problem with a new pci card I bought for my desktop computer. Since it's a desktop computer that is only going to connect to my single AP, I don't really care about roaming, so I cooked a patch to replicate the behaviour of the one posted here earlier for newer NetworkManager versions. I have 0.8.1-6 from Debian sid (which is what I use).

[wouter bolsterlee (wbolster)]

Why? Filling in the BSSID of your wireless network access point should avoid background scanning. See also my earlier comment.

[Mathieu Trudel-Lapierre (cyphermox)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed in the latest version of Ubuntu - Maverick Meerkat.

This is a significant bug in Ubuntu. If you need a fix for the bug in previous versions of Ubuntu, please do steps 1 and 2 of the SRU Procedure [1] to bring the need to a developer's attention.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

Note that a minimal patch has already been identified, it is available upstream as per comment #39.

In the meantime, as a workaround you can use the packages from the NetworkManager trunk PPA which should include this fix.

[AIAMUZZ (muzafsh-113)]

Hi,

I don't know if this is a bug or not...
please let me know if i have to start a new thread to report this bug.

I am using 'NetworkManager Applet 0.8.1'
Normally this works just fine except...

when i want my 3G connection to auto connect on boot with the SIM pin enabled !!! Please note that It works fine if i have the SIM pin disabled.

Shouldn't it work even when the SIM lock pin is enabled ???

Ideally i would expect the nm-applet prompt me to enter the SIM unlock pin at startup, and once i enter the pin it should auto-connect on correct PIN entry.

But instead the nm-applet fails to load on boot when the 3G connection is checked for 'Connect Automatically' and the SIM pin is enabled.

If this is a bug, please help fix this.

If its not a bug, then a functionality described above would be most convenient.

thanks,
Muzafsh

[Jeremy Visser (jeremy-visser)]

AIAMUZZ said:
> I don't know if this is a bug or not...
> please let me know if i have to start a new thread to report this bug.

Yes, it is generally considered bad etiquette to hijack an existing bug
report or topic with something that is off-topic.

Please file a new bug report.

[AIAMUZZ (muzafsh-113)]

thanks !

sorry, am a newbie !

Can somebody tell me how do i open a new thread to report this bug ?

thanks,

[Edwin Grubbs (edwin-grubbs)]

AIAMUZZ said:
> sorry, am a newbie !
>
> Can somebody tell me how do i open a new thread to report this bug ?

If you are reporting a bug with ubuntu, here are directions.
https://help.ubuntu.com/community/ReportingBugs

If you are reporting a bug for software tracked by launchpad.net but you are not running on ubuntu, just search for the project name here:
https://launchpad.net/projects

If you prefer to report bugs via email, here are directions:
https://help.launchpad.net/Bugs/EmailInterface

[Reuben Thomas (rrt)]

This bug is marked as fixed in Maverick, but I am experiencing it precisely as described in a default install of Natty on an Asus EeePC 901: every two minutes, the connection pauses for about a second, and an rt_ioctl_giwscan debug message is written to syslog.

[Reuben Thomas (rrt)]

I'm sorry, I finally understood that this bug is not fixed, but instead there's a workaround (to lock the BSSID). Perhaps someone with the correct authorisation could write a note about this workaround for the bug description at the top of the page? It might save other users' time. For example:

If you suffer from this problem, and you use a wireless network with only one access point, then there is a workaround: in Network Manager, edit the network connection, and fill in the BSSID of your access point. (This can be obtained by running the command "iwconfig" in a terminal.) This stops Network Manager from scanning for other access points, and hence should alleviate the symptoms of the underlying bug. The "real" fix is for the card's network driver not to take so long to scan for other APs, but some drivers have not yet (and may never be) fixed.

(I can't find an easier way to get the BSSID; please feel free to edit the above if there is one!)

[Andrew Barbaccia (andrew-barbaccia)]

I would like to say I have been battling with this issue for a little over a year, when I first started with ralink wireless drivers.

The above post is correct, when scanning for new networks, the network speeds drop out. Wagner Volanin had a PPA which disabled this in network-manager, but the above fix (entering your AP BSSID) is much simpler.

What I have since found is that on heavy traffic loads the driver will start sending these messages to the log:
Feb 2 18:26:31 andrew-desktop kernel: [159845.859209] DeQueueRunning[0]= TRUE!
Feb 2 18:26:52 andrew-desktop kernel: [159864.444015] DeQueueRunning[0]= TRUE!

I have confirmed this by running iperf on two machines in my network and bumping the number of processes to 10 (iperf -c <hostname> -P 10)

Can anybody suggest how to debug further?

[Alex Vorona (alex-vorona)]

>If you suffer from this problem, and you use a wireless network with only one access point, then there is a workaround:
If You have more than one access point - you have to setup unique SSID on each AP and use it with forced BSSID.

[Romuald (romu70)]

Hi,
I also do confirm this bug, and also do confirm that it is fixed by the Walter Volanin's PPA. As it seems to be a pretty old bug, why the fix hasn't been commited upstream yet?

[awelux (alexander-werth)]

Here's a problem:
Some corporations have roaming setup wrong.
Any move to another AP will cause the encryption to fail and the connection to timeout.
For these environments we must have a way to disable roaming.
One option is to disable scanning once connected.

[Jeremy Visser (jeremy-visser)]

On 17/11/2012 00:33, awelux wrote:
> Some corporations have roaming setup wrong. Any move to another AP
> will cause the encryption to fail and the connection to timeout. For
> these environments we must have a way to disable roaming.

I cannot even begin to describe how dumb the logic in the above is.

The proper solution is to fire the incompetent network admins that can't
figure out roaming.

[Koen Mercken (koen-mercken)]

This is still not fixed in 14.04!

[Rolf Leggewie (r0lf)]

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

[NKjoep (nkjoep)]

What a pity :(