MT7615: broadcast broken with 802.11w

[rsalvaterra]

How to reproduce: take an OpenWrt master build (tested on a Redmi RM2100 and a Ubiquiti nanoHD), configure the Wi-Fi encryption as sae-mixed, connect a Linux laptop via Wi-Fi and, from another machine (not the router itself) try to ping it or access it through SSH (both fail). Pinging from the router itself works. ARP requests don't reach the client.
Additionally, it might be relevant, my specific configuration is a multi-VAP setup (four VAPs).

EDIT: Actually, WPA2 does not fix the issue. I left the laptops on overnight and couldn't access them this morning.

[dobo90]

Someone on OpenWrt forum seems to have the same issue as you @rsalvaterra https://forum.openwrt.org/t/device-stops-passing-broadcast-packets-to-wireless-interfaces-after-24h-of-uptime/79426.
I'm also suffering from the same issue. Restaring wireless interfaces using wifi command seems to bring back communication between stations (manually reconnecting on both clients doesn't fix it).
What may be relevant, I didn't notice the same issue on mt7603 but only on mt7615. I can check it also on mt7612 router, maybe it will be helpful to debug this issue.

[rsalvaterra]

I'm also suffering from the same issue. Restaring wireless interfaces using wifi command seems to bring back communication between stations (manually reconnecting on both clients doesn't fix it).

Are you sure the stations are associating to the MT7615 on wifi reload? Because right now I can't connect at all to machines hanging on MT7615 interfaces.

What may be relevant, I didn't notice the same issue on mt7603 but only on mt7615. I can check it also on mt7612 router, maybe it will be helpful to debug this issue.

Yes, the MT7603 is working fine, it's the chip I have on the 2.4 GHz band. I don't have any MT7612 cards to test, unfortunately.

[rsalvaterra]

This seems to have been fixed here.

[dobo90]

@rsalvaterra, I don't think it's fixed. I've tried latest master (abe34816 iptables: update to 1.8.7) which includes the commit you've mentioned.

I've noticed that that the issue starts to occur just after group key handshake completion. If you want to reproduce the issue faster try to:

1. Change wpa_group_rekey to 120 in your wireless interface configuration and restart network service.
2. From the first client machine ping another one (it should work).
3. Wait for specific log on OpenWrt machine: daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx WPA: group key handshake completed (RSN)
4. On the first client delete arp entry using (arp -d) and try to ping one more time the same client as before (it should fail as arp packet won't be transmitted to the client).

If you want to workaround the issue completely set wpa_group_rekey to 0. But it's not a valid solution.

[rsalvaterra]

Yeah, it's definitely not fixed, I hit this issue again with WPA3, this morning.

[dobo90]

I think that this is really mt7615 driver specific bug. When I've disabled gtk offloading, broadcast traffic seems to be working after rekeying.

diff --git a/mt7615/main.c b/mt7615/main.c
index d655604..44d2e3d 100644
--- a/mt7615/main.c
+++ b/mt7615/main.c
@@ -353,14 +353,8 @@ static int mt7615_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
        struct mt76_wcid *wcid = &msta->wcid;
        int idx = key->keyidx, err;
 
-       /* The hardware does not support per-STA RX GTK, fallback
-        * to software mode for these.
-        */
-       if ((vif->type == NL80211_IFTYPE_ADHOC ||
-            vif->type == NL80211_IFTYPE_MESH_POINT) &&
-           (key->cipher == WLAN_CIPHER_SUITE_TKIP ||
-            key->cipher == WLAN_CIPHER_SUITE_CCMP) &&
-           !(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
+       /* Disable GTK offloading */
+       if (!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
                return -EOPNOTSUPP;
 
        /* fall back to sw encryption for unsupported ciphers */

@rsalvaterra can you test whether this patch also works for you? (Just put it into package/kernel/mt76/patches/100_test.patch and recompile.)

[rsalvaterra]

@rsalvaterra can you test whether this patch also works for you? (Just put it into package/kernel/mt76/patches/100_test.patch and recompile.)

Sorry for the delay, @dobo90, I just saw this now. I'll give it a spin, thanks a lot!

[rsalvaterra]

diff --git a/mt7615/main.c b/mt7615/main.c
index d655604..44d2e3d 100644
--- a/mt7615/main.c
+++ b/mt7615/main.c
@@ -353,14 +353,8 @@ static int mt7615_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
        struct mt76_wcid *wcid = &msta->wcid;
        int idx = key->keyidx, err;
 
-       /* The hardware does not support per-STA RX GTK, fallback
-        * to software mode for these.
-        */
-       if ((vif->type == NL80211_IFTYPE_ADHOC ||
-            vif->type == NL80211_IFTYPE_MESH_POINT) &&
-           (key->cipher == WLAN_CIPHER_SUITE_TKIP ||
-            key->cipher == WLAN_CIPHER_SUITE_CCMP) &&
-           !(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
+       /* Disable GTK offloading */
+       if (!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
                return -EOPNOTSUPP;
 
        /* fall back to sw encryption for unsupported ciphers */

Hm. The patch doesn't apply here, for some reason, but it's trivial enough to recreate on my side.

[rsalvaterra]

Ok, I've narrowed it down to 802.11w. WPA2 without 802.11w works, WPA2 with 802.11w and WPA3 fail.

[blocktrron]

I can confirm the same issue for MT7915 (UniFi 6 Lite)

[LorenzoBianconi]

I can confirm the same issue for MT7915 (UniFi 6 Lite) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#494 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOA2CLT46AOMIZZVZG5IDLS5XSC7ANCNFSM4WKM3HKQ> .

Is the issue similar to the one reported for 7610? #410

…

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[blocktrron]

@LorenzoBianconi No, this is a completely different issue for mt7610.

MT7610 multiicast is broken on connection without a rekey, independent whether or not 11w is enabled and only occurs when adding more than one VAP.

[rsalvaterra]

I just noticed now I haven't made clear, but @dobo90's hack works around the problem.

[equid0x]

I just wanted to comment that I seem to be having the same issue. However, I'm on a Marvell 88W8864. The problem seems to occur anytime 802.11w is not full disabled whether on WPA3 or WPA2. WPA3 seems to require this feature, which is how I noticed it. Unicast traffic seems to work fine with 802.11w enabled but multicast & broadcast don't seem to function correctly. The telltale sign was that both Roku wifi remote & Youtube cast would no longer connect to any smartphones. Going back to WPA2 and disabling 802.11w resolves the issue but is clearly not ideal.

[rsalvaterra]

I just wanted to comment that I seem to be having the same issue. However, I'm on a Marvell 88W8864.

That's a completely unrelated, off-topic and unsolvable problem.

[equid0x]

I just wanted to comment that I seem to be having the same issue. However, I'm on a Marvell 88W8864.

That's a completely unrelated, off-topic and unsolvable problem.

Great. Thank you for the snarky reply.

[nbd168]

Rekeying issues should be fixed in the current version for 7915 and 7615, please test.

[dobo90]

On mt7615 works fine for me. śr., 7 kwi 2021, 11:18 użytkownik nbd168 ***@***.***> napisał:

…

Rekeying issues should be fixed in the current version for 7915 and 7615, please test. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#494 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJVZKTWFMM5IGAB4NJYJVLTHQPO5ANCNFSM4WKM3HKQ> .

[rsalvaterra]

Rekeying issues should be fixed in the current version for 7915 and 7615, please test.

Will do, thanks, @nbd168!

[rsalvaterra]

I can confirm @dobo90's result, it's also working fine on my MT7615. Thanks!

[nbd168]

Thanks for testing