On 08/02/2017 02:22 PM, Nick Dennis wrote:
Radio Card and Firmware:

root@njdrlk2:/sys/kernel/debug/ieee80211/phy0/ath10k# cat firmware_info
directory: ath10k/QCA988X/hw2.0
firmware:  firmware-2.bin
fwcfg:     fwcfg-pci-0000:00:00.0.txt
bus:       0000:00:00.0
version:   10.1-ct-8x-__fW-019-f466004
hw_rev:    988x

I added the line
    echo 0x0000000000003FFF > /sys/kernel/debug/ieee80211/phy0/ath10k/ct_special
towards the end of /lib/netifd/wireless/mac80211.sh for long-distance (10kM) 

This works fine for MAC types AP and client.
When the type is set to IBSS (for Batman mesh) on 2 devices, they each show an 
association to the other in iwinfo and a neighbour in batctl n. But, neither 
can ping the other, either ICMP or batctl p {mac address}.

When the line is changed to:
    echo 0x0000000000000000 > /sys/kernel/debug/ieee80211/phy0/ath10k/ct_special
and the devices rebooted, ICMP and batctl pings get responses.

Are the ID and values for this ct special  OK?

Does anyone know what the ath10k clock rate for the ACK timeout counter is so 
the ct special value can be calculated from a distance setting?

There were some patches posted some time back on the ath10k mailing list with a 
big nasty
hack to manually set the ack timeout register.  The clock rate should be 
described in it.

The CT firmware just sets the register with the specified value, and makes sure 
that the
value is (re)set when the NIC logic is reset, so it is up to user-space to use 
the correct
value.  I never actually tested that the values work at long distances, but I 
did confirm
that the register was set accordingly.

I don't know why IBSS would act differently.  One weird thing about IBSS is that
it cannot do AMSDU properly, so that is disabled by default, but I don't see 
why that would matter
for ACK timeout logic.

If you do get it working or understand it better, I'd be happy to apply a patch 
with some
notes on how to make it work at various distances (either comments or maybe a 
few lines to
the ct_special debugfs read text.


Ben Greear <gree...@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Lede-dev mailing list

Reply via email to