Bug? mixed WPA2/WPA3 OpenWRT AP shows as WPA2-only in active scan (mwlwifi WRT1900ACS)

Installing and Using OpenWrt
1

Hi all,

I have my Linksys WRT1900ACS set to mixed WPA2/WPA3 (option encryption 'sae-mixed') for one SSID. When I connect from my Macbook Pro 2019, it shows "WPA3 Personal" as expected.

Interestingly, an active scan using the third-party macOS tool WiFi Explorer Pro 3 from Intuitibits shows the same BSSID as "WPA2 (PSK)". A passive scan however shows it correctly as "WPA2/WPA3 (PSK/SAE).

I reported it to the developer of WiFi Explorer Pro 3 as I first thought it's a bug on their side, and the main developer helped to look through my data captures.

His answer:

It appears there’s an issue in OpenWrt where the RSN information element in the probe response doesn’t match the element in beacons. In fact, the RSN information element in the probe response seems to contain bogus information. This causes WiFi Explorer to show the wrong security configuration when you’re not connected to the AP. Once connected, macOS may provide WiFi Explorer with cached beacons instead of probe responses (this is an internal optimization that macOS performs, not WiFi Explorer).

Fortunately, the capture you sent us contained both beacons and probe responses from the AP in question, and that helped in finding the problem.

Below is the RSN information element from a beacon. Note that the Auth Key Management Suite List correctly enumerates PSK (WPA2) and SAE (WPA3) as supported AKMs. This is expected when using mixed mode.

RSNE - Group Cipher: CCMP-128; Pairwise Cipher(s): CCMP-128; AKM Suite(s): PSK, FT using PSK, PSK (SHA-256), SAE (SHA-256), FT using SAE (SHA-256); MFP Capable
    Element ID: 48
    Length: 36 bytes
    RSN Version: 1
    Group Cipher Suite OUI: 00-0F-AC (IEEE 802.11)
    Group Cipher Suite Type: CCMP-128 (4)
    Pairwise Cipher Suite Count: 1
    Pairwise Cipher Suite List
        Pairwise Cipher Suite OUI: 00-0F-AC (IEEE 802.11)
        Pairwise Cipher Suite Type: CCMP-128 (4)
    Auth Key Management Suite Count: 5
    Auth Key Management Suite List
        Auth Key Management Suite OUI: 00-0F-AC (IEEE 802.11)
        Auth Key Management Suite Type: PSK (2)
        Auth Key Management Suite OUI: 00-0F-AC (IEEE 802.11)
        Auth Key Management Suite Type: FT using PSK (4)
        Auth Key Management Suite OUI: 00-0F-AC (IEEE 802.11)
        Auth Key Management Suite Type: PSK (SHA-256) (6)
        Auth Key Management Suite OUI: 00-0F-AC (IEEE 802.11)
        Auth Key Management Suite Type: SAE (SHA-256) (8)
        Auth Key Management Suite OUI: 00-0F-AC (IEEE 802.11)
        Auth Key Management Suite Type: FT using SAE (SHA-256) (9)
    RSN Capabilities: 0x008c
        .... .... .... ...0 RSN Pre-Authentication Capabilities: Not supported
        .... .... .... ..0. RSN No Pairwise Capabilities: STA can support WEP default key simultaneously with Pairwise key
        .... .... .... 11.. RSN PTKSA Replay Counter Capabilities: 16 replay counters (0x0003)
        .... .... ..00 .... RSN GTKSA Replay Counter Capabilities: 1 replay counter (0x0000)
        .... .... .0.. .... Management Frame Protection Required: No
        .... .... 1... .... Management Frame Protection Capable: Yes
        .... ...0 .... .... Joint Multi-band RSNA: Not supported
        .... ..0. .... .... PeerKey Enabled: No

And here’s the RSN information element from a probe response. Note that the AKM List only enumerates PSK. Instead, three bogus AKMs are listed, and it doesn’t include SAE. In my opinion, this is a bug in OpenWrt.

RSNE - Group Cipher: CCMP-128; Pairwise Cipher(s): CCMP-128; AKM Suite(s): PSK, FT using PSK, None, None, None
    Element ID: 48
    Length: 36 bytes
    RSN Version: 1
    Group Cipher Suite OUI: 00-0F-AC (IEEE 802.11)
    Group Cipher Suite Type: CCMP-128 (4)
    Pairwise Cipher Suite Count: 1
    Pairwise Cipher Suite List
        Pairwise Cipher Suite OUI: 00-0F-AC (IEEE 802.11)
        Pairwise Cipher Suite Type: CCMP-128 (4)
    Auth Key Management Suite Count: 5
    Auth Key Management Suite List
        Auth Key Management Suite OUI: 00-0F-AC (IEEE 802.11)
        Auth Key Management Suite Type: PSK (2)
        Auth Key Management Suite OUI: 00-0F-AC (IEEE 802.11)
        Auth Key Management Suite Type: FT using PSK (4)
        Auth Key Management Suite OUI: 00-0F-00 (Legra Systems Inc.)
        Auth Key Management Suite Type: None (0)
        Auth Key Management Suite OUI: 00-00-00 (Xerox Corp.)
        Auth Key Management Suite Type: None (0)
        Auth Key Management Suite OUI: 00-00-00 (Xerox Corp.)
        Auth Key Management Suite Type: None (0)
    RSN Capabilities: 0x0000
        .... .... .... ...0 RSN Pre-Authentication Capabilities: Not supported
        .... .... .... ..0. RSN No Pairwise Capabilities: STA can support WEP default key simultaneously with Pairwise key
        .... .... .... 00.. RSN PTKSA Replay Counter Capabilities: 1 replay counter (0x0000)
        .... .... ..00 .... RSN GTKSA Replay Counter Capabilities: 1 replay counter (0x0000)
        .... .... .0.. .... Management Frame Protection Required: No
        .... .... 0... .... Management Frame Protection Capable: No
        .... ...0 .... .... Joint Multi-band RSNA: Not supported
        .... ..0. .... .... PeerKey Enabled: No

I am using OpenWrt 23.05.2 r23630.

Can someone reproduce this behaviour? Is this a bug?

Thanks,
softice

2

Welcome to the forum,

Currently there is no working WPA3 for those devices.

In the past the whole Linksys WRT 1900/3200/32x series on real OpenWRT relied on abandoned incomplete source code for the Wifi driver plus a closed source binary blog, which (among a lot of bugs) has no WPA3 support included (though LuCi offers to enable WPA3 it in the GUI option box).

There were some recent discussions about coding attempts to bring in WPA3 for Linksys WRT, but this is so far in the main tree only and experimental, and far from hitting 23.05.xx (and has yet to show the resulting stability/quality).

3 Likes
3

The fixes by @jbsky have actually been backported to 23.05, but after 23.05.2, so the new mwlwifi driver is only visible to 23.05-SNAPSHOT builds and self built 23.05 head builds. (And naturally in main/master as Pico already said.)

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=9cf576963682c98a0183b2fd2408599bb6f69a36

Would be interesting if @s0ftice would test that.

4 Likes
4

When I tried mixed 2 and 3 I could not connect and it reverted.

Since not all my devices can use WPA3 I'm stuck with WPA2.

5

this here is not a client or config issue, but a known issue of the Wifi part of Linksys WRT 1900/3200/32x routers.

2 Likes
6

Okay. I'm not really all that concerned: my password is 21 'random' characters. But I do have an issue with mixed mode and I was just replying to:

1 Like
7

Thanks all for the answers!

Well it does seem to work out of the box for me with 23.05.2. My MacBook Pro 2019 shows "WPA3 Personal" when connected.

wpa3
wpa3586×606 37.4 KB

Am I misinterpreting this?

8

My understanding of the Linksys WRT series is that the 1900 range can use WPA3, but the 3200 range cannot - they have a different version of the wifi chip. (88W8864 vs 88W8964)
My WRT1900ACv1 could use WPA3 under DD-WRT.
My WRT3200ACM can only use WPA2 under DD-WRT and OpenWRT Stable or Snapshot

3 Likes
9

my understanding of DD-WRT was:
DD-WRT is primarily not to be seen as fork.
On most devices they patch the Linux kernel and tools to a higher patch level and add their own mgmt GUI, but keep all the most proprietary vendor drivers in place. Only on rather few devices they throw in open sourced drivers or have contracts with the vendors to get access to the proprietary driver code.

from what I remember, DD-WRT did not rely on the open sourced Marvell wifi driver (which had fewer features) for Linksys WRT, but stayed with the proprietary drivers, which I think just like the vendor drivers were able to do WPA3. I think the lack of WPA3 was related to the open sourced drivers of Linksys WRT.

1 Like
10

WPA3 in the past was not working on Linksys WRT though it was said to offer the handshake to clients and GUIs did pretend falsely to run it.
I think the clients either went for WPA2 silently or would stall.