On 03/13/2018 04:42 PM, Javier Cardona wrote:
Hi,
We have resolved this issue. I'm sharing the details in case that might help
others.
The description of the problem was accurate EXCEPT that the acks that we
observed on the sniffer were not being sent by the failed station (MAP2, in the
context of my original e-mail) but by a third station MAP3. Those Acks were
sent by MAP3 but with MAP2's address in the Transmitter Address field.
These anomalous Block Acks were sent because the MAC-ADDRESS-FILTER was
misconfigured at MAP3, which caused that station to respond to addresses
different than its own. The reasons for this misconfiguration were:
(1) in mesh (and other) mode(s), the driver creates a hidden monitor vif
along the mesh vif
(2) this second monitor vif is assigned the default mac address reported by the
firmware (arvif->mac_addr)
(3) this mac address (which the driver was getting from the pre-cal files) is
XOR'd with the mesh vif address to configure MAC-ADDRESS-FILTER
(4) once that happens, the hardware will ack all addresses that pass the
MAC-ADDRESS-FILTER. If the two mac addresses (vif->addr and arvif->mac_addr)
are very dissimilar, that will result in a storm of invalid Block Acks
We resolved the issue by patching the pre-cal data with the same address as the mesh
interface, so that vif->addr == arvif->mac_addr. This is more a workaround
than a real fix, because this misconfiguration this MAC-ADDRESS-FILTER can easily go
unnoticed. In fact, what unblocked us on this issue was switching to Candela Tech's
custom firmware and driver (ath10k-ct). This provides a nice interface to the
hardware registers:
cat /debug/ieee80211/wiphy1/ath10k/fw_regs
ath10k Target Register Dump
=================
MAC-FILTER-ADDR-L32 0xffffffff
MAC-FILTER-ADDR-U16 0x0000ffff
We would probably be still trying to solve this if Ben Greear did not point us
in the right direction.
I'm glad I could help.
Can anyone think of any reason why a monitor vdev's MAC address should be
considered when calculating the filter? I cannot imagine it should ever ACK
frames, so I think I will remove it from consideration when calculating
the filter in my ath10k-ct firmware unless someone suggests otherwise...
Thanks,
Ben
Cheers,
Javier
On 2/7/18, 2:15 PM, "Javier Cardona" <jcard...@fb.com> wrote:
Hi,
We have observed a problem where, under certain conditions, the ath10k
firmware will acknowledge frames but not send them up to the driver.
Frames are sent by a mesh access point (MAP1) to a second mesh AP (MAP2) at
MCS 9/NSS-3, which at that distance is probably marginal. Since frames get
acknlowledged by MAP2, MAP1 will not try a lower rate. But the driver at MAP2
does not receive the frames.
We have captures of this exchange for both the unsuccessful as well as the
successful case, which happens when we move MAP2 closer to MAP1. They can be
found here:
https://www.dropbox.com/sh/0or86c8vxotygdc/AABI7RmQ2nztcOBF3UDXbPUma
In both scenarios, the frames from MAP1 to MAP2 are acknowledged, as
observed in sniffer captures.
In the successful scenario, the driver logs show the frames being received
by the driver. Sequence numbers in the debug logs match those in the sniffer
captures.
root@nbg-3ed9da:~# journalctl -kf | grep "peer 60:31:97:3e:82:e6" | grep
ucast | grep 'len 374'
Feb 05 05:43:31 nbg-3ed9da kernel: ath10k_pci 0000:01:00.0: rx skb d734f6c0
len 374 peer 60:31:97:3e:82:e6 tid 0 (BE) ucast sn 1027 vht sgi rate_idx 9
vht_nss 3 freq 5825 band 1 flag 0x600800 fcs-err 0 mic-err 0 amsdu-more 0
Feb 05 05:43:42 nbg-3ed9da kernel: ath10k_pci 0000:01:00.0: rx skb d6aaa480
len 374 peer 60:31:97:3e:82:e6 tid 0 (BE) ucast sn 1031 vht sgi rate_idx 9
vht_nss 3 freq 5825 band 1 flag 0x600800 fcs-err 0 mic-err 0 amsdu-more 0
Feb 05 05:43:53 nbg-3ed9da kernel: ath10k_pci 0000:01:00.0: rx skb d53a8d80
len 374 peer 60:31:97:3e:82:e6 tid 0 (BE) ucast sn 1037 vht sgi rate_idx 9
vht_nss 3 freq 5825 band 1 flag 0x600800 fcs-err 0 mic-err 0 amsdu-more 0
In the failure scenario, the driver logs show no frames, even if the
capture shows that the frames are acknowledged.
root@nbg-3ed9da:~# journalctl -kf | grep "peer 60:31:97:3e:82:e6" | grep
ucast | grep 'len 374'
<nothing here>
If we force MAP1 to use a single stream, the frames are received
successfully.
# iw mesh0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-9
It seems as if the firmware is acknowledging but silently discarding
frames… is that possible?
Can anyone provide some pointers on how to troubleshoot this?
We are using this firmware:
https://github.com/kvalo/ath10k-firmware/blob/master/QCA9984/hw1.0/3.4/firmware-5.bin_10.4-3.4-00104
and kernel 4.9.31 with a few cherry-picked patches from the ath10k branch.
The hardware is QCA994.
Best,
Javier
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
