Skip to contentSkip to conversation

ath9k WDS panic without CONFIG_ATH9K_RATE_CONTROL

DISCUSSION Pavel Roskin 3 participants 5 messages Jun 15, 2011 – Jun 17, 2011

lore
Share & tools
lore
#0 lore raw

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
#1 lore raw
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 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.

Quoted 8 lines

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.

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

#2 lore raw
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
#3 lore raw
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

#4 lore raw

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