Re: Fail to Capture QOS data packets in Monitoring mode - QCA988x
rajjoshi at comp.nus.edu.sg
Mon Jul 25 19:07:45 PDT 2016
The following may not necessarily be your case. But since you
mentioned MGMT and CTRL packets are captured and not QoS data packets,
I observed a similar behavior when my configuration was as below:
* Sender: Operating 80Mhz dynamic channel width (secondary channel
either above or below primary channel, doesn't matter)
* Sniffer: Operating on 80MHz width. However, the sniffer's primary
channel doesn't overlap with the sender's primary channel; basically
they have different primary channels.
It is necessary that the primary channels of the sender and the
sniffer match. Otherwise, the sniffer is able to only see the non-HT
duplicate frames sent by the sender. This is because those frames are
sent on all the four 20MHz channels, one of which is your sniffer's
I am not sure if the greenfield configuration could be a culprit here.
But you might want to check the above first :)
On Tue, Jul 26, 2016 at 9:43 AM, sdhrtht <sdhrtht at outlook.com> wrote:
> ath10k monitor failing to capture data packets with WMM enabled on AP.
> AP Status: (when no QOS data Packets. MGMT and CTRL Packets are able to
> 1) 0x03 (3) - Secondary channel is below Primary
> 2) 1 - any Channel width in secondary channel width
> 3) 1 - Use of RIFS permitted
> 4) 0x02 - Only HT STAs in the BSS, however there exists at least on 20Mhz
> 5) 0 - all Associated HT STAs are greenfield capable
> Tested with latest CT and non-CT firmware's.
> ath10k mailing list
> ath10k at lists.infradead.org
More information about the ath10k