(in-progress) Driver doesn't seem to support B.A.T.M.A.N adv setup

[MSLaaf]

The setup is loosely based as documented in B.A.T.M.A.N Advanced Quick start

Hardware: Alfa AWUS036ACH (have some other realtek devices which i will test - waiting for an MT7612U device) on Raspberry Pi 4.

Software: Centos 8, not the very latest patches in the Realtek rt8812au driver - will try them tomorrow but expect no difference.

Setup script:

#!/bin/bash 
#
if [ $# -lt 2 ]; then
   echo "$0: <wlan_interface> <bat_mesh_name>"
   exit 1
fi
# based on the open-mesh batman Quick Start Guide
# 
# setup eth0
sudo modprobe batman-adv
sudo yum install avahi-autoipd -y
sudo batctl if add eth0
sudo atctl if
# setup $1
# cannot remove and read interface as IBSS - can change it though....
sudo iw dev $1 set type ibss
sudo ip link set up mtu 1532 dev $1
sudo iw dev $1 ibss join $2 5785 HT20 fixed-freq
sudo batctl if add $1
sudo ip link set up dev bat0
sudo avahi-autoipd bat0 &
batctl if

When I run this script on two identically configured Pi's, the following happens:

[  112.490762] ------------[ cut here ]------------
[  112.498509] WARNING: CPU: 3 PID: 1649 at /var/lib/dkms/rtl8812au/5.9.3.2/build/core/rtw_cmd.c:4053 rtw_dfs_rd_en_decision+0x118/0x3f0 [8812au]
[  112.517367] Modules linked in: nft_counter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_tcpudp xt_state xt_conntrack nf_conntrack nf_defrag_ipv4 nft_compat nf_tables nfnetlink 8812au(O) bcm2835_codec(C) bcm2835_isp(C) bcm2835_v4l2(C) brcmfmac videobuf2_dma_contig v4l2_mem2mem brcmutil bcm2835_mmal_vchiq(C) videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 dwc2 videobuf2_common raspberrypi_hwmon udc_core videodev vc_sm_cma(C) mc rpivid_mem uio_pdrv_genirq uio sch_fq_codel i2c_dev batman_adv bridge stp llc mac80211 libarc4 sha256_generic libsha256 cfg80211 rfkill ip_tables x_tables ipv6 nf_defrag_ipv6 crc_ccitt
[  112.595604] CPU: 3 PID: 1649 Comm: RTW_CMD_THREAD Tainted: G        WC O      5.4.49-v8.1.el8 #1
[  112.608127] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
[  112.617651] pstate: 20000005 (nzCv daif -PAN -UAO)
[  112.626141] pc : rtw_dfs_rd_en_decision+0x118/0x3f0 [8812au]
[  112.635507] lr : rtw_dfs_rd_en_decision+0xd8/0x3f0 [8812au]
[  112.644680] sp : ffffffc01223bd10
[  112.651543] x29: ffffffc01223bd10 x28: ffffffc008f288b0 
[  112.660438] x27: 0000000000000003 x26: ffffffc00903d000 
[  112.669377] x25: 0000000000000004 x24: ffffffc0113be000 
[  112.678231] x23: ffffffc0113bd000 x22: 000000000000000e 
[  112.687141] x21: ffffff80e92087a8 x20: 00000000000000fe 
[  112.696002] x19: ffffff80e9208000 x18: 0000000000000000 
[  112.704845] x17: 0000000000000000 x16: 0000000000000000 
[  112.713685] x15: 0000000000000000 x14: 0000000000000000 
[  112.722449] x13: 0000000000000000 x12: 0000000000000000 
[  112.731217] x11: 0000000000000001 x10: 00000000000019a0 
[  112.739870] x9 : ffffffc01223b890 x8 : ffffffc01223bd80 
[  112.748521] x7 : 0000000000000000 x6 : 0000000000000001 
[  112.757203] x5 : ffffff80e142dc80 x4 : ffffffc01223bd6a 
[  112.765935] x3 : ffffffc01223bd6b x2 : ffffffc0113bd000 
[  112.774728] x1 : 00000000000000fe x0 : 0000000000000000 
[  112.783451] Call trace:
[  112.789354]  rtw_dfs_rd_en_decision+0x118/0x3f0 [8812au]
[  112.798073]  rtw_mlmeext_disconnect+0x150/0x1a0 [8812au]
[  112.806743]  disconnect_hdl+0x58/0xb8 [8812au]
[  112.814584]  rtw_cmd_thread+0x248/0x38c [8812au]
[  112.822490]  kthread+0x124/0x128
[  112.828937]  ret_from_fork+0x10/0x18
[  112.835677] ---[ end trace 8e322d2dc552c87e ]---
[  120.547318] NOHZ: local_softirq_pending 08
[  141.027706] NOHZ: local_softirq_pending 08
[  143.543924] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[  144.318876] batman_adv: bat0: Interface activated: wlan1
[  144.327626] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[  148.639578] batman_adv: bat0: Interface deactivated: wlan1
[  148.649336] ------------[ cut here ]------------

I looked at the source code, it is in where it makes a decision about the packet type - and this type isn't being handled. rtw_dfs_rd_en_decision()

it falls through to the default: case in the switch statement (it would have been nice if Realtek would have told the switch value there too - but they used just a simple macro instead of WARN_ON(flag,format...)

Don't know whether this can / should be fixed. I'll try to get a bit more data tomorrow.

[morrownr]

Interesting. I have exactly zero experience with mesh but this looks like an adventure. As time permits I will try to spin up to speed on this. You have the source so if you want to play around with it and recompile, go for it. Please post anything you discover.

[morrownr]

@MSLaaf

Ia this issue still active? Sorry for being slow but I moved and it to most my time over the last 3 months.

[MSLaaf]

Nick, it kinda is, but we've moved on to using Mediatek dongles, they support it directly, and mesh mode .. so no urgency really...

Maurice

On Sun, Aug 1, 2021, 11:20 Nick @.***> wrote:

@MSLaaf https://github.com/MSLaaf

Ia this issue still active? Sorry for being slow but I moved and it to most my time over the last 3 months.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/morrownr/8812au/issues/22#issuecomment-890557548, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH34WSMZ6FPBQ56SEWOSROTT2V67FANCNFSM42SAEPAQ .