[REGRESSION] mac80211: IBSS vif queue stopped when started after 11s vif

[Sven Eckelmann <sven.eckelmann@openmesh.com>]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

Hi,

I had following "simple" setup with LEDE with a single ath9k phy and multiple 
vif:

 * encrypted AP
 * encrypted 802.11s meshpoint
 * encrypted IBSS

Everything was started in the order by hostapd/wpa_supplicant (but immediately 
after each other).

The problem which I've experienced was that IBSS was not able to communicate 
with its link partner. The reason for that problem was that the IBSS 
interface's queue was stopped (QUEUE_STATE_DRV_XOFF). This problem disappeared 
when either the IBSS or meshpoint interface was changed to unencrypted (which 
disables wpa_supplicant in LEDE).

It looks like ieee80211_do_open didn't start the queues via 
netif_start_subqueue because local->queue_stop_reasons was for all queues set 
to IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL. This happened because 
ieee80211_offchannel_stop_vifs was called from somewhere in the scan code at 
that time and ieee80211_offchannel_return was not yet called.


This behavior seems to be introduced by 2b730daacee6 ("mac80211: don't start 
new netdev queues if driver stopped"). I have therefore chosen to call it for 
now a regression by this change. Especially because it is rather odd that the 
commit talked about not starting the queues for AP_VLAN and 2b436312f091 
("mac80211: fix queue handling crash") introduced extra code to use the old 
behavior again for AP_VLAN.

But I could be completely wrong about it. It would therefore be interesting 
for me to know who would be responsible to start the queues when 
ieee80211_do_open rejected it for IBSS.

I am now simply using this setup with a revert of 
2b436312f0919c05804fed5aa4b7f255db196e7a and 
2b730daacee6c318bce7b6373c19909e36a74590.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]