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 features: wmi-10.x,has-wmi-mgmt-tx,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT 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) links. 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. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
