[solved][BPI-R64] Mesh (802.11s) on internal WiFi card (MT7622AV)

jonny · September 22, 2021, 12:33pm

Hi,

I’m trying to use Mesh (802.11s) on the internal WiFi Card (MT7622AV according to the openwrt wiki) between two BPI R64 -V1.1, but I didn’t get it to work.

It seems that the beacons aren’t sent at all, because I didn’t even see the network with a iw dev wlan0 scan on the same device.

My wireless config:

root@OpenWrt:~# cat /etc/config/wireless 

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/18000000.wmac'
	option channel '1'
	option band '2g'
	option htmode 'HT20'
	option country 'DE'
	option cell_density '2'
	option beacon_int '15'

config wifi-iface 'wifinet0'
	option device 'radio0'
	option mode 'mesh'
	option encryption 'none'
	option mesh_id 'Avarange-Mesh'
	option mesh_fwding '1'
	option mesh_rssi_threshold '0'
option network 'mesh_network1'

And my network config:

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd1e:8d69:e16e::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'

config interface 'mesh_network1'
	option proto 'static'
	option ipaddr '10.44.0.3'
	option netmask '255.255.255.0'

I build the image by using the latest commit da5bb885e17cf77caea70adcf473f1fb95448553 of the openwrt git.

I also tried to enable all MT76x wireless firmware in the config.

What works:

AP
partly adhoc (I do see the network on the same device, but not from any other device)

Do you have any hint for me ? Am I doing anything wrong?

Thanks!

frank-w · September 22, 2021, 3:46pm

are you sure mt7622 wifi supports mesh? maybe you need to use external eeprom (mtd/file/dts) to get all features. it is needed to increase the tx power…maybe for this too

ericwoud · September 22, 2021, 3:47pm

I do not use openwrt on my R64, but on my system “iw list” gives me:

	Supported interface modes:
		 * IBSS
		 * managed
		 * AP
		 * AP/VLAN
		 * monitor
		 * P2P-client
		 * P2P-GO

so no:

         * mesh point

Like it says in https://openwrt.org/docs/guide-user/network/wifi/mesh/80211s

Hopefully it does shows it on openwrt?

Edit: Forgot setting CONFIG_MAC80211_MESH=y that fixes the missing ‘mesh point’

jonny · September 22, 2021, 10:59pm

Thanks for your answer!

I am confused.

My iw list returns mesh point:

root@OpenWrt:~# iw phy
Wiphy phy0
	wiphy index: 0
	max # scan SSIDs: 4
	max scan IEs length: 2304 bytes
	max # sched scan SSIDs: 0
	max # match sets: 0
	Retry short limit: 7
	Retry long limit: 4
	Coverage class: 0 (up to 0m)
	Device supports AP-side u-APSD.
	Device supports T-DLS.
	Available Antennas: TX 0xf RX 0xf
	Configured Antennas: TX 0xf RX 0xf
	Supported interface modes:
		 * IBSS
		 * managed
		 * AP
		 * AP/VLAN
		 * monitor
		 * mesh point
		 * P2P-client
		 * P2P-GO
	Band 1:
		Capabilities: 0x1ff
			RX LDPC
			HT20/HT40
			SM Power Save disabled
			RX Greenfield
			RX HT20 SGI
			RX HT40 SGI
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: No restriction (0x00)
		HT TX/RX MCS rate indexes supported: 0-31
		Frequencies:
			* 2412 MHz [1] (6.0 dBm)
			* 2417 MHz [2] (6.0 dBm)
			* 2422 MHz [3] (6.0 dBm)
			* 2427 MHz [4] (6.0 dBm)
			* 2432 MHz [5] (6.0 dBm)
			* 2437 MHz [6] (6.0 dBm)
			* 2442 MHz [7] (6.0 dBm)
			* 2447 MHz [8] (6.0 dBm)
			* 2452 MHz [9] (6.0 dBm)
			* 2457 MHz [10] (6.0 dBm)
			* 2462 MHz [11] (6.0 dBm)
			* 2467 MHz [12] (6.0 dBm)
			* 2472 MHz [13] (6.0 dBm)
			* 2484 MHz [14] (disabled)
	valid interface combinations:
		 * #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-GO } <= 16,
		   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }

	HT Capability overrides:
		 * MCS: ff ff ff ff ff ff ff ff ff ff
		 * maximum A-MSDU length
		 * supported channel width
		 * short GI for 40 MHz
		 * max A-MPDU length exponent
		 * min MPDU start spacing
	max # scan plans: 1
	max scan plan interval: 0
	max scan plan iterations: 0
	Supported extended features:
		* [ VHT_IBSS ]: VHT-IBSS
		* [ RRM ]: RRM
		* [ SET_SCAN_DWELL ]: scan dwell setting
		* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
		* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
		* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
		* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
		* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
		* [ AQL ]: Airtime Queue Limits (AQL)
		* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
		* [ DEL_IBSS_STA ]: deletion of IBSS station support
		* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
		* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support

So it should work, right ?

I also do not see any errors or warnings in dmesg when reloading wifi. (and there should be if it isn’t supported)

dangowrt · September 23, 2021, 11:29am

MT7622 should support 802.11s mesh mode, however, there are maybe problems with the mt76 driver or firmware.

ericwoud · September 24, 2021, 3:26pm

If you don’t mind pulling cables between Router and Access Points, you could use 802.11r. Fast Roaming. Just tested it, this work fine on mt7622. You won’t even notice the wifi client changing to another Access Point.

You can find the hostapd.conf here.

Should be almost identical on openwrt…

dangowrt · September 25, 2021, 7:58am

While, of course, you can use 802.11r on Ethernet backbone or even WDS links, this is unrelated to 802.11s mesh capabilities. I know, in the marketing offices where people are completely disconnected from any technical reality they started to sell even the most simple repeater as “mesh” product, see

https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh

Of course, none of this has even the slightest thing to do with actual mesh routing or wireless mesh networks. I suppose this is why the topic even mentions the IEEE standard 802.11s to make it clear that we are not talking about any mesh-washing of the marketing language used to sell repeaters or the like but actual wireless mesh networking in the sense of to IEEE 802.11s standard.

schnickidischnack · September 28, 2021, 8:36am

I have the same issues. Can someone point me to the actual kernel sources of the wireless driver? I would try going through the commits and see if something broke.

schnickidischnack · September 28, 2021, 8:51am

Thanks for also posting this here.

I’m not so familar with the driver. Going through kernel log, the driver seems to also be supported by the mt7615? Log mt7622

frank-w · September 28, 2021, 10:02am

Right,Mt7622 wifi (wmac) is using mt7615 core.

See here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/mediatek/mt76/mt7615/Kconfig#n21

Maybe you should look for commits in

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/net/wireless/mediatek/mt76

To see mt76 core changes too. Was it working before? You could try out firdt kernel versions between working and none working (maybe binary search…by trying always the middle version).

schnickidischnack · September 29, 2021, 8:59am

I use OpenWrt so binary search is not that easy. How would you do a binary search with the BPI R64?

frank-w · September 29, 2021, 9:14am

With binary search i mean that you search like bisect works:

you have a working version, e.g. 5.4
you have a broken version,e.g. 5.14
then you do the “binary search”:
- get the half between working and non working => 5.9
- depending of this is working or not check the breaking half. Still working: check 5.9-5.14 (5.12),not working: check 5.4-5.9 (5.6)
- repeating the steps till you get the breaking kernel version. After that you can use git to get differences between this and the previous to see code changes, e.g. git log 5.9…5.10 – drivers/net/wireless/mediatek/mt76

schnickidischnack · September 29, 2021, 9:37am

Yeah, but using OpenWrt this is not so trivial. xD

frank-w · September 29, 2021, 9:41am

You could try to reproduce on debian

jonny · September 29, 2021, 2:10pm

I did some further testing. (Not related to the kernel version because it is not that easy to change it in openwrt like in debian)

My steps:

Add an USB wifi dongle (with driver kmod-carl9170) to my openwrt router and setup 802.11s
Setup 802.11s on both BPI R64s
My router is able to communicate with booth R64s
With Mesh Fordwarding and my usb doongle in the router the R64s can communicate

I noticed:

If I do iw dev wlan0 scan | grep MESH ID: I only see my USB doongle
The BPI R64s seem to have problems to send the beacons BUT are able to work if the USB doongle somehow compansate it.
If I reset the wifi on my router and do a scan or station dump I do not see any of the R64 BUT if I do ping both from the router (or vice-versa) they appear in the station dump on the router

I will try using debian for testing other kernels.

frank-w · September 29, 2021, 4:26pm

which kernel do you use atm? is 5.4/5.10 working?

jonny · September 30, 2021, 6:52am

For this test I used 5.10.64 on the BPI R64s and 4.14.195 on my router with the usb dongle.

I also found an older openwrt image older openwrt image here. And tested it with 4.19 on the R64s. Very same result!

I guess now that it is not the kernel, which breaks it.

frank-w · September 30, 2021, 9:50am

So all kernel versions are affected,no one is working,right? Then i guess it’s simply not implemented

jonny · September 30, 2021, 11:12am

It seems so. I didn’t test “all” version

But it is working with other not R64 participants. So does 802.11s in general work if only one endpoint support it ?

frank-w · September 30, 2021, 1:17pm

i don’t think so…but if it is working, device may stay in 802.11s mode to allow other devices use it…but here there should be a fallback mode running