ath9k WDS panic without CONFIG_ATH9K_RATE_CONTROL
Hello!
I'm trying to implement WDS support in ath5k, but I have found that the kernel would panic when I bring the interface up:
modprobe ath5k
iwconfig wlan0 mode repeater
iw dev wlan0 set peer 00:01:02:03:04:05
ifconfig wlan0 up
There are many stack traces, but the first one comes from WARN_ON in rate_lowest_index(). I think it should really be BUG_ON (patch submitted separately), as returning an invalid index will surely lead to memory corruption.
I tried WDS with ath9k and found that it doesn't crash the kernel if CONFIG_ATH9K_RATE_CONTROL is set. However, if that setting is off in .config, I would get the same crash.
It appears that rate_control_rate_init() is called in ieee80211_do_open() too early. I think there should be some set on the rates assumed to be available on the WDS link for the given channel.
Alternatively, the WDS interface should not be able to emit packets until either the rates are set manually with iw or they come from a beacon send by the peer. The rate control algorithms should be able to deal with it.
Signature · 2 lines
Regards, Pavel Roskin
Quoted 19 lines · Pavel Roskin
Hello!
I'm trying to implement WDS support in ath5k, but I have found that the kernel would panic when I bring the interface up:
modprobe ath5k
iwconfig wlan0 mode repeater
iw dev wlan0 set peer 00:01:02:03:04:05
ifconfig wlan0 upThere are many stack traces, but the first one comes from
WARN_ONinrate_lowest_index(). I think it should really beBUG_ON(patch submitted separately), as returning an invalid index will surely lead to memory corruption.I tried WDS with ath9k and found that it doesn't crash the kernel if
CONFIG_ATH9K_RATE_CONTROLis set. However, if that setting is off in .config, I would get the same crash.
Quoted 8 lines
It appears that
rate_control_rate_init()is called inieee80211_do_open()too early. I think there should be some set on the rates assumed to be available on the WDS link for the given channel.Alternatively, the WDS interface should not be able to emit packets until either the rates are set manually with iw or they come from a beacon send by the peer. The rate control algorithms should be able to deal with it.
Some time ago I sent some patches to fix the issues with WDS (and add support for HT, including aggregation).
These patches assume that you set up an AP on both sides alongside the WDS interface (beacons of the APs are used to exchange rates and capabilities).
http://thread.gmane.org/gmane.linux.kernel.wireless.general/70872
- Felix
Quoted 6 lines · Felix Fietkau
Some time ago I sent some patches to fix the issues with WDS (and add support for HT, including aggregation).
These patches assume that you set up an AP on both sides alongside the WDS interface (beacons of the APs are used to exchange rates and capabilities).
I think WDS should work without beacons. At least the basic rates should be available when the interface is brought up. Further changes to the set of supported rates can be made with iw.
WDS is somewhat orthogonal to the beacons. The beacons are primarily meant for the stations.
Signature · 2 lines
Regards, Pavel Roskin
Quoted 9 lines · Pavel Roskin
Quoted 6 lines · Felix Fietkau
Some time ago I sent some patches to fix the issues with WDS (and add support for HT, including aggregation).
These patches assume that you set up an AP on both sides alongside the WDS interface (beacons of the APs are used to exchange rates and capabilities).
Quoted 6 lines
I think WDS should work without beacons. At least the basic rates should be available when the interface is brought up. Further changes to the set of supported rates can be made with iw.
WDS is somewhat orthogonal to the beacons. The beacons are primarily meant for the stations.
For 802.11n you need proper HT capabilites anyway. I think it usually doesn't make much sense to use WDS without AP interfaces, but if you consider it worth adding support for, then please build your patches on top of my patch series.
- Felix
Felix,
Quoted 4 lines · Felix Fietkau
For 802.11n you need proper HT capabilites anyway. I think it usually doesn't make much sense to use WDS without AP interfaces, but if you consider it worth adding support for, then please build your patches on top of my patch series.
I've got your patches and I'm seeing a problem with (an admittedly) odd case.
I've got 2 APs, both using ath9k cards/drivers. One of them is configured to use WEP, the other has no security. I'm establishing a WDS connection between them.
Since WEP is incompatible with HT, that AP's beacons only include a/b/g rates. The open AP happily sends lower rate packets to the WEP AP.
However, since beacon from the open AP contains HT rates. In ieee80211_wds_rx_queued_mgmt, the WEP ap calls ieee80211_ht_cap_ie_to_sta_ht_cap, and adds HT rates to the station. "iw wlan0wds0 station dump" reports that the tx bitrate is an HT rate (58.5 MBit/s MCS 6). However, the actual behavior of the radio is horrible. Packets take a long time (frequently well over a second) to be transmitted by the radio.
I believe this is an issue with transmitting HT rates while WEP is configured. If I comment out the call to ieee80211_ht_cap_ie_to_sta_ht_cap in ieee80211_wds_rx_queued_mgmt on the WEP AP, I get decent transmit performance (at 54.0 Mbit/s). If I turn off WEP on the AP, I get good transmit performance at HT rates.
I believe the call to ieee80211_ht_cap_ie_to_sta_ht_cap in ieee80211_wds_rx_queued_mgmt needs to be conditioned on the radio not being in WEP. But I haven't figured out a convenient way to determine this.
-- Bill Jordan --