OpenWrt 22.03 mesh not encrypted

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

$ 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

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.

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

Would this also be the case for WDS?

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.

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)

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

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.

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.

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

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.

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

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

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.

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.

I agree yes it is conceivable and indeed such worries date back to OpenWrt 18.06. Hence the additional test to set encryption on one node to none and see if it still connects, or even better, use a different key.

I have not recently looked at packets on air but have in the past. Nothing leads me to believe there is actually no encryption particularly as all versions of OpenWrt from 19.07.0 onwards can join the same mesh. As for a 21.02 "jumping" all by itself to unencrypted just because ... I'm not sure what because.....

This is a bug. I am seeing the same behavior. The ticket is here if you want to track it: https://github.com/openwrt/openwrt/issues/10687

iw dev mesh scan returns:

BSS c0:c9:e3:e6:16:3d(on mesh)
	last seen: 1391773.136s [boottime]
	TSF: 1389612288059 usec (16d, 02:00:12)
	freq: 5180
	beacon interval: 100 TUs
	capability: (0x0010)
	signal: -56.00 dBm
	last seen: 10 ms ago
	SSID: 
	RSN:	 * Version: 1
		 * Group cipher: CCMP
		 * Pairwise ciphers: CCMP
		 * Authentication suites: SAE
		 * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)
	HT capabilities:
		Capabilities: 0x19ef
			RX LDPC
			HT20/HT40
			SM Power Save disabled
			RX HT20 SGI
			RX HT40 SGI
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 7935 bytes
			DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 8 usec (0x06)
		HT TX/RX MCS rate indexes supported: 0-23
	HT operation:
		 * primary channel: 36
		 * secondary channel offset: above
		 * STA channel width: any
	MESH ID: rsb_mesh
	VHT capabilities:
		VHT Capabilities (0x338001b2):
			Max MPDU length: 11454
			Supported Channel Width: neither 160 nor 80+80
			RX LDPC
			short GI (80 MHz)
			TX STBC
			RX antenna pattern consistency
			TX antenna pattern consistency
		VHT RX MCS set:
			1 streams: MCS 0-9
			2 streams: MCS 0-9
			3 streams: MCS 0-9
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT RX highest supported: 0 Mbps
		VHT TX MCS set:
			1 streams: MCS 0-9
			2 streams: MCS 0-9
			3 streams: MCS 0-9
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT TX highest supported: 0 Mbps
	VHT operation:
		 * channel width: 1 (80 MHz)
		 * center freq segment 1: 42
		 * center freq segment 2: 0
		 * VHT basic MCS set: 0xffff

Changing the password on one router while using encrypted connection does not connect to secondary router (I would not draw the conclustion that this indicates an encrypted channel).

Seen as this is rated a bug now, I presume that this will be handled accordingly and we will get an update soon

1 Like

already posted in #11

1 Like