I've encountered a problem with my wlan0 recently. When I'm trying to connect to my home network it often disconnects after a short while. However, there are spans of stable connection so I don't know what this problem depends on. Using the network (for example launching ping) does not maintain the connection.

In the kernel config you have CONFIG_PM_RUNTIME=n (allowing I/O devices to be put into energy-saving states) and CONFIG_CFG80211_DEFAULT_PS=y (enables powersave mode by default), and though I'm not altogether sure what the cause of your problem is it does exhibit the general symptoms of powersaving (the connection is established, and shortly thereafter drops). So, I would suggest either enabling or disabling both and see if the problem persists with either of these combinations. You can also disable powersaving on the card with 'iwconfig wlan0 power off' (assuming the PS/PM is enabled in the kernel).

welter wrote:

In /etc/conf.d/net I have only one line uncommented:

OK, well, you should probably proivde some option for wpa_supplicant to have it use nl80211 ...

I don't have much time today, so I'll try changing kernel options tomorrow.

Nevertheless, I did some observation today and found out that in my place (where link quality is ~40/70) even when the network connection is not getting disconnected it loses many packets (about 25% packet loss in ping). I don't think it is too far, because when tested on Windows it behaved well in the same place. When I came to a place about 2 meters from the router the connection was stable (a few packets lost out of 1000).

I will also try to check if this issue depends on specific protocol (WPA2).

Also, is nl80211 much better when compared to wext? What is the difference? (wicd said that in most cases I should use wext)

Nevertheless, I did some observation today and found out that in my place (where link quality is ~40/70) even when the network connection is not getting disconnected it loses many packets (about 25% packet loss in ping). I don't think it is too far, because when tested on Windows it behaved well in the same place. When I came to a place about 2 meters from the router the connection was stable (a few packets lost out of 1000).

welter ... don't read too much into this, of course packet loss is generally a sign of some problem (but this much we know) however its *radio* and so is effected by many environmental factors, infact being too close to the AP can effect signal quality. Also, packet loss can occur between any hop from the client and whatever is being pinged, and as you didn't say if you pinged the router, it could be packet loss between you and google for all we know. Anyhow, none of the above is relevant to debugging the issue.

welter wrote:

I will also try to check if this issue depends on specific protocol (WPA2).

... but what leads you to think it's WPA2 thats at issue?

welter wrote:

Also, is nl80211 much better when compared to wext? What is the difference? (wicd said that in most cases I should use wext)

mac80211 is the linux stack for 802.11 hardware, nl80211/cfg80211 is intended to replace wext (Wireless Extensions).

Also, is nl80211 much better when compared to wext? What is the difference? (wicd said that in most cases I should use wext)

I have the same card BCM4313 - it works for me with brcmsmac kernel module and -Dnl80211. It also worked with broadcom-sta driver and -Dwext wpa_supplicant option. So, in your case (CONFIG_BRCMSMAC=m) I suggest to use -Dnl80211.

I use wpa2 encryption, but my network is configured with 'pairwise=TKIP', so my configs are:

The strange thing is that the connection seems to work fine on all networks but not on the one I have in my flat. I haven't tried many networks but my university's eduroam and the network in my hometown worked well. That's why I wanted to try different protocol. But then, why the network is stable on other OS? Maybe it is the specific combination of router and wireless card configurations that causes this behaviour?

The strange thing is that the connection seems to work fine on all networks but not on the one I have in my flat. I haven't tried many networks but my university's eduroam and the network in my hometown worked well. That's why I wanted to try different protocol. But then, why the network is stable on other OS? Maybe it is the specific combination of router and wireless card configurations that causes this behaviour?

welter ... if the symptom only shows itself with one specific AP then the issue is not with powersave. As for the AP does it have a hidden ESSID, and what type of network is it N only, A,G,N mixed, or A,G?

I have a very similar problem with a BCM4401. At first, I thought either AP or laptop radio are on the blink, but it seems that the disconnects only happen on my x86 Gentoo system, not on am64 or FreeBSD (this laptop is quad-boot). I was wondering whether the kernel is the problem, I did not experience it before 3.3.x. Apart from the dis/reconncts, I've also seen the network go dead completely without anything being logged, or any change in ifconfig or routing status.

I've changed the mode of the router to mix B/G and after short while of testing the connection seems to be much more stable than before. Nonetheless it's a pity that the drivers don't allow to use the N mode in my case.

I've changed the mode of the router to mix B/G and after short while of testing the connection seems to be much more stable than before. Nonetheless it's a pity that the drivers don't allow to use the N mode in my case.

welter ... why do you think its the driver? Right now it could be anything as we have no idea of what your current setup is, you were advised to use NL80211, but who knows, maybe you are ... maybe your not, and as you don't seem concerned with providing that information, but continue speculating as to the cause, then really we can't help.

Also, is nl80211 much better when compared to wext? What is the difference? (wicd said that in most cases I should use wext)

I have the same card BCM4313 - it works for me with brcmsmac kernel module and -Dnl80211. It also worked with broadcom-sta driver and -Dwext wpa_supplicant option. So, in your case (CONFIG_BRCMSMAC=m) I suggest to use -Dnl80211.

I use wpa2 encryption, but my network is configured with 'pairwise=TKIP', so my configs are:

I've changed the mode of the router to mix B/G and after short while of testing the connection seems to be much more stable than before. Nonetheless it's a pity that the drivers don't allow to use the N mode in my case.

welter ... why do you think its the driver? Right now it could be anything as we have no idea of what your current setup is, you were advised to use NL80211, but who knows, maybe you are ... maybe your not, and as you don't seem concerned with providing that information, but continue speculating as to the cause, then really we can't help.

This was the same before I've changed the wireless mode and the problems still occurred. And after I've done that it works fine. Are there some specific config options that should be set for different wireless modes? If not, then I think I might have some grounds to suspect the driver.

welter ... thats ok, the only reason for me to make a fuss is that quite often its a case where the poster assumes we know what they have done, or are currently doing, and unless we are told we often don't, and so end up making assumptions.

welter wrote:

My current setup is:

This looks fine ... there are other options you could supply but as it'll default to whatever information is supplied by the AP (with the default 'ap_scan=1') then these don't necessarily need to be supplied.

welter wrote:

This was the same before I've changed the wireless mode and the problems still occurred. And after I've done that it works fine. Are there some specific config options that should be set for different wireless modes? If not, then I think I might have some grounds to suspect the driver.

Well, there is also the protocol itself, WMM/QoS, the AP, and the supplicant, If you read the links I provided above again you will see that there are a number of factors that can cause instability, not least of which is the basic premise that higher bitrates are more prone to error. In my experience N is the least stable 802.11 standard, and the claims made for it are beyond what can be achieved in practice (which is why the end up on the market as its more about selling the product than about the basic functionality). So, while the driver, and underlying mac80211, may be at issue, its equally as likely that other components, or some specific combination of factors, could be at issue.