Using ath10k for WiFi capturing non-11ac traffic
Ben Greear
greearb at candelatech.com
Wed Apr 15 12:34:32 PDT 2015
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