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

[Amato Carbonara <acarbonara13@gmail.com>]

Hello,
  I recently upgraded to the latest ath10k firmware 10.2.4.48 and
performed a WiFi capture.  The capture still does not include
Association Request from the STA, no Action Frames and no AMPDU
frames.  This was the same issue as observed on firmware 10.1.467.2-1

On Thu, Apr 16, 2015 at 9:16 AM, Amato Carbonara <acarbonara13@gmail.com> wrote:
> Also confirmed from my captures.  No AMPDU frames captured using
> ath10k driver.  Using another WiFi adapter and driver, AMPDU frames
> were captured.
>
> On Wed, Apr 15, 2015 at 3:34 PM, Ben Greear <greearb@candelatech.com> wrote:
>> Here's another funny thing I just noticed.
>>
>> When trying to capture high-speed IBSS traffic, I get almost no data packets
>> at all delivered...maybe because the are A-MPDU or something like that and are
>> too big?
>>
>> Anyway, curious if you have tried high-speed captures in networks with block-ack
>> and a-mpdu enabled....
>>
>> Thanks,
>> Ben
>>
>>
>> On 04/15/2015 08:46 AM, Amato Carbonara wrote:
>>> Thanks Ben. I plan to upgrade to latest ath10k firmware and retest. I need to find some time to experiment.
>>>
>>> On Apr 15, 2015 11:41 AM, "Ben Greear" <greearb@candelatech.com <mailto:greearb@candelatech.com>> wrote:
>>>
>>>     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@candelatech.com <mailto:greearb@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@candelatech.com <mailto: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 <mailto:michal.kazior@tieto.com>>
>>>     >>>>> wrote:
>>>     >>>>>>
>>>     >>>>>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13@gmail.com <mailto: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 <mailto:ath10k@lists.infradead.org>
>>>     >>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>     >>>>>
>>>     >>>>
>>>     >>>>
>>>     >>>> --
>>>     >>>> Ben Greear <greearb@candelatech.com <mailto:greearb@candelatech.com>>
>>>     >>>> Candela Technologies Inc  http://www.candelatech.com
>>>     >>>>
>>>     >>>
>>>     >>> _______________________________________________
>>>     >>> ath10k mailing list
>>>     >>> ath10k@lists.infradead.org <mailto:ath10k@lists.infradead.org>
>>>     >>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>     >>>
>>>     >>
>>>     >> --
>>>     >> Ben Greear <greearb@candelatech.com <mailto:greearb@candelatech.com>>
>>>     >> Candela Technologies Inc  http://www.candelatech.com
>>>     >
>>>
>>>
>>>     --
>>>     Ben Greear <greearb@candelatech.com <mailto:greearb@candelatech.com>>
>>>     Candela Technologies Inc  http://www.candelatech.com
>>>
>>
>>
>> --
>> 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