Using ath10k for WiFi capturing non-11ac traffic

Using ath10k for WiFi capturing non-11ac traffic

[Amato Carbonara]

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

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?

Thank you,
Amato

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Michal Kazior]

On 6 April 2015 at 21:49, Amato Carbonara <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
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Amato Carbonara]

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> wrote:
> On 6 April 2015 at 21:49, Amato Carbonara <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
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Ben Greear]

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> wrote:
>> On 6 April 2015 at 21:49, Amato Carbonara <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
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


-- 
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

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

[Amato Carbonara]

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.

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> 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> wrote:
>>> On 6 April 2015 at 21:49, Amato Carbonara <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
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
>
> --
> 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

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

[Ben Greear]

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> 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> wrote:
>>>> On 6 April 2015 at 21:49, Amato Carbonara <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
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>>
>> --
>> 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
>

-- 
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

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

[Amato Carbonara]

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@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>
>> 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>
>>>> wrote:
>>>>>
>>>>> On 6 April 2015 at 21:49, Amato Carbonara <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
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>
>>>
>>> --
>>> 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
>>
>
> --
> 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

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

[Ben Greear]

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> 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>
>>> 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>
>>>>> wrote:
>>>>>>
>>>>>> On 6 April 2015 at 21:49, Amato Carbonara <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
>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>
>>
>> --
>> Ben Greear <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

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

[Adrian Chadd]

IIRC, they're thrown to the internal firmware queue for software processing.



-adrian


On 15 April 2015 at 08:41, Ben Greear <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> 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>
>>>> 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>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 6 April 2015 at 21:49, Amato Carbonara <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
>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>
>>>
>>> --
>>> Ben Greear <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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Ben Greear]

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

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

[Amato Carbonara]

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

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

[Amato Carbonara]

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