ath9k WDS panic without CONFIG_ATH9K_RATE_CONTROL

ath9k WDS panic without CONFIG_ATH9K_RATE_CONTROL

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

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.

-- 
Regards,
Pavel Roskin

Re: ath9k WDS panic without CONFIG_ATH9K_RATE_CONTROL

[Felix Fietkau]

On 2011-06-16 12:24 AM, Pavel Roskin wrote:
> 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.
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

Re: ath9k WDS panic without CONFIG_ATH9K_RATE_CONTROL

[Pavel Roskin]

On 06/15/2011 10:11 PM, Felix Fietkau wrote:

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

-- 
Regards,
Pavel Roskin

Re: ath9k WDS panic without CONFIG_ATH9K_RATE_CONTROL

[Felix Fietkau]

On 2011-06-16 11:54 PM, Pavel Roskin wrote:
> On 06/15/2011 10:11 PM, Felix Fietkau wrote:
>
>>  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.
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

Re: ath9k WDS panic without CONFIG_ATH9K_RATE_CONTROL

[Bill Jordan]

Felix,

On Thu, Jun 16, 2011 at 7:11 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> 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 --