Using ath10k for WiFi capturing non-11ac traffic

Wed Apr 15 08:07:05 PDT 2015

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.

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