@@ -4526,8 +4526,10 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
IEEE80211_TX_CTRL_MLO_LINK_UNSPEC,
NULL);
} else if (ieee80211_vif_is_mld(&sdata->vif) &&
- sdata->vif.type == NL80211_IFTYPE_AP &&
- !ieee80211_hw_check(&sdata->local->hw, MLO_MCAST_MULTI_LINK_TX)) {
+ ((sdata->vif.type == NL80211_IFTYPE_AP &&
+ !ieee80211_hw_check(&sdata->local->hw, MLO_MCAST_MULTI_LINK_TX)) ||
+ ((sdata->vif.type == NL80211_IFTYPE_AP_VLAN) &&
+ !sdata->wdev.use_4addr))) {
ieee80211_mlo_multicast_tx(dev, skb);
} else {
normal:
Currently for MLO, sending out multicast frames on each link is handled by mac80211 only when IEEE80211_HW_MLO_MCAST_MULTI_LINK_TX flag is not set. Dynamic VLAN multicast traffic utilizes software encryption. Due to this, mac80211 should handle transmitting multicast frames on all links for multicast VLAN traffic. Signed-off-by: Muna Sinada <muna.sinada@oss.qualcomm.com> --- v3: rebase to cleanly apply to wireless-next v2: - move clearing links for AP_VLAN into seperate function: ieee80211_apvlan_link_clear() - remove use of goto - replaced "master" terminalogy with "AP bss" - update Author signoff to new email --- net/mac80211/tx.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)