First off let me say, I'm new to gentoo but im loving it . But i seem to be having problems getting the wireless working on my old compaq presario 900 laptop. I'm using a PCMCIA Cardbus linksys wpc100 card because the laptop doesn't have built-in wireless. I've compiled ath9k into the kernel and installed wpa_supplicant and wireless-tools.

It connects but the problem I'm having is that after a short period of time (3-5 min) it will disconnect from my AP. I then have to iwconfig wlan0 essid "TheMatrix" (i need to change that ) to get it started again. It is continually doing this. I am using WPA2. Here is some info about it:

I don't see any disconnection, or any of the usual signs that the signal between the client and AP is lost, so at a guess it may be an issue is with the card going into powersave. Please try disabling power saving and see if the problem persists.

Code:

iwconfig wlan0 power off

If the issue continues, enable the 'debug' useflag on wpa_supplicant and add '-dd -f /var/log/wpa_supplicant.log' to wpa_supplicant_wlan0= in /etc/conf.d/net and pastebin the log, and also provide the output of 'iwconfig wlan0'.

ok I feel like an idiot. I forgot that I turned off my WPA2 awhile back so im not using any encryption at the moment . I followed your post and and disabled power management but it only made it worse.

I have done some more testing. If i have power management on, i can keep the connection going using ping and just letting it run (it does drop some packets tho). I guess its acting as a "keep alive". If i have power management off and use ping again, it fails in a matter of seconds. Even if i don't use ping it still fails in the same amount of time. So far it has done this consistently. I've tried using some of the other power management options in iwconfig but they all give me weird errors. Only "off" and "on" work.

The effect of ping is what you'd expect, the driver is kept from going into powersave. Explicitly disabling powersave may infact cause the driver to balk as the cards power management features are software driven. I'm somewhat speculating but I'm inclined to think PM is at issue.

Yes, if you read the doc/help you will see that it enables power management features for I/O devices. It's under "Power management and ACPI options" as "Run-time PM core functionality". Note that when in menuconfig a "/" and search term (such as "PM_RUNTIME") will show you where in the kernel this item is located.

It WORKS! Thank you so much! I have power management turned on on the card and in the kernel now and it is working on my wpa2 network at work. I want to make sure it will work at home but its looking good so far.

I will try not to uselessly use cat anymore (I see now how it was redundant)

firstly, encryption is disabled on the AP, this is inadvisable, with such a setup it is trivial to sniff the psk and any other network traffic passing between the client and the AP. I'd suggest you enable WPA and configure the client to use it.

mechtech ... the reason I asked is that your PCI card is 802.11n and I have in the past seen issues with mixed g/n networks (but this is not the most likely issue).

mechtech wrote:

Should i use something similar to the code you linked in my wpa_supplicant.conf? wpa_supplicant doesn't start automatically.

Yes, I provided the above as an example WPA2 network configuration. Rather than start wpa_supplicant from init you should simply define wpa_supplicant as the 'module' handling the interface (in /etc/conf.d/net) eg:

You would then link /etc/init.d/net.lo to /etc/init.d/net.wlan0 and use that to start the service (which will then start wpa_supplicant, dhcpcd, etc).

As CFG80211_DEFAULT_PS is currently enabled please try disabling it, the symptoms currently suggest powersave as the most likely issue.

Also, previously I showed how to enable debugging with wpa_supplicant, if the issue persists after disabling CFG80211_DEFAULT_PS then please enable the debug useflags, re-merge, connect, and post the log.

I've recompiled with that option off and it does the same thing. I recompiled again with CONFIG_PM_RUNTIME=n as well just to see but no change. It is almost always reconnecting every 60 seconds UNLESS I turn on power management on the card with

Code:

iwconfig wlan0 power on

If i use that it will reconnect less often and never (so far) while in use. I haven't yet tested it with a streaming application.

When you say "UNLESS I turn on power management" you mean with PS enabled the issue is decreased, and if so how often do the disconnects occur with PS enabled?

Code:

CTRL-EVENT-DISCONNECTED bssid=0c:d5:02:6f:c7:b6 reason=4

This "reason=4" means disassociated due to inactivity, but there is no clue given as to why, but my guess is a beacon miss. It would be good to know if the STA (client) or AP is the cause, but getting this requires that CONFIG_ATH_DEBUG is enabled (well, with ath5k it would be CONFIG_ATH5K_DEBUG, and as I don't see similar for ath9k I assume the above will suffice). With debug enabled you should be able to do the following:

Code:

# echo 0xc80000 > /proc/sys/net/wlan0/debug

... and read the debug in dmesg or /var/log/messages. If its a beacon miss you would see it there, and which end of the connection is the cause.

However, before trying the above we might try increasing beacon misses ... this is not a fix, as I really can't say what the exact cause is, but it should make the connection less inclined to drop due to beacon misses. Doing this however is not really a good idea as the reason for such a setting is to detect when a signal is unavailable (and so close the connection), still, if this fixes it we know that beacon misses are the reason the disassoc happens.

I see from the above dmesg that your using 3.3.8-gentoo, so before doing any of the above it might be an idea to build 3.5.4 as the problem may be fixed in a more recent kernel.

So, to change beacon misses edit /usr/src/linux-{version}/drivers/net/wireless/ath/ath9k and change the value of #define ATH_DEFAULT_BMISS_LIMIT ... its probably set to 10, change it to 20.

Again, it may be that this issue is fixed so before trying to work out the exact cause it is probably a good idea to try a more recent kernel, as what I'm suggesting above is really more of an attempt at getting at the cause than a possible fix.

When you say "UNLESS I turn on power management" you mean with PS enabled the issue is decreased, and if so how often do the disconnects occur with PS enabled?

If i keep power management on with iwconfig, the time between disconnects goes from every 30-120sec to around 10-15min. And from what i can see it wont disconnect if its in use (e.g. emerge, ping). That almost makes it a non issue from what i can see. When i was running 3.3.8 with power managment on it was around 3-5 min between drops so something changed in the new kernel or in how i configured it.

I tried to use

Code:

echo 0xc80000 > /proc/sys/net/wlan0/debug

but I dont have a wlan0 in /proc/sys/net folder. I therefor haven't tried messing with the becon miss limit.

Im going to let it run overnight and I'll post the logs for it tomorrow

mechtech ... I mean't for example in the above, does the /proc/sys/net/ exist when CONFIG_ATH_DEBUG is enabled ... or not, I can't tell from your reply.

mechtech wrote:

I tried pci=noacpi but it gave me a kernel panic.

OK, I'd hoped it'd at least boot, though running without ACPI is not really any kind of fix. Anyhow, with regard to CFG80211_DEFAULT_PS and CONFIG_PM_RUNTIME I can't tell from the above what was tried, only that one or other doesn't work. I'd suggest having both enabled, and then enabling/disabling powersave, via i'wconfig wlan0 power (on|off)', test, and then disable one or other, test, disable both, test .. etc.

Also, I just noticed in the above your passing '-Dwext' to wpa_supplicant, your should try with '-Dnl80211'.

mechtech wrote:

I'm noticing that it is very inconsistent between re-associations. Sometimes 3 min, other times 20 min.

Ok ive been working on this over the past couple weeks and still have nothing. I've tried different variations of the power management options in the kernel like you suggested, but it still does the same thing. Dmesg is reporting a new error though: