Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #440 (assigned defect)

Opened 14 years ago

Last modified 8 years ago

Wireless connection pauses / disconnects on ubuntu / Suse / Mandrake

Reported by: anonymous Assigned to: kelmo (accepted)
Priority: major Milestone: version 0.9.x - progressive release candidate phase
Component: madwifi: other Version: trunk
Keywords: atheros disconnect Cc:
Patch is attached: 0 Pending:

Description (Last modified by mrenzmann)

AMD Athlon XP, DWL-G510, SUSE10 X64 / Ubuntu 5.xx

I have a strange problem with my wireless connection. Both Ubuntu(X86) and SUSE(X64) connections pauses a few seconds in when I download or browse websites. I am not sure what is causing this. There is nothing seems to be worng. This happens for internet, ssh connections from other computers, or even pinging the router(192.168.0.1). The SSH connections(putty) gets disconnected sometimes. SUSE madwifi is the latest source from svn which I compiled and installed. I have a windows XP installation on the same machine which works fine. Windows shows signal quality 85% and KInternet shows 35-37%. Not sure this means anything.

I don;t think this is a DSN issue, even downloads pauses in between and continuous. Also if I browse IP Address the same delay occurs

Pinging various sites shows 35- 55 % packet loss.

Here are the things I tried. (SUSE 10) Disabled firewall. Disabled ipv6. Downloaded and installed Madwifi drivers from svn Disabled eth0 and eth1 (two wired networks, but not connected). Nothing helped med so far.

My Settings.

RESOLV.CONF

search hsd1.ma.comcast.net
nameserver 192.168.0.1

linux:~ # iwconfig
lo        no wireless extensions.
sit0      no wireless extensions.
eth0      no wireless extensions.
wifi0     no wireless extensions.
ath0      IEEE 802.11g  ESSID:"JOEWORKGROUP"  Nickname:"linux"
         Mode:Managed  Frequency:2.437 GHz  Access Point: 00:40:05:C8:44:88
         Bit Rate:11 Mb/s   Tx-Power:18 dBm   Sensitivity=0/3
         Retry:off   RTS thr:off   Fragment thr:off
         Encryption key:<MyKey>   Security mode:open
         Power Management:off
         Link Quality=36/94  Signal level=-59 dBm  Noise level=-95 dBm
         Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
         Tx excessive retries:0  Invalid misc:0   Missed beacon:0
eth1      no wireless extens

linux:~ # tracepath yahoo.com
1:  192.168.0.101 (192.168.0.101)                          0.130ms pmtu 1500
 1:  192.168.0.1 (192.168.0.1)                            asymm  2   3.345ms
 1?: 10.216.192.1 (10.216.192.1)                          asymm  2
 2:  10.216.192.1 (10.216.192.1)                           14.793ms
 3:  68.87.157.33 (68.87.157.33)                           13.440ms
 4:  10g-8-3-ar02.needham.ma.boston.comcast.net (68.87.144.241)  14.897ms
 5:  12.125.47.49 (12.125.47.49)                          asymm 10  15.965ms
 6:  tbr1-p013301.cb1ma.ip.att.net (12.123.40.218)        asymm 16  33.722ms
 7:  tbr2-cl16.n54ny.ip.att.net (12.122.10.22)            asymm 15  31.464ms
 8:  tbr2-cl15.wswdc.ip.att.net (12.122.10.54)            asymm 14  31.441ms
 9:  gar1-p390.ascva.ip.att.net (12.123.8.53)             asymm 12  29.554ms
10:  no reply
11:  ae1.p420.msr2.dcn.yahoo.com (216.115.96.185)         asymm 17  30.238ms
12:  ge6-1.bas1-m.dcn.yahoo.com (216.109.120.217)         asymm 16  28.573ms
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
31:  no reply
    Too many hops: pmtu 1500
    Resume: pmtu 1500

linux:~ # traceroute yahoo.com
traceroute to yahoo.com (216.109.112.135), 30 hops max, 40 byte packets
 1  192.168.0.1  2.036 ms   1.945 ms   1.959 ms
 2  10.216.192.1  12.719 ms   11.597 ms   9.340 ms
 3  68.87.157.33  17.400 ms   19.003 ms   15.223 ms
 4  10g-8-3-ar02.needham.ma.boston.comcast.net (68.87.144.241)  10.848
ms   11.389 ms   12.280 ms
 5  12.125.47.49  10.701 ms   10.427 ms   14.261 ms
 6  tbr1-p013301.cb1ma.ip.att.net (12.123.40.218)  27.224 ms   28.383
ms   27.502 ms
 7  tbr2-cl16.n54ny.ip.att.net (12.122.10.22)  26.165 ms   28.575 ms   31.016 ms
 8  tbr2-cl15.wswdc.ip.att.net (12.122.10.54)  25.382 ms   25.513 ms   26.640 ms
 9  gar1-p390.ascva.ip.att.net (12.123.8.53)  28.240 ms   26.398 ms   25.696 ms
10  * * *
11  vlan220-msr2.dcn.yahoo.com (216.115.96.165)  22.168 ms
ae1.p420.msr2.dcn.yahoo.com (216.115.96.185)  26.223 ms
vlan200-msr1.dcn.yahoo.com (216.115.96.161)  23.939 ms
12  ge7-2.bas1-m.dcn.yahoo.com (216.109.120.201)  27.303 ms
ge3-1.bas1-m.dcn.yahoo.com (216.109.120.149)  24.960 ms
ge6-1.bas1-m.dcn.yahoo.com (216.109.120.217)  25.164 ms
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

linux:~ #  ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=6 ttl=127 time=1.80 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=127 time=1.81 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=127 time=2.47 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=127 time=1.79 ms

--- 192.168.0.1 ping statistics ---
9 packets transmitted, 4 received, 55% packet loss, time 8026ms
rtt min/avg/max/mdev = 1.796/1.971/2.472/0.292 ms

linux:~ # ifconfig
ath0      Link encap:Ethernet  HWaddr 00:13:46:79:E9:A5
          inet addr:192.168.0.101  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::213:46ff:fe79:e9a5/64 Scope:Link
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:38023 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25016 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:54424694 (51.9 Mb)  TX bytes:1861530 (1.7 Mb)

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:71 errors:0 dropped:0 overruns:0 frame:0
          TX packets:71 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:5193 (5.0 Kb)  TX bytes:5193 (5.0 Kb)

wifi0     Link encap:Ethernet  HWaddr 00:13:46:79:E9:A5
          inet6 addr: fe80::213:46ff:fe79:e9a5/64 Scope:Link
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:59427 errors:0 dropped:0 overruns:0 frame:464
          TX packets:25200 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:199
          RX bytes:57908435 (55.2 Mb)  TX bytes:2621229 (2.4 Mb)
          Interrupt:58 Memory:ffffc200009c0000-ffffc200009d0000

from demsg

ath_hal: module not supported by Novell, setting U taint flag.
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
eth0: forcedeth.c: subsystem: 01462:7100 bound to 0000:00:0a.0
usb 1-2: new low speed USB device using ohci_hcd and address 2
wlan: module not supported by Novell, setting U taint flag.
wlan: 0.8.4.2 (svn 1457)
ath_rate_sample: module not supported by Novell, setting U taint flag.
ath_rate_sample: 1.2 (svn 1457)
ath_pci: module not supported by Novell, setting U taint flag.
ath_pci: 0.9.4.5 (svn 1457)
ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 58
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: mac 7.8 phy 4.5 radio 5.6
wifi0: Use hw queue 1 for WME_AC_BE traffic
wifi0: Use hw queue 0 for WME_AC_BK traffic
wifi0: Use hw queue 2 for WME_AC_VI traffic
wifi0: Use hw queue 3 for WME_AC_VO traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
wlan_scan_sta: module not supported by Novell, setting U taint flag.
wifi0: Atheros 5212: mem=0xfe9e0000, irq=58
linux:~> athstats
502 tx management frames
600 long on-chip tx retries
456 tx frames with no ack marked
14 tx frames with an alternate rate
564 rx failed due to bad CRC
247308 PHY errors
    10283 OFDM timing
    237025 CCK timing
5722 periodic calibrations
rssi of last ack: 35
rssi of last rcv: 34
1 switched default/rx antenna
Antenna profile:
[1] tx     9660 rx    99559
[2] tx    18997 rx        0

Pl

Attachments

xyz.txt (7.8 kB) - added by anonymous on 03/01/06 20:57:16.
Outputs attached in text form

Change History

03/01/06 20:57:16 changed by anonymous

  • attachment xyz.txt added.

Outputs attached in text form

03/14/06 11:54:37 changed by mrenzmann

  • description changed.

03/14/06 11:54:47 changed by mrenzmann

  • version set to trunk.

04/04/06 00:53:58 changed by anonymous

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.

04/04/06 12:33:37 changed by anonymous

  • keywords set to atheros disconnect.

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.

04/11/06 12:26:10 changed by TrinitronX

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

04/24/06 21:26:28 changed by anonymous

  • summary changed from Wireless connection pauses / disconnects on ubuntu / Suse to Wireless connection pauses / disconnects on ubuntu / Suse / Mandrake.

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.

04/24/06 22:09:28 changed by anonymous

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

05/23/06 12:42:14 changed by kelmo

  • status changed from new to assigned.
  • owner set to kelmo.
  • milestone set to version 0.9.x - progressive release candidate phase.

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 ;-)

07/07/06 02:08:15 changed by p0g0

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.

08/24/06 16:15:30 changed by tosuja@post.cz

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)

01/11/07 03:08:40 changed by trustlix@linuxrocket.net

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 :)

01/11/07 23:14:20 changed by anonymous

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.

07/03/08 16:29:34 changed by anonymous

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