You could try to reproduce on debian
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.
which kernel do you use atm? is 5.4/5.10 working?
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.
So all kernel versions are affected,no one is working,right? Then i guess it’s simply not implemented
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 ?
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
Do you still think that it is not implemented in the driver ?
If not, do you have an idea where I can look into to solve this issue ?
I think driver is missing this part…i don’t know where iw get the information about “mesh point”
I see some mesh_point references. Have you added this option?
In main.c mesh seems handled like normal AP
Yes,
it is included in the kmod-mac80211
package:
.config - OpenWrt Configuration
> Kernel modules > Wireless Drivers > Search (CONFIG_MAC80211_MESH)
┌──────────────────────────────────────────────────────────────────────────────────────────────────────── Search Results ─────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Symbol: PACKAGE_MAC80211_MESH [=y] │
│ Type : bool │
│ Defined at tmp/.config-package.in:21883 │
│ Prompt: Enable 802.11s mesh support │
│ Depends on: PACKAGE_kmod-mac80211 [=y] │
│ Location: │
│ -> Kernel modules │
│ -> Wireless Drivers │
│ (1) -> kmod-mac80211..................... Linux 802.11 Wireless Networking Stack (PACKAGE_kmod-mac80211 [=y]) │
│
Mhm,i guess the ifdef i linked above only tells iw that mesh is supported…but i do not see that driver handles mesh anyhow in hardware (set any bit in any hardware register)
I’m sure that the driver has issues with starting a mesh. They don’t send any beacons out. However, I still see ipv6 link local traffic when opening a monitor mode on a different device.
I had the time to debug today and finally wrote my first rfc-upstream-commit.
https://lore.kernel.org/linux-wireless/[email protected]/T/#u
Mesh works with this?
Congratulation to your fist patch submission
Small note…Fixes-tag needs to be directly above signed-off
Thanks! It works. You can try it here: https://github.com/openwrt/openwrt/pull/4652
I also updatet there the Patch. I think I will resend it via mailinglist with the correct Fixes: ...
position.
@frank-w Here it is correct, or? https://github.com/openwrt/openwrt/pull/4652/files#diff-ce1668220610e9a21eba50965aef387a3e87b8475d010ce209f822e6bc884344R27
yes now it’s right…
edit: have now added it to my 5.15-rc tree
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).