Beryl 7 incompatibility bug

Hello,

It appears that I have detected a incompatibility in the repeater function.

This happens when I let my Beryl 7 (fw: 4.8.6) connect to my Flint 2 running from OpenWrt master branch with the following config:

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/soc/18000000.wifi'
        option channel '10'
        option band '2g'
        option htmode 'HE20'
        option cell_density '0'
        option txpower '10'
        option country 'NL'
        list hostapd_options 'ssid_protection=1'
        option log_level '3'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/soc/18000000.wifi+1'
        option band '5g'
        option htmode 'HE160'
        option cell_density '0'
        option country 'NL'
        option txpower '17'
        list hostapd_options 'ssid_protection=1'
        option log_level '3'
        list channels '132 100 104 112 116'
        option channel 'auto'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option mode 'ap'
        option ssid 'GL-MT6000-7fa'
        option encryption 'psk2+ccmp'
        option ieee80211r '1'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'
        option ieee80211w '1'
        option ocv '1'
        option wpa_disable_eapol_key_retries '1'
        option mobility_domain 'F8DD'
        option reassociation_deadline '20000'
        option macaddr 'random'
        option wpa_psk_file '/etc/hostapd/ppsk-vlans'
        option skip_inactivity_poll '1'
        option multicast_to_unicast_all '1'
        option vlan_naming '1'
        option dynamic_vlan '2'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option mode 'ap'
        option ssid 'GL-MT6000-7fa-5G'
        option encryption 'psk2+gcmp256'
        option ieee80211r '1'
        option mobility_domain 'F8DC'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'
        option reassociation_deadline '20000'
        option macaddr 'random'
        option ocv '1'
        option wpa_disable_eapol_key_retries '1'
        option skip_inactivity_poll '1'
        option wpa_psk_file '/etc/hostapd/ppsk-vlans'
        option multicast_to_unicast_all '1'
        option dynamic_vlan '2'
        option vlan_naming '1'
        option ieee80211w '2'

config wifi-vlan
        option iface 'default_radio0'
        option vid '178'
        option name 'aqnet'
        option network 'aqaranet'

config wifi-vlan
        option iface 'default_radio0'
        option vid '179'
        option name 'hwnet'
        option network 'hwnet'

config wifi-vlan
        option iface 'default_radio1'
        option vid '90'
        option name 'aya'
        option network 'ayaneo'

config wifi-vlan
        option vid '52'
        option name 'iot'
        option network 'iot'
        option iface 'default_radio0'

config wifi-vlan
        option vid '62'
        option name 'beta'
        option network 'beta'

config wifi-vlan
        option iface 'default_radio0'
        option vid '133'
        option name 'sma'
        option network 'sma'

config wifi-vlan
        option iface 'default_radio1'
        option vid '50'
        option name 'wlan0'
        option network 'wlan0'

config wifi-vlan
        option iface 'default_radio0'
        option vid '51'
        option name 'wlan1'
        option network 'wlan1'

It worked before on the 5ghz channel, the only change I made was using the channel array and I think this causes some minor DFS problems within the repeater function, it seem it tries to brute force random channels on the Beryl 7 and fails.

It is possible that the Flint 2 is using a bug, wifi-scripts-ucode still can cause random problems.

The commit hash of the build for OpenWrt a2b8a3fbb92eeb36a8465df214d5ab454a89272e.

Could there be a limitation perhaps?

Edit:

No it isn't the channel array, I also tried a different vlan password but no avail, from the logs on the Flint 2 I don't see a attempt.

Edit:

It only affects 5G band on the repeater, when I connect to a 2.4ghz network it works fine, is there a way to set wireless country in Beryl 7 since it is not there?

The firmware your MT6000 is using: OpenWrt a2b8a3fbb92eeb36a8465df214d5ab454a89272e

was it provided by us? Or did you obtain it from somewhere else? Could you please provide a download link for this firmware?

It is self compiled on the MT6000, unfortunately there is no link to this firmware since it is for very personal use, if flashed the full configuration is designed for my homelab.

the image can be obtained here Release XSDK-central-a2b8a3 · xize/openwrt-xsdk · GitHub

It will change ip to 10.234.53.1, although it may be better to just compile directly on this commit hash.

1 Like

Apologies for the long wait. We have tested the MT6000 using both the stable firmware release and the GL-iNet OP24 firmware.

In both cases, the MT3600BE was able to successfully connect to a 5G WiFi network in repeater mode.

Consequently, we proceeded to upgrade the device using the firmware link you provided and conducted a WiFi test; it appears to be connecting normally as well. Please refer to the attached screenshots for the test results.

Is this consistently reproducible in your environment?

If so, could you please export the error logs regarding the MT3600BE's failure to connect to 5G WiFi in repeater mode and send them to us for analysis?

Yes there is, I can look at this at weekend :+1:

Did it work with the gcmp cipher on 5ghz on the Beryl 7?, i realize this is a unusual setup since gcmp is mainly wpa3 focused but it can work with wpa2.

(The image does this not have set this option in uci-defaults), the config i posted is a more upstreamed version of what is on my sdk.

Is this what you're talking about?

image

If set to WPA2-PSK, select GCMP (AES) for the Cipher.

The MT3600BE is unable to connect to this Wi-Fi network in repeater mode.

However, I also tested other devices—Android phones, iPhones, Huawei phones, and Windows PCs—and none of them were able to connect.

So, we would like to know: are there other devices in your environment that are able to connect to the MT6000's Wi-Fi?

Or is it the case that only the MT3600BE is unable to connect?

1 Like

Correct :+1:

Yes it seem to be out of scope of standard, although there are a few devices which still can like my Poco X6 pro, for me the reason for honoring wpa2 is to hold the multi psk wildcard ability, SAE/WPA3 however comes with more restriction which enforces also a requirement of mac list, plus for gcmp I think there was also some requirements on WPA3 which on WPA2 isn't.

My thought is however about this unusual configuration, that maybe such scenario can still occur in bussiness environments or even hotels maybe later in the future aswell since it has better encryption without the stronger and restrictive wpa3 policies.

Having this supported would benefit from such corner cases :+1:,maybe only not support in the gl ui as wifi option since it can break that much with incompatibilities.

Only my Poco X6 pro which connects fine.

Edit

Also note when using the multi psk config on wireless that it may break when luci tries to save, best is to use uci directly or raw editor because it removes vlan_naming and dynamic_vlan which rely on a patch which fixes roaming :+1:, otherwise you may hop to vlan 1.

OK.

We have documented this issue; it has been escalated to a requirement but was not classified as a bug.

We will report this requirement to see if it can be implemented in the future.

Thank you.

1 Like