Drivers with fast-xmit (e.g. ath10k) running in
AP_VLAN setups would fail to communicate with
connected 4addr stations.
The reason was when new station associates it
first goes into master AP interface. It is not
until later that a dedicated AP_VLAN is created
for it and the station itself is moved there.
After that Tx directed at the station should use
4addr header. However fast-xmit wasn't
recalculated and 3addr header remained to be used.
This in turn caused the connected 4addr stations
to drop packets coming from the AP until some
other event would cause fast-xmit to recalculate
for that station (which could never come).
Signed-off-by: Michal Kazior <[email protected]>
---
net/mac80211/cfg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 3469bbdc891c..bb9f83640b46 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1411,6 +1411,7 @@ static int ieee80211_change_station(struct wiphy *wiphy,
}
sta->sdata = vlansdata;
+ ieee80211_check_fast_xmit(sta);
if (sta->sta_state == IEEE80211_STA_AUTHORIZED &&
prev_4addr != new_4addr) {
--
2.1.4
On Tue, 2015-05-19 at 14:13 +0200, Michal Kazior wrote:
> Drivers with fast-xmit (e.g. ath10k) running in
> AP_VLAN setups would fail to communicate with
> connected 4addr stations.
>
> The reason was when new station associates it
> first goes into master AP interface. It is not
> until later that a dedicated AP_VLAN is created
> for it and the station itself is moved there.
> After that Tx directed at the station should use
> 4addr header. However fast-xmit wasn't
> recalculated and 3addr header remained to be used.
> This in turn caused the connected 4addr stations
> to drop packets coming from the AP until some
> other event would cause fast-xmit to recalculate
> for that station (which could never come).
Applied.
johannes