Association with wireless AP fails randomly
Though I am able to successfully connect to my wireless network, the connection to the AP randomly drops, usually within about 20 minutes.
Versions: Linux 2.6.16.9 Wireless Extensions v19 Wireless Tools v27 ndiswrapper 1.8 (using the Windows NDIS driver for the card) wpa_supplicant 0.4.8 (using the "wext" driver interface) Hardware (`lspci' output): 05:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) Network: Wireless AP/Router Broadcast SSID, 802.11g WPA with Private Shared Key This problem does not occur in Windows. I have tried multiple versions of the driver but that seems to have no effect. I am running wpa_supplicant as a daemon, but I have to restart it anyway when the signal is lost because it doesn't seem to try to re-aquire. I've created a shell script to run the necessary commands and start over, but I have to do that every time the connection is lost, and it's a major nuisance. |
A couple of things you might think about:
Quote:
Quote:
Code:
CONFIG_DRIVER_NDISWRAPPER=y |
I'm sorry, I reported my version of ndiswrapper incorrectly. The correct version is 1.14; the output of `ndiswrapper -v', however, reports "utils version: 1.8" before its own version, and I simply took the first number I saw.
Secondly, the reason I'm using `wext' instead of `ndiswrapper' with wpa_supplicant is because I get the following message on my console with `ndiswrapper' when I initialize wpa_supplicant: Code:
ndiswrapper: WPA support through 'ndiswrapper' interface is deprecated; use 'wext' interface Third, by the "Windows NDIS driver for the card", I meant bcmwl5.inf/bcmwl5.sys (which is the driver provided by the manufacturer, for the card I'm using, for Windows, written for the NDIS API). Finally, I will upgrade to ndiswrapper 1.15 and try again. At the time I wrote the original version of the article (in Linux - Networking), 1.14 was the latest version. I will also add 'CONFIG_CTRL_IFACE=y' to my wpa_supplicant config and try again (I do not need the EAP parts, I'm using PSK; I'm not using 802.11x either). |
Update
Alright, I've made the following changes:
It should also be noted that this usually happens after about 10/20 minutes of inactivity, but this is not always consistent. |
Quote:
I would also have a look through your logs (/var/log/messages and /var/log/syslog) and see if either your card or ndiswrapper is leaving some messages about why it is shutting down. |
Okay, I've checked for what you said. My BIOS configuration tool provides very few options, none of which seem to relate to power-saving features.
According to `iwconfig', power management is off for the interface. I am using ACPI support (modules 'ac', 'battery', 'processor', and 'thermal') and cpufreq (CPU frequency scaling), with the 'ondemand' and 'conservative' governers (for A/C and battery power respectively). I checked /var/log/syslog and found nothing conclusive, however /var/log/messages showed several perhaps pertinent messages: Code:
Apr 30 23:33:53 echo logger: ACPI group battery / action BAT1 is not defined |
Hm. I think that the only way to figure out what is going on is to do some experiments to see if the problem can be isolated. To be honest, I don't have a good idea of why this is happening but if you are up for it, I would suggest attempting the following:
1) Disable all power-saving features, particularly the power govenors. To my way of thinking these are the most likely culprits. On my laptop I use the ACPI monitors (temp, battery, CPU, etc.) but I don't do any frequency scaling or power control. 2) Temporarily switch your network to WEP or no encyrption so that you can stop using wpa_supplicant. If the shutdowns stop, then wpa_supplicant is the culprit. However, if they keep happening, then it is not the problem. 3) If you are comfortable patching and compiling your own kernel, the bcm43xx drivers (a native linux driver for Broadcom chipsets) is in the current 2.6.17-rc versions of the kernel. That would let you test if ndiswrapper is the problem. Note that the bcm43xx driver doesn't do WPA yet, so you would have to move to WEP or no encryption to test this driver. By the way, I don't think those errors have any bearing on this (though I do reserve the right to be wrong). They're more likely due to one of the ACPI monitoring apps. |
All times are GMT -5. The time now is 11:02 PM. |