IBSS mesh and client mode doesn't work in parallel with ath10k-ct

[oliver]

After the general 5GHz wifi problems with AC7 and 2018.1.1+bremen1 firmware were solved (in #1561), we found out that meshing on 5GHz still does not work.

This affects all FFHB 2018.1 firmwares so far, and has (only) been tested on Archer C7 v2 so far.

Symptoms are that a 5GHz-only device (eg. CPE510) does not create a working wifi mesh connection to the AC7.

Example device: http://og-ac7-testing-2.nodes.ffhb.de (https://map.ffhb.de/#!/en/map/f4f26d70b277).
The AC7 is in the same room as a CPE510 (https://map.ffhb.de/#!/en/map/c4e984b0a84a) and a WDR3600 (https://map.ffhb.de/#!/en/map/c4e984d5138e), both with 2017.1.8+bremen1 (ie. stable) firmware.
The Stable-FW devices are meshing nicely. The AC7 is meshing only via 2.4GHz. As result, the WDR3600 meshes with both other devices while the CPE510 meshes only with WDR3600.

Interestingly the devices appear to see each other via IBSS, but still don't get a mesh connection working:

root@cpe510-og-1:~# iw dev ibss0 station dump
Station aa:85:d3:37:f0:5e (on ibss0)
	inactive time:	0 ms
	rx bytes:	167231521
	rx packets:	1267310
	tx bytes:	15690420
	tx packets:	65650
	tx retries:	2531
	tx failed:	0
	rx drop misc:	0
	signal:  	-58 [-60, -62] dBm
	signal avg:	-59 [-61, -63] dBm
	tx bitrate:	144.4 MBit/s MCS 15 short GI
	rx bitrate:	144.4 MBit/s MCS 15 short GI
	expected throughput:	46.875Mbps
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
	DTIM period:	0
	beacon interval:100
	short slot time:yes
	connected time:	5629 seconds
Station 0e:9e:42:44:91:aa (on ibss0)
	inactive time:	30 ms
	rx bytes:	73632280
	rx packets:	567327
	tx bytes:	0
	tx packets:	0
	tx retries:	0
	tx failed:	0
	rx drop misc:	0
	signal:  	-61 [-63, -65] dBm
	signal avg:	-60 [-63, -63] dBm
	tx bitrate:	6.0 MBit/s
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
	DTIM period:	0
	beacon interval:100
	short slot time:yes
	connected time:	2544 seconds

Nothing strange in batctl if:

root@og-ac7-testing-2:~# batctl if
mesh-vpn: active
ibss1: active
ibss0: active
primary0: active

I'm AFK now for a while; will post dmesg etc. later, but there's not much to see there. What info would be useful to debug this?

[mweinelt]

Please post the output of batctl n

[oliver]

root@og-ac7-testing-2:~# batctl n
Error - no valid command or debug table specified: n
[...]
root@og-ac7-testing-2:~# batctl -v
batctl 2013.4.0 [batman-adv: 2013.4.0]

[oliver]

Various command results of an AC7 v2 with 2018.1.1+bremen2:

• dmesg: dmesg.og-ac7-testing-2.txt
• iw dev: iw-dev.og-ac7-testing-2.txt
• iw list: iw-list.og-ac7-testing-2.txt

Command results of another AC7 v2 with (edit) 2017.1.8+bremen1:

• dmesg: dmesg-2017.1.8.5ghztestnode.txt
• iw dev: iw-dev.2017.1.8.5ghztestnode.txt
• iw list is exactly identical between 2018.1.1+bremen2 and 2017.1.8+bremen1

[oliver]

root@og-ac7-testing-2:~# modinfo batman-adv
module:		/lib/modules/4.4.153/batman-adv.ko
version:	2013.4.0
description:	B.A.T.M.A.N. advanced
author:		Marek Lindner <lindner_marek@yahoo.de>, Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
license:	GPL
depends:	

root@og-ac7-testing-2:~# lsmod | grep batman
batman_adv            106595  0 

root@og-ac7-testing-2:~# lsmod | wc -l
18

On 2018.1.1+bremen2 there are 18 modules loaded; on 2017.1.8+bremen1 there are 117 modules loaded! This is probably related to #1580, but I don't know whether it actually causes these problems.

Anyway, here's lsmod output for old and new firmware:

• lsmod.2017.1.8.5ghztestnode.txt
• lsmod.og-ac7-testing-2.txt

[mweinelt]

On 2018.1.1+bremen2 there are 18 modules loaded; on 2017.1.8+bremen1 there are 117 modules loaded! This is probably related to #1580, but I don't know whether it actually causes these problems.

Sounds like it. Please retry with the latest v2018.1.x commit and report back if that fixes the issue.

[neocturne]

The low number of loaded module is expected, we started building as much as possible into the kernel.

[neocturne]

To check whether the issue is in ath10k or in batadv, try if a simple ping (over IPv6 link-local) on ibss0 works.

Unfortunately, the logs don't show anything unusual. Does the issue only occur between ath9k and ath10k devices, or is it reproducible with two ath10k devices as well?

[neocturne]

One more thing to test: Since v2018.1, we set the htmode of 11ac devices to 'VHT20' in /etc/config/wireless, in older versions, it was always set to 'HT20'.

[blocktrron]

rx_bitrate is missing on iw dev ibss0 station dump, this may be a hint.

[oliver]

(sorry for the silence on my side, I'm not online a lot at the moment and will probably get to this issue in 2019. Thanks for the comments, I will try these hints)

[rotanid]

@oliver we will close this ticket now. feel free to reopen as soon as you can provide additional information like requested

[oszilloskop]

Same behavior with Gluon 2018.1.3 in combination with ibss, an Ubiquiti Loco M5 XW and an Ubiquiti UniFi-AC-MESH are here.

Hint:
rx_bitrate are missing at both devices after iw dev ibss0 station dump.
tx_bitrate are at both just 6.0 MBit/s (same as oliver's).

Our sites are here: https://github.com/freifunk-ffm/site-ffffm/tree/test