Re: Using ath10k for WiFi capturing non-11ac traffic

[Ben Greear <greearb@candelatech.com>]

On 04/15/2015 07:28 AM, Amato Carbonara wrote:
> Hi Ben,
>    I have done numerous captures using the ath10k driver on different
> 802.11 variant networks, specifically 802.11n (20MHz and 40MHz) and
> 802.11ac.  In all these captures, I have captured the Block-Ack frames
> (Wireshark filter wlan.fc.type_subtype == 0x0019), but do not see any
> Block-ACK Request or Response frames.  In fact, none of my captures
> using the ath10k drivers show any Action frames (Wireshark filter
> wlan.fc.type_subtype == 0x000d).  This is very peculiar since the IEEE
> specification 802.11-2012 section 9.21.2 states: "If the intended
> recipient STA is capable of participating, the originator sends an
> ADDBA Request frame".  Therefor, the ADDBA must be sent in order for
> Block-Acks to occur.  I have also noticed missing Association Response
> frames from the STA.
>
> Currently, I am using firmware 10.1.467.2-1 to perform my captures.

I think the ath10k firmware must just consume the block-ack request/response frames internally and
never send them up to the host.  It does send an htt message about blockack control messages being
received.

Probably something I could fix in my 10.1 firmware...but first I need to
figure out why ath9k (mac80211 stack, actually) ignores the block-ack messages that my ibss ath10k
interface sends....

Thanks,
Ben

>
> Has anyone else tried using a different firmware version, for example
> 10.2.4, to perform WiFi captures?
>
> On Tue, Apr 14, 2015 at 8:19 PM, Ben Greear <greearb@candelatech.com> wrote:
>> Out of curiosity, have you been able to capture Action frames (specifically,
>> block-ack add/del frames) with ath10k?  I just wasted a large amount of time wondering
>> why the frames are not seen...but ath9k monitor port sees them just fine.
>>
>> Thanks,
>> Ben
>>
>>
>> On 04/14/2015 11:04 AM, Amato Carbonara wrote:
>>> Hello Michal,
>>>    I was able to decrypt all traffic types (11a, 11n at 20MHz, 11n at
>>> 40MHz and 11ac at 80MHz) using the 10.1.467.2-1 firmware on the
>>> QCA9880 chipset.  The problem was not with Wireshark.  I had to
>>> install backports for the at10k drivers to make it work.  Procedures
>>> are documented here:
>>> https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/backports
>>>
>>> Thank you for your help,
>>> Amato
>>>
>>> On Tue, Apr 14, 2015 at 1:38 AM, Michal Kazior <michal.kazior@tieto.com> wrote:
>>>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13@gmail.com> wrote:
>>>>> Hello,
>>>>>    I have installed a WiFi adapter with the Qualcomm-Atheros QCA-9880
>>>>> chipset using the at10k drivers.  I am using this WiFi adapter to
>>>>> capture WLAN traffic.  The recommended firmware for capturing WiFi
>>>>> traffic is 10.1.467.2-1 per the website.  See following link:
>>>>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor
>>>>
>>>> Generally the 10.x line is preferred for sniffing. You could also try 10.2.4.
>>>>
>>>>
>>>>> I have successfully installed the above firmware and have been using
>>>>> the adapter/driver to capture and decrypt all 802.11ac traffic.
>>>>> However, I have noticed some strange behavior when trying to decrypt
>>>>> other types of traffic such as:
>>>>>    1) 802.11a = not able to decrypt any traffic
>>>>>    2) 802.11n at 20MHz = able to decrypt only partial traffic
>>>>>    3) 802.11n at 40MHz = able to decrypt only partial traffic
>>>>>
>>>>> I have tried using the different "iw" and "iwconfig" commands to set
>>>>> the frequency and channel bandwidth (for example, iw dev wlan1 set
>>>>> freq 5180 HT20).  Has anyone else seen this issue of not being able to
>>>>> decrypt all/some of the WiFi traffic?
>>>>
>>>> `iwconfig` is an old program. You shouldn't use it. Just stick with `iw`.
>>>>
>>>> To decrypt traffic you need to see keying handshake (both after
>>>> association and later for each rekeying). If sniffer misses that you
>>>> won't be able to decipher data either from the start or you'll stop
>>>> being able to decrypt multicast data after GTK rekeying.
>>>>
>>>> Another thing is I've had numerous random problems with wireshark
>>>> refusing to decrypt frames reliably. I recall some older version would
>>>> get stuck and need the key configuration (in preferences window) to be
>>>> re-applied or the decrypt checkbox to be re-checked. YMMV.
>>>>
>>>>
>>>> Michał
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>

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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k