# Ralink Wireless disconnecting after a few moments.

## multix

Hi,

after updating in the last weeks, I noticed that my wireless conneciton became totally unreliable, it can drop within minutes (=the light of the PCMCIA card go off, you need to re-run dhcp on it). The netowkr is always the same and it worked perfectly(and continues to work under windows, thus the hardware is not damaged).

I am running:

 *Quote:*   

> Linux think 3.5.4-gentoo #1 Sun Sep 23 23:22:20 CEST 2012 i686 Mobile Intel(R) Pentium(R) III CPU - M 1000MHz GenuineIntel GNU/Linux
> 
> 

 

However I has an older 3.3 kernel and it does not work well anymore, so I am not sure it is a kernel issue.

I found that running "ping" in a conosle might imprive things a bit.

dmesg recognizes the card as:

```
[  351.173183] Registered led device: rt61pci-phy0::radio

[  351.173627] Registered led device: rt61pci-phy0::assoc

[  351.187783] systemd-udevd[1967]: renamed network interface wlan0 to wlan1

```

lspci as:

```

07:00.0 Network controller: Ralink corp. RT2561/RT61 rev B 802.11g

```

Any ideas? help?

Thank you

----------

## multix

No ideas? I rechecked, leaving a ping running makes it almost usable... but it can't be the proper solution  :Smile: 

----------

## khayyam

multix ...

The issue seems to have the symptoms of the card going into powersave. I'm not entirely sure what to suggest as similar reports (with cards as varied as ath9k and iwlwifi) have been made in other threads and as yet there hasn't been a 'yes, that fixed it'. However, I would suggest looking to see what is enabled in terms of power saving features that might effect PCI, specifically CFG80211_DEFAULT_PS and PM_RUNTIME.

best ... khay

----------

## multix

Hi,

powersaving seems a reasonable explanation, it would explain why "pinging" helps delaying the issue. I haven't enabled anything regarding powersave, a least not knowingly. Where should I look? 

rc-status shows "acpid" running, nothing else might seem relevant. Could acpid cause this?

I keep the PSU pluggged in, the laptop is not running on battery power.

Riccardo

----------

## khayyam

 *multix wrote:*   

> Where should I look?

 

multix ... as I said above check if the above options are enabled/disabled in the kernel. You might also check if powesave is enabled for the card:

```
# iw dev wlan0 get power_save
```

'set' off/on to enable/disable

```
# iw dev wlan0 set power_save off
```

(note I'm using net-wireless/iw but iwconfig from wireless-tools will provide similar capabilites).

 *multix wrote:*   

> rc-status shows "acpid" running, nothing else might seem relevant. Could acpid cause this?

 

No, acpid will interface with ACPI, but its just an event daemon, it matches those events provided in /etc/acpi/events.  

 *multix wrote:*   

> I keep the PSU pluggged in, the laptop is not running on battery power.

 

yes, but powersave is a feature of  the 80211 stack so its status is not triggerd by the the presence of A/C power or battery (though I believe laptop-mode-tools may enable/disable based on events).

So, try to enabling/disabling powersave and see if the problem persists. Also, keep in mind the features of the AP, such as whether the network is 'N only' or 'mixed A,G,N' as this might also be a cause of disassoc.

best ... khay

----------

## multix

 *khayyam wrote:*   

> multix ...
> 
> The issue seems to have the symptoms of the card going into powersave. I'm not entirely sure what to suggest as similar reports (with cards as varied as ath9k and iwlwifi) have been made in other threads and as yet there hasn't been a 'yes, that fixed it'. However, I would suggest looking to see what is enabled in terms of power saving features that might effect PCI, specifically CFG80211_DEFAULT_PS and PM_RUNTIME.
> 
> best ... khay

 

The first option is set, the second not. I will now disable the former. It is interesting that the description specifically says that if something misbehaves you should fix your app  :Smile: 

----------

## multix

I disabled both options, but the card still disconnects, sometimes really after a few seconds that the link was established! Quite annoying.

----------

## khayyam

 *multix wrote:*   

> I disabled both options, but the card still disconnects, sometimes really after a few seconds that the link was established!

 

multix ... you really need to provide more information, I asked previously about the network ('A,G,N' ... 'G,N' ... 'N only') and stated that besides powersave the AP (type of network, and features enabled) may also be the cause. So, what kind of AP, and how is is currently configured (ie, 802.11N with 'N only', hidden ESSID, WMM/QoS enabled, etc). You should also look at the 'bitrate' that the STA (client) is reporting ('iwconfig wlan0'). Higher bitrates mean data is more densely packed and so more prone to error (which can cause the client to see beacon misses ... and so disassoc). Anyhow, without additional information its mostly guesswork on my part. However, you might try lowering the bitrate and seeing if the connection stablises.

/etc/conf.d/net

```
rate_wlan0="5.5M auto"
```

The supported bitrates can be aquired via the 'iwlist' (where "ESSID" would be the broadcast name of the AP) ..

```
# awk '{RS="Cell"}/ESSID/' <(iwlist wlan0 scan)
```

... or 'iw dev wlan0 scan' if you have net-wireless/iw installed. '5.5M' is a fairly low value, but if the connection stablises you would then be able to raise it incrementally. So, rather than set it via /etc/conf.d/net you can test by setting it via 'iwconfig' and then add 'rate_wlan0=' once an optimal value has been found:

```
# iwconfig wlan0 rate 5.5M auto
```

Again, I'm speculating on the possible issues, but as I've seen various N cards with high bitrates (> 140Mb/s) automatically set (and poor connectivity) I suspect this *may* be the cause of your disassoc, but without further information its only speculation.

best ... khay

----------

## multix

Hi,

I don't know exactly how the AP is configured currently, I know it has QoS off, ESSID is not hidden and it has WEP encryption.

the card is a "g" card and when it is connected, it says:

 *Quote:*   

> 
> 
> wlan1     IEEE 802.11bg  ESSID:"westernesse"
> 
>           Mode:Managed  Frequency:2.412 GHz  Access Point: F8:D1:11:B9:07:2A
> ...

 

Here I am relatively far away from the AP, thus the bit rate is low (however, it used to work in the same place and another laptop with a different card, works).

I then went very near to the AP and after connection I still see "1 Mb/s" although the link quality and signal levels rise. If I start transmitting, the rate goes up to 24 Mb/s. I then started flood-pinging a host and the rate goes up to 54 Mb/s when flood-pinging the link stayed up! I went to my usual place again and the rate went doen to only 48 MB/s but remained up several minutes.

Could it be that the drivers tries to dynamically adjust the bit rate, thus doing some power management even if "Power Management" is off? And that this fails?

I will now try fixing the rate as you suggest.

----------

## khayyam

 *multix wrote:*   

> I don't know exactly how the AP is configured currently, I know it has QoS off, ESSID is not hidden and it has WEP encryption.

 

multix ... ok, and I assume by this you don't have access to the AP's management interface?

 *multix wrote:*   

> the card is a "g" card

 

... and the AP, is it also B,G?

 *multix wrote:*   

> 
> 
> ```
> wlan1     IEEE 802.11bg  ESSID:"westernesse"
> 
> ...

 

The link is just at that point at which you would expect some level of instability, and the card is auto-configuring the bitrate to a lower value in order to compensate. Still, there are no missed beacons, so if the airwaves are fairly unpolluted the link should still remain up.

 *multix wrote:*   

> Here I am relatively far away from the AP, thus the bit rate is low (however, it used to work in the same place and another laptop with a different card, works).

 

Yes, but its radio, not all transmitters are equal and there are many additional factors (location, weather, adjacent networks, other clients, etc, etc) that will make such comparisons problematic. 

 *multix wrote:*   

> I then went very near to the AP and after connection I still see "1 Mb/s" although the link quality and signal levels rise. If I start transmitting, the rate goes up to 24 Mb/s. I then started flood-pinging a host and the rate goes up to 54 Mb/s when flood-pinging the link stayed up! I went to my usual place again and the rate went doen to only 48 MB/s but remained up several minutes.

 

This is what you would expect to see, at closer proximity to the AP the link will improve (all other factors excluded), and when there are network transmissions (ie: ping) then the card is forced to negociate the connection (ie, auto-adjust the bitrate) so that the link is maintained.

 *multix wrote:*   

> Could it be that the drivers tries to dynamically adjust the bit rate, thus doing some power management even if "Power Management" is off? And that this fails?

 

No, the auto-negociation of bitrate is a feature of 802.11, it doesn't have anything to do with powersave. I think your issue may just be the distance/interference between you and the AP. However, there are still some unknowns, like how wpa_supplicant is configured, wext or nl80211? Infact, please post your wpa_supplicant.conf (without psk) and the relevent sections of /etc/conf.d/net.

 *multix wrote:*   

> I will now try fixing the rate as you suggest.

 

I don't think you understood, the reason I suggested the above was based on the assumption that the bitrate was too high. So, at 1Mb/s there is nothing to be done here, it can't be set lower, and it will auto-negociate if high bitrates can be established.

best ... khay

----------

## multix

khay,

I can tell you the exact model of the AP, but I don't have access to its console at the moment.

I don't use wpa_supplicant installed because the AP has WEP encryption. What other unknowns could be there?

Perhaps I was confused in my earlier post, but I went also very near to the access point, where the network quality must be high. Without transmission, the bitrate was 1Mb/s, when i started a flood-ping, it went up as to 54Mb/s.

Still, even very close to the AP, without transmission, the card would disconnect. Instead, with a high flow of transmission, going farther away, it remained up, at about 48Mb/s (expected, since the link quality drops).

Stopping flood ping means drop of the connection within seconds. So it is not related to distance.

Riccardo

----------

## khayyam

 *multix wrote:*   

> I can tell you the exact model of the AP, but I don't have access to its console at the moment.

 

multix ... its a TP Link Technologies, but anyhow its not important, its just that knowing exactly what is enabled might help in debugging. 

 *multix wrote:*   

> I don't use wpa_supplicant installed because the AP has WEP encryption.

 

hehe, why is it always some three weeks down the line that information like this comes to light :) ... I don't mean to sound critical but information like this should be provided from the outset. I have been meaning for some time to write a 'how to report wireless issues' with some guidelines on what to report, and how to go about getting that information, and I *really* should do so. Anyhow, wpa_supplicant is not (as the name suggests) only for WPA, it also handles WEP, and OPN networks. The advantage of using wpa_supplicant is that it will bring the link back up should it drop, and it also generates some info as to the connection status, reasons for disconnection, and more detailed debug info (if the 'debug' useflag is enabled and '-dd -f /var/log/wpa_supplicant.log' are provided as options), also wpa_cli (with its own shell) can be enormously usefull for configuration, scanning, debugging, etc. So, I suggest you install it and setup the following:

/etc/wpa_supplicant/wpa_supplicant.conf

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel

update_config=1

network={

    ssid="westernesse"

    bssid=F8:D1:11:B9:07:2A 

    scan_ssid=0

    key_mgmt=NONE

    wep_key0=                  <= add your key here

    wep_tx_keyidx=0

}
```

/etc/conf.d/net

```
modules_wlan0="!plug wpa_supplicant dhcpcd"

wpa_supplicant_wlan0="-Dnl80211"

wpa_timeout_wlan0="15"

config_wlan0="dhcp"
```

If you don't have cfg80211 enabled in your kernel you can subsitute '-Dnl80211' with '-Dwext'. See which are currently enabled:

```
# awk '/(80211|WEXT)/' /usr/src/linux/.config
```

 *multix wrote:*   

> What other unknowns could be there?

 

well, not using a client like wpa_supplicant for one :)

 *multix wrote:*   

> Perhaps I was confused in my earlier post, but I went also very near to the access point, where the network quality must be high. Without transmission, the bitrate was 1Mb/s, when i started a flood-ping, it went up as to 54Mb/s. Still, even very close to the AP, without transmission, the card would disconnect. Instead, with a high flow of transmission, going farther away, it remained up, at about 48Mb/s (expected, since the link quality drops). Stopping flood ping means drop of the connection within seconds. So it is not related to distance.

 

Bitrate auto-negociation will only take place when there is something to cause it, that is, if there is some traffic over the link at which 802.11 can measure the stability of the connection. So, the above makes sense. Also, when you are close to the link the STA and AP still have to negociate the signal and so the same factors are in play as when they are at some distance. Consider also that it the same airspace may be {N} number of other signals, and god knows what other enviromental factors involved. So, yes, the link drops when there is no traffic, but this may simply be the outcome of a number of factors, and this may be alieviated somewhat by having wpa_supplicant manage the connection.

best ... khay

----------

