* Using ath10k for WiFi capturing non-11ac traffic @ 2015-04-06 19:49 Amato Carbonara 2015-04-14 5:38 ` Michal Kazior 0 siblings, 1 reply; 12+ messages in thread From: Amato Carbonara @ 2015-04-06 19:49 UTC (permalink / raw) To: ath10k 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using ath10k for WiFi capturing non-11ac traffic 2015-04-06 19:49 Using ath10k for WiFi capturing non-11ac traffic Amato Carbonara @ 2015-04-14 5:38 ` Michal Kazior 2015-04-14 18:04 ` Amato Carbonara 0 siblings, 1 reply; 12+ messages in thread From: Michal Kazior @ 2015-04-14 5:38 UTC (permalink / raw) To: Amato Carbonara; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using ath10k for WiFi capturing non-11ac traffic 2015-04-14 5:38 ` Michal Kazior @ 2015-04-14 18:04 ` Amato Carbonara 2015-04-15 0:19 ` Ben Greear 0 siblings, 1 reply; 12+ messages in thread From: Amato Carbonara @ 2015-04-14 18:04 UTC (permalink / raw) To: Michal Kazior; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using ath10k for WiFi capturing non-11ac traffic 2015-04-14 18:04 ` Amato Carbonara @ 2015-04-15 0:19 ` Ben Greear 2015-04-15 14:28 ` Amato Carbonara 0 siblings, 1 reply; 12+ messages in thread From: Ben Greear @ 2015-04-15 0:19 UTC (permalink / raw) To: Amato Carbonara; +Cc: Michal Kazior, ath10k 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using ath10k for WiFi capturing non-11ac traffic 2015-04-15 0:19 ` Ben Greear @ 2015-04-15 14:28 ` Amato Carbonara 2015-04-15 14:58 ` Ben Greear 0 siblings, 1 reply; 12+ messages in thread From: Amato Carbonara @ 2015-04-15 14:28 UTC (permalink / raw) To: Ben Greear; +Cc: Michal Kazior, ath10k 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using ath10k for WiFi capturing non-11ac traffic 2015-04-15 14:28 ` Amato Carbonara @ 2015-04-15 14:58 ` Ben Greear 2015-04-15 15:07 ` Amato Carbonara 0 siblings, 1 reply; 12+ messages in thread From: Ben Greear @ 2015-04-15 14:58 UTC (permalink / raw) To: Amato Carbonara; +Cc: Michal Kazior, ath10k 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using ath10k for WiFi capturing non-11ac traffic 2015-04-15 14:58 ` Ben Greear @ 2015-04-15 15:07 ` Amato Carbonara 2015-04-15 15:41 ` Ben Greear 0 siblings, 1 reply; 12+ messages in thread From: Amato Carbonara @ 2015-04-15 15:07 UTC (permalink / raw) To: Ben Greear; +Cc: Michal Kazior, ath10k 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using ath10k for WiFi capturing non-11ac traffic 2015-04-15 15:07 ` Amato Carbonara @ 2015-04-15 15:41 ` Ben Greear 2015-04-15 16:16 ` Adrian Chadd [not found] ` <CAOt_L3-N8eaZpKzTHny9KSZxxAgvHFk0t2MpcgMkmE5DdEGrpA@mail.gmail.com> 0 siblings, 2 replies; 12+ messages in thread From: Ben Greear @ 2015-04-15 15:41 UTC (permalink / raw) To: Amato Carbonara; +Cc: Michal Kazior, ath10k 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using ath10k for WiFi capturing non-11ac traffic 2015-04-15 15:41 ` Ben Greear @ 2015-04-15 16:16 ` Adrian Chadd [not found] ` <CAOt_L3-N8eaZpKzTHny9KSZxxAgvHFk0t2MpcgMkmE5DdEGrpA@mail.gmail.com> 1 sibling, 0 replies; 12+ messages in thread From: Adrian Chadd @ 2015-04-15 16:16 UTC (permalink / raw) To: Ben Greear; +Cc: Amato Carbonara, ath10k, Michal Kazior 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <CAOt_L3-N8eaZpKzTHny9KSZxxAgvHFk0t2MpcgMkmE5DdEGrpA@mail.gmail.com>]
* Re: Using ath10k for WiFi capturing non-11ac traffic [not found] ` <CAOt_L3-N8eaZpKzTHny9KSZxxAgvHFk0t2MpcgMkmE5DdEGrpA@mail.gmail.com> @ 2015-04-15 19:34 ` Ben Greear 2015-04-16 13:16 ` Amato Carbonara 0 siblings, 1 reply; 12+ messages in thread From: Ben Greear @ 2015-04-15 19:34 UTC (permalink / raw) To: Amato Carbonara; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using ath10k for WiFi capturing non-11ac traffic 2015-04-15 19:34 ` Ben Greear @ 2015-04-16 13:16 ` Amato Carbonara 2015-04-23 15:12 ` Amato Carbonara 0 siblings, 1 reply; 12+ messages in thread From: Amato Carbonara @ 2015-04-16 13:16 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using ath10k for WiFi capturing non-11ac traffic 2015-04-16 13:16 ` Amato Carbonara @ 2015-04-23 15:12 ` Amato Carbonara 0 siblings, 0 replies; 12+ messages in thread From: Amato Carbonara @ 2015-04-23 15:12 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-04-23 15:12 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-06 19:49 Using ath10k for WiFi capturing non-11ac traffic Amato Carbonara
2015-04-14 5:38 ` Michal Kazior
2015-04-14 18:04 ` Amato Carbonara
2015-04-15 0:19 ` Ben Greear
2015-04-15 14:28 ` Amato Carbonara
2015-04-15 14:58 ` Ben Greear
2015-04-15 15:07 ` Amato Carbonara
2015-04-15 15:41 ` Ben Greear
2015-04-15 16:16 ` Adrian Chadd
[not found] ` <CAOt_L3-N8eaZpKzTHny9KSZxxAgvHFk0t2MpcgMkmE5DdEGrpA@mail.gmail.com>
2015-04-15 19:34 ` Ben Greear
2015-04-16 13:16 ` Amato Carbonara
2015-04-23 15:12 ` Amato Carbonara
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.