Re: [RFC/WIP 00/33] ath9k_htc AP mode

[Christian Lamparter <chunkeey@googlemail.com>]

On Friday 21 January 2011 03:55:51 Sujith wrote:
> This series is the preliminary work for enabling AP mode for ath9k_htc.
> 
> A firmware update is needed, place look at:
> http://wireless.kernel.org/en/users/Drivers/ath9k_htc#AP_Mode
> 
> Known issues:
> 
> * Beacon misses under heavy TX load
>   ( hopefully, a fix would be sent out soon).
> 
> This has not been tested rigorously, so consider this series as
> experimental code.
> 
Hey that's great! I gave this series a quick whirl and it worked on the first try!
I had no probles getting ath9k to connect, well apart form a WARN_ON_ONCE

WARNING: at net/mac80211/tx.c:57 ieee80211_duration+0x50/0x1b3 [mac80211]()
Call Trace:
[  322.971940]  [<ffffffffa01d1cb0>] ? ieee80211_duration+0x50/0x1b3 [mac80211]
[  322.979297]  [<ffffffffa01d33d5>] ? invoke_tx_handlers+0xf65/0x1001 [mac80211]
[  322.987053]  [<ffffffffa01d0f2d>] ? ieee80211_prepare_and_rx_handle+0x7ff/0x845 [mac80211]
[  322.995865]  [<ffffffffa0004f5d>] ? usb_hcd_giveback_urb+0x76/0xa5 [usbcore]

but that's ok, ieee80211_duration does not make sense when
the rate control is done by the firmware.

--------

But what seems to be strange is the tx feedback...
Because it looks like ath9k_htc just sets IEEE80211_TX_STAT_ACK
for every frame, which obviously can't be "true", right? ;)

This might also break mac80211's *unicast buffering*.

Because the code in ieee80211_tx_status - net/mac80211/status.c
works like this:

211  acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
212  if (!acked && test_sta_flags(sta, WLAN_STA_PS_STA)) {
213		/*
214		 * The STA is in power save mode, so assume
215		 * that this TX packet failed because of that.
216		 */
217		ieee80211_handle_filtered_frame(local, sta, skb);
218		rcu_read_unlock();
219		return;
220	}
...
239	if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
240		ieee80211_handle_filtered_frame(local, sta, skb);
241		rcu_read_unlock();
242		return;
243	} else {
244		if (!acked)
245			sta->tx_retry_failed++;
246		sta->tx_retry_count += retry_count;
247	}

so, mac80211 will never know when it needs to resend certain
frame which could be affected by the race between the "sleepy"
station sending a frame with a PSM-bit set and mac80211 finally
updating the WLAN_STA_PS_STA flag.
[see long comment in mac80211/status.c @ line 73]

unless of course, you don't need it and the firmware can
buffer those frames until the STA comes back?!

Best regards,
	Christian