attempting mesh on ath10k

[Bob Copeland]

[trimmed CC to list]

On Sun, Jul 12, 2015 at 10:25:32AM -0400, Bob Copeland wrote:
> It looks like unicast self-protected action frames (peering) works fine, but
> broadcast multihop action frames (PREQs) never go over the air.  Does
> this sound familiar to anyone?

Actually, it's any group addressed frame.  I tried playing with various
values for htt_data_tx_ext_tid as well as just using the tid on the frame
(in mesh group addressed frames still have a qos header with tid=0).

[  662.170000] XXX htt tx completion msdu_id 0 discard 0 no_ack 0 success 1
[  662.470000] XXX tx seq: 264 txmode 0
[  662.470000] XXX htt tx flags0 5 flags1 3136 len 39 id 0 frags_paddr 07337028, msdu_paddr 06513e2e vdev 0 tid 17 freq 0
[  662.480000] XXX htt tx completion msdu_id 0 discard 0 no_ack 0 success 1
[  662.600000] XXX tx seq: 265 txmode 0
[  662.600000] XXX htt tx flags0 5 flags1 2048 len 156 id 0 frags_paddr 07337028, msdu_paddr 06932028 vdev 0 tid 0 freq 0
[  662.620000] XXX tx seq: 266 txmode 0
[  662.620000] XXX htt tx flags0 5 flags1 2048 len 116 id 1 frags_paddr 07337000, msdu_paddr 06921028 vdev 0 tid 0 freq 0
[  662.630000] XXX htt tx completion msdu_id 0 discard 0 no_ack 1 success 0
[  662.640000] XXX htt tx completion msdu_id 1 discard 0 no_ack 1 success 0
[  663.090000] XXX tx seq: 267 txmode 0

The 'success 1' ones are unicast, the success 0 are mcast (in this case
using the frame's tid, otherwise it would be 16.)

Kind of odd that it's not working, since my earlier snapshot worked...
I guess at worst I can bisect compat-wireless versions but that will
take some time.

-- 
Bob Copeland %% http://bobcopeland.com/