Re: Network stops passing traffic randomly

[Steve Newcomb <srn@coolheads.com>]

On 5/28/20 3:19 PM, Sven Eckelmann wrote:
> On Thursday, 28 May 2020 21:03:20 CEST Steve Newcomb wrote:
>> I have seen Sven's remark about unicast packets.  I'm not sanguine about
>> getting Qualcomm to fix a driver for an older product.
> I am slightly confused now about the mentioning of the candelatech driver.
>
> Just to sync both of you up:
>
> * Are you using ath10k-ct with the ath10k-firmware*-ct or are you using ath10k
>    with the ath10k-firmware*?
> * And are you using IBSS or 802.11s (meshpoint with mesh_fwding=0)? Is this
>    encrypted or not encrypted?
Speaking only for myself:

CONFIG_PACKAGE_ath10k-firmware-qca988x=y
CONFIG_PACKAGE_kmod-ath10k=y
# CONFIG_PACKAGE_ath10k-firmware-qca988x-ct is not set
# CONFIG_PACKAGE_kmod-ath10k-ct is not set

option mesh_fwding '0'
option encryption 'psk2+ccmp'

>
>> The Candela
>> Technologies driver refuses to function on the DFS channels (100, 116,
>> 132), which in my large, populous US residential environment work far,
>> far better than channels 36 or 149.
> Was this reported to Ben Greear?
Not yet, no.  I am planning to do that when I can get serious about 
testing the adhoc alternative.  I tried it just long enough to discover 
that DFS didn't work (log message was something like "forbidden" (can't 
remember exactly what it said right now, but that was the sense of it), 
although I had specified country 'US' and the driver seemed to be aware 
of the corresponding hex code.  No such log message appeared when 
channel was 36 or 149.  I said to myself: hmmm, at least the QCA driver 
*sort-of* works in my environment and returned to it.
>
> Kind regards,
> 	Sven