OpenWrt Forum Archive

Topic: Can't stay with AP in client mode

The content of this topic has been archived on 26 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I'm running kamikaze/7.09/brcm-2.4/openwrt-brcm-2.4-squashfs.trx on my new Asus WL-500gP in client mode. The association with its closest AP drops after a while (between 5 minutes and 8 hours). The funny thing is that iwconfig wl0 shows "Not Associated", but wl sta_info still shows state: AUTHENTICATED ASSOCIATED.

To get online, again, I have to reboot or issue a sequence of wl radio off; wl radio on; wifi up; ifup wan commands. The patch from ticket 2526 doesn't make a difference.

What do I miss?

When it's NOT working:

# wl status; iwconfig wl0; wl sta_info 00:XX:YY:ZZ:CC:DD
SSID: "WiFiISP"
Mode: Managed   RSSI: -44 dBm   noise: -84 dBm  Channel: 1
BSSID: 00:00:00:00:00:00        Capability: ESS
Supported Rates: [ 1(b) 2(b) 5.5 6 9 11 12 18 24 36 48 54 ]

wl0       IEEE 802.11-DS  ESSID:"WiFiISP"
          Mode:Managed  Frequency:2.412 GHz  Access Point: Not-Associated
          Tx-Power:17 dBm
          RTS thr:2347 B   Fragment thr:2346 B
          Encryption key:off
          Link Signal level:-44 dBm  Noise level:-84 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:636  Invalid misc:0   Missed beacon:0

 STA 00:XX:YY:ZZ:CC:DD:
         rateset [ 1 2 5.5 6 9 11 12 18 24 36 48 54 ]
         idle 88 seconds
         in network 1646 seconds
         state: AUTHENTICATED ASSOCIATED
         flags 0x18:

When it's working:

# wl status; iwconfig wl0; wl sta_info 00:XX:YY:ZZ:CC:DD
SSID: "WiFiISP"
Mode: Managed   RSSI: -44 dBm   noise: -84 dBm  Channel: 1
BSSID: 00:XX:YY:ZZ:CC:DD        Capability: ESS
Supported Rates: [ 1(b) 2(b) 5.5 6 9 11 12 18 24 36 48 54 ]

wl0       IEEE 802.11-DS  ESSID:"WiFiISP"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:XX:YY:ZZ:CC:DD
          Tx-Power:17 dBm
          RTS thr:2347 B   Fragment thr:2346 B
          Encryption key:off
          Link Signal level:-44 dBm  Noise level:-84 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:21  Invalid misc:0   Missed beacon:0

 STA 00:XX:YY:ZZ:CC:DD:
         rateset [ 1 2 5.5 6 9 11 12 18 24 36 48 54 ]
         idle 1 seconds
         in network 685 seconds
         state: AUTHENTICATED ASSOCIATED
         flags 0x18:

Additionally, if I just surf the Net or retrieve e-mails, the AP association stays up all day (> 8 hours) easily. When I stress the baby with a BT download of Fedora DVD image, it crumbles into this weird state. The BT download involves hundreds, even thousands at times, of connections, with port forwarding (really "host forwarding" due to Port forwarding stops working after a while).

My Buffalo box running dd-wrt v23 sp2 has no trouble with the download.

I'm trying to rule out the possibility of fragile hardware as the root cause. In the meantime, does anybody successfully BT-download stuff with the 2.4 version of Kamikaze/7.09? How about the 2.6 version?

I have no idea how to do it, but have you tried using xsupplicant (as opposed to the built-in supplicant)?  It might provide more debugging info.

If you do figure out how to use xsupplicant, PLEASE update the wiki.  I put down what I know about wpa_supplicant, but it doesn't support brcm wireless chipsets.

(Last edited by exobyte on 29 Jan 2008, 20:00)

Thank you, exobyte, for your reply. I forgot to say earlier: my WiFi ISP is "open" (at least to allow an instance of association and an IP address). I didn't try any *supplicant.

Yes, it's a bummer that wpa_supplicant doesn't support brcm wireless chipsets. That's why I'm on the "open" side of my WiFi ISP.

wpa_supplicant works with open APs, so xsupplicant might, too (again, debugging info is very useful).

It is a bit weird to see  RTS thr and Fragment thr so close to the MTU (which might not even be the REAL mtu if there's ethernet anywhere), but I wouldn't expect that to cause an AP problem.

exobyte wrote:

wpa_supplicant works with open APs, so xsupplicant might, too (again, debugging info is very useful).

Thanks for your suggestion. I've been in the dark. Will try it.

buildster wrote:

I'm trying to rule out the possibility of fragile hardware as the root cause. In the meantime, does anybody successfully BT-download stuff with the 2.4 version of Kamikaze/7.09? How about the 2.6 version?

Can't fault the hardware... it must be the software. Running with a stable version of dd-wrt v23 sp3, my WL-500gP handled the stress of BT download for over 10 hours.

It seems to me, kamikaze 7.09 brcm-2.4, which can't pass the stress test, is unstable for regular use. Maybe just its port forwarding. Debug the problem or wait for Broadcom 2.6 with b43 driver?

White Russian 0.9 is very stable on my WL-500gP.

Kamikaze left some bugs in the 2.4 station, and has gone onto the 2.6 and beyond.

The discussion might have continued from here.