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:
You might try upgrading to the latest stable ndiswrapper (1.15) and see if that helps. I'm also not sure what you mean by "Windows NDIS driver". For Broadcom chipsets, the bcmwl5.inf and .sys are usually a good choice. Have a look at the ndiswrapper wiki for your card and see what Windows driver they suggest.

Again, maybe I'm misunderstanding you, but wpa_supplicant should be compiled with the ndiswrapper interface. Just for comparison, here is the .config I use and I'm running the same chipset.

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:

I get the same problem with both.

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

Alright, I've made the following changes:

• linux 2.6.16.11 (latest)
• ndiswrapper 1.15 (latest)
• wireless-tools v28 (latest)
• Added 'CONFIG_CTRL_IFACE=y' to wpa_supplicant config file and rebuilt wpa_supplicant

The problem still occurs. It should be noted that, with the 'wext' driver/interface, no changes appear to the output of `ifconfig' and `iwconfig'--which say that my IP address/route are still valid and association with AP has not failed, respectively. With the 'ndiswrapper' driver/interface to wpa_supplicant, both register disassociation (the effect is the same, the results of `iwconfig' and `ifconfig' are different).

It should also be noted that this usually happens after about 10/20 minutes of inactivity, but this is not always consistent.

I'm going to seize on this statement largely because I'm at a bit of a loss as to why this is happening. Have you installed any power saving systems into Slackware? Or have you looked into your BIOS to see if there is any power saving shutdown features? That certainly would explain what is happening. I've got a card with the same chipset and I have used the same Windows drivers with ndiswrapper, and I've never had this happen.

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:

These repeat dozens and dozens of times, accompanied by helpful messages like "last message repeated 11 times" throughout the log. I have no idea what exactly these mean (I believe they might have something to do with unimplemented features or vendor-specific additions), nor if they have a bearing on this problem.

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.