Using ath10k for WiFi capturing non-11ac traffic
Amato Carbonara
acarbonara13 at gmail.com
Thu Apr 16 06:16:21 PDT 2015
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 at 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 at candelatech.com <mailto:greearb at 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 at candelatech.com <mailto: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 <mailto: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 <mailto:michal.kazior at tieto.com>>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at gmail.com <mailto: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 <mailto:ath10k at lists.infradead.org>
>> >>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>> >>>> Candela Technologies Inc http://www.candelatech.com
>> >>>>
>> >>>
>> >>> _______________________________________________
>> >>> ath10k mailing list
>> >>> ath10k at lists.infradead.org <mailto:ath10k at lists.infradead.org>
>> >>> http://lists.infradead.org/mailman/listinfo/ath10k
>> >>>
>> >>
>> >> --
>> >> Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>> >> Candela Technologies Inc http://www.candelatech.com
>> >
>>
>>
>> --
>> Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>> Candela Technologies Inc http://www.candelatech.com
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
More information about the ath10k
mailing list