Wireless connection pauses / disconnects on ubuntu / Suse / Mandrake

Outputs attached in text form

Check with the wiki on performance tuning - http://madwifi.org/wiki/UserDocs/PerformanceTuning

I was experiencing similar issues, but turning off background scanning (iwpriv ath0 bgscan 0) seems to correct the issue.

Give that a try and let us know what you find.

I can confirm this bug in Ubuntu Dapper freshly installed from the flight 6 cd. I did a total reinstall since the flight 5 disc, and still experience this same problem. I believe it's due to a problem with the drivers and atheros based cards. It seems madwifi can't handle iwscan without losing the current connection on these cards. I've reported this as a bug with the ubuntu team, and there is more info on the hardware I'm using, as well as the packaged versions of madwifi in the restricted-modules package.

https://launchpad.net/distros/ubuntu/+source/network-manager/+bug/37821

Also... I remember having connectivity issues in Ubuntu 5.10 as well... using the same setup as before... same exact behavior.

I would like to add that this bug is extremely severe once WPA encryption is enabled on the access point, causing long delays for reassociation, sometimes not even reconnecting at all, causing wpa_supplicant to attempt association in an unending loop. I've tried "iwpriv ath0 bgscan 0", but I get the error message: "Invalid command : bgscan". Apparently my DWL-g520 doesn't like it.

I'm even having troubles getting the connection stable for long enough to send this comment... :P

I get similar behaviour here.

Some more information that may help you to track this down:

I use WPA. When the AP is close to my computer (quality around 65) I have no problems but the other two APs that I can see in the scan sometimes show outrageous power levels (-1dBm with quality maxed out).

With the AP moved into the other room, I get quality of ~30 (-65dBm) but the link is no longer reliable. The other APs are indicated as having -1dBm most of the time but only when they are BOTH up. With just one of them, the link is fairly reliable.

Changing channels doesnt help much, neither did the 6dB antenna nor turning off background scan.

I am running madwifi-ng revision r1524 and wpa supplicant 0.4.8.
Kernel is 2.6.12 with pre-emption running on an Athlon XP2200

From /var/log/messages
Apr 24 19:45:32 brain1 kernel: ath_hal: module license 'Proprietary' taints kernel.
Apr 24 19:45:32 brain1 kernel: ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
Apr 24 19:45:32 brain1 kernel: wlan: 0.8.4.2 (svn 1524)
Apr 24 19:45:32 brain1 kernel: ath_rate_sample: 1.2 (svn 1524)
Apr 24 19:45:32 brain1 kernel: ath_pci: 0.9.4.5 (svn 1524)
Apr 24 19:45:32 brain1 kernel: PCI: Enabling device 0000:00:0f.0 (0014 -> 0016)
Apr 24 19:45:32 brain1 kernel: PCI: setting IRQ 10 as level-triggered
Apr 24 19:45:32 brain1 kernel: PCI: Assigned IRQ 10 for device 0000:00:0f.0
Apr 24 19:45:32 brain1 kernel: PCI: Sharing IRQ 10 with 0000:00:0e.2
Apr 24 19:45:32 brain1 kernel: wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
Apr 24 19:45:32 brain1 kernel: wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
Apr 24 19:45:32 brain1 kernel: wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
Apr 24 19:45:32 brain1 kernel: wifi0: H/W encryption support: WEP AES AES_CCM TKIP
Apr 24 19:45:32 brain1 kernel: wifi0: mac 7.9 phy 4.5 radio 5.6
Apr 24 19:45:32 brain1 kernel: wifi0: Use hw queue 1 for WME_AC_BE traffic
Apr 24 19:45:32 brain1 kernel: wifi0: Use hw queue 0 for WME_AC_BK traffic
Apr 24 19:45:32 brain1 kernel: wifi0: Use hw queue 2 for WME_AC_VI traffic
Apr 24 19:45:32 brain1 kernel: wifi0: Use hw queue 3 for WME_AC_VO traffic
Apr 24 19:45:32 brain1 kernel: wifi0: Use hw queue 8 for CAB traffic
Apr 24 19:45:32 brain1 kernel: wifi0: Use hw queue 9 for beacons
Apr 24 19:45:32 brain1 kernel: wifi0: Atheros 5212: mem=0xcb000000, irq=10

athstats
387 beacon miss interrupts
6195 tx management frames
276 long on-chip tx retries
5419 tx frames with no ack marked
9467 tx frames with short preamble
85 tx frames with an alternate rate
8714 rx failed due to bad CRC
88463 PHY errors
    14385 OFDM timing
    74076 CCK timing
    2 CCK restart
73 periodic calibrations
rssi of last ack: 34
rssi of last rcv: 33
1 switched default/rx antenna
Antenna profile:
[1] tx     2613 rx     9808
[2] tx     1065 rx        0

Like the previous poster, I too am struggling to post this (and will soon be throwing the lot out tbh - it almost isnt worth the hassle compared to hiding a telephone cable under the carpet :-( )
What do you need in order for me to help fix this?
I am a software engineer and whilst I don't want to mess my system up, I am quite happy to modify and test driver code if it will help.

Just to confirm the above, I have now turned off WPA in favour of a simple shared key. The link is now quite responsive.

The offer to help still stands...

I too am seeing a strange disconnect/reconnect phenomenon when using wpa_supplicant with madwifi-ng, though not with the severity described here.

This is most likely related to the discussion in #572.

Will take assignment of this ticket so I do not forget to further discuss this problem ;-)

This may not relate, but I have observed a periodic dropout too.

The gear under test is a repeater array of WRAPS. They are all running voyage (kernel 2.6.15) on CM9 radios in the A band in AHDEMO mode. Bgscan is off, diversity is off, and a single antenna has been selected for send and receive. This mode has no beacons, scanning, and all BSSIDs are 0, so there is no association, and all it does is dump data on a given channel. The receiver can ask for a packet to be resent, like on TP/TB cabling, but that's it. Because it is ADEMO mode, I'd guess that none of the dropouts are due to association/reassociation.

In a 3 WRAP array, the first and last WRAPs have OpenVPN running, and they create a tunnel that moved encrypted data from the eth0 on WRAP1 to eth0 on WRAP3.

During iperf runs from workstations at the two eth0 nodes described above, running top shows the cpu usage hitting 30-40% on the WRAPs running OpenVPN.

Watching top on all three wraps during long (>20 second) shows the cpu usage on WRAPs 1 & 3 in synchrony, and that at something like 20-30 second intervals, the cpu usage falls to that of a WRAP not running OpenVPN. I think this is the tunnel traffic stopping, and that is reinforced by a simultaneous stutter/delay on the ssh session showing top that is linked to WRAP2 via the radio link from WRAP3- if the links quit, then I would expect the WRAP2 top screen to not refresh on the 3 second interval it normally does, and that is just what I see.

It appears that having other cpu activity on the WRAPS, like a ping session from WRAP2 to WRAP3, or the SSH session reduces the frequency and the duration of the dropouts.

I have similar problem with WRAPs coupled with CM9 cards. I'm running Voyage (based on Debian Sarge) with kernel 2.6.15, madwifi svnr1611, WPA using wpa_supplicant 0.5.2 and hostapd 0.5.2. I run it on >10 devices now and I've got some problems.

I've got huge problems with OSPF and its multicast packets (however this problem seems to be resolved using latest development quagga version 0.99.4 and configuring lines as point-to-multipoint) but that's a different story.

Sometimes the client disassociates from the AP. I experience this on longer yet higher quality links (~3km, signal level -67dBm). The client disassociates within seconds or minutes at most and it's not dependant upon encryption status - it does the same running WPA, WEP or no encryption at all. Only when no encryption applied the client disassociates and never associates again, only ifdown/ifup of the interface (on both sides...) helps. Here's part of the log file documenting how often the reassociation occurs:

Aug 24 13:47:18 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 IEEE 802.11: associated                                                      
Aug 24 13:47:18 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: pairwise key handshake completed (WPA)
Aug 24 13:47:18 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: group key handshake completed (WPA)
Aug 24 13:47:32 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 IEEE 802.11: associated                                                      
Aug 24 13:47:32 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: pairwise key handshake completed (WPA)
Aug 24 13:47:32 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: group key handshake completed (WPA)
Aug 24 13:48:00 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 IEEE 802.11: associated                                                      
Aug 24 13:48:00 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: pairwise key handshake completed (WPA)
Aug 24 13:48:00 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: group key handshake completed (WPA)
Aug 24 13:49:53 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 IEEE 802.11: associated                                                      
Aug 24 13:49:53 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: pairwise key handshake completed (WPA)
Aug 24 13:49:53 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: group key handshake completed (WPA)
Aug 24 13:50:15 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 IEEE 802.11: associated                                                      
Aug 24 13:50:15 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: pairwise key handshake completed (WPA)
Aug 24 13:50:15 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: group key handshake completed (WPA)

There are some problems with WPA rekeying causing AP to kick client and sometimes the next handshake doesn't somehow work rendering the connection not operable. Here's what I've seen in logs:

Aug 24 09:28:19 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
Aug 24 09:28:19 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: pairwise key handshake completed (WPA)
Aug 24 09:28:19 wp-xxxx hostapd: ath1: STA 00:0b:6b:37:76:47 WPA: group key handshake completed (WPA)

I'm having this weird disconnect problem with a Thinkpad t60 notebook. I'm running gentoo linux on this computer and below are my configs:

Relevant applications:

madwifi-ng-0.9.2.1
madwifi-ng-tools-0.9.2
wpa_supplicant-0.5.6

Kernel:

Linux trstlx 2.6.19-gentoo-r2.trtlx #10 PREEMPT Wed Jan 10 17:15:05 BRST 2007 i686 Genuine Intel(R) CPU T1300  @ 1.66GHz GenuineIntel GNU/Linux

Device:

03:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)

#cat /etc/wpa_supplicant/wpa_supplicant.conf
network={
        scan_ssid=1
        ssid="id2"
        key_mgmt=WPA-EAP
        eap=LEAP
        identity="user"
        password="pass"
        priority=1
}
network={
        ssid="id1"
        key_mgmt=NONE
        wep_key0==key
        wep_tx_keyidx=0
        priority=2
}
network={
        ssid="id"
        key_mgmt=NONE
        wep_key0=key
        wep_tx_keyidx=0
        priority=10
}

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=1
ap_scan=1
fast_reauth=1

In the lab I work we have other t60 notebooks, and they have the same problem, when running Linux. I also saw a lot of places in the internet with people discussing this same problem, so, any patch fixing it are welcomed :)

Hi all.

Fortunately I discovered something interesting. Disabling the bluetooth device (my thinkpad t60 comes with it) stops those nasty disconnections.

I'll make you know if I find something else.

cheers.

Hi all, have had the same symptoms, changing fast_reauth in wpa-supplicant.conf from 1 to 0 brings a much better performance for association.

greets