yes now it’s right…
edit: have now added it to my 5.15-rc tree
1 Like
Nice, I have now increase tx-power. However, without my patch I still have no adhoc network… 
Edit: @frank-w Could you maybe also ACK that on the wireless mailing list?
I cannot test mesh as i use only normal ac (mt7612)/bgn (r2 ap0).
If you give me some advice (hostapd config+how to test if mesh is working) i can test with mt7615 in second r2 + r64 with mt7622 wifi
To test unencrypted mesh you don’t need hostapd nor wpa_supplicant. You can create the mesh interface and join/create network using iw util.
For encrypted mesh (SAE) you do need wpa_supplicant.
hostapd is not used for mesh interfaces at all, unless you want combined Mesh+AP on the same radio, in that case you do need hostapd for the AP part and quite a bit of extra magic (see OpenWrt patches).
can you post the iw commands to create meshpoint and mesh client (connecting my 2 devices) and show commands to verify mesh works?
Can you point me to these openwrt patches?
Here is a good explanation: https://wiki.archlinux.org/title/ad-hoc_networking
iw wlan0 set type ibss
ip link set wlan0 up
iw interface ibss join bpi-mesh 2412
Now you should already see in a scan the other pi.
1 Like
For 802.11s mesh mode it’s similar, just use type mesh instead of of type ibss and mesh join instead of ibss join.
1 Like
root@bpi-r2:~# iw wlp1s0 set type ibss
root@bpi-r2:~# ip link set wlp1s0 up
RTNETLINK answers: Input/output error
root@bpi-r2:~# dmesg | grep wlp1s0
[ 15.208512] mt7615e 0000:01:00.0 wlp1s0: renamed from wlan0
root@bpi-r2:~# uname -a
Linux bpi-r2 5.15.0-rc4-bpi-r2 #1 SMP Sat Oct 16 20:43:57 CEST 2021 armv7l GNU/Linux
with patch
I think you probably have already an instance of wpa_supplicant running (usually this happens when people forget that NetworkManager takes care of all their interfaces and they will either have to stop NetworkManager or use NetworkManager for all configuration…)
Do you try to do this with banana pi r2? I thought it has a different wifi card?
It is my r2,using mt7615 card.but not interal wifi (ap0)
and no wpa_supplicant/ hostapd running…but network-config done with systemd
tried stopping it, but error comes again
root@bpi-r2:~# service systemd-networkd stop
Warning: Stopping systemd-networkd.service, but it can still be activated by:
systemd-networkd.socket
root@bpi-r2:~# iw wlp1s0 set type ibss
root@bpi-r2:~# ip link set wlp1s0 up
RTNETLINK answers: Input/output error
root@bpi-r2:~#
maybe i need to set ip address first?
edit: wpa_supplicant is not installed in my (nearly fresh) bullseye image, hostapd is installed, but not running. i got the same error without the patch…so at least not related to the patch…
Weird, if I do the exact same thing on OpenWrt it just works.
No, layer 3 settings don’t matter at this point.
The most important thing is to test it on internal mt7622 wifi, since it fixes adhoc and mesh point there. However, thanks for testing, you can just also try to use wpa_supplicant with
ap_scan=2
network={
ssid="OpenWrt-Bla"
mode=1
frequency=2412
key_mgmt=NONE
}
Afterwards you should be able to call that with
wpa_supplicant -i wlan0 -c [THE CONFIG]
However maybe your card is still in 5 ghz somehow? Maybe try some 5 ghz channel?
Thank you very much for testing! I hope the PR will soon be accepted and then backported to OpenWrt.
i missed firmware-files…after installing them, i don’t get the error 
apt install firmware-misc-nonfree
looks like i can now start the mesh
iw wlp1s0 set type ibss
ip link set wlp1s0 up
iw wlp1s0 ibss join bpi-mesh 2412
[ 129.828378] wlp1s0: Trigger new scan to find an IBSS to join
[ 135.274604] wlp1s0: Creating new IBSS network, BSSID 3e:4d:88:d8:1d:45
[ 135.282649] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready
[ 165.361006] wlp1s0: No active IBSS STAs - trying to scan for other IBSS networks with same SSID (merge)
now compiling kernel for r64…
root@bpi-r64:~# apt install iw
root@bpi-r64:~# iw wlan0 set type ibss
root@bpi-r64:~# ip link set wlan0 up
root@bpi-r64:~# iw wlan0 ibss join bpi-mesh 2412
root@bpi-r64:~# [ 188.468176] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
and it looks like there is no scanning anymore, seems like they are connected…
root@bpi-r64:~# iw dev wlan0 station dump
Station 00:0a:52:05:c9:e2 (on wlan0)
inactive time: 80 ms
rx bytes: 68796
rx packets: 1764
tx bytes: 0
tx packets: 0
tx retries: 0
tx failed: 0
rx drop misc: 0
signal: -38 [-38, -64, -76, -69] dBm
signal avg: -37 [-37, -64, -75, -69] dBm
tx bitrate: 1.0 MBit/s
rx duration: 0 us
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 0
beacon interval:100
connected time: 177 seconds
and it seems to work…after adding layer3 (ip address), i can ping each other
ap-mode on r2 (mt7615) and r64 (mt7622_wmac) still works
got wpa_supplicant-method also working…
/etc/wpa_supplicant/meshpoint.conf
#wpa_supplicant -i wlan0 -c config
ap_scan=2
network={
ssid="bpi-mesh"
mode=1
frequency=2412
key_mgmt=NONE
}
how to create mesh_point (with ap)?
1 Like
I could also just rewrite the patch to only check for mt7622 wifi and do there the different initialization.
@frank-w Here is a good tutorial. https://wireless.wiki.kernel.org/en/users/drivers/ath10k/mesh Just go to meshpoint.
1 Like
@frank-w I already backported the patch to OpenWrt:
In the OpenWrt Directory do:
curl https://patch-diff.githubusercontent.com/raw/openwrt/openwrt/pull/4652.patch | git am
then
./scripts/feeds update -a
and
./scripts/feeds install -a
Afterwards select under make menuconfig the BPI R64. Then, select under Network -> WirelessAPD -> wpad (and deselect this wpad-basic).
Now you can just do:
config wifi-iface 'radio0_mesh'
option device 'radio0'
option mode 'mesh'
option mesh_id 'Mesh-OpenWrt'
option mesh_fwding '0'
option network 'lan'
option encryption 'none'
and do
wifi
now you should see a mesh point.
1 Like
As i do not use openwrt,i need a generic way to test it in debian
Ah okay. I think try this wpa_supplicant config:
Okay maybe try this with wpa_supplicant?
user_mpm=1
network={
ssid="bpi-mesh"
mode=5
frequency=2412
key_mgmt=NONE
}
I think mode 5 is mesh point. Thanks a lot for testing!!!
root@bpi-r2:~# wpa_supplicant -i wlp1s0 -c /etc/wpa_supplicant/meshpoint.conf &
[1] 500
Successfully initialized wpa_supplicant
Line 3: unknown global field 'user_mpm=1'.
Line 3: Invalid configuration line 'user_mpm=1'.
Line 8: too large mode (value=5 max_value=4)
Line 8: failed to parse mode '5'.
Line 11: failed to parse network block.
Failed to read or parse configuration '/etc/wpa_supplicant/meshpoint.conf'.
iw list does not show mesh-point…maybe i need a kernel-option (MAC80211_MESH [=n],…)
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* P2P-client
* P2P-GO
iw phy phy0 interface add mesh0 type mp
command failed: Operation not supported (-95)
edit: after adding MAC80211_MESH i see mesh point and can execute the iw line…wpa_supplicant still show error
iw list | grep -i 'phy\|mesh'
Wiphy phy0
wiphy index: 0
* mesh point
* set_mesh_config
* join_mesh
* set_wiphy_netns
* #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-G
O } <= 16,
* mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90
0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* mesh point: 0xb0 0xc0 0xd0
iw phy phy0 interface add mesh0 type mp
iw mesh0 info
Interface mesh0
ifindex 16
wdev 0x2
addr 00:0a:52:05:c9:e2
type mesh point
wiphy 0
txpower 6.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytet
x-packets
0 0 0 0 0 0 0 0 0
ip addr add 192.168.80.1/24 dev mesh0
ip link set mesh0 up
wpa_supplicant -i mesh0 -c /etc/wpa_supplicant/meshpoint.conf &
[1] 504
Successfully initialized wpa_supplicant
Line 3: unknown global field 'user_mpm=1'.
Line 3: Invalid configuration line 'user_mpm=1'.
Line 8: too large mode (value=5 max_value=4)
Line 8: failed to parse mode '5'.
Line 11: failed to parse network block.
Failed to read or parse configuration '/etc/wpa_supplicant/meshpoint.conf'.
It looks like debians wpa_supplicant is compiled without mesh (like defaultconfig from gitrepo)…but i did not found yet why user_mpm is not recognized (but in source it looks like it’s part from mash)
https://w1.fi/cgit/hostap/tree/wpa_supplicant/config.c#n2527
compiled wpa_supplicant with CONFIG_MESH again and it starts, do some further tests later
[1] 503i-r2:~# ./wpa_supplicant -i mesh0 -c /etc/wpa_supplicant/meshpoint.conf
root@bpi-r2:~# Successfully initialized wpa_supplicant
mesh0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
mesh0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
mesh0: interface state UNINITIAL[ 103.530708] IPv6: ADDRCONF(NETDEV_CHANGE): my
IZED->ENABLED
mesh0: AP-ENABLED
mesh0: joining mesh bpi-mesh
mesh0: CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed [id=0 i]
mesh0: MESH-GROUP-STARTED ssid="bpi-mesh" id=0
uploaded wpa_supplicant binaries here: https://drive.google.com/file/d/1_IH6RsjCSlvBiuNUDXSLmvjkuyginoGn/view?usp=sharing
tried now mesh-point between r2+mt7615 and r64/mt7622 wifi
on R2 i got a Kernelwarning, in the moment r64 connects to the mesh-point
mesh0: mesh plink with 00:0c:43:26:60:00 established
mesh0: MESH-PEER-CONNECTED 00:0c:43:26:60:00
[ 1009.473796] ------------[ cut here ]------------
[ 1009.478485] WARNING: CPU: 1 PID: 288 at net/core/flow_dissector.c:984 __skb_4
[ 1009.487735] Modules linked in: xt_CHECKSUM nft_chain_nat xt_MASQUERADE nf_nas
[ 1009.517477] CPU: 1 PID: 288 Comm: napi/phy0-19 Not tainted 5.15.0-rc4-bpi-r21
[ 1009.524803] Hardware name: Mediatek Cortex-A7 (Device Tree)
[ 1009.530384] Backtrace:
[ 1009.532838] [<c0cb3878>] (dump_backtrace) from [<c0cb3ac0>] (show_stack+0x20)
[ 1009.540431] r7:000003d8 r6:c0a22cf8 r5:60010013 r4:c1012ecc
[ 1009.546090] [<c0cb3aa0>] (show_stack) from [<c0cb7870>] (dump_stack_lvl+0x48)
[ 1009.553673] [<c0cb7828>] (dump_stack_lvl) from [<c0cb7894>] (dump_stack+0x18)
[ 1009.561258] r5:00000009 r4:c10db094
[ 1009.564839] [<c0cb787c>] (dump_stack) from [<c0127350>] (__warn+0xfc/0x114)
[ 1009.571822] [<c0127254>] (__warn) from [<c0cb4118>] (warn_slowpath_fmt+0x74/)
[ 1009.579328] r7:c0a22cf8 r6:000003d8 r5:c10db094 r4:00000000
[ 1009.584988] [<c0cb40a8>] (warn_slowpath_fmt) from [<c0a22cf8>] (__skb_flow_d)
[ 1009.593799] r8:00000000 r7:c5c40418 r6:c5d8dd00 r5:c1306360 r4:c5adcc00
[ 1009.600502] [<c0a22afc>] (__skb_flow_dissect) from [<c0a24258>] (__skb_get_h)
[ 1009.608878] r10:c5a6c520 r9:c7329264 r8:00000074 r7:00000001 r6:c7328600 r50
[ 1009.616713] r4:c1439b78
[ 1009.619246] [<c0a241d4>] (__skb_get_hash) from [<bf1adf24>] (ieee80211_queue)
[ 1009.629519] r6:c7328600 r5:c5adcc00 r4:c5a6c520
[ 1009.634140] [<bf1ada20>] (ieee80211_queue_skb [mac80211]) from [<bf1ae18c>] )
[ 1009.645154] r10:c5a6c520 r9:c5a6c520 r8:00000074 r7:00000001 r6:c7328600 r50
[ 1009.652995] r4:c5adcc00
[ 1009.655530] [<bf1ae094>] (ieee80211_tx [mac80211]) from [<bf1af9e8>] (ieee80)
[ 1009.666705] r9:00000000 r8:00000000 r7:c5a6ca3c r6:c7328600 r5:c5a6cb84 r4:0
[ 1009.674454] [<bf1af910>] (ieee80211_tx_pending [mac80211]) from [<c012f384>])
[ 1009.685943] r10:c5d8c000 r9:00000040 r8:00000006 r7:00000000 r6:dedaa2ec r54
[ 1009.693780] r4:c5a6cc84
[ 1009.696313] [<c012f2c4>] (tasklet_action_common.constprop.0) from [<c012f3c0)
[ 1009.705908] r9:00000040 r8:00000101 r7:c14583e0 r6:00000006 r5:00000007 r4:8
[ 1009.713655] [<c012f398>] (tasklet_action) from [<c0101460>] (__do_softirq+0x)
[ 1009.721591] [<c0101318>] (__do_softirq) from [<c012ee00>] (do_softirq+0x7c/0)
[ 1009.729014] r10:c5f95820 r9:c5d8c000 r8:c10db338 r7:00000001 r6:c0a35f60 r50
[ 1009.736850] r4:60010013
[ 1009.739383] [<c012ed84>] (do_softirq) from [<c012eedc>] (__local_bh_enable_i)
[ 1009.747495] r5:ffffe000 r4:00000001
[ 1009.751070] [<c012ee04>] (__local_bh_enable_ip) from [<c0a35f8c>] (napi_thre)
[ 1009.759966] r5:c5a6e768 r4:c5d8c000
[ 1009.763541] [<c0a35ed0>] (napi_threaded_poll) from [<c014f010>] (kthread+0x1)
[ 1009.771394] r8:c5a6e768 r7:c0a35ed0 r6:c253ba6c r5:c5f95800 r4:c5fd6d40
[ 1009.778096] [<c014eeb8>] (kthread) from [<c0100130>] (ret_from_fork+0x14/0x2)
[ 1009.785333] Exception stack(0xc5d8dfb0 to 0xc5d8dff8)
[ 1009.790390] dfa0: ???????? ???????? ?????
[ 1009.798575] dfc0: ???????? ???????? ???????? ???????? ???????? ???????? ?????
[ 1009.806760] dfe0: ???????? ???????? ???????? ???????? ???????? ????????
[ 1009.813383] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r58
[ 1009.821220] r4:c5fd6d40 r3:00000017
[ 1009.824871] ---[ end trace 86a4ea831c8189bf ]---
on r64 i got same warning/trace a bit later…but i can ping over the mesh-connection
root@bpi-r64:~# ./wpa_supplicant_arm64 -i mesh0 -c /etc/wpa_supplicant/meshpoint
.conf
Successfully initialized wpa_supplicant
mesh0: interface[ 388.865305] IPv6: ADDRCONF(NETDEV_CHANGE): mesh0: link become
s ready
state UNINITIALIZED->ENABLED
mesh0: AP-ENABLED
mesh0: joining mesh bpi-mesh
mesh0: CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed [id=0 id
_str=]
mesh0: MESH-GROUP-STARTED ssid="bpi-mesh" id=0
mesh0: new peer notification for 00:0a:52:05:c9:e2
mesh0: mesh plink with 00:0a:52:05:c9:e2 established
mesh0: MESH-PEER-CONNECTED 00:0a:52:05:c9:e2
location is here:
as far as i debugged it, all 3 possible source of net are NULL
[ 104.656046] DEBUG: Passed __skb_flow_dissect 975 skb:0xc5ad9540 net:0x0
[ 104.662738] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0x0,skb-sk:0x0
any idea? where should they be set??
seems to be introduced some time ago by this commit (maybe it helps to fix):
Seems user here have similar issue…with mesh too: https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/248
And found this: https://bugs.openwrt.org/index.php?do=details&task_id=3459&pagenum=2
Looks like driver issue (there it is ath10k) where dev_alloc_skb needs to be replaced by netdev_alloc_skb including net device…but i did not found both in drivers/net/wireless/mediatek/mt76
tried changing this, without success
--- a/drivers/net/wireless/mediatek/mt76/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mcu.c
@@ -13,7 +13,8 @@ mt76_mcu_msg_alloc(struct mt76_dev *dev, const void *data,
int length = ops->headroom + data_len + ops->tailroom;
struct sk_buff *skb;
- skb = alloc_skb(length, GFP_KERNEL);
+ skb = netdev_alloc_skb(&dev->napi_dev,length);
if (!skb)
return NULL;
mhm, looks like it’s related to ip assignment…after i added an ip-adress i see skb-sk is temporarily set, but the reset to zero again. looks like at this time the trace pops up on r64
so i tried this order:
#r64
modprobe mt7615e
iw phy phy0 interface add mesh0 type mp
ip addr add 192.168.80.2/24 dev mesh0
./wpa_supplicant_arm64 -i mesh0 -c /etc/wpa_supplicant/meshpoint.conf &
#r2
iw phy phy0 interface add mesh0 type mp
ip addr add 192.168.80.1/24 dev mesh0
./wpa_supplicant -i mesh0 -c /etc/wpa_supplicant/meshpoint.conf &
while i have not started wpa_supplicant on r64, i see at least skb.dev is set…but after connection this is NULL
./wpa_supplicant -i mesh0 -c /etc/wpa_supplicant/meshpoint.conf &
root@bpi-r2:~# Successfully initialized wpa_supplicant
mesh0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
mesh0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
mesh0: interface state UNINITIAL[ 187.042877] IPv6: ADDRCONF(NETDEV_CHANGE): mesh0: link becomes ready
IZED->ENABLED
mesh0: AP-ENABLED
mesh0: joining mesh bpi-mesh
mesh0: CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed [id=0 id_str=]
mesh0: MESH-GROUP-STARTED ssid="bpi-mesh" id=0
[ 187.080740] DEBUG: Passed __skb_flow_dissect 975 skb:0xc56fe480 net:0x0
[ 187.087396] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0xc71e8000,skb-sk:0xc25c5180
[ 187.100683] DEBUG: Passed __skb_flow_dissect 975 skb:0xc5b9fc00 net:0x0
[ 187.107335] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0xc71e8000,skb-sk:0x0
[ 187.196770] DEBUG: Passed __skb_flow_dissect 975 skb:0xc5b9f600 net:0x0
[ 187.203468] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0xc71e8000,skb-sk:0xc5cf0e00
[ 187.250686] DEBUG: Passed __skb_flow_dissect 975 skb:0xc56fef00 net:0x0
[ 187.257366] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0xc71e8000,skb-sk:0xc25c5180
[ 187.280666] DEBUG: Passed __skb_flow_dissect 975 skb:0xc5b9f180 net:0x0
[ 187.287335] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0xc71e8000,skb-sk:0x0
[ 187.340723] DEBUG: Passed __skb_flow_dissect 975 skb:0xc56feb40 net:0x0
[ 187.347408] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0xc71e8000,skb-sk:0xc25c4e00
[ 187.453632] DEBUG: Passed __skb_flow_dissect 975 skb:0xc5b9f000 net:0x0
[ 187.460288] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0xc71e8000,skb-sk:0xc5cf0e00
[ 187.703625] DEBUG: Passed __skb_flow_dissect 975 skb:0xc5b9f180 net:0x0
[ 187.710287] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0xc71e8000,skb-sk:0xc5cf0e00
[ 188.360879] DEBUG: Passed __skb_flow_dissect 975 skb:0xc56fe180 net:0x0
[ 188.367609] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0xc71e8000,skb-sk:0xc25c5180
[ 188.410682] DEBUG: Passed __skb_flow_dissect 975 skb:0xc5b9f000 net:0x0
[ 188.417343] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0xc71e8000,skb-sk:0xc25c5180
[ 188.880678] DEBUG: Passed __skb_flow_dissect 975 skb:0xc5b9f180 net:0x0
[ 188.887339] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0xc71e8000,skb-sk:0xc25c5180
[ 189.240719] DEBUG: Passed __skb_flow_dissect 975 skb:0xc56fe6c0 net:0x0
[ 189.247380] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0xc71e8000,skb-sk:0xc25c5180
mesh0: new peer notification for 00:0c:43:26:60:00
mesh0: mesh plink with 00:0c:43:26:60:00 established
mesh0: MESH-PEER-CONNECTED 00:0c:43:26:60:00
[ 245.525100] DEBUG: Passed __skb_flow_dissect 975 skb:0xc5b51d80 net:0x0
[ 245.531796] DEBUG: Passed __skb_flow_dissect 977 skb-dev:0x0,skb-sk:0x0
[ 245.538421] ------------[ cut here ]------------
[ 245.543089] WARNING: CPU: 3 PID: 297 at net/core/flow_dissector.c:986 __skb_flow_dissect+0x1cc/0x152c
strange that it takes some time to appear on r64, i can trigger the trace on r64 with a ping, if i do not ping, the trace is not shown
i tried to set skb->dev to &dev->napi_dev in drivers/net/wireless/mediatek/mt76/mcu.c:mt76_mcu_msg_alloc but still got the trace 
at one point the dev is not set (maybe skb created differently)