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,
SvenAttachment:
signature.asc
Description: This is a digitally signed message part.
