Using ath10k for WiFi capturing non-11ac traffic

Wed Apr 15 08:41:46 PDT 2015

On 04/15/2015 08:07 AM, Amato Carbonara wrote:
> Hi Ben,
>   I performed my captures when the WiFi adapter running the ath10k was
> not connected to the WiFi network.  In other words, the capture shows
> traffic between 2 different devices.  The ath10k device is in
> promiscuous mode and capturing all the traffic between the devices.

Yes, I did the same, and still no BlockAck action frames are captured.

Firmware has special handling for these frames, so probably it eats
them before passing on to the host.

Thanks,
Ben

> 
> On Wed, Apr 15, 2015 at 10:58 AM, Ben Greear <greearb at candelatech.com> wrote:
>>
>>
>> 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 at 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 at tieto.com>
>>>>> wrote:
>>>>>>
>>>>>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at 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 at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>
>>>>
>>>>
>>>> --
>>>> Ben Greear <greearb at candelatech.com>
>>>> Candela Technologies Inc  http://www.candelatech.com
>>>>
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
> 

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