openwrt / openwrt

This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins. We will continue to accept Pull Requests here. They will be merged via staging trees then into openwrt.git.
Other
18.9k stars 9.99k forks source link

wpad-mesh-mbedtls breaks backward compatibility for unencrypted mesh #15826

Open ayrstone opened 1 week ago

ayrstone commented 1 week ago

Describe the bug

With wpad-basic-mbedtls, an unencrypted mesh can be created between OpenWRT devices, and it is backwards compatible to at least release 19.07.4. However, in the current snapshot using wpad-mesh-mbedtls, an unencrypted mesh will not connect with an unencrypted mesh created with an earlier version of OpenWRT or with an unencrypted mesh created created with wpad-basic-mbedtls on the same OpenWRT snapshot.

The /var/run/wpa_supplicant-phy0-mesh0.conf file looks like this:

network={

    ssid="d7e8b340b41d54a7"
    key_mgmt=NONE
    mode=5
    fixed_freq=1
    frequency=2437
    disable_ht40=1
    disable_vht=1
    noscan=1
    beacon_int=100
}

which looks like it should work, but it does not.

I have also verified this behavior in the 23.05.3 release; I'm not sure how far back this is broken.

Correct behavior would be for an unencrypted mesh to be compatible across all releases.

Encrypted mesh seems to work OK and is backwards-compatible, but I need the ability to run both encrypted and unencrypted meshes, perhaps on the same radio (e.g. unencrypted on 2.4 GHz., encrypted on 5 GHz.)

OpenWrt version

r26800-843b51b26d

OpenWrt release

SNAPSHOT

OpenWrt target/subtarget

ramips/mt7621

Device

COMFAST CF-EW72 V2

Image kind

Official downloaded image

Steps to reproduce

  1. Download an image from 23.05.3 or later (perhaps earlier, too - have not tested)
  2. Flash two EW-72v2 radios, and use the following wireless config on both:
    
    config wifi-device 'radio0'
    option type 'mac80211'
    option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
    option band '2g'
    option channel '6'
    option htmode 'HT20'
    option disabled '0'
    option log_level '0'

config wifi-iface 'AP' option device 'radio0' option network 'lan' option mode 'ap' option ssid 'xxxxxxxxxx' option encryption 'psk2' option key 'yyyyyyyyyy' config wifi-iface 'mesh' option device 'radio0' option network 'lan' option mode 'mesh' option mesh_id 'zzzzzzzzzz'

config wifi-device 'radio1' option type 'mac80211' option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0' option band '5g' option channel '36' option htmode 'VHT80' option disabled '1'

config wifi-iface 'default_radio1' option device 'radio1' option network 'lan' option mode 'ap' option ssid 'OpenWrt' option encryption 'none'


3. Observe that they mesh using "iw phy0-mesh0 station dump" and "iw phy0-mesh0 mpath dump"
4. On one radio, opkg remove wpad-basic-mbedtls. Leave it on the other radio.
5. On the radio that has had wpad-basic-mbedtls removed, opkg install wpad-mesh-mbedtls (remember to opkg update first)
6. REBOOT
7. Again, observe that they do not mesh; nothing returned from "iw phy0-mesh0 station dump" and "iw phy0-mesh0 mpath dump"
8. If you have any radio running 19.07.4, configure it with the same wireless mesh configuration (mesh_id='zzzzzzzzzz', no encryption) and observe that the radio running wpad-basic-mbedtls meshes, but the radio running wpad-mesh-mbedtls does not.

### Actual behaviour

Radio configured for unencrypted mesh works with older versions of OpenWRT if they are using wpad-basic-mbedtls, but don't work with older versions of OpenWRT if they're using wpad-mesh-mbedtls.

Radios running wpad-mesh-mbedtls configured for unencrypted mesh will mesh with each other, but not with older versions of OpenWRT.

### Expected behaviour

A radio running any version of OpenWRT with open80211s should form an unencrypted mesh with any other radio running any version of OpenWRT with open80211s.

### Additional info

_No response_

### Diffconfig

_No response_

### Terms

- [X] I am reporting an issue for OpenWrt, not an unsupported fork.
ayrstone commented 6 days ago

I pulled out an Alfa N2Q and flashed the 23.05.3 release. It exhibits the same behavior; the problem appears to be in wpa-supplicant (or the instantiation of it), not in the platform.