Regular network drops with madwifi

Attached is a log of a wpa_cli session in which it logs the many many disconnects/reconnects, as well as some failed attempts at connecting, where I ended up doing one of the following:
1) click on the applet, and click on my AP's SSID to reconnect
2) close the applet, close the kde wallet, and restart the applet to reconnect
3) manually issue commands to wpa_supplicant through the client interface

All of these attempts resulted in temporary relief, until the next disconnect. Disconnects seemed random, at first it would at least stay on for about a minute, with intermittent disconnects/reconnects thereafter.
As mentioned earlier, I have had no problems other than having to manually run:
wpa_supplicant -iath0 -dmadwifi -c/etc/wpa_supplicant.conf -B -w
sudo invoke-rc.d networking restart

On every restart (Somehow I couldn't get wpasupplicant to run on boot... something wrong with the rc.d scripts). The signal strength was very good both in windows on the same machine, as well as while using wpasupplicant and the madwifi drivers before due to having a high gain antenna attached to the PC's wireless card. Perhaps the versions of these differ between those used for the network-manager package, and those previously installed.

I've got the same problem on my Lenovo X41 (not tablet) with an ipw2200 connecting to a WRT54g running DD-WRT, and WPA2 AES PSK. Reconnects every 3ish seconds, and dumps a ridiculous amount of information to syslog. I essentially can't read my work email over this connection, since it requires a VPN (which keeps timing out).

Upgrading NM to 0.6.2 now.

Still occurs with 0.6.2-0ubuntu1.

Zack: initial report is about madwifi driver and it is a known issue. You report is using ipw2200 and this driver is supposed to be quite stable in regards to NM.

Even more strange, I have very similar config: HP nw8240, ipw2200 connecting to ASUS wl500gd running OpenWRT with WPA2-PSK AES. This combination is running fine for some time with NM 0.6.

Can you attach the errors reported to syslog and potentially also output of NetworkManager if started with -no-daemon mode. You may also want to consider opening new bug as the initial problem is known madwifi driver issue.

I'll file a separate bug. Thanks.

Ok... good to know this issue with madwifi is already known. After some searching, I found 2 posts in the ubuntu forums detailing this problem, basically coming to the conclusion that "madwifi can't handle iwscan without losing the current connection".
Hopefully this problem gets resolved in a madwifi update, and gets into the restricted modules package, everything else about the network-manager app works fine.

Also, I just tried a possible fix for this by attempting to run: iwpriv ath0 bgscan 0
however, it appears that 'bgscan' is not a recognized variable in my card.
The command returns: Invalid command : bgscan

I have been able to disable network-manager, and get wpa_supplicant and the madwifi drivers running without any disconnects, it seems the background scanning is definately the problem.

As a suggestion for a fix, at least until madwifi gets fixed, perhaps adding the functionality in network manager to disable background scanning, and also an option for manual scanning for when it's needed.

I just tried to add this to the upstream madwifi package, but couldn't find madwifi or the restricted modules listed in the "product name" search anywhere. I used 'network-manager' as the product name... but assigned it to madwifi trac. Hope this is ok... maybe I should report a bug with malone...lol

This is a known problem and is caused by the madwifi drivers not supporting "background scanning", so when NM scans for new networks the card gets disassociated from the AP.

madwifi-ng does not exhibit this problem.

I'm also getting something similar to this. Every ~2 minutes I lose network connectivity for approximately 10-15 seconds. I've attached my syslog dump in case that's of use.

Showing a lot of activity through Network Manager. Disconnection every ~2 minutes for about 10-15 seconds.

Confirmed on an Fujitsu-Siemens Amilo A1650G with Dapper 6.06 LTS and a WN2302A-F4 13ch. mPCI WLAN IEEE802.11 b/g (Atheros chipset).

Scott: Does this mean that Dapper does not use madwifi-ng and that if I install it I will stop having the problems?

Anyone still alive here?

Yes.... I've worked around this problem magically. I'm trying to figure out what it was that I did to get this to work, and hopefully it will work for a new install of Dapper too.

A temporary workaround for avoiding those annoyning disconnecting sessions is to run wpa_cli:

$ sudo wpa_cli

and issue the command ap_scan 0

> ap_scan 0

This will tell wpa_supplicant to stop scan. I tried to enter this into the /etc/wpa_supplicant.conf but nothing seems to happen.

confirmed disconecting issue on ibm x31

This happens on my Edgy system, too. I'm seeing a load of stuff in my system log about wpa-supplicant, even though I'm using WEP (yeah, I know.)

Can also confirm this bug on Edgy x86 32bit using a Dell Latitude D620 (ipw3945). Seeing this with both with WPA and WPA access points. When connecting to an AP by directly using wpa_supplicant without NetworkManager no disconnects appear.

Just wanted to confirm this bug with the current feisty build.

I do have an atheros based card that is supposed to work great with linux and did that before. It works well with wpa_supplicant but definitively doesn't with feisty and network manager.

I've searched all over the internet and it seems that network-manager probably searches other wlans while being connected - and that is the problem with the network-manager/wpa_supplicant/madwifi combination.

madwifi - works great, if not scanning while beeing connected
wpa-supplicant - works great
network-manager - works great, if it would not search for wlans while being connected

My advice :
* make an Konfiguration option for desktop pcs with wlan that disables wlan search while being connected - this isn't neccessary.
* Make it possible to configure a static wlan/wpa config for such people - more or less a gui for wpa_supplicant

I started having this problem right after upgrading to Feisty. I solved it by just uninstalling network-manager using add/remove applications. I don't know if that's useful or not:

Router: WRTP54G with Vonage firmware (1.00.62)

nVidia nForce 2 networking - wired

This bug neither is necessarily caused by wpa_supplicant, nor by madwifi. For more info and a different approach to fixing visit Bug #64173 , please.

It is indeed a problem with Network Manager, and not the madwifi drivers. I have worked around this by uninstalling network manager, and simply configuring wpa_supplicant by hand. This involved putting a startup script in /etc/init.d that starts wpa_supplicant at bootup.
If you want to make it able to start, stop, and restart it like a normal debian-style init.d script, then you'll have to create a different one. Mine's just a quick hack, and it's all I need:

#!/bin/bash
wpa_supplicant -Bw -qq -Dmadwifi -iath0 -c/etc/wpa_supplicant.conf

Of course, adjust options to suit your interface and configuration file path, etc... After putting this script in /etc/init.d, I made a symlink to that script in /etc/rcS.d . It must come before networking in the boot process. I named it "S40iwpasupplicant" so that it came just before "S40networking".
I'm sure there's a more official way of doing this that is cleaner, but this worked for me.

The solution would be an option to disable background scanning in nm -- sure

While no one in nm devel does so, i've done a hackish fix: in nm-device-802-11-wireless.c, changing 14 to 10 solved the problem (since my atheros has 11 channels)

/*¬
* A/B/G cards should only scan if they are disconnected. Set the timeout to active¬
* for the case we lose this connection shortly, it will reach this point and then¬
* nm_device_is_activated will return FALSE, letting the scan proceed.¬
*/¬

/////if ((self->priv->num_freqs > 14) && nm_device_is_activated (NM_DEVICE (self)) == TRUE)¬
/////Atheros does not like scanning too and has 11 channels, changing this to 10 (Kassick)
if ((self->priv->num_freqs > 10) && nm_device_is_activated (NM_DEVICE (self)) == TRUE)¬
{¬
   nm_device_802_11_wireless_set_scan_interval (app_data, self, NM_WIRELESS_SCAN_INTERVAL_ACTIVE);>¬
  goto reschedule;¬
}¬

linux-restricted-modules-2.6.20 ships with madwifi 0.9.1 - Current WEXT compliance should have been added to this release as requested here http://madwifi.org/ticket/462

Is it worth just applying the patch which has already been submitted for this? It looks like the problem could possibly lie with network manager after all. http://launchpadlibrarian.net/6824480/reconnect-timeout.diff.gz

This seems to have been fixed in network-manager 0.6.5-0ubuntu9.

Since a month or so, my wireless connections are almost rock-solid, so the fix seems to work. Thanks!

Ciao

Martin (TP T41p, madwifi, gutsy i386)

For Martin this bug appears to be fixed for madwifi in gutsy? anyone still has issues with that driver?

definitly not a deluge bug.

> For Martin this bug appears to be fixed for madwifi in gutsy? anyone
> still has issues with that driver?

It wasn't *really* a bug with madwifi as such ;-) Perhaps more the way
that network manager used madwifi (although it could be argued that
madwifi should work differently.....)

Anyway - now that network-manager is patched, there (hopefully)
shouldn't be any more problems. I don't know if that means the madwifi
bug should be marked invalid or not - probably....

Cheers

Chris

On Mon, Sep 03, 2007 at 04:39:00PM -0000, Chris Rowson wrote:
>
> It wasn't *really* a bug with madwifi as such ;-) Perhaps more the way
> that network manager used madwifi (although it could be argued that
> madwifi should work differently.....)
>
> Anyway - now that network-manager is patched, there (hopefully)
> shouldn't be any more problems. I don't know if that means the madwifi
> bug should be marked invalid or not - probably....

Which patch are you referring to?

 - Alexander

> Which patch are you referring to?
>
> - Alexander

Hi Alex,

The one you committed here
https://bugs.launchpad.net/network-manager/+bug/64173/comments/70

Raising the connection timeout seems to have settled down these
disconnects. We're not seeing frequent reports of them anymore. Unless
someone else has committed a patch to madwifi too? :-S

Catch you later.

Chris

> It wasn't *really* a bug with madwifi as such

Oh yes it was. If madwifi isn't capable of scanning when already connected, then it just shouldn't do the scan when given the order by NetworkManager (or by whoever). Either you support a feature or you don't support it; if you don't, you should refuse to do it when asked, either ignoring the request or returning an error.

I'm trying Ubunto 7.10 live CD with a DWL-G650 (atheros AR5212 chipset) on an intel pentium4.

I just boot the live CD and try to connect to my wifi network which is WEP-encrypted.

I have the exact symptoms described in the original post: wasn't this supposed to be fixed????
Should I assume my problem is not due to this bug, or isn't the fixed version of network manager included in the latest ubuntu release?

Note I'm using Ubuntu as it comes out of the box, I haven't installed anything.

I tried uninstalling network manager and connecting manually but it didn't help at all.
Nothing changed.

My steps:
- I boot the Ubuntu 7.10 live CD
- I go to Applications--> Add/Remove, uncheck Network Manager (i.e. uninstall) and OK
- After succesful uninstallation, I open a terminal and do the following:

====== TERMINAL =======
ubuntu@ubuntu:~$ iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wifi0 no wireless extensions.

ath0 IEEE 802.11g ESSID:"" Nickname:""
          Mode:Managed Frequency:2.437 GHz Access Point: Not-Associated
          Bit Rate:0 kb/s Tx-Power:18 dBm Sensitivity=1/1
          Retry:off RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=0/70 Signal level=-93 dBm Noise level=-93 dBm
          Rx invalid nwid:2297 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

ubuntu@ubuntu:~$ sudo iwconfig ath0 essid WLAN_6A
ubuntu@ubuntu:~$ sudo iwconfig ath0 key **********************
ubuntu@ubuntu:~$ sudo dhclient ath0
Internet Systems Consortium DHCP Client V3.0.5
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

wifi0: unknown hardware address type 801
wifi0: unknown hardware address type 801
Listening on LPF/ath0/00:15:e9:84:19:b6
Sending on LPF/ath0/00:15:e9:84:19:b6
Sending on Socket/fallback
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 5
DHCPOFFER from 10.40.156.201
DHCPREQUEST on ath0 to 255.255.255.255 port 67
DHCPACK from 10.40.156.201
grep: /etc/resolv.conf: No such file or directory
chown: failed to get attributes of `/etc/resolv.conf': No such file or directory
chmod: failed to get attributes of `/etc/resolv.conf': No such file or directory
bound to 192.168.1.36 -- renewal in 17626 seconds.
ubuntu@ubuntu:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=128 time=10.5 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=128 time=27.5 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=128 time=2.02 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=128 time=27.5 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=128 time=2.62 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=128 time=27.5 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=128 time=6.66 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=128 time=27.6 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=128 time=5.58 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=128 time=2.27 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=128 time=27.6 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=128 time=2.59 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=128 time=27.6 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=128 time=4.55 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=128 time=4.07 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=128 time=6.20 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=128 time=2.78 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=128 time=4.71 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=128 time=27.5 ms
64 bytes from 192.168.1.1: icmp_seq=42 ttl=128 time=9.66 ms
64 bytes from 192.168.1.1: icmp_seq=95 ttl=...

>
> Oh yes it was. If madwifi isn't capable of scanning when already
> connected, then it just shouldn't do the scan when given the order by
> NetworkManager (or by whoever). Either you support a feature or you
> don't support it; if you don't, you should refuse to do it when asked,
> either ignoring the request or returning an error.

Well Matteo, I think that various people have various opinions on the
matter. It's probably best not raking over those old coals again is
it? ;-)

I might be related:

I have a netgear PCMCIA card and a netgear router. I use 7.10 and wpa_supplicant with roaming configuration. Connection seems quite stable as long as I'm browsing or reading mails, but:
- watching movie from an NFS share (to server is connected via UTP to the same router) causes the link to be dropped every once in a while
- starting to copy from the NFS share (ie.: a movie) to the laptops disk causes the link to be dropped in a few seconds. Link than comes up, lights show heavy traffic and than link gets dropped in a few seconds again....and so on.

The above symptoms (hardly any link drops on low traffic intensity, and lots of drop on high int.) show me, that the driver has issues on high load. As I said this might not be related, but I'm no expert, however, I'm glad to provide more info or write a new bugreport in case you think it's relevant.

@Chris:

> Well Matteo, I think that various people have various opinions on the
> matter. It's probably best not raking over those old coals again is
> it? ;-)

I guess it is not. Sorry about that. Didn't mean to offend anyone though.

However, maybe in my case it is not this very bug, but symptoms are the same and I couldn't in any way get my wifi card to work correctly with madwifi.

- Disabling Network Manager didn't help (see my previous post)
- sudo iwpriv ath0 bgscan 0 didn't help.
- A few other "solutions" I found on similar bug reports didn't help.

The only way I could get connected was by getting rid of madwifi and using ndiswrapper + windows drivers.

I tried 8 linux distros, including Ubuntu; all of them booted with the live CD come out of the box with madwifi as the driver of the wifi card, the card is recognized and supposed to be working; however ALL of them exhibit more or less the behaviour described in this report: I can connect every once in a while and then lose connection soon. Latest version today of all the distros I tried, though probably this doesn't mean they include the latest version of madwifi.

Both in Ubuntu and Sabayon, I could easily get the connection working (at least as well as solid and fast as in windows) by replacing madwifi with ndiswrapper, without even touching network manager.

I've fight with this problem for long time. This is about a algorithm in HAL called ANI (Ambient Noise Immunization). ANI avoid a common nightmare called 'stuck beacon error', but in some chipsets brings low performance and recurrent disconnections. Since 9.4 version there's the possibility to turn off at runtime with a sysctl event. Try this:

====TERMINAL====
sysctl -w dev.wifi0.intmit=0

============

If it's ok you can edit /etc/sysctl.conf and add 'dev.wifi0.intmit=0' at end of file for set it at boot time.

More info here http://madwifi-project.org/ticket/705