OpenWrt 22.03 mesh not encrypted

Installing and Using OpenWrt
1

In the recently launched final of OpenWrt 22.03, mesh connection between routers is not encrypted any more.

Upgrading from 21.02 (where mesh worked encrypter) to 22.03 left mesh running unencrypted.

There is no entry about failed crypto-channel in the logs.

Some comments (red: OpenWrt mesh routers problems (Encryption, MAC address & Hostname) - #43 by wepee) guess an error in LUCI. This is not the case.

command line tools like iwinfo or uci show wireless clearly report mesh unencrypted.

So:
Settings worked before upgrade.
After upgrade, encryption was not performed
(Yes, i have set the hostname, exchanged wpad-* to the correct ssl version and even replaced the firmware to the working one).

=> There is an issue in the mesh implementation.

Is there a workaround or fix?

2

same issue 22.03 with mesh doesn't work on Archer C7v2? - #4 by uweklatt ?

3

Are you sure it is not misreporting it as none? Used to get the same issue in 18.06. Try running a scan from each router to check the encryption of the others.

I'm still using a release candidate, but encryption is shown as none in the web interface and the output of iwinfo

However, a scan from another router

iwinfo phy0 scan

detecting the same mesh node shows Encryption: WPA3 SAE (CCMP)

1 Like
4

No there isn't, it is iwinfo that does not support mesh devices with sae encryption.

You can do what @mjs suggests and do a scan, ie something like:
iw dev mesh0 scan | grep -A13 BSS

Look in the output for the BSS (mac address) of the other mesh nodes in your network.
You will see something like this:

BSS e4:95:6e:45:2e:09(on mesh0)
	last seen: 2922.240s [boottime]
	TSF: 123591373222 usec (1d, 10:19:51)
	freq: 2472
	beacon interval: 100 TUs
	capability: (0x0010)
	signal: -26.00 dBm
	last seen: 30 ms ago
	SSID: 
	RSN:	 * Version: 1
		 * Group cipher: CCMP
		 * Pairwise ciphers: CCMP
		 * Authentication suites: SAE
		 * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)

Alternatively you can set encryption to 'none' on just one of your meshnodes and see if it still connects.

1 Like
5

Thanks.
I ran into the same - luci saying "none" - but the scan looks fine.

6 
$ iwinfo mesh info
mesh      ESSID: "rsb_mesh"
          Access Point: 60:E3:27:4F:BB:0F
          Mode: Mesh Point  Channel: 36 (5.180 GHz)
          Center Channel 1: 42 2: unknown
          Tx-Power: 23 dBm  Link Quality: 64/70
          Signal: -46 dBm  Noise: -103 dBm
          Bit Rate: 585.0 MBit/s
          **Encryption: none**
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: 168C:003C 0000:0000 [Qualcomm Atheros QCA9880]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0


$ iwinfo phy0 scan
Cell 02 - Address: C0:C9:E3:E6:16:3D
          ESSID: "rsb_mesh"
          Mode: Mesh Point  Channel: 36
          Signal: -40 dBm  Quality: 70/70
          **Encryption: WPA3 SAE (CCMP)**
          HT Operation:
                    Primary Channel: 36
                    Secondary Channel Offset: above
                    Channel Width: unknown
          VHT Operation:
                    Channel Width: unknown
                    Center Frequency 1: 42
                    Center Frequency 2: 0

Cell 04 - Address: 50:6F:9A:01:00:00
          ESSID: unknown
          Mode: Mesh Point  Channel: 36
          Signal: -58 dBm  Quality: 52/70
          **Encryption: none**
          HT Operation:
                    Primary Channel: 0
                    Secondary Channel Offset: no secondary
                    Channel Width: unknown

"One of us is lying, one of us is crying ..." (ABBA).

Unencryted MAC address belongs to:

Wi-Fi Alliance
10900-B Stonelake Boulevard
Suite126
Austin TX 78759
UNITED STATES

It is a unicast address.

Why does LUCI and uci report encryption for this cell?

2 Likes
7

I'm having the same issue. I have three identical ASUS MAP-AC2200 devices. I upgraded just one to 22.03 it can no longer connect onto the mesh. The logs show MESH-SAE-AUTH-FAILURE. The mesh info shows encryption none. These devices use the ath10k drivers and I was very carefull to ensure that they have the NON -ct drivers and firmware. Of course it was also working on 21.02.

8

What does that mean in practice? Surely not that anyone eavesdropping can see all local traffic?

Would this also be the case for WDS?

9

You can also check the encryption and key used in the wpa_supplicant config file

root@router:/# cat /tmp/run/wpa_supplicant*.conf


country=GB
network={

        ssid="mymesh"
        key_mgmt=SAE
        mode=5
        mesh_fwding=0
        mesh_rssi_threshold=1
        fixed_freq=1
        frequency=5240
        ht40=1
        vht=1
        max_oper_chwidth=1
        noscan=1
        sae_password="mysecret"
        beacon_int=100
}


country=GB
network={

        ssid="myothermesh"
        key_mgmt=SAE
        mode=5
        mesh_fwding=0
        mesh_rssi_threshold=0
        fixed_freq=1
        frequency=2452
        ht40=1
        disable_vht=1
        noscan=1
        sae_password="imnotpostingthat"
        beacon_int=100
}

I've previously had an older version of openwrt that reported wpa encryption on one router connected by mesh with a build of the 22.x branch which iwinfo and luci was reporting open on another.

10

This is a configuration file.
I assume, everyone has one similar to yours.
This does not prove anything other than your intention to encrypt.

The problem is: The router does not encrypt the communication.

If I use wireshark and can read the communication, there must be something wrong (and I'm not talking about the IP headers)

11
12

Clearly, if that's the case. Not something I checked myself because my wifi card doesn't support monitor mode.

Have you confirmed 21.03 is encrypted, because a mesh running on it showing encrypted will still successfully connect to one on 22.03 showing encryption: none, I just checked:-

V21.03

config# iwinfo mesh0 info
mesh0     ESSID: "mymesh"
          Access Point: 12:34:56:78:9a:25
          Mode: Mesh Point  Channel: 48 (5.240 GHz)
          Center Channel 1: 42 2: unknown
          Tx-Power: 20 dBm  Link Quality: 58/70
          Signal: -52 dBm  Noise: -103 dBm
          Bit Rate: 390.3 MBit/s
          Encryption: WPA3 SAE (CCMP)
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: 168C:003C 0000:0000 [Qualcomm Atheros QCA9880]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

V22.03

root@router:/etc/config# iwinfo mesh0 info
mesh0     ESSID: "mymesh"
          Access Point: 11:22:33:44:55:11
          Mode: Mesh Point  Channel: 48 (5.240 GHz)
          Center Channel 1: 42 2: unknown
          Tx-Power: 23 dBm  Link Quality: 62/70
          Signal: -48 dBm  Noise: -101 dBm
          Bit Rate: 650.3 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: 168C:003C 0000:0000 [Qualcomm Atheros QCA9880]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

(Swaping the 22.03 node from wpad-wolfssl to wpad-openssl also connects and iwinfo in both still report the same.)

13

How many times do you want to ask the same question?

Both endpoints are unencrypted. The communication is unencrypted. The reading says unencrypted.

It will not change by reiterating the same question.

14

Then in that case either:

  1. Your hardware does not support encryption
    or
  2. You have configured it incorrectly.

As I said two weeks ago - NOT using the buggy iwinfo, do a scan:

..... ie something like:
iw dev mesh0 scan | grep -A13 BSS

Look in the output for the BSS (mac address) of the other mesh nodes in your network.
You will see something like this:

BSS e4:95:6e:45:2e:09(on mesh0)
	last seen: 2922.240s [boottime]
	TSF: 123591373222 usec (1d, 10:19:51)
	freq: 2472
	beacon interval: 100 TUs
	capability: (0x0010)
	signal: -26.00 dBm
	last seen: 30 ms ago
	SSID: 
	RSN:	 * Version: 1
		 * Group cipher: CCMP
		 * Pairwise ciphers: CCMP
		 * Authentication suites: SAE
		 * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)

Alternatively you can set encryption to 'none' on just one of your meshnodes and see if it still connects.

What are you running wireshark on? Your workstation no doubt.
Wireshark can only see packets received on an interface. On a wireless interface, packets are decrypted before Wireshark receives them. But even given that, you will not even be monitoring the mesh interface on a meshnode, rather, you will be looking at packets received from an AP mode radio by the STA mode interface on your workstation.

15

Please refer to my FIRST entry (top of the page):

mesh was encrypted in 21.02.

Why would my hardware suddenly decide to stop encrypting. And how would hardware care about a software capability?

I'm sorry to become even more impatient. I come here for help and advice. I prepare my input to my maximum technical knowledge. If I forget something, I provide it immediately. I read through all cells BEFORE I submit something.

But how on earth (which btw. is round) can anyone come up with:

Maybe your hardware does not do it

Packets are decrypted before getting to Wireshark

(Actually no: the WiFi interface is set to promiscuous mode and then reads all traffic regardless of being connected or not. And I use a special Raspberry Pi, and please don't tell me, maybe your Raspberry cannot encrypt wireless signals)

If you are interested in the basics: Andrew Tannenbaum, Computer Networks

16

OK, as I've never looked at wifi traffic, I thought I'd have another stab at capturing the 802.11 traffic from my mesh.

I checked my router's wifi capabilities and it supports monitor mode, and conveniently a monitor interface can even be configured via the openwrt browser UI.

So, I used tcpdump on a third router to capture the wireless traffic including the mesh connection between my other two, to a usb stick and samba to view it in wireshark and filtered by my mesh's wlan.bssid to get rid of a mass of the neighbours wifi frames.

I've not looked at 802.11 packets before, but I saw nothing in plaintext that I wouldn't expect to be readable. Lots of beacons with a field indicating AES and "IEEE 802.11 QoS Data." frames with a "CCMP Ext. Initialization Vector:xxxxx" with what I would take to be the encrypted payload.

And nothing in plaintext below the wifi layer, which would suggest to me it is encrypted :slight_smile: . Not so much as an IP address.

Ergo, I still think it is encrypted, and just iwinfo and luci misreporting that it is not.

Also as I pointed out in my previous post a mesh node on 21.x version on openwrt connects to a mesh node running on openwrt 22.x with both configured to use sae encryption, so it is difficult to see how encryption could be working on one and not on the other.

17

@mjs: Thanks for your reply. I understand:

  • in mixed mode, encrypted (21.02) and presumably unencrypted (23.02) worked jointly.

I cannot restore this setting now, but I believe my 21.02 jumped to unencrypted connecting to 23.02. Right now, I have 23.02 - 23.02 connection that is unencrypted

  • you verified on a network level that packets are encrypted.

(As 802.11s does no header encryption, you see the IP headers and that is correct).

You conclude that iwinfo and LUci misreport the encryption state. Could be. In my case I see the content of the packets.

However, if there is a false reporting of encryption state, this needs to be resolved as well.

18

Well if you are certain that:

  1. Your hardware can do it
  2. There is no encryption

Then the obvious conclusion is that you have configured it incorrectly (given the known issue with iwinfo and the fact it is encrypted for everyone else).

Have you done the iw scan method of checking or do you dismiss it as irrelevant?

1 Like
19

No IP headers, just the radio headers, MAC addresses, etc as you'd expect.

Also, I'm using monitor mode, rather than promiscuous mode, because as I understood it you need to join the network to use promiscuous mode and it doesn't capture encrypted traffic.

Wireshark Promiscuous mode

In promiscuous mode the MAC address filter mentioned above is disabled and all packets of the currently joined 802.11 network (with a specific SSID and channel) are captured, just as in traditional Ethernet. However, on a "protected" network, packets from or to other hosts will not be able to be decrypted by the adapter, and will not be captured, so that promiscuous mode works the same as non-promiscuous mode.

20

Presumably, the scan is just indicating the encryption method requested/required by the other mesh node, and if there is/was a bug in both end points perhaps it is conceivable that they might negotiate encryption, yet send packets in plain text.