MT7610E: multicast broken when using WPA2/WPA3

[blocktrron]

I've discovered today that when using mt76 (version from OpenWrt master as well as 19.07) with a MT7610E will result in no multicast TX when using encryption (WPA2-PASK / WPA3-SAE). It's very noticeable as IPv6 RAs won't be received by the clients.

When using an open AP, multicast TX works flawlessly. I've tested this on a Archer C20i as well as a Archer C2 and both show the same symptoms. It also does not matter whether or not 802.11w was enabled or disabled.

I've patched mt76 to disable hwcrypto for the MT7610E and multicast appears to be working w/o issues

The same settings work flawlessly on MT7612E (Archer C50 v3).

Client tested: Nokia 6.1 (Android 10) ; Intel AX200 ; Qualcomm QCA6174A

[blocktrron]

@LorenzoBianconi @nbd168

Okay, got multicast working now on MT7610E. Can you provide me with feedback for this patch before i submit it to linux-wireless?

From ae01717951013fbc8bb0315d902d5b9f5873631a Mon Sep 17 00:00:00 2001
From: David Bauer <mail@david-bauer.net>
Date: Fri, 12 Jun 2020 01:09:57 +0200
Subject: [PATCH] mt76: mt76x0: disable GTK offloading

When the GTK is offloaded, MT7610 won't transmit any multicast frames.
This is most likely due to a bug in the offloading datapath. MT7612 is
not affected.

Disable GTK offloading for now. It can be re-enabled once the bug in the
offloading path is fixed.

Signed-off-by: David Bauer <mail@david-bauer.net>
---
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 44822a849eb1..d5e20b18c5ea 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -439,6 +439,10 @@ int mt76x02_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
        !(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
        return -EOPNOTSUPP;

+   /* MT76x0 GTK offloading is currently broken */
+   if (is_mt76x0(dev) && !(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
+       return -EOPNOTSUPP;
+
    /*
     * In USB AP mode, broadcast/multicast frames are setup in beacon
     * data registers and sent via HW beacons engine, they require to
-- 
2.26.2

[LorenzoBianconi]

I've discovered today that when using mt76 (version from OpenWrt master as well as 19.07) with a MT7610E will result in no multicast TX when using encryption (WPA2-PASK / WPA3-SAE). It's very noticeable as IPv6 RAs won't be received by the clients.

When using an open AP, multicast TX works flawlessly. I've tested this on a Archer C20i as well as a Archer C2 and both show the same symptoms. It also does not matter whether or not 802.11w was enabled or disabled.

I've patched mt76 to disable hwcrypto for the MT7610E and multicast appears to be working w/o issues

The same settings work flawlessly on MT7612E (Archer C50 v3).

Client tested: Nokia 6.1 (Android 10) ; Intel AX200 ; Qualcomm QCA6174A

can you please provide your configuration? Are you running multiple-bss?

[blocktrron]

It's a simple single-VAP configuration using PSK2 (CCMP).

I've sent you an email with more details regarding this issue.

[spakka]

I found this problem also on MT7615E, also noticed because IPv6 stops working. The initial router solicitation receives a unicast router advertisement. Then I watch with tcpdump and I see the router sending periodic multicast advertisements, but do not arrive at the client. Eventually the client expires the default route.

My config is a pair of SSIDs (for 2 different vlans) with WPA2-PSK/WPA3-SAE mixed mode. The device is only an AP, not acting as a router.

[LorenzoBianconi]

It's a simple single-VAP configuration using PSK2 (CCMP).

I've sent you an email with more details regarding this issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/410#issuecomment-660098641, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOA2CO5GMT5L5MKNME7J73R4BEXTANCNFSM4N3OGE5A .

Hi David,

I have just tired and broadcast traffic from the AP (e.g. ARP) seems encrypted. Where did you exactly sniff the traffic? from a node into the bss or from an unconnected device?

Regards, Lorenzo

[blocktrron]

It was from an unconnected node.

I've sent you wireless settings yesterday. When you were trying this, did you use an automatically assigned MAC address or did you set one from /sys/class/ieee80211/phy0/addresses? Broadcast encryption works for me when i don't set a specific MAC address and breaks when i set a specific one from sysfs.

I'm aware MediaTek chips have an internal hardware MAC filter. Could be the issue that a specific MAC has to be assigned a specific BSS-ID within the driver?

[blocktrron]

Okay, it seems to only work when the VAP is assigned the first MAC address. As soon as i have a second VAP, encryption only seems to work for the first interface created.

[LorenzoBianconi]

Okay, it seems to only work when the VAP is assigned the first MAC address. As soon as i have a second VAP, encryption only seems to work for the first interface created.

Ok, maybe I identified the issue. I will provide you a patch to test

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/410#issuecomment-662574553, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOA2CMIIWEYVK2FET4HQXTR44MI5ANCNFSM4N3OGE5A .

-- 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

[LorenzoBianconi]

@blocktrron can you please try this patch?

[blocktrron]

Hi Lorenzo,

I've tried you suggested patch. The effect is now that i am able to exchange multicast data using my mobile phone, however it is still impossible for my Notebook to exchange data. When capturing the packets on the air, multicast traffic still seems to be unencrypted (maybe it is using a nullcipher?), but my mobile phone is happily sending unencrypted multicast messages to the AP.

Shall i send you pcaps or are you able to reproduce the issue?

[LorenzoBianconi]

Hi Lorenzo,

I've tried you suggested patch. The effect is now that i am able to exchange multicast data using my mobile phone, however it is still impossible for my Notebook to exchange data. When capturing the packets on the air, multicast traffic still seems to be unencrypted (maybe it is using a nullcipher?), but my mobile phone is happily sending enencrypted multicast messages to the AP.

What is the difference with respect to the upstream code? were you able to connect with the mobile before? Was the mobile phone the first or the second device connected?

Shall i send you pcaps or are you able to reproduce the issue?

yes, please.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/410#issuecomment-663108140, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOA2CKI4EJZFS3V5IQYLZTR5BREPANCNFSM4N3OGE5A .

[blocktrron]

Hi Lorenzo,

were you able to connect with the mobile before?

Previously i was able to connect with the mobile only if the MAC address of the VAP was the first one from sysfs.

Was the mobile phone the first or the second device connected?

It is the first one connected.

See this pcap: https://drive.google.com/file/d/1x4aliLZR9bS_f_JjYwPL0Sf9J43piuTD/view?usp=sharing

[blocktrron]

Correction: Connection was possible previously, multicast traffic was only possible when the MAC address was the first one from sysfs. Now multicast traffic works to the phone, but it seems unencrypted.

Question here: As I'm still not able to receive multicast traffic using my notebook: Does the phones implementation seem to be broken in that regard?

[LorenzoBianconi]

On Thu, Jul 23, 2020 at 6:46 PM David Bauer notifications@github.com wrote:

Hi Lorenzo,

were you able to connect with the mobile before?

Previously i was able to connect with the mobile only if the MAC address of the VAP was the first one from sysfs.

Was the mobile phone the first or the second device connected?

It is the first one connected.

See this pcap: https://drive.google.com/file/d/1x4aliLZR9bS_f_JjYwPL0Sf9J43piuTD/view?usp=sharing

can you please add read permission for that?

What happens if you add multiple interfaces but without changing the mac address?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/410#issuecomment-663113458, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOA2CJXE4AB6HP33LRXQHTR5BSNZANCNFSM4N3OGE5A .

[blocktrron]

Read permissions added.

What happens if you add multiple interfaces but without changing the mac address?

The situation does not change when i remove the mac address from the configuration.

[LorenzoBianconi]

Read permissions added.

What happens if you add multiple interfaces but without changing the mac address?

The situation does not change when i remove the mac address from the configuration.

ok, they are not-encrypted for sure. IIUC you changed the AP mac address respect to the eeprom one, right? If so, what happens if you do not change the address and add multiple interfaces?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

-- 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]

Hi Lorenzo,

the situation does not change when i use the MAC address from eeprom.

[LorenzoBianconi]

Hi Lorenzo,

the situation does not change when i use the MAC address from eeprom.

are you using psk2 or owe as encryption method? are there any difference using psk2 or owe?

[blocktrron]

I've tried both and neither of them worked.

Out of curiosity - are you able to reproduce the issue yourself?

[blocktrron]

@LorenzoBianconi We're you able to reproduce the issue? In case you are lacking a MT7610 device, i might be able to sent you one (if you are based in EU).

I'm not sure how to otherwise progress this here. All documentation i have is a age-old vendor driver. As this is an information disclosure issue, from my POV falling back to software-crypto for multicast traffic on this chip is still preferred over having this unfixed.

If you agree, i will sent my patch to linux-wireless to push this forward (and maybe increase awareness of this bug).

[nicklowe]

@nbd168 Are you aware of this?

[tiagogaspar8]

I'm also facing this issue... How is it possible this is not fixe yet? @blocktrron , did your patch fix the issue for you? I'm actually seeing this issue on the 7620 radio.