From zefir.kurtisi at neratec.com  Wed Apr  1 03:04:33 2015
From: zefir.kurtisi at neratec.com (Zefir Kurtisi)
Date: Wed, 01 Apr 2015 12:04:33 +0200
Subject: [PATCH] ath: use PRI value given by spec for fixed PRI
In-Reply-To: <55198EA4.1010101@codeaurora.org>
References: <1427475590-2198-1-git-send-email-poh@qca.qualcomm.com>
 <55191D89.2000300@neratec.com> <55198EA4.1010101@codeaurora.org>
Message-ID: <551BC2B1.3030002@neratec.com>

On 03/30/2015 07:57 PM, Peter Oh wrote:
> 
> On 03/30/2015 02:55 AM, Zefir Kurtisi wrote:
>> [...]
>> That's why I believe we need to
>> be very cautious when changing it to fix / improve minor issues.
> This patch is not for minor fix.
> Current DFS detector fails on Japan W53 band which requires at least 50% of data
> traffic during DFS certificate.
> So this patch should apply to both of 9k and 10k.

That is the core of my concern: you add changes to fix FCC/JP, which at the same
time also affects ETSI.

Our company (and maybe others) got ath9k certified for ETSI, and any potential
change to the detector relevant for that domain would essentially require to
re-certify.

There were several patches lately added to the detector that were isolated to
specific domains (like the recent updates for FCC pattern 1) which I knew won't
affect the ETSI detector performance, since they touched only the FCC
configuration but not the algorithm itself. This patch does, and that's why I need
to point out that doing so might void certification efforts out there.

Unfortunately, I have no good idea how to cope with it. Freezing the driver at the
certified state is no option, since we all want to evolve. Having multiple copies
of the detector for each regulatory domain would be an option (and essentially
will happen since FCC/JP can't be covered by PRI detectors only), but gives
unacceptable code duplication. Ideally we would fully separate algorithm from
configuration and leave the algorithm untouched ever after, not sure how doable,
though.


As for your patch at hand, I tested it for ETSI and it does not change detector
performance, therefore (please replace 16 with PRI_TOLERANCE in the macro)

Acked-by: Zefir Kurtisi <zefir.kurtisi at neratec.com>


From michal.kazior at tieto.com  Wed Apr  1 05:38:13 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 1 Apr 2015 14:38:13 +0200
Subject: [PATCH v2 2/2] ath10k: implement more versatile set_bitrate_mask
In-Reply-To: <1427798961-7334-3-git-send-email-michal.kazior@tieto.com>
References: <1427798961-7334-1-git-send-email-michal.kazior@tieto.com>
 <1427798961-7334-3-git-send-email-michal.kazior@tieto.com>
Message-ID: <CA+BoTQmhEf3fZSo2FPFbXa=Uc4ia0Sg2SD89gceyc8O+jVJeUg@mail.gmail.com>

On 31 March 2015 at 12:49, Michal Kazior <michal.kazior at tieto.com> wrote:
> Until now only a single fixed tx rate or nss was
> allowed to be set.
>
> The patch attempts to improve this by allowing
> most bitrate masks. The limitation is VHT MCS
> rates cannot be expressed separately and only the
> following VHT MCS ranges are supported: none, 0-7,
> 0-8, and 0-9.
>
> This keeps the old behaviour when requesting
> single tx rate or single nss. The new bitrate mask
> logic is only applied to other cases that would
> return -EINVAL until now.
>
> Depending on firmware revisions some combinations
> may crash firmware so use with care, please.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
> ---

Hi Kalle,

Drop this patch ([2/2]) for now, please. It looks like it doesn't work
well with crypto networks. I'll need to rework this. The [1/2] is fine
as it is though.


Micha?


From jhihn at gmx.com  Wed Apr  1 07:20:47 2015
From: jhihn at gmx.com (Jason H)
Date: Wed, 1 Apr 2015 16:20:47 +0200
Subject: QCA6174 hw2.1?
In-Reply-To: <trinity-b1ca9c09-4b5d-4cd4-8a8b-bd61df2a40c4-1427119021325@3capp-mailcom-lxa02>
References: <trinity-78717edb-041b-4b77-8173-d7ba2ac3aeea-1426969886147@msvc024>, 
 <CA+BoTQkAckpbgTKg=9+ea5Me0m9=FO3aMU=qYHmX0Y96KubKeA@mail.gmail.com>,
 <trinity-b1ca9c09-4b5d-4cd4-8a8b-bd61df2a40c4-1427119021325@3capp-mailcom-lxa02>
Message-ID: <trinity-9d575602-c6d3-49a6-9c64-0370c705f590-1427898046917@3capp-mailcom-lxa02>



> Sent: Monday, March 23, 2015 at 9:57 AM
> > Sent: Monday, March 23, 2015 at 4:23 AM
> >
> > On 21 March 2015 at 21:31,  <jhihn at gmx.com> wrote:
> > > is there anyway you could process these files for me?. I would be willing to send you the files and go through some back and forth of feedback and whatnot. The issue is I just don't think I have the time or the expertise to devote to this. However I investigated exchanging  the laptop to get a  Linux compatible one, but its going to cost me money for the restocking fee. On top of that the next user of this laptop will be disgruntled when they find a non working copy of Linux on it. I investigated getting the restore cd but Lenovo's charging $70 for the media. So if you could help I would really appreciate it because this is the last thing that I need to get working but I really need it.
> > >
> > > and we could also get this chipset supported. I saw I wasn't the only one looking for Linux support for this driver.
> > 
> > Thanks for willing to help. However I finally got my hands on the
> > Killer 1525 card. I tried playing with it but I couldn't get ath10k to
> > work with it yet.
> > 
> > There's some firmware crash issue that needs investigating. Kalle's
> > doing his best to sort this out internally.
> > 
> > Hopefully we'll get this working soon and we'll let everyone know on
> > the mailing list. I can understand your situation very well. I know it
> > sucks.
> > 
> 
> 
> Thanks however in my investigation, this was not the same as the "Killer" card.

Any updates to QCA6174? 


From kvalo at qca.qualcomm.com  Wed Apr  1 10:09:23 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 1 Apr 2015 20:09:23 +0300
Subject: [PATCH v2 2/2] ath10k: implement more versatile set_bitrate_mask
In-Reply-To: <CA+BoTQmhEf3fZSo2FPFbXa=Uc4ia0Sg2SD89gceyc8O+jVJeUg@mail.gmail.com>
 (Michal Kazior's message of "Wed, 1 Apr 2015 14:38:13 +0200")
References: <1427798961-7334-1-git-send-email-michal.kazior@tieto.com>
 <1427798961-7334-3-git-send-email-michal.kazior@tieto.com>
 <CA+BoTQmhEf3fZSo2FPFbXa=Uc4ia0Sg2SD89gceyc8O+jVJeUg@mail.gmail.com>
Message-ID: <87iodfzsfw.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> On 31 March 2015 at 12:49, Michal Kazior <michal.kazior at tieto.com> wrote:
>> Until now only a single fixed tx rate or nss was
>> allowed to be set.
>>
>> The patch attempts to improve this by allowing
>> most bitrate masks. The limitation is VHT MCS
>> rates cannot be expressed separately and only the
>> following VHT MCS ranges are supported: none, 0-7,
>> 0-8, and 0-9.
>>
>> This keeps the old behaviour when requesting
>> single tx rate or single nss. The new bitrate mask
>> logic is only applied to other cases that would
>> return -EINVAL until now.
>>
>> Depending on firmware revisions some combinations
>> may crash firmware so use with care, please.
>>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>> ---
>
> Hi Kalle,
>
> Drop this patch ([2/2]) for now, please. It looks like it doesn't work
> well with crypto networks. I'll need to rework this. The [1/2] is fine
> as it is though.

Ok, patch 2 dropped.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  1 10:12:53 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 1 Apr 2015 20:12:53 +0300
Subject: [PATCH] ath10k: mac: match wait_for_completion_timeout return type
In-Reply-To: <1426271886-20562-1-git-send-email-hofrat@osadl.org> (Nicholas Mc
 Guire's message of "Fri, 13 Mar 2015 14:38:06 -0400")
References: <1426271886-20562-1-git-send-email-hofrat@osadl.org>
Message-ID: <87ego3zsa2.fsf@kamboji.qca.qualcomm.com>

Nicholas Mc Guire <hofrat at osadl.org> writes:

> Return type of wait_for_completion_timeout is unsigned long not int.
> An appropriately named unsigned long is added, respectively 'ret'
> renamed, and the assignments fixed up.
>
> Signed-off-by: Nicholas Mc Guire <hofrat at osadl.org>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  1 10:14:45 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 1 Apr 2015 20:14:45 +0300
Subject: [PATCH] ath10k: htc: match wait_for_completion_timeout return type
In-Reply-To: <1426271901-20596-1-git-send-email-hofrat@osadl.org> (Nicholas Mc
 Guire's message of "Fri, 13 Mar 2015 14:38:21 -0400")
References: <1426271901-20596-1-git-send-email-hofrat@osadl.org>
Message-ID: <87a8yrzs6y.fsf@kamboji.qca.qualcomm.com>

Nicholas Mc Guire <hofrat at osadl.org> writes:

> Return type of wait_for_completion_timeout is unsigned long not int.
> An appropriately named unsigned long is added and the assignments fixed up.
>
> Signed-off-by: Nicholas Mc Guire <hofrat at osadl.org>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  1 10:16:24 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 1 Apr 2015 20:16:24 +0300
Subject: [PATCH] ath10k: debug: match wait_for_completion_timeout return
 type
In-Reply-To: <1426325830-19740-1-git-send-email-hofrat@osadl.org> (Nicholas Mc
 Guire's message of "Sat, 14 Mar 2015 05:37:10 -0400")
References: <1426325830-19740-1-git-send-email-hofrat@osadl.org>
Message-ID: <87619fzs47.fsf@kamboji.qca.qualcomm.com>

Nicholas Mc Guire <hofrat at osadl.org> writes:

> Return type of wait_for_completion_timeout is unsigned long not int.
> An appropriately named unsigned long is added and the assignments fixed up.
> Missing spaces 1*HZ -> 1 * HZ were also added along the way.
>
> Signed-off-by: Nicholas Mc Guire <hofrat at osadl.org>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  1 10:17:18 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 1 Apr 2015 20:17:18 +0300
Subject: [PATCH] ath10k: thermal: match wait_for_completion_timeout return
 type
In-Reply-To: <1426325842-19774-1-git-send-email-hofrat@osadl.org> (Nicholas Mc
 Guire's message of "Sat, 14 Mar 2015 05:37:22 -0400")
References: <1426325842-19774-1-git-send-email-hofrat@osadl.org>
Message-ID: <871tk3zs2p.fsf@kamboji.qca.qualcomm.com>

Nicholas Mc Guire <hofrat at osadl.org> writes:

> Return type of wait_for_completion_timeout is unsigned long not int.
> An appropriately named unsigned long is added and the assignments fixed up.
>
> Signed-off-by: Nicholas Mc Guire <hofrat at osadl.org>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  1 10:18:42 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 1 Apr 2015 20:18:42 +0300
Subject: [PATCH] ath10k: core: match wait_for_completion_timeout return
 type
In-Reply-To: <1426325858-19808-1-git-send-email-hofrat@osadl.org> (Nicholas Mc
 Guire's message of "Sat, 14 Mar 2015 05:37:37 -0400")
References: <1426325858-19808-1-git-send-email-hofrat@osadl.org>
Message-ID: <87wq1vydfw.fsf@kamboji.qca.qualcomm.com>

Nicholas Mc Guire <hofrat at osadl.org> writes:

> Return type of wait_for_completion_timeout is unsigned long not int.
> An appropriately named unsigned long is added and the assignments fixed up.
>
> Signed-off-by: Nicholas Mc Guire <hofrat at osadl.org>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  1 10:19:26 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 1 Apr 2015 20:19:26 +0300
Subject: [PATCH] ath10k: core: match wait_for_completion_timeout return
 type
In-Reply-To: <1426325858-19808-1-git-send-email-hofrat@osadl.org> (Nicholas Mc
 Guire's message of "Sat, 14 Mar 2015 05:37:37 -0400")
References: <1426325858-19808-1-git-send-email-hofrat@osadl.org>
Message-ID: <87sicjydep.fsf@kamboji.qca.qualcomm.com>

Nicholas Mc Guire <hofrat at osadl.org> writes:

> Return type of wait_for_completion_timeout is unsigned long not int.
> An appropriately named unsigned long is added and the assignments fixed up.
>
> Signed-off-by: Nicholas Mc Guire <hofrat at osadl.org>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  1 10:20:47 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 1 Apr 2015 20:20:47 +0300
Subject: [PATCH] ath10k: fix survey reporting
In-Reply-To: <1427200691-7109-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Tue, 24 Mar 2015 12:38:11 +0000")
References: <1427200691-7109-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87oan7ydcg.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> Number of channels is stored in a separate macro
> in a header file and channel list is constructed
> independently. The macro is used to define survey
> array.
>
> This fixes a recent regression introduced after
> adding support for 144 channel. The regression
> would lead to a warning and incomplete survey data
> on channel 165:
>
>   chan info: invalid frequency 5825 (idx 38 out of bounds)
>
> Also make sure to enforce the sizes and avoid this
> kind of problem in the future.
>
> Fixes: 4a7898fed5f3 ("ath10k: enable channel 144 on 5GHz band")
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  1 10:22:29 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 1 Apr 2015 20:22:29 +0300
Subject: [PATCH] ath10k: don't call quiet mode if it's not implemented
In-Reply-To: <1427200817-7407-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Tue, 24 Mar 2015 12:40:17 +0000")
References: <1427200817-7407-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87k2xvyd9m.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> qca6174 and wmi-tlv doesn't have quiet mode
> implemented. Don't even attempt to call it. This
> fixes a warning when bringing first interface up:
>
>   failed to set quiet mode period 100 duarion 0 enabled 0 ret -95
>
> Fixes: 8515b5c79a54 ("ath10k: configure thermal throttle while powering up")
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  1 10:32:54 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 1 Apr 2015 20:32:54 +0300
Subject: [PATCH v6 0/7] ath10k: add multi-channel support
In-Reply-To: <1427797586-5132-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Tue, 31 Mar 2015 10:26:19 +0000")
References: <1427797586-5132-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <878uebycs9.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> New qca6174 with wmi-tlv firmware supports
> multi-channel operation. To make use of it
> ath10k needs a few changes: implement mac80211's
> chanctx API and rework tx queue control a bit.
>
>
> Changes since RFC:
>  * I've sent `ath10k: defer AP self-peer removal
>    wait` separately now because it's not really
>    required for multi-channel per se
>
> v2:
>  * fix null deref after rebasing
>  * fix commit log typo
>
> v3:
>  * remove some duplication wrt mac80211 [Johannes]
>  * small fixes
>
> v4:
>  * rebased
>  * fix STA CSA
>  * drop ar->arvifs data_lock protection patch
>  * drop ar->arvifs for vif iteration in favour of
>    ieee80211_iterate_active_interfaces()
>  * small refactor in monitor recalc
>  * add a patch to fix fw resource allocation for
>    multi-vif/chan
>
> v5:
>  * rebased on top of pending branch
>  * 12 char commit ids
>  * increase vif limit to 3 in ifcombs
>
> v6:
>  * fix rcu locking
>  * rebased on master branch
>    (mind the cfg80211_get_bss conflict when
>     applying to pending branch)
>
> Michal Kazior (7):
>   ath10k: allow empty ssid vdev config
>   ath10k: implement chanctx API
>   ath10k: implement adaptive qcs command
>   ath10k: rework tx queue locking
>   ath10k: implement tx pause wmi event
>   ath10k: enable multi-channel on supported devices
>   ath10k: allocate fw resources for iface combinations

Thanks, all seven patches applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  1 10:34:20 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 1 Apr 2015 20:34:20 +0300
Subject: [PATCH v2 0/2] ath10k: improve set_bitrate_mask
In-Reply-To: <1427798961-7334-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Tue, 31 Mar 2015 10:49:19 +0000")
References: <1427798961-7334-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <874mozycpv.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> This makes set_bitrate_mask more flexible by
> allowing more than applying simple single rate or
> max nss limits.
>
> This still isn't ideal and VHT MCSs can't be set
> separately (only a few range-options are allowed).
>
> v2:
>  * fix ouf-of-bounds
>  * rebased to master branch + multi-channel patches
>
> This will not apply cleanly without multi-channel
> support and conflict resolution will be
> non-trivial.
>
>
> Michal Kazior (2):
>   ath10k: clean up set_bitrate_mask handling

Thanks, this patch applied.

>   ath10k: implement more versatile set_bitrate_mask

This patch dropped as requested.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr  1 12:47:03 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 1 Apr 2015 22:47:03 +0300
Subject: [PATCH] ath10k: fix IBSS scanning on wmi-tlv and qca6174
In-Reply-To: <1427202843-9172-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Tue, 24 Mar 2015 13:14:03 +0000")
References: <1427202843-9172-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87zj6rws08.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> WLAN.RM.2.0-00073 firmware requires self-peer to
> be created prior to issuing scan command. Without
> this wmi-tlv with qca6174 firmware crashes after
> submitting a scan request.
>
> Creating the peer as soon as add_interface()
> shouldn't be a problem.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From poh at codeaurora.org  Wed Apr  1 14:00:01 2015
From: poh at codeaurora.org (Peter Oh)
Date: Wed, 01 Apr 2015 14:00:01 -0700
Subject: [PATCH] ath: use PRI value given by spec for fixed PRI
In-Reply-To: <551BC2B1.3030002@neratec.com>
References: <1427475590-2198-1-git-send-email-poh@qca.qualcomm.com>
 <55191D89.2000300@neratec.com> <55198EA4.1010101@codeaurora.org>
 <551BC2B1.3030002@neratec.com>
Message-ID: <551C5C51.8010109@codeaurora.org>

Hi,


On 04/01/2015 03:04 AM, Zefir Kurtisi wrote:
> On 03/30/2015 07:57 PM, Peter Oh wrote:
>> On 03/30/2015 02:55 AM, Zefir Kurtisi wrote:
>>> [...]
>>> That's why I believe we need to
>>> be very cautious when changing it to fix / improve minor issues.
>> This patch is not for minor fix.
>> Current DFS detector fails on Japan W53 band which requires at least 50%
> of data
>> traffic during DFS certificate.
>> So this patch should apply to both of 9k and 10k.
> That is the core of my concern: you add changes to fix FCC/JP, which at
> the same
> time also affects ETSI.
>
> Our company (and maybe others) got ath9k certified for ETSI, and any
> potential
> change to the detector relevant for that domain would essentially require
> to
> re-certify.
>
> There were several patches lately added to the detector that were isolated
> to
> specific domains (like the recent updates for FCC pattern 1) which I knew
> won't
> affect the ETSI detector performance, since they touched only the FCC
> configuration but not the algorithm itself. This patch does, and that's
> why I need
> to point out that doing so might void certification efforts out there.
I'll try to find a way to not affect ETSI detector to keep the existing 
certificate.
> Unfortunately, I have no good idea how to cope with it. Freezing the
> driver at the
> certified state is no option, since we all want to evolve. Having multiple
> copies
> of the detector for each regulatory domain would be an option (and
> essentially
> will happen since FCC/JP can't be covered by PRI detectors only), but
> gives
> unacceptable code duplication. Ideally we would fully separate algorithm
> from
> configuration and leave the algorithm untouched ever after, not sure how
> doable,
> though.
>
>
> As for your patch at hand, I tested it for ETSI and it does not change
> detector
> performance,
The patch is useful when there are many missing pulses within a burst.
It happens almost every time when channel loading rate is higher than 40%,
but around 30% channel loading does not miss pulses that much.
> therefore (please replace 16 with PRI_TOLERANCE in the macro)
I'll do.
> Acked-by: Zefir Kurtisi <zefir.kurtisi at neratec.com>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
Thanks,
Peter


From sujith at msujith.org  Thu Apr  2 18:12:11 2015
From: sujith at msujith.org (Sujith Manoharan)
Date: Fri, 3 Apr 2015 06:42:11 +0530
Subject: [PATCH 3/4] ath10k: Fix no-ack frame status
In-Reply-To: <87a8yu4n6r.fsf@kamboji.qca.qualcomm.com>
References: <1418226973-13779-1-git-send-email-sujith@msujith.org>
 <1418226973-13779-3-git-send-email-sujith@msujith.org>
 <87oarazecg.fsf@kamboji.qca.qualcomm.com>
 <21646.15326.159197.316821@gargle.gargle.HOWL>
 <87vblduxlk.fsf@kamboji.qca.qualcomm.com>
 <87a8yu4n6r.fsf@kamboji.qca.qualcomm.com>
Message-ID: <21789.59627.667215.173720@gargle.gargle.HOWL>

Kalle Valo wrote:
> > https://patchwork.kernel.org/patch/5470621/
> 
> Naturally I did forget this :) But the patch is in pending branch now.

Thanks...

Sujith


From greearb at candelatech.com  Mon Apr  6 10:55:45 2015
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 06 Apr 2015 10:55:45 -0700
Subject: IBSS support in ath10k - our test results and questions
In-Reply-To: <1638549.OfoyQL4eQV@bentobox>
References: <2680922.jiTnlqor3W@prime> <550B425A.7090505@candelatech.com>
 <1638549.OfoyQL4eQV@bentobox>
Message-ID: <5522C8A1.6040007@candelatech.com>

I was missing the CONFIG_IBSS_RSN...it does not seem to be documented in
the defconfig for supplicant, so I didn't know to add it.

I am going to try RSN again shortly.

Also, I tried using my latest 4.0 kernel tree and I am seeing block-acks apparently
work correctly when using IBSS between two of my ath10k systems on channel 36.
No significant changes to my firmware from what I last uploaded to the beta
directory...

Throughput is still a miserable 13Mbps or so when sending UDP/ipv5 between them,
but a sniff shows the rate reported as 450Mbps for at least many of the data
frames (I guess I am still missing patches to enable VHT IBSS currently).

My tree is here.  It is basically a forward ported and cleaned up version
of my 3.19 tree, with a few additional patches.  I plan to skip 3.19
and focus on 4.0 for our own purposes, so my 3.19 tree is basically EOL at
this point:

git clone git://dmz2.candelatech.com/linux-4.0.dev.y

Thanks,
Ben


On 03/23/2015 04:24 AM, Sven Eckelmann wrote:
> On Thursday 19 March 2015 14:40:42 Ben Greear wrote:
>> In case you have a public kernel tree available somewhere with all your
>> patches, that might help speed up someone's attempt to reproduce this?
> 
> I have uploaded the patchset of our test setup at
> 
>  git://dev.cloudtrax.com/ath10k-ibss-test.git
>  https://dev.cloudtrax.com/git/ath10k-ibss-test.git
> 
> As Simon already said, it is not a kernel tree but patches on top of compat-
> wireless from OpenWrt r44654. If you want to import something into an actual 
> tree then please create patches and replace the CPTCFG_* strings with 
> CONFIG_*.
> 
> Here a small explanation of the branches:
> 
>  * openwrt_44654: initial import of the source + patches of mac80211
>    (compat-wireless) package from OpenWrt r44654
>  * ath3.19: patches of ath10k which were between the compat-wireless version
>    and Linux 3.19
>  * candelatech-lf-lf-5.3.1 patches taken from Candelatech's 3.19 tree (minus
>    some patches which weren't related to the wireless stuff)
>  * master: the patches which were used for the IBSS test with Ben Greear's
>    firmware. Most came from Janusz Dziedzic. The rest are just a few small
>    changes to fix builds, workarounds to fix loading of the firmware and some
>    required patches for Janusz Dziedzic's IBSS stuff.
>  * fw-999.999-ibss patch to allow loading of the original firmware with most
>    of Ben Greear's patches. Was used to verify that the original 999.x
>    firmware worked fine with block ack sessions + aggregation
> 
> The only patches not included here are some test patches which weren't part of 
> the actual "performance" tests. This includes patches used for debugging and 
> tests to check the IBSS RSN stuff over ath10k (which failed - most likely due 
> to some firmware "features" regarding encryption which resulted in non-
> decryptable packets).
> 
> I think you can use wpa_supplicant 2.4 for VHT. I personally used a patched 
> version of iw which hardcoded the ibss join VHT parameters. I haven't tested 
> this yet because I've done the port of the OpenWrt patches on friday evening 
> and hadn't time to test it with ath10k. But this problem doesn't require VHT 
> features and thus should be visible with the plain HT setup and no VHT 
> enabled.
> 
> Kind regards,
> 	Sven
> 
> PS: Not sure if you have finished the test with ath9k IBSS RSN + HT. I was 
> under the impression that you had problems with it. Beside the stuff I already 
> wrote in an earlier mail, the only thing which came to my mind was the 
> wpa_supplicant build setup. IBSS RSN doesn't work with a standard build and 
> you have to enable CONFIG_IBSS_RSN in the wpa_supplicant config. An example 
> config which works (with the OpenWrt build system of course) can be found at
> 
>  https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/wpa_supplicant-full.config?rev=38852
> 
> The wpa_supplicant (runtime) config would be look like this:
> 
> ap_scan=2
> network={
>         scan_ssid=0
>         ssid="mesh"
>         key_mgmt=WPA-PSK
>         mode=1
>         fixed_freq=1
>         frequency=5180
>         mode=1
>         psk="9f0a965af38f2d0a13b66d8b46ab962c"
>         proto=RSN
>         bssid=02:CA:FE:CA:CA:40
>         # openwrt specific patch for htmode, mcast_rate
>         htmode=HT40+
>         mcast_rate=18
> }
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From acarbonara13 at gmail.com  Mon Apr  6 12:49:19 2015
From: acarbonara13 at gmail.com (Amato Carbonara)
Date: Mon, 6 Apr 2015 15:49:19 -0400
Subject: Using ath10k for WiFi capturing non-11ac traffic
Message-ID: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>

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


From greearb at candelatech.com  Mon Apr  6 13:04:35 2015
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 06 Apr 2015 13:04:35 -0700
Subject: IBSS support in ath10k - our test results and questions
In-Reply-To: <5522C8A1.6040007@candelatech.com>
References: <2680922.jiTnlqor3W@prime> <550B425A.7090505@candelatech.com>
 <1638549.OfoyQL4eQV@bentobox> <5522C8A1.6040007@candelatech.com>
Message-ID: <5522E6D3.30109@candelatech.com>

So, IBSS RSN with ath9k works great on my systems now.

I'm trying ath10k, and what I see is that it appears the supplicant
is trying to send the 1/4 message, and it never hits the air.

Firmware has some special handling for this sort of thing..so I'll
go poke around...  If anyone has any suggestions, please let me know.

Thanks,
Ben


On 04/06/2015 10:55 AM, Ben Greear wrote:
> I was missing the CONFIG_IBSS_RSN...it does not seem to be documented in
> the defconfig for supplicant, so I didn't know to add it.
> 
> I am going to try RSN again shortly.
> 
> Also, I tried using my latest 4.0 kernel tree and I am seeing block-acks apparently
> work correctly when using IBSS between two of my ath10k systems on channel 36.
> No significant changes to my firmware from what I last uploaded to the beta
> directory...
> 
> Throughput is still a miserable 13Mbps or so when sending UDP/ipv5 between them,
> but a sniff shows the rate reported as 450Mbps for at least many of the data
> frames (I guess I am still missing patches to enable VHT IBSS currently).
> 
> My tree is here.  It is basically a forward ported and cleaned up version
> of my 3.19 tree, with a few additional patches.  I plan to skip 3.19
> and focus on 4.0 for our own purposes, so my 3.19 tree is basically EOL at
> this point:
> 
> git clone git://dmz2.candelatech.com/linux-4.0.dev.y
> 
> Thanks,
> Ben
> 
> 
> On 03/23/2015 04:24 AM, Sven Eckelmann wrote:
>> On Thursday 19 March 2015 14:40:42 Ben Greear wrote:
>>> In case you have a public kernel tree available somewhere with all your
>>> patches, that might help speed up someone's attempt to reproduce this?
>>
>> I have uploaded the patchset of our test setup at
>>
>>  git://dev.cloudtrax.com/ath10k-ibss-test.git
>>  https://dev.cloudtrax.com/git/ath10k-ibss-test.git
>>
>> As Simon already said, it is not a kernel tree but patches on top of compat-
>> wireless from OpenWrt r44654. If you want to import something into an actual 
>> tree then please create patches and replace the CPTCFG_* strings with 
>> CONFIG_*.
>>
>> Here a small explanation of the branches:
>>
>>  * openwrt_44654: initial import of the source + patches of mac80211
>>    (compat-wireless) package from OpenWrt r44654
>>  * ath3.19: patches of ath10k which were between the compat-wireless version
>>    and Linux 3.19
>>  * candelatech-lf-lf-5.3.1 patches taken from Candelatech's 3.19 tree (minus
>>    some patches which weren't related to the wireless stuff)
>>  * master: the patches which were used for the IBSS test with Ben Greear's
>>    firmware. Most came from Janusz Dziedzic. The rest are just a few small
>>    changes to fix builds, workarounds to fix loading of the firmware and some
>>    required patches for Janusz Dziedzic's IBSS stuff.
>>  * fw-999.999-ibss patch to allow loading of the original firmware with most
>>    of Ben Greear's patches. Was used to verify that the original 999.x
>>    firmware worked fine with block ack sessions + aggregation
>>
>> The only patches not included here are some test patches which weren't part of 
>> the actual "performance" tests. This includes patches used for debugging and 
>> tests to check the IBSS RSN stuff over ath10k (which failed - most likely due 
>> to some firmware "features" regarding encryption which resulted in non-
>> decryptable packets).
>>
>> I think you can use wpa_supplicant 2.4 for VHT. I personally used a patched 
>> version of iw which hardcoded the ibss join VHT parameters. I haven't tested 
>> this yet because I've done the port of the OpenWrt patches on friday evening 
>> and hadn't time to test it with ath10k. But this problem doesn't require VHT 
>> features and thus should be visible with the plain HT setup and no VHT 
>> enabled.
>>
>> Kind regards,
>> 	Sven
>>
>> PS: Not sure if you have finished the test with ath9k IBSS RSN + HT. I was 
>> under the impression that you had problems with it. Beside the stuff I already 
>> wrote in an earlier mail, the only thing which came to my mind was the 
>> wpa_supplicant build setup. IBSS RSN doesn't work with a standard build and 
>> you have to enable CONFIG_IBSS_RSN in the wpa_supplicant config. An example 
>> config which works (with the OpenWrt build system of course) can be found at
>>
>>  https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/wpa_supplicant-full.config?rev=38852
>>
>> The wpa_supplicant (runtime) config would be look like this:
>>
>> ap_scan=2
>> network={
>>         scan_ssid=0
>>         ssid="mesh"
>>         key_mgmt=WPA-PSK
>>         mode=1
>>         fixed_freq=1
>>         frequency=5180
>>         mode=1
>>         psk="9f0a965af38f2d0a13b66d8b46ab962c"
>>         proto=RSN
>>         bssid=02:CA:FE:CA:CA:40
>>         # openwrt specific patch for htmode, mcast_rate
>>         htmode=HT40+
>>         mcast_rate=18
>> }
>>
> 
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From jhihn at gmx.com  Tue Apr  7 07:44:37 2015
From: jhihn at gmx.com (Jason H)
Date: Tue, 7 Apr 2015 16:44:37 +0200
Subject: QCA6174 hw2.1?
In-Reply-To: <trinity-b1ca9c09-4b5d-4cd4-8a8b-bd61df2a40c4-1427119021325@3capp-mailcom-lxa02>
References: <trinity-78717edb-041b-4b77-8173-d7ba2ac3aeea-1426969886147@msvc024>, 
 <CA+BoTQkAckpbgTKg=9+ea5Me0m9=FO3aMU=qYHmX0Y96KubKeA@mail.gmail.com>,
 <trinity-b1ca9c09-4b5d-4cd4-8a8b-bd61df2a40c4-1427119021325@3capp-mailcom-lxa02>
Message-ID: <trinity-b17ca295-ac0b-4117-bf4d-daa1653254fc-1428417877122@3capp-mailcom-lxa05>

Just checking in. Any updates for the QCA6174?

> Sent: Monday, March 23, 2015 at 9:57 AM
> From: "Jason H" <jhihn at gmx.com>
> To: "Michal Kazior" <michal.kazior at tieto.com>
> Cc: "ath10k at lists.infradead.org" <ath10k at lists.infradead.org>
> Subject: Re: Re: QCA6174 hw2.1?
>
> 
> 
> > Sent: Monday, March 23, 2015 at 4:23 AM
> > From: "Michal Kazior" <michal.kazior at tieto.com>
> > To: "Jason H" <jhihn at gmx.com>
> > Cc: "ath10k at lists.infradead.org" <ath10k at lists.infradead.org>
> > Subject: Re: Re: QCA6174 hw2.1?
> >
> > On 21 March 2015 at 21:31,  <jhihn at gmx.com> wrote:
> > > is there anyway you could process these files for me?. I would be willing to send you the files and go through some back and forth of feedback and whatnot. The issue is I just don't think I have the time or the expertise to devote to this. However I investigated exchanging  the laptop to get a  Linux compatible one, but its going to cost me money for the restocking fee. On top of that the next user of this laptop will be disgruntled when they find a non working copy of Linux on it. I investigated getting the restore cd but Lenovo's charging $70 for the media. So if you could help I would really appreciate it because this is the last thing that I need to get working but I really need it.
> > >
> > > and we could also get this chipset supported. I saw I wasn't the only one looking for Linux support for this driver.
> > 
> > Thanks for willing to help. However I finally got my hands on the
> > Killer 1525 card. I tried playing with it but I couldn't get ath10k to
> > work with it yet.
> > 
> > There's some firmware crash issue that needs investigating. Kalle's
> > doing his best to sort this out internally.
> > 
> > Hopefully we'll get this working soon and we'll let everyone know on
> > the mailing list. I can understand your situation very well. I know it
> > sucks.
> > 
> 
> 
> Thanks however in my investigation, this was not the same as the "Killer" card.
> 
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


From greearb at candelatech.com  Tue Apr  7 14:17:13 2015
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 07 Apr 2015 14:17:13 -0700
Subject: IBSS support in ath10k - our test results and questions
In-Reply-To: <CALhHN=qch721dGPWWjmBb15qwH8gGQprafUEK+XjYu0ajm-tZw@mail.gmail.com>
References: <2680922.jiTnlqor3W@prime> <550B425A.7090505@candelatech.com>
 <CALhHN=qch721dGPWWjmBb15qwH8gGQprafUEK+XjYu0ajm-tZw@mail.gmail.com>
Message-ID: <55244959.6080408@candelatech.com>

On 03/19/2015 11:44 PM, Janusz Dziedzic wrote:
> On 19 March 2015 at 22:40, Ben Greear <greearb at candelatech.com> wrote:

> Regarding IBSS/RSN and 636 firmware, this works sometimes (ath10k
> patch required here).
> But in case this don't work firmware don't send EAPOL frames - I think
> this is main problem ...

I've been trying to figure out IBSS + RSN in my firmware.

It seems in my FW I was never (or at least rarely) sending the EAPOL
frames.  I found a way around this, but now I see 1/4 go out fine,
but 2/4 reports MIC errors.  I don't think my work-around is to blame,
but it could be.  Also not sure why my work-around is required (or at least
why STA/AP mode works w/out the hack.)

A big part of my problem is that I don't actually know how IBSS + RSN
is supposed to work.

If someone has time to clue me in on that, I might make faster progress
(or progress at all) on supporting IBSS + RSN on ath10k.

In particular, I am curious when what type of key is supposed to
be set at which stages...and for instance, what is supposed to happen
between the 1/4 message and the 2/4 message (are keys supposed to be set?)

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From will.pearse at gmail.com  Tue Apr  7 14:18:46 2015
From: will.pearse at gmail.com (Will)
Date: Tue, 7 Apr 2015 17:18:46 -0400
Subject: [PATCH] ath10k: match wait_for_completion_timeout return type
Message-ID: <CAJs-zoZHwhgf4d=SioPSpcEjjof8SJC-e6rRnyghKJd8FwcmQg@mail.gmail.com>

Hello,

Sorry to bother you all, but I'm one of a few people affected by the
problem described in this thread (which is also on launchpad;
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1383184).

Is there anything I can do to help things along? Whether it be testing
or (...if someone pointed me in the right direction...) coding, I'd
like to help out, and so maybe get my wi-fi card working :D

Thanks!

Will


From greearb at candelatech.com  Tue Apr  7 17:05:27 2015
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 07 Apr 2015 17:05:27 -0700
Subject: Getting bad MIC when trying ath10k + ath9k IBSS with RSN
Message-ID: <552470C7.9040002@candelatech.com>

I have been hacking on ath10k driver and firmware in attempt to enable IBSS + RSN.

Currently, I see message 1/4 in both directions, but the ath9k wpa_supplicant always reports 2/4
from ath10k station as having bad MIC (and AC supplicant dumps core shortly after when there is an EAPOL timeout,
I haven't looked into the core yet, but unlikely to be directly related to bad MIC I think since
ath9k <-> ath9k works fine).

Almost certainly this is some bug in ath10k and/or the firmware, but if someone
has some suggestions as to what it might be or how to debug it further, I would
appreciate the help!

Network capture and supplicant logs are found here:

https://www.candelatech.com/downloads/tmp/

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Wed Apr  8 11:38:10 2015
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 08 Apr 2015 11:38:10 -0700
Subject: IBSS support in ath10k - our test results and questions
In-Reply-To: <5522E6D3.30109@candelatech.com>
References: <2680922.jiTnlqor3W@prime> <550B425A.7090505@candelatech.com>
 <1638549.OfoyQL4eQV@bentobox> <5522C8A1.6040007@candelatech.com>
 <5522E6D3.30109@candelatech.com>
Message-ID: <55257592.1080900@candelatech.com>

So, I've made some progress.

After fixing PSK (I had it misconfigured all of yesterday!), and with full restart of supplicant,
I can get the 4-way to complete, and I see PTK and GTK set in driver and firmware.
I do not know if the keys are set correctly, but the logs seem plausible.

After that, I see plain-text ARPs hit the air (the should be encrypted),
and the last 21 bytes of the packet appear to be random garbage.

I am guessing driver and/or firmware and/or hardware is not properly
encrypting the frames.

Off to do some more spelunking in the firmware.

Thanks,
Ben



On 04/06/2015 01:04 PM, Ben Greear wrote:
> So, IBSS RSN with ath9k works great on my systems now.
> 
> I'm trying ath10k, and what I see is that it appears the supplicant
> is trying to send the 1/4 message, and it never hits the air.
> 
> Firmware has some special handling for this sort of thing..so I'll
> go poke around...  If anyone has any suggestions, please let me know.
> 
> Thanks,
> Ben
> 
> 
> On 04/06/2015 10:55 AM, Ben Greear wrote:
>> I was missing the CONFIG_IBSS_RSN...it does not seem to be documented in
>> the defconfig for supplicant, so I didn't know to add it.
>>
>> I am going to try RSN again shortly.
>>
>> Also, I tried using my latest 4.0 kernel tree and I am seeing block-acks apparently
>> work correctly when using IBSS between two of my ath10k systems on channel 36.
>> No significant changes to my firmware from what I last uploaded to the beta
>> directory...
>>
>> Throughput is still a miserable 13Mbps or so when sending UDP/ipv5 between them,
>> but a sniff shows the rate reported as 450Mbps for at least many of the data
>> frames (I guess I am still missing patches to enable VHT IBSS currently).
>>
>> My tree is here.  It is basically a forward ported and cleaned up version
>> of my 3.19 tree, with a few additional patches.  I plan to skip 3.19
>> and focus on 4.0 for our own purposes, so my 3.19 tree is basically EOL at
>> this point:
>>
>> git clone git://dmz2.candelatech.com/linux-4.0.dev.y
>>
>> Thanks,
>> Ben
>>
>>
>> On 03/23/2015 04:24 AM, Sven Eckelmann wrote:
>>> On Thursday 19 March 2015 14:40:42 Ben Greear wrote:
>>>> In case you have a public kernel tree available somewhere with all your
>>>> patches, that might help speed up someone's attempt to reproduce this?
>>>
>>> I have uploaded the patchset of our test setup at
>>>
>>>  git://dev.cloudtrax.com/ath10k-ibss-test.git
>>>  https://dev.cloudtrax.com/git/ath10k-ibss-test.git
>>>
>>> As Simon already said, it is not a kernel tree but patches on top of compat-
>>> wireless from OpenWrt r44654. If you want to import something into an actual 
>>> tree then please create patches and replace the CPTCFG_* strings with 
>>> CONFIG_*.
>>>
>>> Here a small explanation of the branches:
>>>
>>>  * openwrt_44654: initial import of the source + patches of mac80211
>>>    (compat-wireless) package from OpenWrt r44654
>>>  * ath3.19: patches of ath10k which were between the compat-wireless version
>>>    and Linux 3.19
>>>  * candelatech-lf-lf-5.3.1 patches taken from Candelatech's 3.19 tree (minus
>>>    some patches which weren't related to the wireless stuff)
>>>  * master: the patches which were used for the IBSS test with Ben Greear's
>>>    firmware. Most came from Janusz Dziedzic. The rest are just a few small
>>>    changes to fix builds, workarounds to fix loading of the firmware and some
>>>    required patches for Janusz Dziedzic's IBSS stuff.
>>>  * fw-999.999-ibss patch to allow loading of the original firmware with most
>>>    of Ben Greear's patches. Was used to verify that the original 999.x
>>>    firmware worked fine with block ack sessions + aggregation
>>>
>>> The only patches not included here are some test patches which weren't part of 
>>> the actual "performance" tests. This includes patches used for debugging and 
>>> tests to check the IBSS RSN stuff over ath10k (which failed - most likely due 
>>> to some firmware "features" regarding encryption which resulted in non-
>>> decryptable packets).
>>>
>>> I think you can use wpa_supplicant 2.4 for VHT. I personally used a patched 
>>> version of iw which hardcoded the ibss join VHT parameters. I haven't tested 
>>> this yet because I've done the port of the OpenWrt patches on friday evening 
>>> and hadn't time to test it with ath10k. But this problem doesn't require VHT 
>>> features and thus should be visible with the plain HT setup and no VHT 
>>> enabled.
>>>
>>> Kind regards,
>>> 	Sven
>>>
>>> PS: Not sure if you have finished the test with ath9k IBSS RSN + HT. I was 
>>> under the impression that you had problems with it. Beside the stuff I already 
>>> wrote in an earlier mail, the only thing which came to my mind was the 
>>> wpa_supplicant build setup. IBSS RSN doesn't work with a standard build and 
>>> you have to enable CONFIG_IBSS_RSN in the wpa_supplicant config. An example 
>>> config which works (with the OpenWrt build system of course) can be found at
>>>
>>>  https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/wpa_supplicant-full.config?rev=38852
>>>
>>> The wpa_supplicant (runtime) config would be look like this:
>>>
>>> ap_scan=2
>>> network={
>>>         scan_ssid=0
>>>         ssid="mesh"
>>>         key_mgmt=WPA-PSK
>>>         mode=1
>>>         fixed_freq=1
>>>         frequency=5180
>>>         mode=1
>>>         psk="9f0a965af38f2d0a13b66d8b46ab962c"
>>>         proto=RSN
>>>         bssid=02:CA:FE:CA:CA:40
>>>         # openwrt specific patch for htmode, mcast_rate
>>>         htmode=HT40+
>>>         mcast_rate=18
>>> }
>>>
>>
>>
> 
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From nicolas.cavallari at green-communications.fr  Thu Apr  9 01:41:00 2015
From: nicolas.cavallari at green-communications.fr (Nicolas Cavallari)
Date: Thu, 09 Apr 2015 10:41:00 +0200
Subject: Getting bad MIC when trying ath10k + ath9k IBSS with RSN
In-Reply-To: <5525B8F3.4050702@candelatech.com>
References: <552470C7.9040002@candelatech.com>
 <5524F0E9.9030208@green-communications.fr> <55254106.7040807@candelatech.com>
 <5525B8F3.4050702@candelatech.com>
Message-ID: <55263B1C.4020708@green-communications.fr>

[re-adding ath10k, sorry for removing it]

On 09/04/2015 01:25, Ben Greear wrote:
> On 04/08/2015 07:53 AM, Ben Greear wrote:
> Ok, the EAPOL seems to work now, as long as I restart both supplicants before
> I try to connect.
> 
> It appears now that there is something wrong with setting the keys.  The
> firmware appears to get a real key, and then shortly after, the keys are
> removed and encryption is disabled.
> 
> The supplicant log is below.  I believe the crucial part is this.  Any idea why
> this would be failing?  (I'll poke in the kernel tomorrow to try to find
> the reason as well...)
> 
> 1428534417.236258: wpa_driver_nl80211_set_key: ifindex=131 (wlan0) alg=3 addr=0x2344900 key_idx=1 set_tx=0 seq_len=6 key_len=16
> 1428534417.236273: nl80211: KEY_DATA - hexdump(len=16): a5 28 f3 02 e9 cb a4 de 87 01 a4 9c c9 d2 a8 89
> 1428534417.236298: nl80211: KEY_SEQ - hexdump(len=6): 00 00 00 00 00 00
> 1428534417.236311:    addr=00:0e:8e:3e:8b:96
> 1428534417.236319:    RSN IBSS RX GTK
> 1428534417.236355: nl80211: set_key failed; err=-22 Invalid argument)
> 1428534417.236367: wlan0: WPA: Failed to set GTK to the driver (alg=3 keylen=16 keyidx=1)
> 1428534417.236376: wlan0: RSN: Failed to install GTK
> 1428534417.236385: wlan0: RSN: Failed to configure GTK
> 1428534417.236393: SUPP: supp_deauthenticate (TODO)
> 1428534417.236419: l2_packet_receive: src=00:0e:8e:3e:8b:96 len=99

I see this failure with drivers that do not support IBSS-RSN...
Otherwise, this request must succeed.

The only difference between AP mode and IBSS mode is that in IBSS mode,
each peer have their own GTK, so you have to program a per-sta GTK for
decryption.

But GTK is for multicast frames, and I already made broken IBSS-RSN
networks with drivers that do not support IBSS-RSN, because the PTK was
still programmed correctly. You just have a network that can only pass
unicast traffic.  Your PTK was programmed correctly:

1428534380.576614: AUTH: set_key - key - hexdump(len=16): 99 76 89 40 b3
61 28 4f 60 2c 4b 75 72 6b 4e e8
1428534380.576645: wpa_driver_nl80211_set_key: ifindex=131 (wlan0) alg=3
addr=0x23490f0 key_idx=0 set_tx=1 seq_len=6 key_len=16
1428534380.576657: nl80211: KEY_DATA - hexdump(len=16): 99 76 89 40 b3
61 28 4f 60 2c 4b 75 72 6b 4e e8
1428534380.576668: nl80211: KEY_SEQ - hexdump(len=6): 00 00 00 00 00 00
1428534380.576677:    addr=00:0e:8e:3e:8b:96
1428534380.577056: nl80211: Set STA flags - ifname=wlan0
addr=00:0e:8e:3e:8b:96 total_flags=0x1 flags_or=0x1 flags_and=0xffffffff
authorized=1
1428534380.577108: AUTH: 00:0e:8e:3e:8b:96 authorizing port


However, there are other problems in your log:

1) There are two NL80211_CMD_JOIN_IBSS events from the kernel, for only
one join request.

2) wpa_supplicant sent a authentication frame at 1428534380.167582 and
never got any tx_status response from the kernel.  This was before the
second NL80211_CMD_JOIN_IBSS event.

Loosing a authentication frame is normally no big deal. It often
happens. They are even stations that do not support them.  If i remember
the logic that i implemented in wpa_supplicant, you consider the other
station as authenticated if you receive an authentication response or an
authentication request, or after a timeout.

3) But this timeout seems buggy: after completing the EAPOL exchange,
this timer fires:

1428534381.168652: RSN: Timeout on waiting Authentication frame response
from 00:0e:8e:3e:8b:96 - start authenticator

This timer shouldn't even be present. And even if it did, it shouldn't
start the authenticator as it is already started.  I didn't track the
latest changes in wpa_supplicant's IBSS-RSN support, but this seems wrong.

But it restart the authenticator anyway, which clears the PTK:

1428534381.168693: AUTH: auth_set_key(alg=0 addr=00:0e:8e:3e:8b:96
key_idx=0)
1428534381.168703: AUTH: set_key - key - hexdump(len=0): [NULL]
1428534381.168737: wpa_driver_nl80211_set_key: ifindex=131 (wlan0) alg=0
addr=0x2344bb0 key_idx=0 set_tx=1 seq_len=6 key_len=0
1428534381.168751: nl80211: KEY_SEQ - hexdump(len=6): 00 00 00 00 00 00
1428534381.168761:    addr=00:0e:8e:3e:8b:96

And mark the station as unauthorized:

1428534381.169266: nl80211: Set STA flags - ifname=wlan0
addr=00:0e:8e:3e:8b:96 total_flags=0x0 flags_or=0x0 flags_and=0xfffffffe
authorized=0
1428534381.169347: AUTH: 00:0e:8e:3e:8b:96 unauthorizing port

After that, it retries an EAPOL exchange which basically fail: the
remote station still have an encrypted session, and the logic in
wpa_supplicant is that you can only reset a encryption session by
sending an authentication frame.


From kvalo at qca.qualcomm.com  Thu Apr  9 04:56:19 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 9 Apr 2015 14:56:19 +0300
Subject: [PATCH] ath10k: disable burst mode
In-Reply-To: <1427271291-31683-1-git-send-email-janusz.dziedzic@tieto.com>
 (Janusz Dziedzic's message of "Wed, 25 Mar 2015 09:14:51 +0100")
References: <1427271291-31683-1-git-send-email-janusz.dziedzic@tieto.com>
Message-ID: <87d23dfrbw.fsf@kamboji.qca.qualcomm.com>

Janusz Dziedzic <janusz.dziedzic at tieto.com> writes:

> Firmwares that indicate BURST_SERVICE as enabled
> could overwrite some wmm parameters (eg. txop).
> This could lead IOT and balancing issues.
> Hence disable this by default.
>
> Signed-off-by: Janusz Dziedzic <janusz.dziedzic at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Thu Apr  9 04:57:35 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 9 Apr 2015 14:57:35 +0300
Subject: [PATCH] ath10k: fix insufficient tracing buffer size
In-Reply-To: <1427364202-25235-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Thu, 26 Mar 2015 10:03:22 +0000")
References: <1427364202-25235-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <878ue1fr9s.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> Some trace messages were truncated and a kernel
> splat could be seen in the log:
>
>   WARNING: CPU: 3 PID: 0 at /devel/src/linux/drivers/net/wireless/ath/ath10k/./trace.h:114 ftrace_raw_event_ath10k_log_dbg+0x20e/0x220 [ath10k_core]()
>   Modules linked in: ath10k_pci(O) ath10k_core(O) ath iwldvm iwlwifi [last unloaded: iwlwifi]
>   CPU: 3 PID: 0 Comm: swapper/3 Tainted: G        W  O    4.0.0-rc3-wl-ath+ #703
>   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
>    ffffffffa01d4cb0 ffff88001fd83998 ffffffff8191b86c ffffffff81e3b718
>    0000000000000000 ffff88001fd839d8 ffffffff8105573a ffff88001c0a5528
>    ffff88001bea9ae0 ffff88001c3dd940 00000000000d0018 ffff88001fd83a80
>   Call Trace:
>    <IRQ>  [<ffffffff8191b86c>] dump_stack+0x45/0x57
>    [<ffffffff8105573a>] warn_slowpath_common+0x8a/0xc0
>    [<ffffffff8105582a>] warn_slowpath_null+0x1a/0x20
>    [<ffffffffa01c61fe>] ftrace_raw_event_ath10k_log_dbg+0x20e/0x220 [ath10k_core]
>    [<ffffffffa01aaa6b>] ath10k_dbg+0xbb/0xd0 [ath10k_core]
>    [<ffffffff810eed89>] ? trace_clock_local+0x9/0x10
>    [<ffffffffa01bd069>] ath10k_wmi_event_service_ready+0x479/0x520 [ath10k_core]
>    [<ffffffff810fdf90>] ? trace_buffer_unlock_commit+0x50/0x60
>    [<ffffffffa01c2113>] ath10k_wmi_tlv_op_rx+0x6b3/0x8b0 [ath10k_core]
>
> This could be reproduced with:
>
>   trace-cmd record -e ath10k
>   ifconfig wlan0 down
>   ifconfig wlan0 up
>
> Fixes: 5c01aa3de918 ("ath10k: deduplicate wmi service ready logic")
> Fixes: ca996ec56608 ("ath10k: implement wmi-tlv backend")
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Thu Apr  9 04:58:54 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 9 Apr 2015 14:58:54 +0300
Subject: [PATCH] ath10k: replenish htc tx credits always
In-Reply-To: <1427368943-29526-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Thu, 26 Mar 2015 11:22:23 +0000")
References: <1427368943-29526-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <874mopfr7l.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> There's always at most 2 credits and it makes
> little sense to set the
> ATH10K_HTC_FLAG_NEED_CREDIT_UPDATE flag
> conditionally.
>
> This seems to fix some random issues with tx
> credit starvation on WLAN.RM.2.0-00073 I've been
> seeing. Note: this isn't related to wmi mgmt tx.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Thu Apr  9 05:05:22 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 9 Apr 2015 15:05:22 +0300
Subject: [PATCH 1/2] ath10k: fix arvif->wep_keys clearing
In-Reply-To: <1427444516-974-1-git-send-email-michal.kazior@tieto.com> (Michal
 Kazior's message of "Fri, 27 Mar 2015 08:21:55 +0000")
References: <1427444516-974-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87zj6heccd.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> The variable should be cleared regardless of
> whether there's a peer associated with the key or
> not.
>
> This fixes case when user first associates with 2
> WEP keys and then disconnects and connects with 1
> WEP key. This resulted in WEP key count being 2 in
> the driver leading to default keyidx fixup
> failure.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, both patches applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Thu Apr  9 05:08:01 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 9 Apr 2015 15:08:01 +0300
Subject: [PATCH] ath10k: Change the fw stats access mask
In-Reply-To: <1427476680-5532-1-git-send-email-yanbol@qca.qualcomm.com> (Yanbo
 Li's message of "Fri, 27 Mar 2015 10:18:00 -0700")
References: <1427476680-5532-1-git-send-email-yanbol@qca.qualcomm.com>
Message-ID: <87vbh5ec7y.fsf@kamboji.qca.qualcomm.com>

Yanbo Li <yanbol at qca.qualcomm.com> writes:

> This fix the regerssion introduced after "ath10k_wmi_requests_stats()
> call to use more stat bits", both the 10.2.X FW and community FW 10.1.X
> will return time out when access the fw_stats with the STAT_VDEV and
> STAT_PDEV. Add the condition to use different fw_stats mask for different
> FW versions.
>
> Fixes:7777d8c7ef6f("ath10k: implement fw stats for wmi-tlv")
> Signed-off-by: Yanbo Li <yanbol at qca.qualcomm.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Thu Apr  9 05:11:09 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 9 Apr 2015 15:11:09 +0300
Subject: [PATCH 3/4] ath10k: Fix no-ack frame status
In-Reply-To: <1418226973-13779-3-git-send-email-sujith@msujith.org> (Sujith
 Manoharan's message of "Wed, 10 Dec 2014 21:26:12 +0530")
References: <1418226973-13779-1-git-send-email-sujith@msujith.org>
 <1418226973-13779-3-git-send-email-sujith@msujith.org>
Message-ID: <87lhi1ec2q.fsf@kamboji.qca.qualcomm.com>

Sujith Manoharan <sujith at msujith.org> writes:

> From: Sujith Manoharan <c_manoha at qca.qualcomm.com>
>
> Use the new IEEE80211_TX_STAT_NOACK_TRANSMITTED flag
> to indicate successful transmission of no-ack frames.
> This fixes multicast frame accounting.
>
> Cc: ath10k at lists.infradead.org
> Signed-off-by: Sujith Manoharan <c_manoha at qca.qualcomm.com>

Thanks, applied.

-- 
Kalle Valo


From greearb at candelatech.com  Thu Apr  9 14:47:43 2015
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 09 Apr 2015 14:47:43 -0700
Subject: Getting bad MIC when trying ath10k + ath9k IBSS with RSN
In-Reply-To: <55263B1C.4020708@green-communications.fr>
References: <552470C7.9040002@candelatech.com>
 <5524F0E9.9030208@green-communications.fr> <55254106.7040807@candelatech.com>
 <5525B8F3.4050702@candelatech.com> <55263B1C.4020708@green-communications.fr>
Message-ID: <5526F37F.5070303@candelatech.com>

On 04/09/2015 01:41 AM, Nicolas Cavallari wrote:
> [re-adding ath10k, sorry for removing it]
> 
> On 09/04/2015 01:25, Ben Greear wrote:
>> On 04/08/2015 07:53 AM, Ben Greear wrote:
>> Ok, the EAPOL seems to work now, as long as I restart both supplicants before
>> I try to connect.
>>
>> It appears now that there is something wrong with setting the keys.  The
>> firmware appears to get a real key, and then shortly after, the keys are
>> removed and encryption is disabled.
>>
>> The supplicant log is below.  I believe the crucial part is this.  Any idea why
>> this would be failing?  (I'll poke in the kernel tomorrow to try to find
>> the reason as well...)
>>
>> 1428534417.236258: wpa_driver_nl80211_set_key: ifindex=131 (wlan0) alg=3 addr=0x2344900 key_idx=1 set_tx=0 seq_len=6 key_len=16
>> 1428534417.236273: nl80211: KEY_DATA - hexdump(len=16): a5 28 f3 02 e9 cb a4 de 87 01 a4 9c c9 d2 a8 89
>> 1428534417.236298: nl80211: KEY_SEQ - hexdump(len=6): 00 00 00 00 00 00
>> 1428534417.236311:    addr=00:0e:8e:3e:8b:96
>> 1428534417.236319:    RSN IBSS RX GTK
>> 1428534417.236355: nl80211: set_key failed; err=-22 Invalid argument)
>> 1428534417.236367: wlan0: WPA: Failed to set GTK to the driver (alg=3 keylen=16 keyidx=1)
>> 1428534417.236376: wlan0: RSN: Failed to install GTK
>> 1428534417.236385: wlan0: RSN: Failed to configure GTK
>> 1428534417.236393: SUPP: supp_deauthenticate (TODO)
>> 1428534417.236419: l2_packet_receive: src=00:0e:8e:3e:8b:96 len=99
> 
> I see this failure with drivers that do not support IBSS-RSN...
> Otherwise, this request must succeed.

Yeah, I thought I had applied Januz's patch to enable this in ath10k,
but I had not.

With that enabled, the system tries to do encrypted traffic, but
it looks like the unicast frames from ath10k are corrupted.

> However, there are other problems in your log:
> 
> 1) There are two NL80211_CMD_JOIN_IBSS events from the kernel, for only
> one join request.
> 
> 2) wpa_supplicant sent a authentication frame at 1428534380.167582 and
> never got any tx_status response from the kernel.  This was before the
> second NL80211_CMD_JOIN_IBSS event.
> 
> Loosing a authentication frame is normally no big deal. It often
> happens. They are even stations that do not support them.  If i remember
> the logic that i implemented in wpa_supplicant, you consider the other
> station as authenticated if you receive an authentication response or an
> authentication request, or after a timeout.
> 
> 3) But this timeout seems buggy: after completing the EAPOL exchange,
> this timer fires:
> 
> 1428534381.168652: RSN: Timeout on waiting Authentication frame response
> from 00:0e:8e:3e:8b:96 - start authenticator
> 
> This timer shouldn't even be present. And even if it did, it shouldn't
> start the authenticator as it is already started.  I didn't track the
> latest changes in wpa_supplicant's IBSS-RSN support, but this seems wrong.
> 
> But it restart the authenticator anyway, which clears the PTK:
> 
> 1428534381.168693: AUTH: auth_set_key(alg=0 addr=00:0e:8e:3e:8b:96
> key_idx=0)
> 1428534381.168703: AUTH: set_key - key - hexdump(len=0): [NULL]
> 1428534381.168737: wpa_driver_nl80211_set_key: ifindex=131 (wlan0) alg=0
> addr=0x2344bb0 key_idx=0 set_tx=1 seq_len=6 key_len=0
> 1428534381.168751: nl80211: KEY_SEQ - hexdump(len=6): 00 00 00 00 00 00
> 1428534381.168761:    addr=00:0e:8e:3e:8b:96
> 
> And mark the station as unauthorized:
> 
> 1428534381.169266: nl80211: Set STA flags - ifname=wlan0
> addr=00:0e:8e:3e:8b:96 total_flags=0x0 flags_or=0x0 flags_and=0xfffffffe
> authorized=0
> 1428534381.169347: AUTH: 00:0e:8e:3e:8b:96 unauthorizing port
> 
> After that, it retries an EAPOL exchange which basically fail: the
> remote station still have an encrypted session, and the logic in
> wpa_supplicant is that you can only reset a encryption session by
> sending an authentication frame.


Ok, this is probably why I have to restart supplicant on each side when
I try to make the stations associate.

I think I'll look at this later, since now my stations are staying
authenticated long enough to do some traffic tests at least.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Thu Apr  9 19:38:16 2015
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 09 Apr 2015 19:38:16 -0700
Subject: IBSS support in ath10k - our test results and questions
In-Reply-To: <55257592.1080900@candelatech.com>
References: <2680922.jiTnlqor3W@prime> <550B425A.7090505@candelatech.com>
 <1638549.OfoyQL4eQV@bentobox> <5522C8A1.6040007@candelatech.com>
 <5522E6D3.30109@candelatech.com> <55257592.1080900@candelatech.com>
Message-ID: <55273798.3000004@candelatech.com>

I am still getting closer..found place in my 10.1 firmware that was setting
the mcast peer's key-index when it shouldn't, and now I can generate
udp broadcast frames on ath10k and ath9k receives them fine
(and they are encrypted on the air).

But, ARP request and response packets are being transmitted wrong by the ath10k.  Looks like
they are truncated and/or scrambled a bit..but they do decrypt on the
ath9k peer (just as mal-formed packet).

I found a bit of stuff that adjusts TID for ARP in the firmware,
but could not find any other special handling.

Anyone know if there is other special handling somewhere that might
account for this?

Thanks,
Ben


On 04/08/2015 11:38 AM, Ben Greear wrote:
> So, I've made some progress.
> 
> After fixing PSK (I had it misconfigured all of yesterday!), and with full restart of supplicant,
> I can get the 4-way to complete, and I see PTK and GTK set in driver and firmware.
> I do not know if the keys are set correctly, but the logs seem plausible.
> 
> After that, I see plain-text ARPs hit the air (the should be encrypted),
> and the last 21 bytes of the packet appear to be random garbage.
> 
> I am guessing driver and/or firmware and/or hardware is not properly
> encrypting the frames.
> 
> Off to do some more spelunking in the firmware.
> 
> Thanks,
> Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From michal.kazior at tieto.com  Fri Apr 10 05:26:39 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 10 Apr 2015 14:26:39 +0200
Subject: [PATCH V3 1/2] ath10k: Add abstraction layer for peer flags
In-Reply-To: <1425641270-4059-1-git-send-email-sjegadee@qti.qualcomm.com>
References: <1425641270-4059-1-git-send-email-sjegadee@qti.qualcomm.com>
Message-ID: <CA+BoTQmn6WTQY2OqS+jPeKHsJvy7Yxro0fuZ19xGzddfkJgJ3A@mail.gmail.com>

On 6 March 2015 at 12:27, SenthilKumar Jegadeesan
<sjegadee at qti.qualcomm.com> wrote:
> Abstraction layer for peer flags is added to fix
> ABI breakage.
>
> Signed-off-by: SenthilKumar Jegadeesan <sjegadee at qti.qualcomm.com>
[...]

Hi,

This patch seems to have many formatting issues:


> diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
> index f34baa0..a99793e 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
> @@ -2788,6 +2788,25 @@ static const struct wmi_ops wmi_tlv_ops = {
>         .gen_sta_keepalive = ath10k_wmi_tlv_op_gen_sta_keepalive,
>  };
>
> +static struct wmi_peer_flags_map wmi_tlv_peer_flags_map = {
> +        .auth = WMI_TLV_PEER_AUTH,
> +        .qos = WMI_TLV_PEER_QOS,
> +        .need_ptk_4_way = WMI_TLV_PEER_NEED_PTK_4_WAY,
> +        .need_gtk_2_way = WMI_TLV_PEER_NEED_GTK_2_WAY,
> +        .apsd = WMI_TLV_PEER_APSD,
> +        .ht = WMI_TLV_PEER_HT,
> +        .bw40 = WMI_TLV_PEER_40MHZ,
> +        .stbc = WMI_TLV_PEER_STBC,
> +        .ldbc = WMI_TLV_PEER_LDPC,
> +        .dyn_mimops = WMI_TLV_PEER_DYN_MIMOPS,
> +        .static_mimops = WMI_TLV_PEER_STATIC_MIMOPS,
> +        .spatial_mux = WMI_TLV_PEER_SPATIAL_MUX,
> +        .vht = WMI_TLV_PEER_VHT,
> +        .bw80 = WMI_TLV_PEER_80MHZ,
> +        .pmf = WMI_TLV_PEER_PMF,

Should be indented with tabs, not spaces.


> diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
> index d7a31e1..7159b69 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
> @@ -527,6 +527,25 @@ enum wmi_tlv_vdev_param {
>         WMI_TLV_VDEV_PARAM_IBSS_PS_1RX_CHAIN_IN_ATIM_WINDOW_ENABLE,
>  };
>
> +enum wmi_tlv_peer_flags {
> +

Unnecessary empty line.


> +        WMI_TLV_PEER_AUTH = 0x00000001,
> +        WMI_TLV_PEER_QOS = 0x00000002,
> +        WMI_TLV_PEER_NEED_PTK_4_WAY = 0x00000004,
> +        WMI_TLV_PEER_NEED_GTK_2_WAY = 0x00000010,
> +        WMI_TLV_PEER_APSD = 0x00000800,
> +        WMI_TLV_PEER_HT = 0x00001000,
> +        WMI_TLV_PEER_40MHZ = 0x00002000,
> +        WMI_TLV_PEER_STBC = 0x00008000,
> +        WMI_TLV_PEER_LDPC = 0x00010000,
> +        WMI_TLV_PEER_DYN_MIMOPS = 0x00020000,
> +        WMI_TLV_PEER_STATIC_MIMOPS = 0x00040000,
> +        WMI_TLV_PEER_SPATIAL_MUX = 0x00200000,
> +        WMI_TLV_PEER_VHT = 0x02000000,
> +        WMI_TLV_PEER_80MHZ = 0x04000000,
> +        WMI_TLV_PEER_PMF = 0x08000000,

Should be indented with tabs, not spaces.


> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index c7ea77e..6be3726 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
[...]
> +static struct wmi_peer_flags_map wmi_10x_peer_flags_map = {
> +        .auth = WMI_10X_PEER_AUTH,
> +        .qos = WMI_10X_PEER_QOS,
> +        .need_ptk_4_way = WMI_10X_PEER_NEED_PTK_4_WAY,
> +        .need_gtk_2_way = WMI_10X_PEER_NEED_GTK_2_WAY,
> +        .apsd = WMI_10X_PEER_APSD,
> +        .ht = WMI_10X_PEER_HT,
> +        .bw40 = WMI_10X_PEER_40MHZ,
> +        .stbc = WMI_10X_PEER_STBC,
> +        .ldbc = WMI_10X_PEER_LDPC,
> +        .dyn_mimops = WMI_10X_PEER_DYN_MIMOPS,
> +        .static_mimops = WMI_10X_PEER_STATIC_MIMOPS,
> +        .spatial_mux = WMI_10X_PEER_SPATIAL_MUX,
> +        .vht = WMI_10X_PEER_VHT,
> +        .bw80 = WMI_10X_PEER_80MHZ,

Should be indented with tabs, not spaces.


> +};
> +
> +static struct wmi_peer_flags_map wmi_10_2_peer_flags_map = {
> +        .auth = WMI_10_2_PEER_AUTH,
> +        .qos = WMI_10_2_PEER_QOS,
> +        .need_ptk_4_way = WMI_10_2_PEER_NEED_PTK_4_WAY,
> +        .need_gtk_2_way = WMI_10_2_PEER_NEED_GTK_2_WAY,
> +        .apsd = WMI_10_2_PEER_APSD,
> +        .ht = WMI_10_2_PEER_HT,
> +        .bw40 = WMI_10_2_PEER_40MHZ,
> +        .stbc = WMI_10_2_PEER_STBC,
> +        .ldbc = WMI_10_2_PEER_LDPC,
> +        .dyn_mimops = WMI_10_2_PEER_DYN_MIMOPS,
> +        .static_mimops = WMI_10_2_PEER_STATIC_MIMOPS,
> +        .spatial_mux = WMI_10_2_PEER_SPATIAL_MUX,
> +        .vht = WMI_10_2_PEER_VHT,
> +        .bw80 = WMI_10_2_PEER_80MHZ,
> +        .vht_2g = WMI_10_2_PEER_VHT_2G,
> +        .pmf = WMI_10_2_PEER_PMF,

Should be indented with tabs, not spaces.


> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
> index 28c1822..40d5244 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
[...]
> +struct wmi_peer_flags_map {
> +       u32 auth;
> +       u32 qos;
> +       u32 need_ptk_4_way;
> +       u32 need_gtk_2_way;
> +       u32 apsd;
> +       u32 ht;
> +       u32 bw40;
> +       u32 stbc;
> +       u32 ldbc;
> +       u32 dyn_mimops;
> +       u32 static_mimops;
> +       u32 spatial_mux;
> +       u32 vht;
> +       u32 bw80;
> +       u32 vht_2g;
> +       u32 pmf;
> +};
> +
> +enum wmi_peer_flags {
> +

Unnecessary empty line.


> +       WMI_PEER_AUTH = 0x00000001,
> +       WMI_PEER_QOS = 0x00000002,
> +       WMI_PEER_NEED_PTK_4_WAY = 0x00000004,
> +       WMI_PEER_NEED_GTK_2_WAY = 0x00000010,
> +       WMI_PEER_APSD = 0x00000800,
> +       WMI_PEER_HT = 0x00001000,
> +       WMI_PEER_40MHZ = 0x00002000,
> +       WMI_PEER_STBC = 0x00008000,
> +       WMI_PEER_LDPC = 0x00010000,
> +       WMI_PEER_DYN_MIMOPS = 0x00020000,
> +       WMI_PEER_STATIC_MIMOPS = 0x00040000,
> +       WMI_PEER_SPATIAL_MUX = 0x00200000,
> +       WMI_PEER_VHT = 0x02000000,
> +       WMI_PEER_80MHZ = 0x04000000,
> +       WMI_PEER_VHT_2G = 0x08000000,
> +       WMI_PEER_PMF = 0x10000000,
> +};
> +
> +enum wmi_10x_peer_flags {
> +

Unnecessary empty lines.


> +       WMI_10X_PEER_AUTH = 0x00000001,

This one's good, but..


> +        WMI_10X_PEER_QOS = 0x00000002,
> +        WMI_10X_PEER_NEED_PTK_4_WAY = 0x00000004,
> +        WMI_10X_PEER_NEED_GTK_2_WAY = 0x00000010,
> +        WMI_10X_PEER_APSD = 0x00000800,
> +        WMI_10X_PEER_HT = 0x00001000,
> +        WMI_10X_PEER_40MHZ = 0x00002000,
> +        WMI_10X_PEER_STBC = 0x00008000,
> +        WMI_10X_PEER_LDPC = 0x00010000,
> +        WMI_10X_PEER_DYN_MIMOPS = 0x00020000,
> +        WMI_10X_PEER_STATIC_MIMOPS = 0x00040000,
> +        WMI_10X_PEER_SPATIAL_MUX = 0x00200000,
> +        WMI_10X_PEER_VHT = 0x02000000,
> +        WMI_10X_PEER_80MHZ = 0x04000000,

These should be indented with tabs as well, not spaces.


> +};
> +
> +enum wmi_10_2_peer_flags {
> +

Unnecessary empty line.


> +        WMI_10_2_PEER_AUTH = 0x00000001,
> +        WMI_10_2_PEER_QOS = 0x00000002,
> +        WMI_10_2_PEER_NEED_PTK_4_WAY = 0x00000004,
> +        WMI_10_2_PEER_NEED_GTK_2_WAY = 0x00000010,
> +        WMI_10_2_PEER_APSD = 0x00000800,
> +        WMI_10_2_PEER_HT = 0x00001000,
> +        WMI_10_2_PEER_40MHZ = 0x00002000,
> +        WMI_10_2_PEER_STBC = 0x00008000,
> +        WMI_10_2_PEER_LDPC = 0x00010000,
> +        WMI_10_2_PEER_DYN_MIMOPS = 0x00020000,
> +        WMI_10_2_PEER_STATIC_MIMOPS = 0x00040000,
> +        WMI_10_2_PEER_SPATIAL_MUX = 0x00200000,
> +        WMI_10_2_PEER_VHT = 0x02000000,
> +        WMI_10_2_PEER_80MHZ = 0x04000000,
> +        WMI_10_2_PEER_VHT_2G = 0x08000000,
> +        WMI_10_2_PEER_PMF = 0x10000000,

Should be indented with tabs, not spaces.


Micha?


From michal.kazior at tieto.com  Fri Apr 10 06:01:27 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 10 Apr 2015 13:01:27 +0000
Subject: [PATCH] ath10k: fix error handling in pci_probe
Message-ID: <1428670887-7533-1-git-send-email-michal.kazior@tieto.com>

If chip_id wasn't recognized clean up code wasn't
executed properly. It would skip freeing memory
causing a leak and irqs causing possibly MSI
warning splats later or even kernel crashes.

Fixes: 1a7fecb766c8 ("ath10k: reset chip before reading chip_id in probe")
Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 262a84f67f62..1f770ac28df4 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2684,7 +2684,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
 	if (!ath10k_pci_chip_is_supported(pdev->device, chip_id)) {
 		ath10k_err(ar, "device %04x with chip_id %08x isn't supported\n",
 			   pdev->device, chip_id);
-		goto err_sleep;
+		goto err_free_irq;
 	}
 
 	ret = ath10k_core_register(ar, chip_id);
-- 
2.1.4



From michal.kazior at tieto.com  Fri Apr 10 06:02:28 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 10 Apr 2015 13:02:28 +0000
Subject: [PATCH] ath10k: add extra check for frame tracing
Message-ID: <1428670948-7665-1-git-send-email-michal.kazior@tieto.com>

Frames are logged via tracing in two slices:
header and payload, separately. This is done for
performance reasons when one wants to, e.g.
analyse metadata only of frames only.

If for some reason device delivered a frame buffer
which was sized below what 802.11 header implied
tracing logic would blow doing an invalid memory
accesses.

I've hit this problem when running IBSS on QCA988X
with 999.999.0.636 and tracing at the same time.

Fixes: 5ce8e7fdcc7a ("ath10k: handle ieee80211 header and payload tracing separately")
Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/trace.h | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/trace.h b/drivers/net/wireless/ath/ath10k/trace.h
index 71dfcd96354b..71bdb368813d 100644
--- a/drivers/net/wireless/ath/ath10k/trace.h
+++ b/drivers/net/wireless/ath/ath10k/trace.h
@@ -21,11 +21,16 @@
 #include "core.h"
 
 #if !defined(_TRACE_H_)
-static inline u32 ath10k_frm_hdr_len(const void *buf)
+static inline u32 ath10k_frm_hdr_len(const void *buf, size_t len)
 {
 	const struct ieee80211_hdr *hdr = buf;
 
-	return ieee80211_hdrlen(hdr->frame_control);
+	/* In some rare cases (e.g. fcs error) device reports frame buffer
+	 * shorter than what frame header implies (e.g. len = 0). The buffer
+	 * can still be accessed so do a simple min() to guarantee caller
+	 * doesn't get value greater than len.
+	 */
+	return min_t(u32, len, ieee80211_hdrlen(hdr->frame_control));
 }
 #endif
 
@@ -360,13 +365,13 @@ DECLARE_EVENT_CLASS(ath10k_hdr_event,
 		__string(device, dev_name(ar->dev))
 		__string(driver, dev_driver_string(ar->dev))
 		__field(size_t, len)
-		__dynamic_array(u8, data, ath10k_frm_hdr_len(data))
+		__dynamic_array(u8, data, ath10k_frm_hdr_len(data, len))
 	),
 
 	TP_fast_assign(
 		__assign_str(device, dev_name(ar->dev));
 		__assign_str(driver, dev_driver_string(ar->dev));
-		__entry->len = ath10k_frm_hdr_len(data);
+		__entry->len = ath10k_frm_hdr_len(data, len);
 		memcpy(__get_dynamic_array(data), data, __entry->len);
 	),
 
@@ -387,15 +392,16 @@ DECLARE_EVENT_CLASS(ath10k_payload_event,
 		__string(device, dev_name(ar->dev))
 		__string(driver, dev_driver_string(ar->dev))
 		__field(size_t, len)
-		__dynamic_array(u8, payload, (len - ath10k_frm_hdr_len(data)))
+		__dynamic_array(u8, payload, (len -
+					      ath10k_frm_hdr_len(data, len)))
 	),
 
 	TP_fast_assign(
 		__assign_str(device, dev_name(ar->dev));
 		__assign_str(driver, dev_driver_string(ar->dev));
-		__entry->len = len - ath10k_frm_hdr_len(data);
+		__entry->len = len - ath10k_frm_hdr_len(data, len);
 		memcpy(__get_dynamic_array(payload),
-		       data + ath10k_frm_hdr_len(data), __entry->len);
+		       data + ath10k_frm_hdr_len(data, len), __entry->len);
 	),
 
 	TP_printk(
-- 
2.1.4



From michal.kazior at tieto.com  Fri Apr 10 06:05:58 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 10 Apr 2015 13:05:58 +0000
Subject: [PATCH] ath10k: change static wep key handling for client mode
Message-ID: <1428671158-8159-1-git-send-email-michal.kazior@tieto.com>

mac80211 sets static WEP keys as groupwise while
firmware requires them to be installed twice as
both pairwise and groupwise.

Until now these keys were installed once as
pairwise only and, due to that special handling,
needed additional tricks to support 802.1x as
well.

Without this patch in some cases (when AP and
ath10k client use different default tx keys)
multicast communication was broken.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 89 +++++++++--------------------------
 1 file changed, 23 insertions(+), 66 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index a7a84f52b8b4..79ce278ddb32 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -360,47 +360,6 @@ static int ath10k_clear_vdev_key(struct ath10k_vif *arvif,
 	return first_errno;
 }
 
-static int ath10k_mac_vif_sta_fix_wep_key(struct ath10k_vif *arvif, int keyidx)
-{
-	struct ath10k *ar = arvif->ar;
-	enum nl80211_iftype iftype = arvif->vif->type;
-	struct ieee80211_key_conf *key;
-	u32 flags;
-	int ret;
-	int i;
-
-	lockdep_assert_held(&ar->conf_mutex);
-
-	if (iftype != NL80211_IFTYPE_STATION)
-		return 0;
-
-	if (keyidx < 0)
-		return 0;
-
-	for (i = 0; i < ARRAY_SIZE(arvif->wep_keys); i++) {
-		if (!arvif->wep_keys[i])
-			continue;
-
-		key = arvif->wep_keys[i];
-
-		flags = 0;
-		flags |= WMI_KEY_PAIRWISE;
-
-		if (key->keyidx == keyidx)
-			flags |= WMI_KEY_TX_USAGE;
-
-		ret = ath10k_install_key(arvif, key, SET_KEY, arvif->bssid,
-					 flags);
-		if (ret) {
-			ath10k_warn(ar, "failed to install key %i on vdev %i: %d\n",
-				    key->keyidx, arvif->vdev_id, ret);
-			return ret;
-		}
-	}
-
-	return 0;
-}
-
 static int ath10k_mac_vif_update_wep_key(struct ath10k_vif *arvif,
 					 struct ieee80211_key_conf *key)
 {
@@ -4703,7 +4662,9 @@ static int ath10k_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 	bool is_wep = key->cipher == WLAN_CIPHER_SUITE_WEP40 ||
 		      key->cipher == WLAN_CIPHER_SUITE_WEP104;
 	int ret = 0;
+	int ret2;
 	u32 flags = 0;
+	u32 flags2;
 
 	/* this one needs to be done in software */
 	if (key->cipher == WLAN_CIPHER_SUITE_AES_CMAC)
@@ -4774,24 +4735,6 @@ static int ath10k_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 		 */
 		if (cmd == SET_KEY && arvif->def_wep_key_idx == -1)
 			flags |= WMI_KEY_TX_USAGE;
-
-		/* mac80211 uploads static WEP keys as groupwise while fw/hw
-		 * requires pairwise keys for non-self peers, i.e. BSSID in STA
-		 * mode and associated stations in AP/IBSS.
-		 *
-		 * Static WEP keys for peer_addr=vif->addr and 802.1X WEP keys
-		 * work fine when mapped directly from mac80211.
-		 *
-		 * Note: When installing first static WEP groupwise key (which
-		 * should be pairwise) def_wep_key_idx isn't known yet (it's
-		 * equal to -1).  Since .set_default_unicast_key is called only
-		 * for static WEP it's used to re-upload the key as pairwise.
-		 */
-		if (arvif->def_wep_key_idx >= 0 &&
-		    memcmp(peer_addr, arvif->vif->addr, ETH_ALEN)) {
-			flags &= ~WMI_KEY_GROUP;
-			flags |= WMI_KEY_PAIRWISE;
-		}
 	}
 
 	ret = ath10k_install_key(arvif, key, cmd, peer_addr, flags);
@@ -4801,6 +4744,27 @@ static int ath10k_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 		goto exit;
 	}
 
+	/* mac80211 sets static WEP keys as groupwise while firmware requires
+	 * them to be installed twice as both pairwise and groupwise.
+	 */
+	if (is_wep && !sta && vif->type == NL80211_IFTYPE_STATION) {
+		flags2 = flags;
+		flags2 &= ~WMI_KEY_GROUP;
+		flags2 |= WMI_KEY_PAIRWISE;
+
+		ret = ath10k_install_key(arvif, key, cmd, peer_addr, flags2);
+		if (ret) {
+			ath10k_warn(ar, "failed to install (ucast) key for vdev %i peer %pM: %d\n",
+				    arvif->vdev_id, peer_addr, ret);
+			ret2 = ath10k_install_key(arvif, key, DISABLE_KEY,
+						  peer_addr, flags);
+			if (ret2)
+				ath10k_warn(ar, "failed to disable (mcast) key for vdev %i peer %pM: %d\n",
+					    arvif->vdev_id, peer_addr, ret2);
+			goto exit;
+		}
+	}
+
 	ath10k_set_key_h_def_keyidx(ar, arvif, cmd, key);
 
 	spin_lock_bh(&ar->data_lock);
@@ -4849,13 +4813,6 @@ static void ath10k_set_default_unicast_key(struct ieee80211_hw *hw,
 
 	arvif->def_wep_key_idx = keyidx;
 
-	ret = ath10k_mac_vif_sta_fix_wep_key(arvif, keyidx);
-	if (ret) {
-		ath10k_warn(ar, "failed to fix sta wep key on vdev %i: %d\n",
-			    arvif->vdev_id, ret);
-		goto unlock;
-	}
-
 unlock:
 	mutex_unlock(&arvif->ar->conf_mutex);
 }
-- 
2.1.4



From michal.kazior at tieto.com  Fri Apr 10 06:23:20 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 10 Apr 2015 13:23:20 +0000
Subject: [PATCH 1/4] ath10k: don't use reassoc flag
In-Reply-To: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
References: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1428672203-8604-2-git-send-email-michal.kazior@tieto.com>

Firmware actually re-creates peer entry when
reassoc flag is set. This is undesired and could
cause trouble with IBSS crypto-wise. This is also
important for upcomming bitrate mask improvement.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index a7a84f52b8b4..6664bcc9ba88 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2593,7 +2593,6 @@ static int ath10k_station_assoc(struct ath10k *ar,
 		return ret;
 	}
 
-	peer_arg.peer_reassoc = reassoc;
 	ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
 	if (ret) {
 		ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev %i: %d\n",
-- 
2.1.4



From michal.kazior at tieto.com  Fri Apr 10 06:23:19 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 10 Apr 2015 13:23:19 +0000
Subject: [PATCH 0/4] ath10k: ibss crypto fixes
Message-ID: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>

I've mainly tested this on kvalo/pending branch.
Currently master branch contains 0f611d28fc2e
("mac80211: count interfaces correctly for
combination checks") which breaks IBSS in
wpa_supplicant due to P2P Device and interface
combinations. This has been pointed out in the
following thread:

 [1]: http://thread.gmane.org/gmane.linux.kernel.wireless.general/135570/focus=136643

If someone's interested in running ath10k IBSS
make sure to use kernel prior to 4.0, revert the
mentioned mac80211 patch or apply wpa_supplicant
workaround patch from [1].


Janusz Dziedzic (1):
  ath10k: enable ibss-rsn

Michal Kazior (3):
  ath10k: don't use reassoc flag
  ath10k: fix multiple key static wep with ibss
  ath10k: set def key idx for ibss

 drivers/net/wireless/ath/ath10k/mac.c | 44 +++++++++++++++++++++++++++++------
 1 file changed, 37 insertions(+), 7 deletions(-)

-- 
2.1.4



From michal.kazior at tieto.com  Fri Apr 10 06:23:22 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 10 Apr 2015 13:23:22 +0000
Subject: [PATCH 3/4] ath10k: set def key idx for ibss
In-Reply-To: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
References: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1428672203-8604-4-git-send-email-michal.kazior@tieto.com>

Some time ago there was a weird issue with AP
using wrong multicast keys and generating
corrupted traffic on 10.1 firmware.

Apparently a very similar problem applies for
IBSS-RSN on 999.999.0.636.

ath10k doesn't have IBSS-RSN enabled yet. This
patch is a prerequisite to support it.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 93f753cb839a..9428d75d0d76 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4691,10 +4691,14 @@ static void ath10k_set_key_h_def_keyidx(struct ath10k *ar,
 	 * frames with multi-vif APs. This is not required for main firmware
 	 * branch (e.g. 636).
 	 *
-	 * FIXME: This has been tested only in AP. It remains unknown if this
-	 * is required for multi-vif STA interfaces on 10.1 */
+	 * This is also needed for 636 fw for IBSS-RSN to work more reliably.
+	 *
+	 * FIXME: It remains unknown if this is required for multi-vif STA
+	 * interfaces on 10.1.
+	 */
 
-	if (arvif->vdev_type != WMI_VDEV_TYPE_AP)
+	if (arvif->vdev_type != WMI_VDEV_TYPE_AP &&
+	    arvif->vdev_type != WMI_VDEV_TYPE_IBSS)
 		return;
 
 	if (key->cipher == WLAN_CIPHER_SUITE_WEP40)
-- 
2.1.4



From michal.kazior at tieto.com  Fri Apr 10 06:23:21 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 10 Apr 2015 13:23:21 +0000
Subject: [PATCH 2/4] ath10k: fix multiple key static wep with ibss
In-Reply-To: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
References: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1428672203-8604-3-git-send-email-michal.kazior@tieto.com>

Apparently firmware requires both pairwise and
groupwise keys to be installed per-peer for static
WEP in IBSS. This wasn't necessary for AP mode
(and installing both doesn't seem to break AP
mode thus there's no special handling).

Also there seems to be some kind of issue with
mapping tx/rx keys in firmware properly which
resulted in wrong keys being used and broken
communication between devices.

It can be argued the vdev param part is more of a
workaround than a real fix. However I couldn't
figure out how to fix this differently. It works
and isn't super ugly.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 31 ++++++++++++++++++++++++++++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 6664bcc9ba88..93f753cb839a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -230,9 +230,13 @@ static int ath10k_install_peer_wep_keys(struct ath10k_vif *arvif,
 		flags = 0;
 		flags |= WMI_KEY_PAIRWISE;
 
-		/* set TX_USAGE flag for default key id */
-		if (arvif->def_wep_key_idx == i)
-			flags |= WMI_KEY_TX_USAGE;
+		ret = ath10k_install_key(arvif, arvif->wep_keys[i], SET_KEY,
+					 addr, flags);
+		if (ret)
+			return ret;
+
+		flags = 0;
+		flags |= WMI_KEY_GROUP;
 
 		ret = ath10k_install_key(arvif, arvif->wep_keys[i], SET_KEY,
 					 addr, flags);
@@ -244,6 +248,27 @@ static int ath10k_install_peer_wep_keys(struct ath10k_vif *arvif,
 		spin_unlock_bh(&ar->data_lock);
 	}
 
+	/* In some cases (notably with static WEP IBSS with multiple keys)
+	 * multicast Tx becomes broken. Both pairwise and groupwise keys are
+	 * installed already. Using WMI_KEY_TX_USAGE in different combinations
+	 * didn't seem help. Using def_keyid vdev parameter seems to be
+	 * effective so use that.
+	 *
+	 * FIXME: Revisit. Perhaps this can be done in a less hacky way.
+	 */
+	if (arvif->def_wep_key_idx == -1)
+		return 0;
+
+	ret = ath10k_wmi_vdev_set_param(arvif->ar,
+					arvif->vdev_id,
+					arvif->ar->wmi.vdev_param->def_keyid,
+					arvif->def_wep_key_idx);
+	if (ret) {
+		ath10k_warn(ar, "failed to re-set def wpa key idxon vdev %i: %d\n",
+			    arvif->vdev_id, ret);
+		return ret;
+	}
+
 	return 0;
 }
 
-- 
2.1.4



From michal.kazior at tieto.com  Fri Apr 10 06:23:23 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 10 Apr 2015 13:23:23 +0000
Subject: [PATCH 4/4] ath10k: enable ibss-rsn
In-Reply-To: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
References: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1428672203-8604-5-git-send-email-michal.kazior@tieto.com>

From: Janusz Dziedzic <janusz.dziedzic at tieto.com>

With latest additions to the driver it seems
viable to enable support for IBSS-RSN.

It seems to work on QCA988X and 999.999.0.636 but
is a bit slow to exchange RSN keys for some
reason. This may be a firmware quirk or ath10k is
missing something. Nevertheless it makes sense to
finally enable IBSS-RSN in ath10k even if somewhat
handicapped.

QCA6174 firmware doesn't seem to be able to Tx
EAPOL frames at all now (they get stuck in hw
queues for some reason) so it never gets to set
the keys in driver. It's fairly safe to assume that
once this is fixed IBSS-RSN will work with QCA6174
firmware without any additional changes. Hence no
special handling for advertising
IEEE80211_HW_SUPPORTS_PER_STA_GTK and
WIPHY_FLAG_IBSS_RSN is done now.

Signed-off-by: Janusz Dziedzic <janusz.dziedzic at tieto.com>
Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 9428d75d0d76..7485d5ccee3d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6720,11 +6720,13 @@ int ath10k_mac_register(struct ath10k *ar)
 			IEEE80211_HW_SPECTRUM_MGMT |
 			IEEE80211_HW_SW_CRYPTO_CONTROL |
 			IEEE80211_HW_CONNECTION_MONITOR |
+			IEEE80211_HW_SUPPORTS_PER_STA_GTK |
 			IEEE80211_HW_WANT_MONITOR_VIF |
 			IEEE80211_HW_CHANCTX_STA_CSA |
 			IEEE80211_HW_QUEUE_CONTROL;
 
 	ar->hw->wiphy->features |= NL80211_FEATURE_STATIC_SMPS;
+	ar->hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN;
 
 	if (ar->ht_cap_info & WMI_HT_CAP_DYNAMIC_SMPS)
 		ar->hw->wiphy->features |= NL80211_FEATURE_DYNAMIC_SMPS;
-- 
2.1.4



From michal.kazior at tieto.com  Fri Apr 10 06:32:52 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 10 Apr 2015 13:32:52 +0000
Subject: [PATCH] ath10k: implement more versatile set_bitrate_mask
Message-ID: <1428672772-9275-1-git-send-email-michal.kazior@tieto.com>

Until now only a single fixed tx rate or nss was
allowed to be set.

The patch attempts to improve this by allowing
most bitrate masks. The limitation is VHT MCS
rates cannot be expressed separately using
existing firmware interfaces and only the
following VHT MCS ranges are supported: none, 0-7,
0-8, and 0-9.

This keeps the old behaviour when requesting
single tx rate or single nss. The new bitrate mask
logic is only applied to other cases that would
return -EINVAL until now.

Depending on firmware revisions some combinations
may crash firmware so use with care, please.

This depends on "ath10k: don't use reassoc flag".
Without it key cache would effectively be
invalidated upon bitrate change leading to
communication being no longer possible.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---

Notes:
    v3:
     * fix rebase derp (use s/arvif->bitrate_mask/mask/
                        in op_set_bitrate_mask)
     * get rid of 2 `WARNING: line over 80 characters`
     * update commit message
    
    v2:
     * fix out-of-bounds array access [Kalle]
       (the vht_mcs_mask shouldn't have been used in peer_h_ht
        helper to begin with)

 drivers/net/wireless/ath/ath10k/core.h |   1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 270 ++++++++++++++++++++++++++++++---
 2 files changed, 251 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index b0e8905ca325..0a36f3b7fd87 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -354,6 +354,7 @@ struct ath10k_vif {
 	struct wmi_wmm_params_all_arg wmm_params;
 	struct work_struct ap_csa_work;
 	struct delayed_work connection_loss_work;
+	struct cfg80211_bitrate_mask bitrate_mask;
 };
 
 struct ath10k_vif_iter {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index a7a84f52b8b4..256848587653 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -130,6 +130,30 @@ static int ath10k_mac_get_max_vht_mcs_map(u16 mcs_map, int nss)
 	return 0;
 }
 
+static u32
+ath10k_mac_max_ht_nss(const u8 ht_mcs_mask[IEEE80211_HT_MCS_MASK_LEN])
+{
+	int nss;
+
+	for (nss = IEEE80211_HT_MCS_MASK_LEN - 1; nss >= 0; nss--)
+		if (ht_mcs_mask[nss])
+			return nss + 1;
+
+	return 1;
+}
+
+static u32
+ath10k_mac_max_vht_nss(const u16 vht_mcs_mask[NL80211_VHT_NSS_MAX])
+{
+	int nss;
+
+	for (nss = NL80211_VHT_NSS_MAX - 1; nss >= 0; nss--)
+		if (vht_mcs_mask[nss])
+			return nss + 1;
+
+	return 1;
+}
+
 /**********/
 /* Crypto */
 /**********/
@@ -2009,10 +2033,12 @@ static void ath10k_peer_assoc_h_rates(struct ath10k *ar,
 				      struct ieee80211_sta *sta,
 				      struct wmi_peer_assoc_complete_arg *arg)
 {
+	struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
 	struct wmi_rate_set_arg *rateset = &arg->peer_legacy_rates;
 	struct cfg80211_chan_def def;
 	const struct ieee80211_supported_band *sband;
 	const struct ieee80211_rate *rates;
+	enum ieee80211_band band;
 	u32 ratemask;
 	u8 rate;
 	int i;
@@ -2022,8 +2048,10 @@ static void ath10k_peer_assoc_h_rates(struct ath10k *ar,
 	if (WARN_ON(ath10k_mac_vif_chan(vif, &def)))
 		return;
 
-	sband = ar->hw->wiphy->bands[def.chan->band];
-	ratemask = sta->supp_rates[def.chan->band];
+	band = def.chan->band;
+	sband = ar->hw->wiphy->bands[band];
+	ratemask = sta->supp_rates[band];
+	ratemask &= arvif->bitrate_mask.control[band].legacy;
 	rates = sband->bitrates;
 
 	rateset->num_rates = 0;
@@ -2038,19 +2066,60 @@ static void ath10k_peer_assoc_h_rates(struct ath10k *ar,
 	}
 }
 
+static bool
+ath10k_peer_assoc_h_ht_masked(const u8 ht_mcs_mask[IEEE80211_HT_MCS_MASK_LEN])
+{
+	int nss;
+
+	for (nss = 0; nss < IEEE80211_HT_MCS_MASK_LEN; nss++)
+		if (ht_mcs_mask[nss])
+			return false;
+
+	return true;
+}
+
+static bool
+ath10k_peer_assoc_h_vht_masked(const u16 vht_mcs_mask[NL80211_VHT_NSS_MAX])
+{
+	int nss;
+
+	for (nss = 0; nss < NL80211_VHT_NSS_MAX; nss++)
+		if (vht_mcs_mask[nss])
+			return false;
+
+	return true;
+}
+
 static void ath10k_peer_assoc_h_ht(struct ath10k *ar,
+				   struct ieee80211_vif *vif,
 				   struct ieee80211_sta *sta,
 				   struct wmi_peer_assoc_complete_arg *arg)
 {
 	const struct ieee80211_sta_ht_cap *ht_cap = &sta->ht_cap;
-	int i, n;
+	struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+	struct cfg80211_chan_def def;
+	enum ieee80211_band band;
+	const u8 *ht_mcs_mask;
+	const u16 *vht_mcs_mask;
+	int i, n, max_nss;
 	u32 stbc;
 
 	lockdep_assert_held(&ar->conf_mutex);
 
+	if (WARN_ON(ath10k_mac_vif_chan(vif, &def)))
+		return;
+
 	if (!ht_cap->ht_supported)
 		return;
 
+	band = def.chan->band;
+	ht_mcs_mask = arvif->bitrate_mask.control[band].ht_mcs;
+	vht_mcs_mask = arvif->bitrate_mask.control[band].vht_mcs;
+
+	if (ath10k_peer_assoc_h_ht_masked(ht_mcs_mask) &&
+	    ath10k_peer_assoc_h_vht_masked(vht_mcs_mask))
+		return;
+
 	arg->peer_flags |= WMI_PEER_HT;
 	arg->peer_max_mpdu = (1 << (IEEE80211_HT_MAX_AMPDU_FACTOR +
 				    ht_cap->ampdu_factor)) - 1;
@@ -2069,11 +2138,13 @@ static void ath10k_peer_assoc_h_ht(struct ath10k *ar,
 		arg->peer_rate_caps |= WMI_RC_CW40_FLAG;
 	}
 
-	if (ht_cap->cap & IEEE80211_HT_CAP_SGI_20)
-		arg->peer_rate_caps |= WMI_RC_SGI_FLAG;
+	if (arvif->bitrate_mask.control[band].gi != NL80211_TXRATE_FORCE_LGI) {
+		if (ht_cap->cap & IEEE80211_HT_CAP_SGI_20)
+			arg->peer_rate_caps |= WMI_RC_SGI_FLAG;
 
-	if (ht_cap->cap & IEEE80211_HT_CAP_SGI_40)
-		arg->peer_rate_caps |= WMI_RC_SGI_FLAG;
+		if (ht_cap->cap & IEEE80211_HT_CAP_SGI_40)
+			arg->peer_rate_caps |= WMI_RC_SGI_FLAG;
+	}
 
 	if (ht_cap->cap & IEEE80211_HT_CAP_TX_STBC) {
 		arg->peer_rate_caps |= WMI_RC_TX_STBC_FLAG;
@@ -2093,9 +2164,12 @@ static void ath10k_peer_assoc_h_ht(struct ath10k *ar,
 	else if (ht_cap->mcs.rx_mask[1])
 		arg->peer_rate_caps |= WMI_RC_DS_FLAG;
 
-	for (i = 0, n = 0; i < IEEE80211_HT_MCS_MASK_LEN*8; i++)
-		if (ht_cap->mcs.rx_mask[i/8] & (1 << i%8))
+	for (i = 0, n = 0, max_nss = 0; i < IEEE80211_HT_MCS_MASK_LEN * 8; i++)
+		if ((ht_cap->mcs.rx_mask[i / 8] & BIT(i % 8)) &&
+		    (ht_mcs_mask[i / 8] & BIT(i % 8))) {
+			max_nss = (i / 8) + 1;
 			arg->peer_ht_rates.rates[n++] = i;
+		}
 
 	/*
 	 * This is a workaround for HT-enabled STAs which break the spec
@@ -2112,7 +2186,7 @@ static void ath10k_peer_assoc_h_ht(struct ath10k *ar,
 			arg->peer_ht_rates.rates[i] = i;
 	} else {
 		arg->peer_ht_rates.num_rates = n;
-		arg->peer_num_spatial_streams = sta->rx_nss;
+		arg->peer_num_spatial_streams = max_nss;
 	}
 
 	ath10k_dbg(ar, ATH10K_DBG_MAC, "mac ht peer %pM mcs cnt %d nss %d\n",
@@ -2188,13 +2262,63 @@ static int ath10k_peer_assoc_qos_ap(struct ath10k *ar,
 	return 0;
 }
 
+static u16
+ath10k_peer_assoc_h_vht_limit(u16 tx_mcs_set,
+			      const u16 vht_mcs_limit[NL80211_VHT_NSS_MAX])
+{
+	int idx_limit;
+	int nss;
+	u16 mcs_map;
+	u16 mcs;
+
+	for (nss = 0; nss < NL80211_VHT_NSS_MAX; nss++) {
+		mcs_map = ath10k_mac_get_max_vht_mcs_map(tx_mcs_set, nss) &
+			  vht_mcs_limit[nss];
+
+		if (mcs_map)
+			idx_limit = fls(mcs_map) - 1;
+		else
+			idx_limit = -1;
+
+		switch (idx_limit) {
+		case 0: /* fall through */
+		case 1: /* fall through */
+		case 2: /* fall through */
+		case 3: /* fall through */
+		case 4: /* fall through */
+		case 5: /* fall through */
+		case 6: /* fall through */
+		default:
+			/* see ath10k_mac_can_set_bitrate_mask() */
+			WARN_ON(1);
+			/* fall through */
+		case -1:
+			mcs = IEEE80211_VHT_MCS_NOT_SUPPORTED; break;
+		case 7:
+			mcs = IEEE80211_VHT_MCS_SUPPORT_0_7; break;
+		case 8:
+			mcs = IEEE80211_VHT_MCS_SUPPORT_0_8; break;
+		case 9:
+			mcs = IEEE80211_VHT_MCS_SUPPORT_0_9; break;
+		}
+
+		tx_mcs_set &= ~(0x3 << (nss * 2));
+		tx_mcs_set |= mcs << (nss * 2);
+	}
+
+	return tx_mcs_set;
+}
+
 static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
 				    struct ieee80211_vif *vif,
 				    struct ieee80211_sta *sta,
 				    struct wmi_peer_assoc_complete_arg *arg)
 {
 	const struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
+	struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
 	struct cfg80211_chan_def def;
+	enum ieee80211_band band;
+	const u16 *vht_mcs_mask;
 	u8 ampdu_factor;
 
 	if (WARN_ON(ath10k_mac_vif_chan(vif, &def)))
@@ -2203,6 +2327,12 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
 	if (!vht_cap->vht_supported)
 		return;
 
+	band = def.chan->band;
+	vht_mcs_mask = arvif->bitrate_mask.control[band].vht_mcs;
+
+	if (ath10k_peer_assoc_h_vht_masked(vht_mcs_mask))
+		return;
+
 	arg->peer_flags |= WMI_PEER_VHT;
 
 	if (def.chan->band == IEEE80211_BAND_2GHZ)
@@ -2231,8 +2361,8 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
 		__le16_to_cpu(vht_cap->vht_mcs.rx_mcs_map);
 	arg->peer_vht_rates.tx_max_rate =
 		__le16_to_cpu(vht_cap->vht_mcs.tx_highest);
-	arg->peer_vht_rates.tx_mcs_set =
-		__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map);
+	arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
+		__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
 
 	ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 0x%x\n",
 		   sta->addr, arg->peer_max_mpdu, arg->peer_flags);
@@ -2282,20 +2412,30 @@ static void ath10k_peer_assoc_h_phymode(struct ath10k *ar,
 					struct ieee80211_sta *sta,
 					struct wmi_peer_assoc_complete_arg *arg)
 {
+	struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
 	struct cfg80211_chan_def def;
+	enum ieee80211_band band;
+	const u8 *ht_mcs_mask;
+	const u16 *vht_mcs_mask;
 	enum wmi_phy_mode phymode = MODE_UNKNOWN;
 
 	if (WARN_ON(ath10k_mac_vif_chan(vif, &def)))
 		return;
 
-	switch (def.chan->band) {
+	band = def.chan->band;
+	ht_mcs_mask = arvif->bitrate_mask.control[band].ht_mcs;
+	vht_mcs_mask = arvif->bitrate_mask.control[band].vht_mcs;
+
+	switch (band) {
 	case IEEE80211_BAND_2GHZ:
-		if (sta->vht_cap.vht_supported) {
+		if (sta->vht_cap.vht_supported &&
+		    !ath10k_peer_assoc_h_vht_masked(vht_mcs_mask)) {
 			if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
 				phymode = MODE_11AC_VHT40;
 			else
 				phymode = MODE_11AC_VHT20;
-		} else if (sta->ht_cap.ht_supported) {
+		} else if (sta->ht_cap.ht_supported &&
+			   !ath10k_peer_assoc_h_ht_masked(ht_mcs_mask)) {
 			if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
 				phymode = MODE_11NG_HT40;
 			else
@@ -2311,15 +2451,17 @@ static void ath10k_peer_assoc_h_phymode(struct ath10k *ar,
 		/*
 		 * Check VHT first.
 		 */
-		if (sta->vht_cap.vht_supported) {
+		if (sta->vht_cap.vht_supported &&
+		    !ath10k_peer_assoc_h_vht_masked(vht_mcs_mask)) {
 			if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 				phymode = MODE_11AC_VHT80;
 			else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
 				phymode = MODE_11AC_VHT40;
 			else if (sta->bandwidth == IEEE80211_STA_RX_BW_20)
 				phymode = MODE_11AC_VHT20;
-		} else if (sta->ht_cap.ht_supported) {
-			if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
+		} else if (sta->ht_cap.ht_supported &&
+			   !ath10k_peer_assoc_h_ht_masked(ht_mcs_mask)) {
+			if (sta->bandwidth >= IEEE80211_STA_RX_BW_40)
 				phymode = MODE_11NA_HT40;
 			else
 				phymode = MODE_11NA_HT20;
@@ -2351,7 +2493,7 @@ static int ath10k_peer_assoc_prepare(struct ath10k *ar,
 	ath10k_peer_assoc_h_basic(ar, vif, sta, arg);
 	ath10k_peer_assoc_h_crypto(ar, vif, arg);
 	ath10k_peer_assoc_h_rates(ar, vif, sta, arg);
-	ath10k_peer_assoc_h_ht(ar, sta, arg);
+	ath10k_peer_assoc_h_ht(ar, vif, sta, arg);
 	ath10k_peer_assoc_h_vht(ar, vif, sta, arg);
 	ath10k_peer_assoc_h_qos(ar, vif, sta, arg);
 	ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
@@ -4043,6 +4185,14 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
 	INIT_DELAYED_WORK(&arvif->connection_loss_work,
 			  ath10k_mac_vif_sta_connection_loss_work);
 
+	for (i = 0; i < ARRAY_SIZE(arvif->bitrate_mask.control); i++) {
+		arvif->bitrate_mask.control[i].legacy = 0xffffffff;
+		memset(arvif->bitrate_mask.control[i].ht_mcs, 0xff,
+		       sizeof(arvif->bitrate_mask.control[i].ht_mcs));
+		memset(arvif->bitrate_mask.control[i].vht_mcs, 0xff,
+		       sizeof(arvif->bitrate_mask.control[i].vht_mcs));
+	}
+
 	if (ar->free_vdev_map == 0) {
 		ath10k_warn(ar, "Free vdev map is empty, no more interfaces allowed.\n");
 		ret = -EBUSY;
@@ -4866,6 +5016,10 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
 	struct ath10k_vif *arvif;
 	struct ath10k_sta *arsta;
 	struct ieee80211_sta *sta;
+	struct cfg80211_chan_def def;
+	enum ieee80211_band band;
+	const u8 *ht_mcs_mask;
+	const u16 *vht_mcs_mask;
 	u32 changed, bw, nss, smps;
 	int err;
 
@@ -4874,6 +5028,13 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
 	arvif = arsta->arvif;
 	ar = arvif->ar;
 
+	if (WARN_ON(ath10k_mac_vif_chan(arvif->vif, &def)))
+		return;
+
+	band = def.chan->band;
+	ht_mcs_mask = arvif->bitrate_mask.control[band].ht_mcs;
+	vht_mcs_mask = arvif->bitrate_mask.control[band].vht_mcs;
+
 	spin_lock_bh(&ar->data_lock);
 
 	changed = arsta->changed;
@@ -4887,6 +5048,10 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
 
 	mutex_lock(&ar->conf_mutex);
 
+	nss = max_t(u32, 1, nss);
+	nss = min(nss, max(ath10k_mac_max_ht_nss(ht_mcs_mask),
+			   ath10k_mac_max_vht_nss(vht_mcs_mask)));
+
 	if (changed & IEEE80211_RC_BW_CHANGED) {
 		ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM peer bw %d\n",
 			   sta->addr, bw);
@@ -5772,6 +5937,53 @@ static int ath10k_mac_set_fixed_rate_params(struct ath10k_vif *arvif,
 	return 0;
 }
 
+static bool
+ath10k_mac_can_set_bitrate_mask(struct ath10k *ar,
+				enum ieee80211_band band,
+				const struct cfg80211_bitrate_mask *mask)
+{
+	int i;
+	u16 vht_mcs;
+
+	/* Due to firmware limitation in WMI_PEER_ASSOC_CMDID it is impossible
+	 * to express all VHT MCS rate masks. Effectively only the following
+	 * ranges can be used: none, 0-7, 0-8 and 0-9.
+	 */
+	for (i = 0; i < NL80211_VHT_NSS_MAX; i++) {
+		vht_mcs = mask->control[band].vht_mcs[i];
+
+		switch (vht_mcs) {
+		case 0:
+		case BIT(8) - 1:
+		case BIT(9) - 1:
+		case BIT(10) - 1:
+			break;
+		default:
+			ath10k_warn(ar, "refusing bitrate mask with missing 0-7 VHT MCS rates\n");
+			return false;
+		}
+	}
+
+	return true;
+}
+
+static void ath10k_mac_set_bitrate_mask_iter(void *data,
+					     struct ieee80211_sta *sta)
+{
+	struct ath10k_vif *arvif = data;
+	struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+	struct ath10k *ar = arvif->ar;
+
+	if (arsta->arvif != arvif)
+		return;
+
+	spin_lock_bh(&ar->data_lock);
+	arsta->changed |= IEEE80211_RC_SUPP_RATES_CHANGED;
+	spin_unlock_bh(&ar->data_lock);
+
+	ieee80211_queue_work(ar->hw, &arsta->update_wk);
+}
+
 static int ath10k_mac_op_set_bitrate_mask(struct ieee80211_hw *hw,
 					  struct ieee80211_vif *vif,
 					  const struct cfg80211_bitrate_mask *mask)
@@ -5780,6 +5992,8 @@ static int ath10k_mac_op_set_bitrate_mask(struct ieee80211_hw *hw,
 	struct cfg80211_chan_def def;
 	struct ath10k *ar = arvif->ar;
 	enum ieee80211_band band;
+	const u8 *ht_mcs_mask;
+	const u16 *vht_mcs_mask;
 	u8 rate;
 	u8 nss;
 	u8 sgi;
@@ -5790,6 +6004,8 @@ static int ath10k_mac_op_set_bitrate_mask(struct ieee80211_hw *hw,
 		return -EPERM;
 
 	band = def.chan->band;
+	ht_mcs_mask = mask->control[band].ht_mcs;
+	vht_mcs_mask = mask->control[band].vht_mcs;
 
 	sgi = mask->control[band].gi;
 	if (sgi == NL80211_TXRATE_FORCE_LGI)
@@ -5809,7 +6025,21 @@ static int ath10k_mac_op_set_bitrate_mask(struct ieee80211_hw *hw,
 		nss = single_nss;
 	} else {
 		rate = WMI_FIXED_RATE_NONE;
-		nss = ar->num_rf_chains;
+		nss = min(ar->num_rf_chains,
+			  max(ath10k_mac_max_ht_nss(ht_mcs_mask),
+			      ath10k_mac_max_vht_nss(vht_mcs_mask)));
+
+		if (!ath10k_mac_can_set_bitrate_mask(ar, band, mask))
+			return -EINVAL;
+
+		mutex_lock(&ar->conf_mutex);
+
+		arvif->bitrate_mask = *mask;
+		ieee80211_iterate_stations_atomic(ar->hw,
+						  ath10k_mac_set_bitrate_mask_iter,
+						  arvif);
+
+		mutex_unlock(&ar->conf_mutex);
 	}
 
 	mutex_lock(&ar->conf_mutex);
-- 
2.1.4



From greearb at candelatech.com  Fri Apr 10 10:17:26 2015
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 10 Apr 2015 10:17:26 -0700
Subject: [PATCH 2/4] ath10k: fix multiple key static wep with ibss
In-Reply-To: <1428672203-8604-3-git-send-email-michal.kazior@tieto.com>
References: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
 <1428672203-8604-3-git-send-email-michal.kazior@tieto.com>
Message-ID: <552805A6.6030108@candelatech.com>

On 04/10/2015 06:23 AM, Michal Kazior wrote:
> Apparently firmware requires both pairwise and
> groupwise keys to be installed per-peer for static
> WEP in IBSS. This wasn't necessary for AP mode
> (and installing both doesn't seem to break AP
> mode thus there's no special handling).
> 
> Also there seems to be some kind of issue with
> mapping tx/rx keys in firmware properly which
> resulted in wrong keys being used and broken
> communication between devices.
> 
> It can be argued the vdev param part is more of a
> workaround than a real fix. However I couldn't
> figure out how to fix this differently. It works
> and isn't super ugly.
> 
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 31 ++++++++++++++++++++++++++++---
>  1 file changed, 28 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 6664bcc9ba88..93f753cb839a 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -230,9 +230,13 @@ static int ath10k_install_peer_wep_keys(struct ath10k_vif *arvif,
>  		flags = 0;
>  		flags |= WMI_KEY_PAIRWISE;
>  
> -		/* set TX_USAGE flag for default key id */
> -		if (arvif->def_wep_key_idx == i)
> -			flags |= WMI_KEY_TX_USAGE;
> +		ret = ath10k_install_key(arvif, arvif->wep_keys[i], SET_KEY,
> +					 addr, flags);
> +		if (ret)
> +			return ret;
> +
> +		flags = 0;
> +		flags |= WMI_KEY_GROUP;

That could be a single assigment to WMI_KEY_GROUP?

Also, this does not merge cleanly with my 4.0 tree,
but I'm not using WEP anyway, so no big deal...

Thanks,
Ben



-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Fri Apr 10 14:57:24 2015
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 10 Apr 2015 14:57:24 -0700
Subject: [PATCH 4/4] ath10k: enable ibss-rsn
In-Reply-To: <1428672203-8604-5-git-send-email-michal.kazior@tieto.com>
References: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
 <1428672203-8604-5-git-send-email-michal.kazior@tieto.com>
Message-ID: <55284744.80105@candelatech.com>

On 04/10/2015 06:23 AM, Michal Kazior wrote:
> From: Janusz Dziedzic <janusz.dziedzic at tieto.com>
> 
> With latest additions to the driver it seems
> viable to enable support for IBSS-RSN.
> 
> It seems to work on QCA988X and 999.999.0.636 but
> is a bit slow to exchange RSN keys for some
> reason. This may be a firmware quirk or ath10k is
> missing something. Nevertheless it makes sense to
> finally enable IBSS-RSN in ath10k even if somewhat
> handicapped.
> 
> QCA6174 firmware doesn't seem to be able to Tx
> EAPOL frames at all now (they get stuck in hw
> queues for some reason) so it never gets to set
> the keys in driver. It's fairly safe to assume that
> once this is fixed IBSS-RSN will work with QCA6174
> firmware without any additional changes. Hence no
> special handling for advertising
> IEEE80211_HW_SUPPORTS_PER_STA_GTK and
> WIPHY_FLAG_IBSS_RSN is done now.

With your patches (though not certain they are all needed on my firmware
now), and this patch below, my 10.1 system seems to be doing IBSS + RSN properly.

In case you are seeing any issues with small packets on your IBSS systems, I would
be curious to know your results if you gave this patch a try.

Without this, I see runt frames received on the peer (ARP responses in this particular case).

I was also seeing similarly corrupted EAPOL frames from what I can tell.

I don't really know why this is required, or if it is required for more than just
IBSS + RSN at this point.

[greearb at ben-dt2 ath10k]$ git diff
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d3add01..853bf55 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2631,6 +2631,19 @@ static void ath10k_tx(struct ieee80211_hw *hw,
        struct ieee80211_vif *vif = info->control.vif;
        struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;

+
+       if (vif && vif->type == NL80211_IFTYPE_ADHOC) {
+               static int my_zlen = 78;
+               /* This nasty little hack fixes IBSS + RSN with small
+                * frames frames (ARP, etc) on 10.1 (CT) firmware.
+                * Shouldn't hurt any firmware, and may help other as well. --Ben
+                */
+               if (skb->len < my_zlen) {
+                       if (skb_put_padto(skb, my_zlen))
+                               return; /* skb was consumed by skb_padto on error */
+               }
+       }
+
        /* We should disable CCK RATE due to P2P */
        if (info->flags & IEEE80211_TX_CTL_NO_CCK_RATE)
                ath10k_dbg(ar, ATH10K_DBG_MAC, "IEEE80211_TX_CTL_NO_CCK_RATE\n");


Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Fri Apr 10 16:32:29 2015
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 10 Apr 2015 16:32:29 -0700
Subject: CT ath10k firmware now supports IBSS + RSN
Message-ID: <55285D8D.6070703@candelatech.com>

First, thanks to everyone that helped me with questions,
QCA/Tieto's upstream patches, etc.

This needs more testing, but it appears to at least mostly work.

I am using this 4.0 related kernel.  I think only the last 3 patches
are IBSS specific, but possibly there are others that matter as well.

http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-4.0.dev.y/.git;a=summary

Firmware binaries and release notes are here:
http://www.candelatech.com/downloads/ath10k-fw-beta/

I'm using a very recent wpa_supplicant..upstream should work I think,
but I am using this one:

https://github.com/greearb/hostap-ct/tree/master/hostapd

supplicant needs to have this enabled, among other things:

CONFIG_IBSS_RSN=y


I suspect there are lingering bugs, perhaps in supplicant, as it seems to take
a few tries for the 4-way to happen properly, and I have to re-start hostapd
on each side each time I associate.

My supplicant config files look like this (you can comment out any options
your supplicant doesn't know about...I have a few extra features not specifically
related to IBSS in my hostapd tree)

ctrl_interface=/var/run/wpa_supplicant
fast_reauth=1
concurrent_assoc_ok=1
scan_cur_freq=1
min_scan_gap=5
freq_list=5180

bss_max_count=2000
network={
    ssid="ota-ibss-ssid"
    disable_ht=0
    disable_vht=0
    ieee80211w=0
    disable_ht40=1
    disable_sgi=0
    ht_mcs=""
    disable_max_amsdu=-1
    ampdu_factor=-1
    ampdu_density=-1
    freq_list=5180
    fixed_freq=1

    mode=1
    frequency=5180
    proto=RSN
    key_mgmt=WPA-PSK
    #psk="ben-ota-passwd"
    psk=fc29b6edf32abd7a9818af3c94b2aa5364c785eee33ed3df11605a3db8f905bc
    pairwise=CCMP
    group=CCMP
    proactive_key_caching=0

}


I'm curious to know if anyone tries it out.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From janusz.dziedzic at tieto.com  Mon Apr 13 00:45:40 2015
From: janusz.dziedzic at tieto.com (Janusz Dziedzic)
Date: Mon, 13 Apr 2015 09:45:40 +0200
Subject: [RFC 1/2] ath10k: refactor ASPM workaround
Message-ID: <1428911141-6534-1-git-send-email-janusz.dziedzic@tieto.com>

Disable ASPM only when loading firmware.
After that back to BIOS/system ASMP
settings. When ASPM is enable by system,
this decrease power consumtion.

Signed-off-by: Janusz Dziedzic <janusz.dziedzic at tieto.com>
---
 drivers/net/wireless/ath/ath10k/pci.c | 17 ++++++++++++-----
 drivers/net/wireless/ath/ath10k/pci.h |  3 +++
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 51e3921..9923c09 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1227,11 +1227,16 @@ static void ath10k_pci_irq_enable(struct ath10k *ar)
 
 static int ath10k_pci_hif_start(struct ath10k *ar)
 {
+	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");
 
 	ath10k_pci_irq_enable(ar);
 	ath10k_pci_rx_post(ar);
 
+	/* Workaround: Back to BIOS/system settings */
+	pcie_capability_write_word(ar_pci->pdev, PCI_EXP_LNKCTL,
+				   ar_pci->link_ctl);
+
 	return 0;
 }
 
@@ -1982,6 +1987,7 @@ static int ath10k_pci_chip_reset(struct ath10k *ar)
 
 static int ath10k_pci_hif_power_up(struct ath10k *ar)
 {
+	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
 	int ret;
 
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif power up\n");
@@ -1992,6 +1998,12 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
 		return ret;
 	}
 
+	/* Workaround: Disable ASPM */
+	pcie_capability_read_word(ar_pci->pdev, PCI_EXP_LNKCTL,
+				  &ar_pci->link_ctl);
+	pcie_capability_write_word(ar_pci->pdev, PCI_EXP_LNKCTL,
+				   ar_pci->link_ctl & ~PCI_EXP_LNKCTL_ASPMC);
+
 	/*
 	 * Bring the target up cleanly.
 	 *
@@ -2515,7 +2527,6 @@ static int ath10k_pci_claim(struct ath10k *ar)
 {
 	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
 	struct pci_dev *pdev = ar_pci->pdev;
-	u32 lcr_val;
 	int ret;
 
 	pci_set_drvdata(pdev, ar);
@@ -2549,10 +2560,6 @@ static int ath10k_pci_claim(struct ath10k *ar)
 
 	pci_set_master(pdev);
 
-	/* Workaround: Disable ASPM */
-	pci_read_config_dword(pdev, 0x80, &lcr_val);
-	pci_write_config_dword(pdev, 0x80, (lcr_val & 0xffffff00));
-
 	/* Arrange for access to Target SoC registers. */
 	ar_pci->mem = pci_iomap(pdev, BAR_NUM, 0);
 	if (!ar_pci->mem) {
diff --git a/drivers/net/wireless/ath/ath10k/pci.h b/drivers/net/wireless/ath/ath10k/pci.h
index 56795ed..a6eafec 100644
--- a/drivers/net/wireless/ath/ath10k/pci.h
+++ b/drivers/net/wireless/ath/ath10k/pci.h
@@ -185,6 +185,9 @@ struct ath10k_pci {
 	/* Map CE id to ce_state */
 	struct ath10k_ce_pipe ce_states[CE_COUNT_MAX];
 	struct timer_list rx_post_retry;
+
+	/* Link Control */
+	u16 link_ctl;
 };
 
 static inline struct ath10k_pci *ath10k_pci_priv(struct ath10k *ar)
-- 
1.9.1



From janusz.dziedzic at tieto.com  Mon Apr 13 00:45:41 2015
From: janusz.dziedzic at tieto.com (Janusz Dziedzic)
Date: Mon, 13 Apr 2015 09:45:41 +0200
Subject: [RFC 2/2] ath10k: don't disable PS when not connected
In-Reply-To: <1428911141-6534-1-git-send-email-janusz.dziedzic@tieto.com>
References: <1428911141-6534-1-git-send-email-janusz.dziedzic@tieto.com>
Message-ID: <1428911141-6534-2-git-send-email-janusz.dziedzic@tieto.com>

Don't disable PS while we are not connected.
In other case we will get higher power consumption.

Signed-off-by: Janusz Dziedzic <janusz.dziedzic at tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 52c5b1f..b896dd4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1730,7 +1730,13 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif *arvif)
 		enable_ps = false;
 	}
 
-	if (enable_ps) {
+	if (!arvif->is_started) {
+		/* enable power save mode while not connected,
+		 * in other case after iface up we will get
+		 * higher power consumption - firmware design
+		 */
+		psmode = WMI_STA_PS_MODE_ENABLED;
+	} else if (enable_ps) {
 		psmode = WMI_STA_PS_MODE_ENABLED;
 		param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
 
-- 
1.9.1



From michal.kazior at tieto.com  Mon Apr 13 01:41:57 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 13 Apr 2015 10:41:57 +0200
Subject: [PATCH 4/4] ath10k: enable ibss-rsn
In-Reply-To: <1428672203-8604-5-git-send-email-michal.kazior@tieto.com>
References: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
 <1428672203-8604-5-git-send-email-michal.kazior@tieto.com>
Message-ID: <CA+BoTQmdJOYzYgfZq68tqr4G+PJKSvOvWRiDp=esMzv1vuS+jw@mail.gmail.com>

On 10 April 2015 at 15:23, Michal Kazior <michal.kazior at tieto.com> wrote:
> From: Janusz Dziedzic <janusz.dziedzic at tieto.com>
>
> With latest additions to the driver it seems
> viable to enable support for IBSS-RSN.
>
> It seems to work on QCA988X and 999.999.0.636 but
> is a bit slow to exchange RSN keys for some
> reason. This may be a firmware quirk or ath10k is
> missing something. Nevertheless it makes sense to
> finally enable IBSS-RSN in ath10k even if somewhat
> handicapped.
>
> QCA6174 firmware doesn't seem to be able to Tx
> EAPOL frames at all now (they get stuck in hw
> queues for some reason) so it never gets to set
> the keys in driver. It's fairly safe to assume that
> once this is fixed IBSS-RSN will work with QCA6174
> firmware without any additional changes. Hence no
> special handling for advertising
> IEEE80211_HW_SUPPORTS_PER_STA_GTK and
> WIPHY_FLAG_IBSS_RSN is done now.

As a matter of fact QCA6174 firmware does seem to work with IBSS as
well. I just found out (by accident, after leaving a failed test setup
for a while) that after approx. 300 seconds firmware discards all
stuck EAPOL frames and starts sending subsequent ones properly. Keys
gets exchanged, installed and traffic seems to work fine with this
patchset. I suppose this warrants an updated commit log.


Micha?


From greearb at candelatech.com  Mon Apr 13 10:41:12 2015
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 13 Apr 2015 10:41:12 -0700
Subject: CT ath10k firmware now supports IBSS + RSN
In-Reply-To: <55285D8D.6070703@candelatech.com>
References: <55285D8D.6070703@candelatech.com>
Message-ID: <552BFFB8.6030301@candelatech.com>

Looks like I have some more work to do.  For any moderately large frames,
I am now dropping the last 16 bytes.  Looks like the skb_put_padto logic
was working around a more serious issue...

Thanks,
Ben

On 04/10/2015 04:32 PM, Ben Greear wrote:
> First, thanks to everyone that helped me with questions,
> QCA/Tieto's upstream patches, etc.
> 
> This needs more testing, but it appears to at least mostly work.
> 
> I am using this 4.0 related kernel.  I think only the last 3 patches
> are IBSS specific, but possibly there are others that matter as well.
> 
> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-4.0.dev.y/.git;a=summary
> 
> Firmware binaries and release notes are here:
> http://www.candelatech.com/downloads/ath10k-fw-beta/
> 
> I'm using a very recent wpa_supplicant..upstream should work I think,
> but I am using this one:
> 
> https://github.com/greearb/hostap-ct/tree/master/hostapd
> 
> supplicant needs to have this enabled, among other things:
> 
> CONFIG_IBSS_RSN=y
> 
> 
> I suspect there are lingering bugs, perhaps in supplicant, as it seems to take
> a few tries for the 4-way to happen properly, and I have to re-start hostapd
> on each side each time I associate.
> 
> My supplicant config files look like this (you can comment out any options
> your supplicant doesn't know about...I have a few extra features not specifically
> related to IBSS in my hostapd tree)
> 
> ctrl_interface=/var/run/wpa_supplicant
> fast_reauth=1
> concurrent_assoc_ok=1
> scan_cur_freq=1
> min_scan_gap=5
> freq_list=5180
> 
> bss_max_count=2000
> network={
>     ssid="ota-ibss-ssid"
>     disable_ht=0
>     disable_vht=0
>     ieee80211w=0
>     disable_ht40=1
>     disable_sgi=0
>     ht_mcs=""
>     disable_max_amsdu=-1
>     ampdu_factor=-1
>     ampdu_density=-1
>     freq_list=5180
>     fixed_freq=1
> 
>     mode=1
>     frequency=5180
>     proto=RSN
>     key_mgmt=WPA-PSK
>     #psk="ben-ota-passwd"
>     psk=fc29b6edf32abd7a9818af3c94b2aa5364c785eee33ed3df11605a3db8f905bc
>     pairwise=CCMP
>     group=CCMP
>     proactive_key_caching=0
> 
> }
> 
> 
> I'm curious to know if anyone tries it out.
> 
> Thanks,
> Ben
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From poh at qca.qualcomm.com  Mon Apr 13 11:01:20 2015
From: poh at qca.qualcomm.com (Peter Oh)
Date: Mon, 13 Apr 2015 11:01:20 -0700
Subject: [PATCH v2] ath10k: use MAC clock rate same as FW uses for survey
 accuracy
Message-ID: <6a113cdb1b0dbbb6d98ab6b363b4912474c32bac.1428701627.git.poh@qca.qualcomm.com>

WLAN survey data provides several informative values on each channels
such as noise, active time, transmit time, and etc.
Regarding the channel activity time data, it is reported from firmware
in different form which is number of cycles instead of time itself.
Hence host driver converts it to time unit by dividing it by clock rate
that is used at baseband MAC.

Using difference clock rate from that actual HW is using will result in
inaccurate survey data. For instance, channel active time can be reported
with bigger than 150ms even though we set Dwell time to 150ms.
Therefore set the clock rate to 88000 (88 MHz) which is ath10k baseband
MAC is using.

Signed-off-by: Peter Oh <poh at qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index d0942b0..2c03496 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4653,9 +4653,7 @@ struct wmi_peer_sta_kickout_event {
 } __packed;
 
 #define WMI_CHAN_INFO_FLAG_COMPLETE BIT(0)
-
-/* FIXME: empirically extrapolated */
-#define WMI_CHAN_INFO_MSEC(x) ((x) / 76595)
+#define WMI_CHAN_INFO_MSEC(x) ((x) / 88000)
 
 /* Beacon filter wmi command info */
 #define BCN_FLT_MAX_SUPPORTED_IES	256
-- 
1.9.1



From greearb at candelatech.com  Mon Apr 13 17:10:17 2015
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 13 Apr 2015 17:10:17 -0700
Subject: CT ath10k firmware now supports IBSS + RSN
In-Reply-To: <552BFFB8.6030301@candelatech.com>
References: <55285D8D.6070703@candelatech.com>
 <552BFFB8.6030301@candelatech.com>
Message-ID: <552C5AE9.4050304@candelatech.com>

On 04/13/2015 10:41 AM, Ben Greear wrote:
> Looks like I have some more work to do.  For any moderately large frames,
> I am now dropping the last 16 bytes.  Looks like the skb_put_padto logic
> was working around a more serious issue...

A better-tested version of kernel and firmware is uploaded now.

Looks like I needed to add a hack to firmware to bump pkt-size by
16 for IBSS + RSN encrypted frames.  Not sure exactly why, but seems
to work in light testing.

I removed the skb-padto hack from the kernel, and kernel is rebased on
top of official 4.0 now.

Thanks,
Ben

> On 04/10/2015 04:32 PM, Ben Greear wrote:
>> First, thanks to everyone that helped me with questions,
>> QCA/Tieto's upstream patches, etc.
>>
>> This needs more testing, but it appears to at least mostly work.
>>
>> I am using this 4.0 related kernel.  I think only the last 3 patches
>> are IBSS specific, but possibly there are others that matter as well.
>>
>> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-4.0.dev.y/.git;a=summary
>>
>> Firmware binaries and release notes are here:
>> http://www.candelatech.com/downloads/ath10k-fw-beta/
>>
>> I'm using a very recent wpa_supplicant..upstream should work I think,
>> but I am using this one:
>>
>> https://github.com/greearb/hostap-ct/tree/master/hostapd
>>
>> supplicant needs to have this enabled, among other things:
>>
>> CONFIG_IBSS_RSN=y
>>
>>
>> I suspect there are lingering bugs, perhaps in supplicant, as it seems to take
>> a few tries for the 4-way to happen properly, and I have to re-start hostapd
>> on each side each time I associate.
>>
>> My supplicant config files look like this (you can comment out any options
>> your supplicant doesn't know about...I have a few extra features not specifically
>> related to IBSS in my hostapd tree)
>>
>> ctrl_interface=/var/run/wpa_supplicant
>> fast_reauth=1
>> concurrent_assoc_ok=1
>> scan_cur_freq=1
>> min_scan_gap=5
>> freq_list=5180
>>
>> bss_max_count=2000
>> network={
>>     ssid="ota-ibss-ssid"
>>     disable_ht=0
>>     disable_vht=0
>>     ieee80211w=0
>>     disable_ht40=1
>>     disable_sgi=0
>>     ht_mcs=""
>>     disable_max_amsdu=-1
>>     ampdu_factor=-1
>>     ampdu_density=-1
>>     freq_list=5180
>>     fixed_freq=1
>>
>>     mode=1
>>     frequency=5180
>>     proto=RSN
>>     key_mgmt=WPA-PSK
>>     #psk="ben-ota-passwd"
>>     psk=fc29b6edf32abd7a9818af3c94b2aa5364c785eee33ed3df11605a3db8f905bc
>>     pairwise=CCMP
>>     group=CCMP
>>     proactive_key_caching=0
>>
>> }
>>
>>
>> I'm curious to know if anyone tries it out.
>>
>> Thanks,
>> Ben
>>
> 
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From jhihn at gmx.com  Mon Apr 13 17:37:14 2015
From: jhihn at gmx.com (Jason H)
Date: Tue, 14 Apr 2015 02:37:14 +0200
Subject: QCA6174 hw2.1?
In-Reply-To: <trinity-b17ca295-ac0b-4117-bf4d-daa1653254fc-1428417877122@3capp-mailcom-lxa05>
References: <trinity-78717edb-041b-4b77-8173-d7ba2ac3aeea-1426969886147@msvc024>, 
 <CA+BoTQkAckpbgTKg=9+ea5Me0m9=FO3aMU=qYHmX0Y96KubKeA@mail.gmail.com>,
 <trinity-b1ca9c09-4b5d-4cd4-8a8b-bd61df2a40c4-1427119021325@3capp-mailcom-lxa02>,
 <trinity-b17ca295-ac0b-4117-bf4d-daa1653254fc-1428417877122@3capp-mailcom-lxa05>
Message-ID: <trinity-d69b60ae-f27f-4610-b5dc-0d358d929eb0-1428971834225@3capp-mailcom-lxa15>

Checking in again. Could I get the QCA6174 /2.1hw firmware made faster if I "sponsored" it?


> Sent: Tuesday, April 07, 2015 at 10:44 AM
> From: "Jason H" <jhihn at gmx.com>
> To: "Jason H" <jhihn at gmx.com>
> Cc: "Michal Kazior" <michal.kazior at tieto.com>, "ath10k at lists.infradead.org" <ath10k at lists.infradead.org>
> Subject: Re: Re: QCA6174 hw2.1?
>
> Just checking in. Any updates for the QCA6174?
> 
> > Sent: Monday, March 23, 2015 at 9:57 AM
> > From: "Jason H" <jhihn at gmx.com>
> > To: "Michal Kazior" <michal.kazior at tieto.com>
> > Cc: "ath10k at lists.infradead.org" <ath10k at lists.infradead.org>
> > Subject: Re: Re: QCA6174 hw2.1?
> >
> > 
> > 
> > > Sent: Monday, March 23, 2015 at 4:23 AM
> > > From: "Michal Kazior" <michal.kazior at tieto.com>
> > > To: "Jason H" <jhihn at gmx.com>
> > > Cc: "ath10k at lists.infradead.org" <ath10k at lists.infradead.org>
> > > Subject: Re: Re: QCA6174 hw2.1?
> > >
> > > On 21 March 2015 at 21:31,  <jhihn at gmx.com> wrote:
> > > > is there anyway you could process these files for me?. I would be willing to send you the files and go through some back and forth of feedback and whatnot. The issue is I just don't think I have the time or the expertise to devote to this. However I investigated exchanging  the laptop to get a  Linux compatible one, but its going to cost me money for the restocking fee. On top of that the next user of this laptop will be disgruntled when they find a non working copy of Linux on it. I investigated getting the restore cd but Lenovo's charging $70 for the media. So if you could help I would really appreciate it because this is the last thing that I need to get working but I really need it.
> > > >
> > > > and we could also get this chipset supported. I saw I wasn't the only one looking for Linux support for this driver.
> > > 
> > > Thanks for willing to help. However I finally got my hands on the
> > > Killer 1525 card. I tried playing with it but I couldn't get ath10k to
> > > work with it yet.
> > > 
> > > There's some firmware crash issue that needs investigating. Kalle's
> > > doing his best to sort this out internally.
> > > 
> > > Hopefully we'll get this working soon and we'll let everyone know on
> > > the mailing list. I can understand your situation very well. I know it
> > > sucks.
> > > 
> > 
> > 
> > Thanks however in my investigation, this was not the same as the "Killer" card.
> > 
> > 
> > _______________________________________________
> > ath10k mailing list
> > ath10k at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/ath10k
> > 
> 


From michal.kazior at tieto.com  Mon Apr 13 22:34:53 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 14 Apr 2015 07:34:53 +0200
Subject: CT ath10k firmware now supports IBSS + RSN
In-Reply-To: <552C5AE9.4050304@candelatech.com>
References: <55285D8D.6070703@candelatech.com>
 <552BFFB8.6030301@candelatech.com>
 <552C5AE9.4050304@candelatech.com>
Message-ID: <CA+BoTQ=C0xxDifiiQVbyBe=OHYUjzHcu49mULJpU+=2SNCZ-dQ@mail.gmail.com>

On 14 April 2015 at 02:10, Ben Greear <greearb at candelatech.com> wrote:
> On 04/13/2015 10:41 AM, Ben Greear wrote:
>> Looks like I have some more work to do.  For any moderately large frames,
>> I am now dropping the last 16 bytes.  Looks like the skb_put_padto logic
>> was working around a more serious issue...
>
> A better-tested version of kernel and firmware is uploaded now.
>
> Looks like I needed to add a hack to firmware to bump pkt-size by
> 16 for IBSS + RSN encrypted frames.  Not sure exactly why, but seems
> to work in light testing.
>
> I removed the skb-padto hack from the kernel, and kernel is rebased on
> top of official 4.0 now.

Hmm.. Maybe this is related to MMIC. Maybe frame fragment length must
be different from frame length (ath10k_htt_tx(),
htt_data_tx_desc_frag)? Perhaps a similar hack as with RAW txmode[1]
needs to be applied..?


[1]: https://www.mail-archive.com/ath10k at lists.infradead.org/msg00241.html


Micha?


From michal.kazior at tieto.com  Mon Apr 13 22:38:03 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 14 Apr 2015 07:38:03 +0200
Subject: Using ath10k for WiFi capturing non-11ac traffic
In-Reply-To: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>
References: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>
Message-ID: <CA+BoTQmh2zQRpzq2=d9KKQy_Zn7TAFa3qL-LeaRZJ8e6Xheo6g@mail.gmail.com>

On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at gmail.com> wrote:
> Hello,
>   I have installed a WiFi adapter with the Qualcomm-Atheros QCA-9880
> chipset using the at10k drivers.  I am using this WiFi adapter to
> capture WLAN traffic.  The recommended firmware for capturing WiFi
> traffic is 10.1.467.2-1 per the website.  See following link:
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor

Generally the 10.x line is preferred for sniffing. You could also try 10.2.4.


> I have successfully installed the above firmware and have been using
> the adapter/driver to capture and decrypt all 802.11ac traffic.
> However, I have noticed some strange behavior when trying to decrypt
> other types of traffic such as:
>   1) 802.11a = not able to decrypt any traffic
>   2) 802.11n at 20MHz = able to decrypt only partial traffic
>   3) 802.11n at 40MHz = able to decrypt only partial traffic
>
> I have tried using the different "iw" and "iwconfig" commands to set
> the frequency and channel bandwidth (for example, iw dev wlan1 set
> freq 5180 HT20).  Has anyone else seen this issue of not being able to
> decrypt all/some of the WiFi traffic?

`iwconfig` is an old program. You shouldn't use it. Just stick with `iw`.

To decrypt traffic you need to see keying handshake (both after
association and later for each rekeying). If sniffer misses that you
won't be able to decipher data either from the start or you'll stop
being able to decrypt multicast data after GTK rekeying.

Another thing is I've had numerous random problems with wireshark
refusing to decrypt frames reliably. I recall some older version would
get stuck and need the key configuration (in preferences window) to be
re-applied or the decrypt checkbox to be re-checked. YMMV.


Micha?


From greearb at candelatech.com  Tue Apr 14 08:01:41 2015
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 14 Apr 2015 08:01:41 -0700
Subject: CT ath10k firmware now supports IBSS + RSN
In-Reply-To: <CA+BoTQ=C0xxDifiiQVbyBe=OHYUjzHcu49mULJpU+=2SNCZ-dQ@mail.gmail.com>
References: <55285D8D.6070703@candelatech.com>	<552BFFB8.6030301@candelatech.com>	<552C5AE9.4050304@candelatech.com>
 <CA+BoTQ=C0xxDifiiQVbyBe=OHYUjzHcu49mULJpU+=2SNCZ-dQ@mail.gmail.com>
Message-ID: <552D2BD5.7050204@candelatech.com>



On 04/13/2015 10:34 PM, Michal Kazior wrote:
> On 14 April 2015 at 02:10, Ben Greear <greearb at candelatech.com> wrote:
>> On 04/13/2015 10:41 AM, Ben Greear wrote:
>>> Looks like I have some more work to do.  For any moderately large frames,
>>> I am now dropping the last 16 bytes.  Looks like the skb_put_padto logic
>>> was working around a more serious issue...
>>
>> A better-tested version of kernel and firmware is uploaded now.
>>
>> Looks like I needed to add a hack to firmware to bump pkt-size by
>> 16 for IBSS + RSN encrypted frames.  Not sure exactly why, but seems
>> to work in light testing.
>>
>> I removed the skb-padto hack from the kernel, and kernel is rebased on
>> top of official 4.0 now.
>
> Hmm.. Maybe this is related to MMIC. Maybe frame fragment length must
> be different from frame length (ath10k_htt_tx(),
> htt_data_tx_desc_frag)? Perhaps a similar hack as with RAW txmode[1]
> needs to be applied..?
>
>
> [1]: https://www.mail-archive.com/ath10k at lists.infradead.org/msg00241.html

This IBSS+RSN hack could be done in the kernel, but if my firmware is the only thing that
needs it, then it is more convenient for me to hack firmware than have it
incompatible with upstream drivers.

If you do find similar problems with other firmware, then certainly a driver
patch is welcome, and I will back out my firmware hack accordingly.

And, it would be nice if someone put some version if your raw-tx patch upstream.
I can also adjust length for raw pkts in firmware too, but again, in many cases
it is better to be similarly broken to existing firmware than to be technically
correct but break compatibility with the driver.  If I ever get a 'ct-firmware'
feature flag upstream, then we could of course do the changes to take advantage
of my firmwares differences as needed.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From acarbonara13 at gmail.com  Tue Apr 14 11:04:46 2015
From: acarbonara13 at gmail.com (Amato Carbonara)
Date: Tue, 14 Apr 2015 14:04:46 -0400
Subject: Using ath10k for WiFi capturing non-11ac traffic
In-Reply-To: <CA+BoTQmh2zQRpzq2=d9KKQy_Zn7TAFa3qL-LeaRZJ8e6Xheo6g@mail.gmail.com>
References: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>
 <CA+BoTQmh2zQRpzq2=d9KKQy_Zn7TAFa3qL-LeaRZJ8e6Xheo6g@mail.gmail.com>
Message-ID: <CAOt_L3-cv7npPmWdheLjhXBiiOQRjC=GYoEZw2OSwgf-kEsUWg@mail.gmail.com>

Hello Michal,
  I was able to decrypt all traffic types (11a, 11n at 20MHz, 11n at
40MHz and 11ac at 80MHz) using the 10.1.467.2-1 firmware on the
QCA9880 chipset.  The problem was not with Wireshark.  I had to
install backports for the at10k drivers to make it work.  Procedures
are documented here:
https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/backports

Thank you for your help,
Amato

On Tue, Apr 14, 2015 at 1:38 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at gmail.com> wrote:
>> Hello,
>>   I have installed a WiFi adapter with the Qualcomm-Atheros QCA-9880
>> chipset using the at10k drivers.  I am using this WiFi adapter to
>> capture WLAN traffic.  The recommended firmware for capturing WiFi
>> traffic is 10.1.467.2-1 per the website.  See following link:
>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor
>
> Generally the 10.x line is preferred for sniffing. You could also try 10.2.4.
>
>
>> I have successfully installed the above firmware and have been using
>> the adapter/driver to capture and decrypt all 802.11ac traffic.
>> However, I have noticed some strange behavior when trying to decrypt
>> other types of traffic such as:
>>   1) 802.11a = not able to decrypt any traffic
>>   2) 802.11n at 20MHz = able to decrypt only partial traffic
>>   3) 802.11n at 40MHz = able to decrypt only partial traffic
>>
>> I have tried using the different "iw" and "iwconfig" commands to set
>> the frequency and channel bandwidth (for example, iw dev wlan1 set
>> freq 5180 HT20).  Has anyone else seen this issue of not being able to
>> decrypt all/some of the WiFi traffic?
>
> `iwconfig` is an old program. You shouldn't use it. Just stick with `iw`.
>
> To decrypt traffic you need to see keying handshake (both after
> association and later for each rekeying). If sniffer misses that you
> won't be able to decipher data either from the start or you'll stop
> being able to decrypt multicast data after GTK rekeying.
>
> Another thing is I've had numerous random problems with wireshark
> refusing to decrypt frames reliably. I recall some older version would
> get stuck and need the key configuration (in preferences window) to be
> re-applied or the decrypt checkbox to be re-checked. YMMV.
>
>
> Micha?


From dreamfly281 at gmail.com  Tue Apr 14 15:45:38 2015
From: dreamfly281 at gmail.com (YanBo)
Date: Tue, 14 Apr 2015 15:45:38 -0700
Subject: [RFC 2/2] ath10k: don't disable PS when not connected
In-Reply-To: <1428911141-6534-2-git-send-email-janusz.dziedzic@tieto.com>
References: <1428911141-6534-1-git-send-email-janusz.dziedzic@tieto.com>
 <1428911141-6534-2-git-send-email-janusz.dziedzic@tieto.com>
Message-ID: <CAFuUQkhQeCwP098DH7_R4mNCvrJ7WxdT7wnHi52DSOKm8c0k1Q@mail.gmail.com>

On Mon, Apr 13, 2015 at 12:45 AM, Janusz Dziedzic
<janusz.dziedzic at tieto.com> wrote:
> Don't disable PS while we are not connected.
> In other case we will get higher power consumption.
>
> Signed-off-by: Janusz Dziedzic <janusz.dziedzic at tieto.com>
> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 52c5b1f..b896dd4 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -1730,7 +1730,13 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif *arvif)
>                 enable_ps = false;
>         }
>
> -       if (enable_ps) {
> +       if (!arvif->is_started) {
> +               /* enable power save mode while not connected,
> +                * in other case after iface up we will get
> +                * higher power consumption - firmware design
> +                */
> +               psmode = WMI_STA_PS_MODE_ENABLED;
> +       } else if (enable_ps) {
>                 psmode = WMI_STA_PS_MODE_ENABLED;
>                 param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
>
> --

What the expectation behavior after we enable the
WMI_STA_PS_MODE_ENABLED at Idle status?
Is there any effect for TX or RX chain after set it?

BR /Yanbo


From greearb at candelatech.com  Tue Apr 14 17:19:41 2015
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 14 Apr 2015 17:19:41 -0700
Subject: Using ath10k for WiFi capturing non-11ac traffic
In-Reply-To: <CAOt_L3-cv7npPmWdheLjhXBiiOQRjC=GYoEZw2OSwgf-kEsUWg@mail.gmail.com>
References: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>
 <CA+BoTQmh2zQRpzq2=d9KKQy_Zn7TAFa3qL-LeaRZJ8e6Xheo6g@mail.gmail.com>
 <CAOt_L3-cv7npPmWdheLjhXBiiOQRjC=GYoEZw2OSwgf-kEsUWg@mail.gmail.com>
Message-ID: <552DAE9D.7090405@candelatech.com>

Out of curiosity, have you been able to capture Action frames (specifically,
block-ack add/del frames) with ath10k?  I just wasted a large amount of time wondering
why the frames are not seen...but ath9k monitor port sees them just fine.

Thanks,
Ben


On 04/14/2015 11:04 AM, Amato Carbonara wrote:
> Hello Michal,
>   I was able to decrypt all traffic types (11a, 11n at 20MHz, 11n at
> 40MHz and 11ac at 80MHz) using the 10.1.467.2-1 firmware on the
> QCA9880 chipset.  The problem was not with Wireshark.  I had to
> install backports for the at10k drivers to make it work.  Procedures
> are documented here:
> https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/backports
> 
> Thank you for your help,
> Amato
> 
> On Tue, Apr 14, 2015 at 1:38 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at gmail.com> wrote:
>>> Hello,
>>>   I have installed a WiFi adapter with the Qualcomm-Atheros QCA-9880
>>> chipset using the at10k drivers.  I am using this WiFi adapter to
>>> capture WLAN traffic.  The recommended firmware for capturing WiFi
>>> traffic is 10.1.467.2-1 per the website.  See following link:
>>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor
>>
>> Generally the 10.x line is preferred for sniffing. You could also try 10.2.4.
>>
>>
>>> I have successfully installed the above firmware and have been using
>>> the adapter/driver to capture and decrypt all 802.11ac traffic.
>>> However, I have noticed some strange behavior when trying to decrypt
>>> other types of traffic such as:
>>>   1) 802.11a = not able to decrypt any traffic
>>>   2) 802.11n at 20MHz = able to decrypt only partial traffic
>>>   3) 802.11n at 40MHz = able to decrypt only partial traffic
>>>
>>> I have tried using the different "iw" and "iwconfig" commands to set
>>> the frequency and channel bandwidth (for example, iw dev wlan1 set
>>> freq 5180 HT20).  Has anyone else seen this issue of not being able to
>>> decrypt all/some of the WiFi traffic?
>>
>> `iwconfig` is an old program. You shouldn't use it. Just stick with `iw`.
>>
>> To decrypt traffic you need to see keying handshake (both after
>> association and later for each rekeying). If sniffer misses that you
>> won't be able to decipher data either from the start or you'll stop
>> being able to decrypt multicast data after GTK rekeying.
>>
>> Another thing is I've had numerous random problems with wireshark
>> refusing to decrypt frames reliably. I recall some older version would
>> get stuck and need the key configuration (in preferences window) to be
>> re-applied or the decrypt checkbox to be re-checked. YMMV.
>>
>>
>> Micha?
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From janusz.dziedzic at tieto.com  Tue Apr 14 22:00:32 2015
From: janusz.dziedzic at tieto.com (Janusz Dziedzic)
Date: Wed, 15 Apr 2015 07:00:32 +0200
Subject: [RFC 2/2] ath10k: don't disable PS when not connected
In-Reply-To: <CAFuUQkhQeCwP098DH7_R4mNCvrJ7WxdT7wnHi52DSOKm8c0k1Q@mail.gmail.com>
References: <1428911141-6534-1-git-send-email-janusz.dziedzic@tieto.com>
 <1428911141-6534-2-git-send-email-janusz.dziedzic@tieto.com>
 <CAFuUQkhQeCwP098DH7_R4mNCvrJ7WxdT7wnHi52DSOKm8c0k1Q@mail.gmail.com>
Message-ID: <CALhHN=pefUssihniviRiBWg+EU2wYp3excwodJBDt1+H0tiiHQ@mail.gmail.com>

On 15 April 2015 at 00:45, YanBo <dreamfly281 at gmail.com> wrote:
> On Mon, Apr 13, 2015 at 12:45 AM, Janusz Dziedzic
> <janusz.dziedzic at tieto.com> wrote:
>> Don't disable PS while we are not connected.
>> In other case we will get higher power consumption.
>>
>> Signed-off-by: Janusz Dziedzic <janusz.dziedzic at tieto.com>
>> ---
>>  drivers/net/wireless/ath/ath10k/mac.c | 8 +++++++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>> index 52c5b1f..b896dd4 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -1730,7 +1730,13 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif *arvif)
>>                 enable_ps = false;
>>         }
>>
>> -       if (enable_ps) {
>> +       if (!arvif->is_started) {
>> +               /* enable power save mode while not connected,
>> +                * in other case after iface up we will get
>> +                * higher power consumption - firmware design
>> +                */
>> +               psmode = WMI_STA_PS_MODE_ENABLED;
>> +       } else if (enable_ps) {
>>                 psmode = WMI_STA_PS_MODE_ENABLED;
>>                 param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
>>
>> --
>
> What the expectation behavior after we enable the
> WMI_STA_PS_MODE_ENABLED at Idle status?
> Is there any effect for TX or RX chain after set it?
>

First I think that WMI_STA_PS_MODE_ENABLED is important only when we
are connected.
But, I see current consumption drop in my test environtment from 88mA
to 33mA when:
1) load driver, iface up
2) disconnect network, iface down, iface up
So, seems WMI_STA_PS_MODE_ENABLED do something more in FW (not only
standard PS enable/disable when
connected to AP). Probably someone from FW team should answer that, if
that is a feature or a bug.

BTW.
Patch don't change behavior we had before, when we are connected. We
can enable/disable PS using iw.

BR
Janusz


From kvalo at qca.qualcomm.com  Wed Apr 15 05:00:45 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 15 Apr 2015 15:00:45 +0300
Subject: [PATCH] ath: support new FCC DFS Radar Type 1
In-Reply-To: <1427305036-20326-1-git-send-email-poh@qca.qualcomm.com> (Peter
 Oh's message of "Wed, 25 Mar 2015 10:37:16 -0700")
References: <1427305036-20326-1-git-send-email-poh@qca.qualcomm.com>
Message-ID: <87sic17g9e.fsf@kamboji.qca.qualcomm.com>

Peter Oh <poh at qca.qualcomm.com> writes:

> Add support for new FCC DFS rules released on August 14, 2014.
> FCC has added a new radar type named Radar Type 1 and original
> Radar Type 1 is renamed to Radar Type 0 in consequence.
>
> During the certificate test, Type 1 PRI values are randomly selected
> within the range of 518 and 3066 and we divide it to 3 groups based on
> practical test result data collected for more than a year.
>
> For about Radar type ID, it does nothing to functionalities.
> In other words, even if we re-order the IDs, DFS detection will
> work as well, but we give the ID with matching to FCC doc.
>
> By adding this support, the drivers using this DFS function are
> able to support both of old and new FCC DFS rules simultaneously
> without any other changes.
>
> Signed-off-by: Peter Oh <poh at qca.qualcomm.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr 15 05:08:26 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 15 Apr 2015 15:08:26 +0300
Subject: [PATCH 1/2] ath10k: fix hw roc expiration
In-Reply-To: <1427799828-9539-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Tue, 31 Mar 2015 11:03:47 +0000")
References: <1427799828-9539-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87oamp7fwl.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> It is not guaranteed firmware will switch to
> foreign channel immediately after starting scan
> sequence. To account for that don't use duration
> parameter for scan time. Instead request insanely
> long scan and use timeout worker to cancel it from
> driver.
>
> This should improve P2P reliability a bit.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr 15 05:16:27 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 15 Apr 2015 15:16:27 +0300
Subject: [PATCH v2 1/2] ath: define JP DFS patterns separated from FCC
In-Reply-To: <413e207292d5c52cd621912762e6d4a40a8dfc48.1427845453.git.poh@qca.qualcomm.com>
 (Peter Oh's message of "Tue, 31 Mar 2015 16:44:42 -0700")
References: <413e207292d5c52cd621912762e6d4a40a8dfc48.1427845453.git.poh@qca.qualcomm.com>
Message-ID: <87k2xd7fj8.fsf@kamboji.qca.qualcomm.com>

Peter Oh <poh at qca.qualcomm.com> writes:

> Separate Japan's DFS pattern from FCC to control PPB threshold.
>
> Currently all the radar detectors use the same threshold rate at
> 50%, but it's not able to achieve if data traffic rate is higher
> than 40% because WLAN baseband used by ath9k and ath10k often fails
> detecting radar pulses, so that SW cannot get enough radar reports
> to achieve the rate.
>
> Since Japan's W53 band requires 50% data traffic during its DFS
> test we need to apply different threshold rate than others on it.
> Hence define its own pattern to give flexibility to threshold rate.
>
> Signed-off-by: Peter Oh <poh at qca.qualcomm.com>

Thanks, both patches applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr 15 05:41:58 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 15 Apr 2015 15:41:58 +0300
Subject: [PATCH] ath: use PRI value given by spec for fixed PRI
In-Reply-To: <551C5C51.8010109@codeaurora.org> (Peter Oh's message of "Wed, 01
 Apr 2015 14:00:01 -0700")
References: <1427475590-2198-1-git-send-email-poh@qca.qualcomm.com>
 <55191D89.2000300@neratec.com> <55198EA4.1010101@codeaurora.org>
 <551BC2B1.3030002@neratec.com> <551C5C51.8010109@codeaurora.org>
Message-ID: <87fv817ecp.fsf@kamboji.qca.qualcomm.com>

Peter Oh <poh at codeaurora.org> writes:

>> As for your patch at hand, I tested it for ETSI and it does not
>> change detector performance,
>
> The patch is useful when there are many missing pulses within a burst.
> It happens almost every time when channel loading rate is higher than
> 40%, but around 30% channel loading does not miss pulses that much.
>
>> therefore (please replace 16 with PRI_TOLERANCE in the macro)
>
> I'll do.
>
>> Acked-by: Zefir Kurtisi <zefir.kurtisi at neratec.com>

So what's the conclusion? Should I wait for v2 or is this good to
commit? I didn't quite get Zefir's comment about PRI_TOLERANCE above.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr 15 06:02:56 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 15 Apr 2015 16:02:56 +0300
Subject: [PATCH 0/4] ath10k: ibss crypto fixes
In-Reply-To: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 10 Apr 2015 13:23:19 +0000")
References: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87bnip7ddr.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> I've mainly tested this on kvalo/pending branch.
> Currently master branch contains 0f611d28fc2e
> ("mac80211: count interfaces correctly for
> combination checks") which breaks IBSS in
> wpa_supplicant due to P2P Device and interface
> combinations. This has been pointed out in the
> following thread:
>
>  [1]: http://thread.gmane.org/gmane.linux.kernel.wireless.general/135570/focus=136643
>
> If someone's interested in running ath10k IBSS
> make sure to use kernel prior to 4.0, revert the
> mentioned mac80211 patch or apply wpa_supplicant
> workaround patch from [1].

Is this IBSS regression fixed now or what's the status?

-- 
Kalle Valo


From acarbonara13 at gmail.com  Wed Apr 15 07:28:35 2015
From: acarbonara13 at gmail.com (Amato Carbonara)
Date: Wed, 15 Apr 2015 10:28:35 -0400
Subject: Using ath10k for WiFi capturing non-11ac traffic
In-Reply-To: <552DAE9D.7090405@candelatech.com>
References: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>
 <CA+BoTQmh2zQRpzq2=d9KKQy_Zn7TAFa3qL-LeaRZJ8e6Xheo6g@mail.gmail.com>
 <CAOt_L3-cv7npPmWdheLjhXBiiOQRjC=GYoEZw2OSwgf-kEsUWg@mail.gmail.com>
 <552DAE9D.7090405@candelatech.com>
Message-ID: <CAOt_L3_FG53W5xK1csb=+VXDy2wdW-V3nbg8mtFaHarEOdkLCg@mail.gmail.com>

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 at candelatech.com> wrote:
> Out of curiosity, have you been able to capture Action frames (specifically,
> block-ack add/del frames) with ath10k?  I just wasted a large amount of time wondering
> why the frames are not seen...but ath9k monitor port sees them just fine.
>
> Thanks,
> Ben
>
>
> On 04/14/2015 11:04 AM, Amato Carbonara wrote:
>> Hello Michal,
>>   I was able to decrypt all traffic types (11a, 11n at 20MHz, 11n at
>> 40MHz and 11ac at 80MHz) using the 10.1.467.2-1 firmware on the
>> QCA9880 chipset.  The problem was not with Wireshark.  I had to
>> install backports for the at10k drivers to make it work.  Procedures
>> are documented here:
>> https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/backports
>>
>> Thank you for your help,
>> Amato
>>
>> On Tue, Apr 14, 2015 at 1:38 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
>>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at gmail.com> wrote:
>>>> Hello,
>>>>   I have installed a WiFi adapter with the Qualcomm-Atheros QCA-9880
>>>> chipset using the at10k drivers.  I am using this WiFi adapter to
>>>> capture WLAN traffic.  The recommended firmware for capturing WiFi
>>>> traffic is 10.1.467.2-1 per the website.  See following link:
>>>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor
>>>
>>> Generally the 10.x line is preferred for sniffing. You could also try 10.2.4.
>>>
>>>
>>>> I have successfully installed the above firmware and have been using
>>>> the adapter/driver to capture and decrypt all 802.11ac traffic.
>>>> However, I have noticed some strange behavior when trying to decrypt
>>>> other types of traffic such as:
>>>>   1) 802.11a = not able to decrypt any traffic
>>>>   2) 802.11n at 20MHz = able to decrypt only partial traffic
>>>>   3) 802.11n at 40MHz = able to decrypt only partial traffic
>>>>
>>>> I have tried using the different "iw" and "iwconfig" commands to set
>>>> the frequency and channel bandwidth (for example, iw dev wlan1 set
>>>> freq 5180 HT20).  Has anyone else seen this issue of not being able to
>>>> decrypt all/some of the WiFi traffic?
>>>
>>> `iwconfig` is an old program. You shouldn't use it. Just stick with `iw`.
>>>
>>> To decrypt traffic you need to see keying handshake (both after
>>> association and later for each rekeying). If sniffer misses that you
>>> won't be able to decipher data either from the start or you'll stop
>>> being able to decrypt multicast data after GTK rekeying.
>>>
>>> Another thing is I've had numerous random problems with wireshark
>>> refusing to decrypt frames reliably. I recall some older version would
>>> get stuck and need the key configuration (in preferences window) to be
>>> re-applied or the decrypt checkbox to be re-checked. YMMV.
>>>
>>>
>>> Micha?
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>


From greearb at candelatech.com  Wed Apr 15 07:58:25 2015
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 15 Apr 2015 07:58:25 -0700
Subject: Using ath10k for WiFi capturing non-11ac traffic
In-Reply-To: <CAOt_L3_FG53W5xK1csb=+VXDy2wdW-V3nbg8mtFaHarEOdkLCg@mail.gmail.com>
References: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>
 <CA+BoTQmh2zQRpzq2=d9KKQy_Zn7TAFa3qL-LeaRZJ8e6Xheo6g@mail.gmail.com>
 <CAOt_L3-cv7npPmWdheLjhXBiiOQRjC=GYoEZw2OSwgf-kEsUWg@mail.gmail.com>
 <552DAE9D.7090405@candelatech.com>
 <CAOt_L3_FG53W5xK1csb=+VXDy2wdW-V3nbg8mtFaHarEOdkLCg@mail.gmail.com>
Message-ID: <552E7C91.5030607@candelatech.com>



On 04/15/2015 07:28 AM, Amato Carbonara wrote:
> Hi Ben,
>    I have done numerous captures using the ath10k driver on different
> 802.11 variant networks, specifically 802.11n (20MHz and 40MHz) and
> 802.11ac.  In all these captures, I have captured the Block-Ack frames
> (Wireshark filter wlan.fc.type_subtype == 0x0019), but do not see any
> Block-ACK Request or Response frames.  In fact, none of my captures
> using the ath10k drivers show any Action frames (Wireshark filter
> wlan.fc.type_subtype == 0x000d).  This is very peculiar since the IEEE
> specification 802.11-2012 section 9.21.2 states: "If the intended
> recipient STA is capable of participating, the originator sends an
> ADDBA Request frame".  Therefor, the ADDBA must be sent in order for
> Block-Acks to occur.  I have also noticed missing Association Response
> frames from the STA.
>
> Currently, I am using firmware 10.1.467.2-1 to perform my captures.

I think the ath10k firmware must just consume the block-ack request/response frames internally and
never send them up to the host.  It does send an htt message about blockack control messages being
received.

Probably something I could fix in my 10.1 firmware...but first I need to
figure out why ath9k (mac80211 stack, actually) ignores the block-ack messages that my ibss ath10k
interface sends....

Thanks,
Ben

>
> Has anyone else tried using a different firmware version, for example
> 10.2.4, to perform WiFi captures?
>
> On Tue, Apr 14, 2015 at 8:19 PM, Ben Greear <greearb at candelatech.com> wrote:
>> Out of curiosity, have you been able to capture Action frames (specifically,
>> block-ack add/del frames) with ath10k?  I just wasted a large amount of time wondering
>> why the frames are not seen...but ath9k monitor port sees them just fine.
>>
>> Thanks,
>> Ben
>>
>>
>> On 04/14/2015 11:04 AM, Amato Carbonara wrote:
>>> Hello Michal,
>>>    I was able to decrypt all traffic types (11a, 11n at 20MHz, 11n at
>>> 40MHz and 11ac at 80MHz) using the 10.1.467.2-1 firmware on the
>>> QCA9880 chipset.  The problem was not with Wireshark.  I had to
>>> install backports for the at10k drivers to make it work.  Procedures
>>> are documented here:
>>> https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/backports
>>>
>>> Thank you for your help,
>>> Amato
>>>
>>> On Tue, Apr 14, 2015 at 1:38 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
>>>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at gmail.com> wrote:
>>>>> Hello,
>>>>>    I have installed a WiFi adapter with the Qualcomm-Atheros QCA-9880
>>>>> chipset using the at10k drivers.  I am using this WiFi adapter to
>>>>> capture WLAN traffic.  The recommended firmware for capturing WiFi
>>>>> traffic is 10.1.467.2-1 per the website.  See following link:
>>>>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor
>>>>
>>>> Generally the 10.x line is preferred for sniffing. You could also try 10.2.4.
>>>>
>>>>
>>>>> I have successfully installed the above firmware and have been using
>>>>> the adapter/driver to capture and decrypt all 802.11ac traffic.
>>>>> However, I have noticed some strange behavior when trying to decrypt
>>>>> other types of traffic such as:
>>>>>    1) 802.11a = not able to decrypt any traffic
>>>>>    2) 802.11n at 20MHz = able to decrypt only partial traffic
>>>>>    3) 802.11n at 40MHz = able to decrypt only partial traffic
>>>>>
>>>>> I have tried using the different "iw" and "iwconfig" commands to set
>>>>> the frequency and channel bandwidth (for example, iw dev wlan1 set
>>>>> freq 5180 HT20).  Has anyone else seen this issue of not being able to
>>>>> decrypt all/some of the WiFi traffic?
>>>>
>>>> `iwconfig` is an old program. You shouldn't use it. Just stick with `iw`.
>>>>
>>>> To decrypt traffic you need to see keying handshake (both after
>>>> association and later for each rekeying). If sniffer misses that you
>>>> won't be able to decipher data either from the start or you'll stop
>>>> being able to decrypt multicast data after GTK rekeying.
>>>>
>>>> Another thing is I've had numerous random problems with wireshark
>>>> refusing to decrypt frames reliably. I recall some older version would
>>>> get stuck and need the key configuration (in preferences window) to be
>>>> re-applied or the decrypt checkbox to be re-checked. YMMV.
>>>>
>>>>
>>>> Micha?
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From acarbonara13 at gmail.com  Wed Apr 15 08:07:05 2015
From: acarbonara13 at gmail.com (Amato Carbonara)
Date: Wed, 15 Apr 2015 11:07:05 -0400
Subject: Using ath10k for WiFi capturing non-11ac traffic
In-Reply-To: <552E7C91.5030607@candelatech.com>
References: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>
 <CA+BoTQmh2zQRpzq2=d9KKQy_Zn7TAFa3qL-LeaRZJ8e6Xheo6g@mail.gmail.com>
 <CAOt_L3-cv7npPmWdheLjhXBiiOQRjC=GYoEZw2OSwgf-kEsUWg@mail.gmail.com>
 <552DAE9D.7090405@candelatech.com>
 <CAOt_L3_FG53W5xK1csb=+VXDy2wdW-V3nbg8mtFaHarEOdkLCg@mail.gmail.com>
 <552E7C91.5030607@candelatech.com>
Message-ID: <CAOt_L3_nN-U41wm+=Skb7RixZr=8x-Y_VEO1vEQohFDJMa66fg@mail.gmail.com>

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 at candelatech.com> wrote:
>
>
> On 04/15/2015 07:28 AM, Amato Carbonara wrote:
>>
>> Hi Ben,
>>    I have done numerous captures using the ath10k driver on different
>> 802.11 variant networks, specifically 802.11n (20MHz and 40MHz) and
>> 802.11ac.  In all these captures, I have captured the Block-Ack frames
>> (Wireshark filter wlan.fc.type_subtype == 0x0019), but do not see any
>> Block-ACK Request or Response frames.  In fact, none of my captures
>> using the ath10k drivers show any Action frames (Wireshark filter
>> wlan.fc.type_subtype == 0x000d).  This is very peculiar since the IEEE
>> specification 802.11-2012 section 9.21.2 states: "If the intended
>> recipient STA is capable of participating, the originator sends an
>> ADDBA Request frame".  Therefor, the ADDBA must be sent in order for
>> Block-Acks to occur.  I have also noticed missing Association Response
>> frames from the STA.
>>
>> Currently, I am using firmware 10.1.467.2-1 to perform my captures.
>
>
> I think the ath10k firmware must just consume the block-ack request/response
> frames internally and
> never send them up to the host.  It does send an htt message about blockack
> control messages being
> received.
>
> Probably something I could fix in my 10.1 firmware...but first I need to
> figure out why ath9k (mac80211 stack, actually) ignores the block-ack
> messages that my ibss ath10k
> interface sends....
>
> Thanks,
> Ben
>
>
>>
>> Has anyone else tried using a different firmware version, for example
>> 10.2.4, to perform WiFi captures?
>>
>> On Tue, Apr 14, 2015 at 8:19 PM, Ben Greear <greearb at candelatech.com>
>> wrote:
>>>
>>> Out of curiosity, have you been able to capture Action frames
>>> (specifically,
>>> block-ack add/del frames) with ath10k?  I just wasted a large amount of
>>> time wondering
>>> why the frames are not seen...but ath9k monitor port sees them just fine.
>>>
>>> Thanks,
>>> Ben
>>>
>>>
>>> On 04/14/2015 11:04 AM, Amato Carbonara wrote:
>>>>
>>>> Hello Michal,
>>>>    I was able to decrypt all traffic types (11a, 11n at 20MHz, 11n at
>>>> 40MHz and 11ac at 80MHz) using the 10.1.467.2-1 firmware on the
>>>> QCA9880 chipset.  The problem was not with Wireshark.  I had to
>>>> install backports for the at10k drivers to make it work.  Procedures
>>>> are documented here:
>>>> https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/backports
>>>>
>>>> Thank you for your help,
>>>> Amato
>>>>
>>>> On Tue, Apr 14, 2015 at 1:38 AM, Michal Kazior <michal.kazior at tieto.com>
>>>> wrote:
>>>>>
>>>>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>    I have installed a WiFi adapter with the Qualcomm-Atheros QCA-9880
>>>>>> chipset using the at10k drivers.  I am using this WiFi adapter to
>>>>>> capture WLAN traffic.  The recommended firmware for capturing WiFi
>>>>>> traffic is 10.1.467.2-1 per the website.  See following link:
>>>>>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor
>>>>>
>>>>>
>>>>> Generally the 10.x line is preferred for sniffing. You could also try
>>>>> 10.2.4.
>>>>>
>>>>>
>>>>>> I have successfully installed the above firmware and have been using
>>>>>> the adapter/driver to capture and decrypt all 802.11ac traffic.
>>>>>> However, I have noticed some strange behavior when trying to decrypt
>>>>>> other types of traffic such as:
>>>>>>    1) 802.11a = not able to decrypt any traffic
>>>>>>    2) 802.11n at 20MHz = able to decrypt only partial traffic
>>>>>>    3) 802.11n at 40MHz = able to decrypt only partial traffic
>>>>>>
>>>>>> I have tried using the different "iw" and "iwconfig" commands to set
>>>>>> the frequency and channel bandwidth (for example, iw dev wlan1 set
>>>>>> freq 5180 HT20).  Has anyone else seen this issue of not being able to
>>>>>> decrypt all/some of the WiFi traffic?
>>>>>
>>>>>
>>>>> `iwconfig` is an old program. You shouldn't use it. Just stick with
>>>>> `iw`.
>>>>>
>>>>> To decrypt traffic you need to see keying handshake (both after
>>>>> association and later for each rekeying). If sniffer misses that you
>>>>> won't be able to decipher data either from the start or you'll stop
>>>>> being able to decrypt multicast data after GTK rekeying.
>>>>>
>>>>> Another thing is I've had numerous random problems with wireshark
>>>>> refusing to decrypt frames reliably. I recall some older version would
>>>>> get stuck and need the key configuration (in preferences window) to be
>>>>> re-applied or the decrypt checkbox to be re-checked. YMMV.
>>>>>
>>>>>
>>>>> Micha?
>>>>
>>>>
>>>> _______________________________________________
>>>> ath10k mailing list
>>>> ath10k at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Wed Apr 15 08:41:46 2015
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 15 Apr 2015 08:41:46 -0700
Subject: Using ath10k for WiFi capturing non-11ac traffic
In-Reply-To: <CAOt_L3_nN-U41wm+=Skb7RixZr=8x-Y_VEO1vEQohFDJMa66fg@mail.gmail.com>
References: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>
 <CA+BoTQmh2zQRpzq2=d9KKQy_Zn7TAFa3qL-LeaRZJ8e6Xheo6g@mail.gmail.com>
 <CAOt_L3-cv7npPmWdheLjhXBiiOQRjC=GYoEZw2OSwgf-kEsUWg@mail.gmail.com>
 <552DAE9D.7090405@candelatech.com>
 <CAOt_L3_FG53W5xK1csb=+VXDy2wdW-V3nbg8mtFaHarEOdkLCg@mail.gmail.com>
 <552E7C91.5030607@candelatech.com>
 <CAOt_L3_nN-U41wm+=Skb7RixZr=8x-Y_VEO1vEQohFDJMa66fg@mail.gmail.com>
Message-ID: <552E86BA.9000206@candelatech.com>

On 04/15/2015 08:07 AM, Amato Carbonara wrote:
> Hi Ben,
>   I performed my captures when the WiFi adapter running the ath10k was
> not connected to the WiFi network.  In other words, the capture shows
> traffic between 2 different devices.  The ath10k device is in
> promiscuous mode and capturing all the traffic between the devices.

Yes, I did the same, and still no BlockAck action frames are captured.

Firmware has special handling for these frames, so probably it eats
them before passing on to the host.

Thanks,
Ben

> 
> On Wed, Apr 15, 2015 at 10:58 AM, Ben Greear <greearb at candelatech.com> wrote:
>>
>>
>> On 04/15/2015 07:28 AM, Amato Carbonara wrote:
>>>
>>> Hi Ben,
>>>    I have done numerous captures using the ath10k driver on different
>>> 802.11 variant networks, specifically 802.11n (20MHz and 40MHz) and
>>> 802.11ac.  In all these captures, I have captured the Block-Ack frames
>>> (Wireshark filter wlan.fc.type_subtype == 0x0019), but do not see any
>>> Block-ACK Request or Response frames.  In fact, none of my captures
>>> using the ath10k drivers show any Action frames (Wireshark filter
>>> wlan.fc.type_subtype == 0x000d).  This is very peculiar since the IEEE
>>> specification 802.11-2012 section 9.21.2 states: "If the intended
>>> recipient STA is capable of participating, the originator sends an
>>> ADDBA Request frame".  Therefor, the ADDBA must be sent in order for
>>> Block-Acks to occur.  I have also noticed missing Association Response
>>> frames from the STA.
>>>
>>> Currently, I am using firmware 10.1.467.2-1 to perform my captures.
>>
>>
>> I think the ath10k firmware must just consume the block-ack request/response
>> frames internally and
>> never send them up to the host.  It does send an htt message about blockack
>> control messages being
>> received.
>>
>> Probably something I could fix in my 10.1 firmware...but first I need to
>> figure out why ath9k (mac80211 stack, actually) ignores the block-ack
>> messages that my ibss ath10k
>> interface sends....
>>
>> Thanks,
>> Ben
>>
>>
>>>
>>> Has anyone else tried using a different firmware version, for example
>>> 10.2.4, to perform WiFi captures?
>>>
>>> On Tue, Apr 14, 2015 at 8:19 PM, Ben Greear <greearb at candelatech.com>
>>> wrote:
>>>>
>>>> Out of curiosity, have you been able to capture Action frames
>>>> (specifically,
>>>> block-ack add/del frames) with ath10k?  I just wasted a large amount of
>>>> time wondering
>>>> why the frames are not seen...but ath9k monitor port sees them just fine.
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>>
>>>> On 04/14/2015 11:04 AM, Amato Carbonara wrote:
>>>>>
>>>>> Hello Michal,
>>>>>    I was able to decrypt all traffic types (11a, 11n at 20MHz, 11n at
>>>>> 40MHz and 11ac at 80MHz) using the 10.1.467.2-1 firmware on the
>>>>> QCA9880 chipset.  The problem was not with Wireshark.  I had to
>>>>> install backports for the at10k drivers to make it work.  Procedures
>>>>> are documented here:
>>>>> https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/backports
>>>>>
>>>>> Thank you for your help,
>>>>> Amato
>>>>>
>>>>> On Tue, Apr 14, 2015 at 1:38 AM, Michal Kazior <michal.kazior at tieto.com>
>>>>> wrote:
>>>>>>
>>>>>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>    I have installed a WiFi adapter with the Qualcomm-Atheros QCA-9880
>>>>>>> chipset using the at10k drivers.  I am using this WiFi adapter to
>>>>>>> capture WLAN traffic.  The recommended firmware for capturing WiFi
>>>>>>> traffic is 10.1.467.2-1 per the website.  See following link:
>>>>>>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor
>>>>>>
>>>>>>
>>>>>> Generally the 10.x line is preferred for sniffing. You could also try
>>>>>> 10.2.4.
>>>>>>
>>>>>>
>>>>>>> I have successfully installed the above firmware and have been using
>>>>>>> the adapter/driver to capture and decrypt all 802.11ac traffic.
>>>>>>> However, I have noticed some strange behavior when trying to decrypt
>>>>>>> other types of traffic such as:
>>>>>>>    1) 802.11a = not able to decrypt any traffic
>>>>>>>    2) 802.11n at 20MHz = able to decrypt only partial traffic
>>>>>>>    3) 802.11n at 40MHz = able to decrypt only partial traffic
>>>>>>>
>>>>>>> I have tried using the different "iw" and "iwconfig" commands to set
>>>>>>> the frequency and channel bandwidth (for example, iw dev wlan1 set
>>>>>>> freq 5180 HT20).  Has anyone else seen this issue of not being able to
>>>>>>> decrypt all/some of the WiFi traffic?
>>>>>>
>>>>>>
>>>>>> `iwconfig` is an old program. You shouldn't use it. Just stick with
>>>>>> `iw`.
>>>>>>
>>>>>> To decrypt traffic you need to see keying handshake (both after
>>>>>> association and later for each rekeying). If sniffer misses that you
>>>>>> won't be able to decipher data either from the start or you'll stop
>>>>>> being able to decrypt multicast data after GTK rekeying.
>>>>>>
>>>>>> Another thing is I've had numerous random problems with wireshark
>>>>>> refusing to decrypt frames reliably. I recall some older version would
>>>>>> get stuck and need the key configuration (in preferences window) to be
>>>>>> re-applied or the decrypt checkbox to be re-checked. YMMV.
>>>>>>
>>>>>>
>>>>>> Micha?
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ath10k mailing list
>>>>> ath10k at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>
>>>>
>>>>
>>>> --
>>>> Ben Greear <greearb at candelatech.com>
>>>> Candela Technologies Inc  http://www.candelatech.com
>>>>
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From adrian at freebsd.org  Wed Apr 15 09:16:07 2015
From: adrian at freebsd.org (Adrian Chadd)
Date: Wed, 15 Apr 2015 09:16:07 -0700
Subject: Using ath10k for WiFi capturing non-11ac traffic
In-Reply-To: <552E86BA.9000206@candelatech.com>
References: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>
 <CA+BoTQmh2zQRpzq2=d9KKQy_Zn7TAFa3qL-LeaRZJ8e6Xheo6g@mail.gmail.com>
 <CAOt_L3-cv7npPmWdheLjhXBiiOQRjC=GYoEZw2OSwgf-kEsUWg@mail.gmail.com>
 <552DAE9D.7090405@candelatech.com>
 <CAOt_L3_FG53W5xK1csb=+VXDy2wdW-V3nbg8mtFaHarEOdkLCg@mail.gmail.com>
 <552E7C91.5030607@candelatech.com>
 <CAOt_L3_nN-U41wm+=Skb7RixZr=8x-Y_VEO1vEQohFDJMa66fg@mail.gmail.com>
 <552E86BA.9000206@candelatech.com>
Message-ID: <CAJ-VmokKsw0qZw0Bs_6kxVbdxkH4SZsOhR7xEd2Wfevj9j3-0g@mail.gmail.com>

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



-adrian


On 15 April 2015 at 08:41, Ben Greear <greearb at candelatech.com> wrote:
> On 04/15/2015 08:07 AM, Amato Carbonara wrote:
>> Hi Ben,
>>   I performed my captures when the WiFi adapter running the ath10k was
>> not connected to the WiFi network.  In other words, the capture shows
>> traffic between 2 different devices.  The ath10k device is in
>> promiscuous mode and capturing all the traffic between the devices.
>
> Yes, I did the same, and still no BlockAck action frames are captured.
>
> Firmware has special handling for these frames, so probably it eats
> them before passing on to the host.
>
> Thanks,
> Ben
>
>>
>> On Wed, Apr 15, 2015 at 10:58 AM, Ben Greear <greearb at candelatech.com> wrote:
>>>
>>>
>>> On 04/15/2015 07:28 AM, Amato Carbonara wrote:
>>>>
>>>> Hi Ben,
>>>>    I have done numerous captures using the ath10k driver on different
>>>> 802.11 variant networks, specifically 802.11n (20MHz and 40MHz) and
>>>> 802.11ac.  In all these captures, I have captured the Block-Ack frames
>>>> (Wireshark filter wlan.fc.type_subtype == 0x0019), but do not see any
>>>> Block-ACK Request or Response frames.  In fact, none of my captures
>>>> using the ath10k drivers show any Action frames (Wireshark filter
>>>> wlan.fc.type_subtype == 0x000d).  This is very peculiar since the IEEE
>>>> specification 802.11-2012 section 9.21.2 states: "If the intended
>>>> recipient STA is capable of participating, the originator sends an
>>>> ADDBA Request frame".  Therefor, the ADDBA must be sent in order for
>>>> Block-Acks to occur.  I have also noticed missing Association Response
>>>> frames from the STA.
>>>>
>>>> Currently, I am using firmware 10.1.467.2-1 to perform my captures.
>>>
>>>
>>> I think the ath10k firmware must just consume the block-ack request/response
>>> frames internally and
>>> never send them up to the host.  It does send an htt message about blockack
>>> control messages being
>>> received.
>>>
>>> Probably something I could fix in my 10.1 firmware...but first I need to
>>> figure out why ath9k (mac80211 stack, actually) ignores the block-ack
>>> messages that my ibss ath10k
>>> interface sends....
>>>
>>> Thanks,
>>> Ben
>>>
>>>
>>>>
>>>> Has anyone else tried using a different firmware version, for example
>>>> 10.2.4, to perform WiFi captures?
>>>>
>>>> On Tue, Apr 14, 2015 at 8:19 PM, Ben Greear <greearb at candelatech.com>
>>>> wrote:
>>>>>
>>>>> Out of curiosity, have you been able to capture Action frames
>>>>> (specifically,
>>>>> block-ack add/del frames) with ath10k?  I just wasted a large amount of
>>>>> time wondering
>>>>> why the frames are not seen...but ath9k monitor port sees them just fine.
>>>>>
>>>>> Thanks,
>>>>> Ben
>>>>>
>>>>>
>>>>> On 04/14/2015 11:04 AM, Amato Carbonara wrote:
>>>>>>
>>>>>> Hello Michal,
>>>>>>    I was able to decrypt all traffic types (11a, 11n at 20MHz, 11n at
>>>>>> 40MHz and 11ac at 80MHz) using the 10.1.467.2-1 firmware on the
>>>>>> QCA9880 chipset.  The problem was not with Wireshark.  I had to
>>>>>> install backports for the at10k drivers to make it work.  Procedures
>>>>>> are documented here:
>>>>>> https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/backports
>>>>>>
>>>>>> Thank you for your help,
>>>>>> Amato
>>>>>>
>>>>>> On Tue, Apr 14, 2015 at 1:38 AM, Michal Kazior <michal.kazior at tieto.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>    I have installed a WiFi adapter with the Qualcomm-Atheros QCA-9880
>>>>>>>> chipset using the at10k drivers.  I am using this WiFi adapter to
>>>>>>>> capture WLAN traffic.  The recommended firmware for capturing WiFi
>>>>>>>> traffic is 10.1.467.2-1 per the website.  See following link:
>>>>>>>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor
>>>>>>>
>>>>>>>
>>>>>>> Generally the 10.x line is preferred for sniffing. You could also try
>>>>>>> 10.2.4.
>>>>>>>
>>>>>>>
>>>>>>>> I have successfully installed the above firmware and have been using
>>>>>>>> the adapter/driver to capture and decrypt all 802.11ac traffic.
>>>>>>>> However, I have noticed some strange behavior when trying to decrypt
>>>>>>>> other types of traffic such as:
>>>>>>>>    1) 802.11a = not able to decrypt any traffic
>>>>>>>>    2) 802.11n at 20MHz = able to decrypt only partial traffic
>>>>>>>>    3) 802.11n at 40MHz = able to decrypt only partial traffic
>>>>>>>>
>>>>>>>> I have tried using the different "iw" and "iwconfig" commands to set
>>>>>>>> the frequency and channel bandwidth (for example, iw dev wlan1 set
>>>>>>>> freq 5180 HT20).  Has anyone else seen this issue of not being able to
>>>>>>>> decrypt all/some of the WiFi traffic?
>>>>>>>
>>>>>>>
>>>>>>> `iwconfig` is an old program. You shouldn't use it. Just stick with
>>>>>>> `iw`.
>>>>>>>
>>>>>>> To decrypt traffic you need to see keying handshake (both after
>>>>>>> association and later for each rekeying). If sniffer misses that you
>>>>>>> won't be able to decipher data either from the start or you'll stop
>>>>>>> being able to decrypt multicast data after GTK rekeying.
>>>>>>>
>>>>>>> Another thing is I've had numerous random problems with wireshark
>>>>>>> refusing to decrypt frames reliably. I recall some older version would
>>>>>>> get stuck and need the key configuration (in preferences window) to be
>>>>>>> re-applied or the decrypt checkbox to be re-checked. YMMV.
>>>>>>>
>>>>>>>
>>>>>>> Micha?
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> ath10k mailing list
>>>>>> ath10k at lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ben Greear <greearb at candelatech.com>
>>>>> Candela Technologies Inc  http://www.candelatech.com
>>>>>
>>>>
>>>> _______________________________________________
>>>> ath10k mailing list
>>>> ath10k at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From dreamfly281 at gmail.com  Wed Apr 15 10:10:09 2015
From: dreamfly281 at gmail.com (YanBo)
Date: Wed, 15 Apr 2015 10:10:09 -0700
Subject: [RFC 2/2] ath10k: don't disable PS when not connected
In-Reply-To: <CALhHN=pefUssihniviRiBWg+EU2wYp3excwodJBDt1+H0tiiHQ@mail.gmail.com>
References: <1428911141-6534-1-git-send-email-janusz.dziedzic@tieto.com>
 <1428911141-6534-2-git-send-email-janusz.dziedzic@tieto.com>
 <CAFuUQkhQeCwP098DH7_R4mNCvrJ7WxdT7wnHi52DSOKm8c0k1Q@mail.gmail.com>
 <CALhHN=pefUssihniviRiBWg+EU2wYp3excwodJBDt1+H0tiiHQ@mail.gmail.com>
Message-ID: <CAFuUQkieJ0CC83wPFm=c_gA5a6OzdbWBF-0EaDL0N=nNAsU2_g@mail.gmail.com>

On Tue, Apr 14, 2015 at 10:00 PM, Janusz Dziedzic
<janusz.dziedzic at tieto.com> wrote:
> On 15 April 2015 at 00:45, YanBo <dreamfly281 at gmail.com> wrote:
>> On Mon, Apr 13, 2015 at 12:45 AM, Janusz Dziedzic
>> <janusz.dziedzic at tieto.com> wrote:
>>> Don't disable PS while we are not connected.
>>> In other case we will get higher power consumption.
>>>
>>> Signed-off-by: Janusz Dziedzic <janusz.dziedzic at tieto.com>
>>> ---
>>>  drivers/net/wireless/ath/ath10k/mac.c | 8 +++++++-
>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>>> index 52c5b1f..b896dd4 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -1730,7 +1730,13 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif *arvif)
>>>                 enable_ps = false;
>>>         }
>>>
>>> -       if (enable_ps) {
>>> +       if (!arvif->is_started) {
>>> +               /* enable power save mode while not connected,
>>> +                * in other case after iface up we will get
>>> +                * higher power consumption - firmware design
>>> +                */
>>> +               psmode = WMI_STA_PS_MODE_ENABLED;
>>> +       } else if (enable_ps) {
>>>                 psmode = WMI_STA_PS_MODE_ENABLED;
>>>                 param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
>>>
>>> --
>>
>> What the expectation behavior after we enable the
>> WMI_STA_PS_MODE_ENABLED at Idle status?
>> Is there any effect for TX or RX chain after set it?
>>
>
> First I think that WMI_STA_PS_MODE_ENABLED is important only when we
> are connected.
> But, I see current consumption drop in my test environtment from 88mA
> to 33mA when:
> 1) load driver, iface up
> 2) disconnect network, iface down, iface up
> So, seems WMI_STA_PS_MODE_ENABLED do something more in FW (not only
> standard PS enable/disable when
> connected to AP). Probably someone from FW team should answer that, if
> that is a feature or a bug.
>
I guess the chip enter Idle  mode power save  after set this,  did you
run the the
test on QCA61XX or QCA 98XX?   Can it still auto scan to get all the APs around
it, cause for IMPS mode it will only looks in its existing profile
list and sends a probe request,
with SSID specified in profile for what I know

BR /Yanbo


From poh at codeaurora.org  Wed Apr 15 10:10:20 2015
From: poh at codeaurora.org (Peter Oh)
Date: Wed, 15 Apr 2015 10:10:20 -0700
Subject: [PATCH] ath: use PRI value given by spec for fixed PRI
In-Reply-To: <87fv817ecp.fsf@kamboji.qca.qualcomm.com>
References: <1427475590-2198-1-git-send-email-poh@qca.qualcomm.com>
 <55191D89.2000300@neratec.com> <55198EA4.1010101@codeaurora.org>
 <551BC2B1.3030002@neratec.com> <551C5C51.8010109@codeaurora.org>
 <87fv817ecp.fsf@kamboji.qca.qualcomm.com>
Message-ID: <552E9B7C.5080109@codeaurora.org>


On 04/15/2015 05:41 AM, Kalle Valo wrote:
> Peter Oh <poh at codeaurora.org> writes:
>
>>> As for your patch at hand, I tested it for ETSI and it does not
>>> change detector performance,
>> The patch is useful when there are many missing pulses within a burst.
>> It happens almost every time when channel loading rate is higher than
>> 40%, but around 30% channel loading does not miss pulses that much.
>>
>>> therefore (please replace 16 with PRI_TOLERANCE in the macro)
>> I'll do.
>>
>>> Acked-by: Zefir Kurtisi <zefir.kurtisi at neratec.com>
> So what's the conclusion? Should I wait for v2 or is this good to
> commit? I didn't quite get Zefir's comment about PRI_TOLERANCE above.
>
Please wait for 2nd patches. I'll prepare the patches that do not void 
this current products certificate.

Regards,
Peter


From greearb at candelatech.com  Wed Apr 15 12:34:32 2015
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 15 Apr 2015 12:34:32 -0700
Subject: Using ath10k for WiFi capturing non-11ac traffic
In-Reply-To: <CAOt_L3-N8eaZpKzTHny9KSZxxAgvHFk0t2MpcgMkmE5DdEGrpA@mail.gmail.com>
References: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>
 <CA+BoTQmh2zQRpzq2=d9KKQy_Zn7TAFa3qL-LeaRZJ8e6Xheo6g@mail.gmail.com>
 <CAOt_L3-cv7npPmWdheLjhXBiiOQRjC=GYoEZw2OSwgf-kEsUWg@mail.gmail.com>
 <552DAE9D.7090405@candelatech.com>
 <CAOt_L3_FG53W5xK1csb=+VXDy2wdW-V3nbg8mtFaHarEOdkLCg@mail.gmail.com>
 <552E7C91.5030607@candelatech.com>
 <CAOt_L3_nN-U41wm+=Skb7RixZr=8x-Y_VEO1vEQohFDJMa66fg@mail.gmail.com>
 <552E86BA.9000206@candelatech.com>
 <CAOt_L3-N8eaZpKzTHny9KSZxxAgvHFk0t2MpcgMkmE5DdEGrpA@mail.gmail.com>
Message-ID: <552EBD48.5000605@candelatech.com>

Here's another funny thing I just noticed.

When trying to capture high-speed IBSS traffic, I get almost no data packets
at all delivered...maybe because the are A-MPDU or something like that and are
too big?

Anyway, curious if you have tried high-speed captures in networks with block-ack
and a-mpdu enabled....

Thanks,
Ben


On 04/15/2015 08:46 AM, Amato Carbonara wrote:
> Thanks Ben. I plan to upgrade to latest ath10k firmware and retest. I need to find some time to experiment.
> 
> On Apr 15, 2015 11:41 AM, "Ben Greear" <greearb at candelatech.com <mailto:greearb at candelatech.com>> wrote:
> 
>     On 04/15/2015 08:07 AM, Amato Carbonara wrote:
>     > Hi Ben,
>     >   I performed my captures when the WiFi adapter running the ath10k was
>     > not connected to the WiFi network.  In other words, the capture shows
>     > traffic between 2 different devices.  The ath10k device is in
>     > promiscuous mode and capturing all the traffic between the devices.
> 
>     Yes, I did the same, and still no BlockAck action frames are captured.
> 
>     Firmware has special handling for these frames, so probably it eats
>     them before passing on to the host.
> 
>     Thanks,
>     Ben
> 
>     >
>     > On Wed, Apr 15, 2015 at 10:58 AM, Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>> wrote:
>     >>
>     >>
>     >> On 04/15/2015 07:28 AM, Amato Carbonara wrote:
>     >>>
>     >>> Hi Ben,
>     >>>    I have done numerous captures using the ath10k driver on different
>     >>> 802.11 variant networks, specifically 802.11n (20MHz and 40MHz) and
>     >>> 802.11ac.  In all these captures, I have captured the Block-Ack frames
>     >>> (Wireshark filter wlan.fc.type_subtype == 0x0019), but do not see any
>     >>> Block-ACK Request or Response frames.  In fact, none of my captures
>     >>> using the ath10k drivers show any Action frames (Wireshark filter
>     >>> wlan.fc.type_subtype == 0x000d).  This is very peculiar since the IEEE
>     >>> specification 802.11-2012 section 9.21.2 states: "If the intended
>     >>> recipient STA is capable of participating, the originator sends an
>     >>> ADDBA Request frame".  Therefor, the ADDBA must be sent in order for
>     >>> Block-Acks to occur.  I have also noticed missing Association Response
>     >>> frames from the STA.
>     >>>
>     >>> Currently, I am using firmware 10.1.467.2-1 to perform my captures.
>     >>
>     >>
>     >> I think the ath10k firmware must just consume the block-ack request/response
>     >> frames internally and
>     >> never send them up to the host.  It does send an htt message about blockack
>     >> control messages being
>     >> received.
>     >>
>     >> Probably something I could fix in my 10.1 firmware...but first I need to
>     >> figure out why ath9k (mac80211 stack, actually) ignores the block-ack
>     >> messages that my ibss ath10k
>     >> interface sends....
>     >>
>     >> Thanks,
>     >> Ben
>     >>
>     >>
>     >>>
>     >>> Has anyone else tried using a different firmware version, for example
>     >>> 10.2.4, to perform WiFi captures?
>     >>>
>     >>> On Tue, Apr 14, 2015 at 8:19 PM, Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>     >>> wrote:
>     >>>>
>     >>>> Out of curiosity, have you been able to capture Action frames
>     >>>> (specifically,
>     >>>> block-ack add/del frames) with ath10k?  I just wasted a large amount of
>     >>>> time wondering
>     >>>> why the frames are not seen...but ath9k monitor port sees them just fine.
>     >>>>
>     >>>> Thanks,
>     >>>> Ben
>     >>>>
>     >>>>
>     >>>> On 04/14/2015 11:04 AM, Amato Carbonara wrote:
>     >>>>>
>     >>>>> Hello Michal,
>     >>>>>    I was able to decrypt all traffic types (11a, 11n at 20MHz, 11n at
>     >>>>> 40MHz and 11ac at 80MHz) using the 10.1.467.2-1 firmware on the
>     >>>>> QCA9880 chipset.  The problem was not with Wireshark.  I had to
>     >>>>> install backports for the at10k drivers to make it work.  Procedures
>     >>>>> are documented here:
>     >>>>> https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/backports
>     >>>>>
>     >>>>> Thank you for your help,
>     >>>>> Amato
>     >>>>>
>     >>>>> On Tue, Apr 14, 2015 at 1:38 AM, Michal Kazior <michal.kazior at tieto.com <mailto:michal.kazior at tieto.com>>
>     >>>>> wrote:
>     >>>>>>
>     >>>>>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at gmail.com <mailto:acarbonara13 at gmail.com>>
>     >>>>>> wrote:
>     >>>>>>>
>     >>>>>>> Hello,
>     >>>>>>>    I have installed a WiFi adapter with the Qualcomm-Atheros QCA-9880
>     >>>>>>> chipset using the at10k drivers.  I am using this WiFi adapter to
>     >>>>>>> capture WLAN traffic.  The recommended firmware for capturing WiFi
>     >>>>>>> traffic is 10.1.467.2-1 per the website.  See following link:
>     >>>>>>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor
>     >>>>>>
>     >>>>>>
>     >>>>>> Generally the 10.x line is preferred for sniffing. You could also try
>     >>>>>> 10.2.4.
>     >>>>>>
>     >>>>>>
>     >>>>>>> I have successfully installed the above firmware and have been using
>     >>>>>>> the adapter/driver to capture and decrypt all 802.11ac traffic.
>     >>>>>>> However, I have noticed some strange behavior when trying to decrypt
>     >>>>>>> other types of traffic such as:
>     >>>>>>>    1) 802.11a = not able to decrypt any traffic
>     >>>>>>>    2) 802.11n at 20MHz = able to decrypt only partial traffic
>     >>>>>>>    3) 802.11n at 40MHz = able to decrypt only partial traffic
>     >>>>>>>
>     >>>>>>> I have tried using the different "iw" and "iwconfig" commands to set
>     >>>>>>> the frequency and channel bandwidth (for example, iw dev wlan1 set
>     >>>>>>> freq 5180 HT20).  Has anyone else seen this issue of not being able to
>     >>>>>>> decrypt all/some of the WiFi traffic?
>     >>>>>>
>     >>>>>>
>     >>>>>> `iwconfig` is an old program. You shouldn't use it. Just stick with
>     >>>>>> `iw`.
>     >>>>>>
>     >>>>>> To decrypt traffic you need to see keying handshake (both after
>     >>>>>> association and later for each rekeying). If sniffer misses that you
>     >>>>>> won't be able to decipher data either from the start or you'll stop
>     >>>>>> being able to decrypt multicast data after GTK rekeying.
>     >>>>>>
>     >>>>>> Another thing is I've had numerous random problems with wireshark
>     >>>>>> refusing to decrypt frames reliably. I recall some older version would
>     >>>>>> get stuck and need the key configuration (in preferences window) to be
>     >>>>>> re-applied or the decrypt checkbox to be re-checked. YMMV.
>     >>>>>>
>     >>>>>>
>     >>>>>> Micha?
>     >>>>>
>     >>>>>
>     >>>>> _______________________________________________
>     >>>>> ath10k mailing list
>     >>>>> ath10k at lists.infradead.org <mailto:ath10k at lists.infradead.org>
>     >>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>     >>>>>
>     >>>>
>     >>>>
>     >>>> --
>     >>>> Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>     >>>> Candela Technologies Inc  http://www.candelatech.com
>     >>>>
>     >>>
>     >>> _______________________________________________
>     >>> ath10k mailing list
>     >>> ath10k at lists.infradead.org <mailto:ath10k at lists.infradead.org>
>     >>> http://lists.infradead.org/mailman/listinfo/ath10k
>     >>>
>     >>
>     >> --
>     >> Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>     >> Candela Technologies Inc  http://www.candelatech.com
>     >
> 
> 
>     --
>     Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>     Candela Technologies Inc  http://www.candelatech.com
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Wed Apr 15 14:51:45 2015
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 15 Apr 2015 14:51:45 -0700
Subject: CT ath10k firmware now supports IBSS + RSN
In-Reply-To: <552D2BD5.7050204@candelatech.com>
References: <55285D8D.6070703@candelatech.com>	<552BFFB8.6030301@candelatech.com>	<552C5AE9.4050304@candelatech.com>
 <CA+BoTQ=C0xxDifiiQVbyBe=OHYUjzHcu49mULJpU+=2SNCZ-dQ@mail.gmail.com>
 <552D2BD5.7050204@candelatech.com>
Message-ID: <552EDD71.2070207@candelatech.com>

I have uploaded a new firmware.

http://www.candelatech.com/downloads/ath10k-fw-beta/

It fixes IBSS blockack (firmware was mis-configuring the BSSID, so
blockacks were sent to wrong BSS address and were not processed when
received).

I also disabled AMSDU for IBSS stations, which significantly improves
performance in my ath10k <-> ath10k IBSS test.  I do not know why this
is needed.

There is still a bug:  I cannot get ath10k <-> ath10k to do IBSS + RSN.

I can get ath9k <-> ath10k IBSS + RSN to work,
and open IBSS ath10k <-> ath10k works.

I am taking a break on IBSS + RSN for a while.

Thanks,
Ben




On 04/14/2015 08:01 AM, Ben Greear wrote:
> 
> 
> On 04/13/2015 10:34 PM, Michal Kazior wrote:
>> On 14 April 2015 at 02:10, Ben Greear <greearb at candelatech.com> wrote:
>>> On 04/13/2015 10:41 AM, Ben Greear wrote:
>>>> Looks like I have some more work to do.  For any moderately large frames,
>>>> I am now dropping the last 16 bytes.  Looks like the skb_put_padto logic
>>>> was working around a more serious issue...
>>>
>>> A better-tested version of kernel and firmware is uploaded now.
>>>
>>> Looks like I needed to add a hack to firmware to bump pkt-size by
>>> 16 for IBSS + RSN encrypted frames.  Not sure exactly why, but seems
>>> to work in light testing.
>>>
>>> I removed the skb-padto hack from the kernel, and kernel is rebased on
>>> top of official 4.0 now.
>>
>> Hmm.. Maybe this is related to MMIC. Maybe frame fragment length must
>> be different from frame length (ath10k_htt_tx(),
>> htt_data_tx_desc_frag)? Perhaps a similar hack as with RAW txmode[1]
>> needs to be applied..?
>>
>>
>> [1]: https://www.mail-archive.com/ath10k at lists.infradead.org/msg00241.html
> 
> This IBSS+RSN hack could be done in the kernel, but if my firmware is the only thing that
> needs it, then it is more convenient for me to hack firmware than have it
> incompatible with upstream drivers.
> 
> If you do find similar problems with other firmware, then certainly a driver
> patch is welcome, and I will back out my firmware hack accordingly.
> 
> And, it would be nice if someone put some version if your raw-tx patch upstream.
> I can also adjust length for raw pkts in firmware too, but again, in many cases
> it is better to be similarly broken to existing firmware than to be technically
> correct but break compatibility with the driver.  If I ever get a 'ct-firmware'
> feature flag upstream, then we could of course do the changes to take advantage
> of my firmwares differences as needed.
> 
> Thanks,
> Ben
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From janusz.dziedzic at tieto.com  Wed Apr 15 21:35:38 2015
From: janusz.dziedzic at tieto.com (Janusz Dziedzic)
Date: Thu, 16 Apr 2015 06:35:38 +0200
Subject: [RFC 2/2] ath10k: don't disable PS when not connected
In-Reply-To: <CAFuUQkieJ0CC83wPFm=c_gA5a6OzdbWBF-0EaDL0N=nNAsU2_g@mail.gmail.com>
References: <1428911141-6534-1-git-send-email-janusz.dziedzic@tieto.com>
 <1428911141-6534-2-git-send-email-janusz.dziedzic@tieto.com>
 <CAFuUQkhQeCwP098DH7_R4mNCvrJ7WxdT7wnHi52DSOKm8c0k1Q@mail.gmail.com>
 <CALhHN=pefUssihniviRiBWg+EU2wYp3excwodJBDt1+H0tiiHQ@mail.gmail.com>
 <CAFuUQkieJ0CC83wPFm=c_gA5a6OzdbWBF-0EaDL0N=nNAsU2_g@mail.gmail.com>
Message-ID: <CALhHN=pDDwx=AA=wnkbqrckXCu4JnBvJ=iDv=6MNrygVc73fNw@mail.gmail.com>

On 15 April 2015 at 19:10, YanBo <dreamfly281 at gmail.com> wrote:
> On Tue, Apr 14, 2015 at 10:00 PM, Janusz Dziedzic
> <janusz.dziedzic at tieto.com> wrote:
>> On 15 April 2015 at 00:45, YanBo <dreamfly281 at gmail.com> wrote:
>>> On Mon, Apr 13, 2015 at 12:45 AM, Janusz Dziedzic
>>> <janusz.dziedzic at tieto.com> wrote:
>>>> Don't disable PS while we are not connected.
>>>> In other case we will get higher power consumption.
>>>>
>>>> Signed-off-by: Janusz Dziedzic <janusz.dziedzic at tieto.com>
>>>> ---
>>>>  drivers/net/wireless/ath/ath10k/mac.c | 8 +++++++-
>>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>>>> index 52c5b1f..b896dd4 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>>> @@ -1730,7 +1730,13 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif *arvif)
>>>>                 enable_ps = false;
>>>>         }
>>>>
>>>> -       if (enable_ps) {
>>>> +       if (!arvif->is_started) {
>>>> +               /* enable power save mode while not connected,
>>>> +                * in other case after iface up we will get
>>>> +                * higher power consumption - firmware design
>>>> +                */
>>>> +               psmode = WMI_STA_PS_MODE_ENABLED;
>>>> +       } else if (enable_ps) {
>>>>                 psmode = WMI_STA_PS_MODE_ENABLED;
>>>>                 param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
>>>>
>>>> --
>>>
>>> What the expectation behavior after we enable the
>>> WMI_STA_PS_MODE_ENABLED at Idle status?
>>> Is there any effect for TX or RX chain after set it?
>>>
>>
>> First I think that WMI_STA_PS_MODE_ENABLED is important only when we
>> are connected.
>> But, I see current consumption drop in my test environtment from 88mA
>> to 33mA when:
>> 1) load driver, iface up
>> 2) disconnect network, iface down, iface up
>> So, seems WMI_STA_PS_MODE_ENABLED do something more in FW (not only
>> standard PS enable/disable when
>> connected to AP). Probably someone from FW team should answer that, if
>> that is a feature or a bug.
>>
> I guess the chip enter Idle  mode power save  after set this,  did you
> run the the
> test on QCA61XX or QCA 98XX?   Can it still auto scan to get all the APs around
> it, cause for IMPS mode it will only looks in its existing profile
> list and sends a probe request,
> with SSID specified in profile for what I know
>
I see iw scan works correctly after iface up (same scan results like ath9k):

In my laptop I have 3 cards
wlan0 - ath9k
wlan1 - QCA9888
wlan4 - QCA6174

janusz at dell6430:~$ sudo iw wlan0 scan dump|grep SSID |wc -l
0
janusz at dell6430:~$ sudo iw wlan0 scan |grep SSID| wc -l
21
janusz at dell6430:~$ sudo ifconfig wlan0 down

janusz at dell6430:~$ sudo iw wlan1 scan dump|grep SSID|wc -l
0
janusz at dell6430:~$ sudo iw wlan1 scan |grep SSID|wc -l
21
janusz at dell6430:~$ sudo ifconfig wlan1 down

janusz at dell6430:~$ sudo iw wlan4 scan dump|grep SSID|wc -l
0
janusz at dell6430:~$ sudo iw wlan4 scan |grep SSID|wc -l
22

Should I run any other scan tests?

BR
Janusz


From acarbonara13 at gmail.com  Thu Apr 16 06:16:21 2015
From: acarbonara13 at gmail.com (Amato Carbonara)
Date: Thu, 16 Apr 2015 09:16:21 -0400
Subject: Using ath10k for WiFi capturing non-11ac traffic
In-Reply-To: <552EBD48.5000605@candelatech.com>
References: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>
 <CA+BoTQmh2zQRpzq2=d9KKQy_Zn7TAFa3qL-LeaRZJ8e6Xheo6g@mail.gmail.com>
 <CAOt_L3-cv7npPmWdheLjhXBiiOQRjC=GYoEZw2OSwgf-kEsUWg@mail.gmail.com>
 <552DAE9D.7090405@candelatech.com>
 <CAOt_L3_FG53W5xK1csb=+VXDy2wdW-V3nbg8mtFaHarEOdkLCg@mail.gmail.com>
 <552E7C91.5030607@candelatech.com>
 <CAOt_L3_nN-U41wm+=Skb7RixZr=8x-Y_VEO1vEQohFDJMa66fg@mail.gmail.com>
 <552E86BA.9000206@candelatech.com>
 <CAOt_L3-N8eaZpKzTHny9KSZxxAgvHFk0t2MpcgMkmE5DdEGrpA@mail.gmail.com>
 <552EBD48.5000605@candelatech.com>
Message-ID: <CAOt_L39edL7vNzcTcnXEVfgwa7TOAj5LWAvqjgpG--_GnEOCEw@mail.gmail.com>

Also confirmed from my captures.  No AMPDU frames captured using
ath10k driver.  Using another WiFi adapter and driver, AMPDU frames
were captured.

On Wed, Apr 15, 2015 at 3:34 PM, Ben Greear <greearb at candelatech.com> wrote:
> Here's another funny thing I just noticed.
>
> When trying to capture high-speed IBSS traffic, I get almost no data packets
> at all delivered...maybe because the are A-MPDU or something like that and are
> too big?
>
> Anyway, curious if you have tried high-speed captures in networks with block-ack
> and a-mpdu enabled....
>
> Thanks,
> Ben
>
>
> On 04/15/2015 08:46 AM, Amato Carbonara wrote:
>> Thanks Ben. I plan to upgrade to latest ath10k firmware and retest. I need to find some time to experiment.
>>
>> On Apr 15, 2015 11:41 AM, "Ben Greear" <greearb at candelatech.com <mailto:greearb at candelatech.com>> wrote:
>>
>>     On 04/15/2015 08:07 AM, Amato Carbonara wrote:
>>     > Hi Ben,
>>     >   I performed my captures when the WiFi adapter running the ath10k was
>>     > not connected to the WiFi network.  In other words, the capture shows
>>     > traffic between 2 different devices.  The ath10k device is in
>>     > promiscuous mode and capturing all the traffic between the devices.
>>
>>     Yes, I did the same, and still no BlockAck action frames are captured.
>>
>>     Firmware has special handling for these frames, so probably it eats
>>     them before passing on to the host.
>>
>>     Thanks,
>>     Ben
>>
>>     >
>>     > On Wed, Apr 15, 2015 at 10:58 AM, Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>> wrote:
>>     >>
>>     >>
>>     >> On 04/15/2015 07:28 AM, Amato Carbonara wrote:
>>     >>>
>>     >>> Hi Ben,
>>     >>>    I have done numerous captures using the ath10k driver on different
>>     >>> 802.11 variant networks, specifically 802.11n (20MHz and 40MHz) and
>>     >>> 802.11ac.  In all these captures, I have captured the Block-Ack frames
>>     >>> (Wireshark filter wlan.fc.type_subtype == 0x0019), but do not see any
>>     >>> Block-ACK Request or Response frames.  In fact, none of my captures
>>     >>> using the ath10k drivers show any Action frames (Wireshark filter
>>     >>> wlan.fc.type_subtype == 0x000d).  This is very peculiar since the IEEE
>>     >>> specification 802.11-2012 section 9.21.2 states: "If the intended
>>     >>> recipient STA is capable of participating, the originator sends an
>>     >>> ADDBA Request frame".  Therefor, the ADDBA must be sent in order for
>>     >>> Block-Acks to occur.  I have also noticed missing Association Response
>>     >>> frames from the STA.
>>     >>>
>>     >>> Currently, I am using firmware 10.1.467.2-1 to perform my captures.
>>     >>
>>     >>
>>     >> I think the ath10k firmware must just consume the block-ack request/response
>>     >> frames internally and
>>     >> never send them up to the host.  It does send an htt message about blockack
>>     >> control messages being
>>     >> received.
>>     >>
>>     >> Probably something I could fix in my 10.1 firmware...but first I need to
>>     >> figure out why ath9k (mac80211 stack, actually) ignores the block-ack
>>     >> messages that my ibss ath10k
>>     >> interface sends....
>>     >>
>>     >> Thanks,
>>     >> Ben
>>     >>
>>     >>
>>     >>>
>>     >>> Has anyone else tried using a different firmware version, for example
>>     >>> 10.2.4, to perform WiFi captures?
>>     >>>
>>     >>> On Tue, Apr 14, 2015 at 8:19 PM, Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>>     >>> wrote:
>>     >>>>
>>     >>>> Out of curiosity, have you been able to capture Action frames
>>     >>>> (specifically,
>>     >>>> block-ack add/del frames) with ath10k?  I just wasted a large amount of
>>     >>>> time wondering
>>     >>>> why the frames are not seen...but ath9k monitor port sees them just fine.
>>     >>>>
>>     >>>> Thanks,
>>     >>>> Ben
>>     >>>>
>>     >>>>
>>     >>>> On 04/14/2015 11:04 AM, Amato Carbonara wrote:
>>     >>>>>
>>     >>>>> Hello Michal,
>>     >>>>>    I was able to decrypt all traffic types (11a, 11n at 20MHz, 11n at
>>     >>>>> 40MHz and 11ac at 80MHz) using the 10.1.467.2-1 firmware on the
>>     >>>>> QCA9880 chipset.  The problem was not with Wireshark.  I had to
>>     >>>>> install backports for the at10k drivers to make it work.  Procedures
>>     >>>>> are documented here:
>>     >>>>> https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/backports
>>     >>>>>
>>     >>>>> Thank you for your help,
>>     >>>>> Amato
>>     >>>>>
>>     >>>>> On Tue, Apr 14, 2015 at 1:38 AM, Michal Kazior <michal.kazior at tieto.com <mailto:michal.kazior at tieto.com>>
>>     >>>>> wrote:
>>     >>>>>>
>>     >>>>>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at gmail.com <mailto:acarbonara13 at gmail.com>>
>>     >>>>>> wrote:
>>     >>>>>>>
>>     >>>>>>> Hello,
>>     >>>>>>>    I have installed a WiFi adapter with the Qualcomm-Atheros QCA-9880
>>     >>>>>>> chipset using the at10k drivers.  I am using this WiFi adapter to
>>     >>>>>>> capture WLAN traffic.  The recommended firmware for capturing WiFi
>>     >>>>>>> traffic is 10.1.467.2-1 per the website.  See following link:
>>     >>>>>>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor
>>     >>>>>>
>>     >>>>>>
>>     >>>>>> Generally the 10.x line is preferred for sniffing. You could also try
>>     >>>>>> 10.2.4.
>>     >>>>>>
>>     >>>>>>
>>     >>>>>>> I have successfully installed the above firmware and have been using
>>     >>>>>>> the adapter/driver to capture and decrypt all 802.11ac traffic.
>>     >>>>>>> However, I have noticed some strange behavior when trying to decrypt
>>     >>>>>>> other types of traffic such as:
>>     >>>>>>>    1) 802.11a = not able to decrypt any traffic
>>     >>>>>>>    2) 802.11n at 20MHz = able to decrypt only partial traffic
>>     >>>>>>>    3) 802.11n at 40MHz = able to decrypt only partial traffic
>>     >>>>>>>
>>     >>>>>>> I have tried using the different "iw" and "iwconfig" commands to set
>>     >>>>>>> the frequency and channel bandwidth (for example, iw dev wlan1 set
>>     >>>>>>> freq 5180 HT20).  Has anyone else seen this issue of not being able to
>>     >>>>>>> decrypt all/some of the WiFi traffic?
>>     >>>>>>
>>     >>>>>>
>>     >>>>>> `iwconfig` is an old program. You shouldn't use it. Just stick with
>>     >>>>>> `iw`.
>>     >>>>>>
>>     >>>>>> To decrypt traffic you need to see keying handshake (both after
>>     >>>>>> association and later for each rekeying). If sniffer misses that you
>>     >>>>>> won't be able to decipher data either from the start or you'll stop
>>     >>>>>> being able to decrypt multicast data after GTK rekeying.
>>     >>>>>>
>>     >>>>>> Another thing is I've had numerous random problems with wireshark
>>     >>>>>> refusing to decrypt frames reliably. I recall some older version would
>>     >>>>>> get stuck and need the key configuration (in preferences window) to be
>>     >>>>>> re-applied or the decrypt checkbox to be re-checked. YMMV.
>>     >>>>>>
>>     >>>>>>
>>     >>>>>> Micha?
>>     >>>>>
>>     >>>>>
>>     >>>>> _______________________________________________
>>     >>>>> ath10k mailing list
>>     >>>>> ath10k at lists.infradead.org <mailto:ath10k at lists.infradead.org>
>>     >>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>     >>>>>
>>     >>>>
>>     >>>>
>>     >>>> --
>>     >>>> Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>>     >>>> Candela Technologies Inc  http://www.candelatech.com
>>     >>>>
>>     >>>
>>     >>> _______________________________________________
>>     >>> ath10k mailing list
>>     >>> ath10k at lists.infradead.org <mailto:ath10k at lists.infradead.org>
>>     >>> http://lists.infradead.org/mailman/listinfo/ath10k
>>     >>>
>>     >>
>>     >> --
>>     >> Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>>     >> Candela Technologies Inc  http://www.candelatech.com
>>     >
>>
>>
>>     --
>>     Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>>     Candela Technologies Inc  http://www.candelatech.com
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>


From dreamfly281 at gmail.com  Thu Apr 16 10:02:05 2015
From: dreamfly281 at gmail.com (YanBo)
Date: Thu, 16 Apr 2015 10:02:05 -0700
Subject: [RFC 2/2] ath10k: don't disable PS when not connected
In-Reply-To: <CALhHN=pDDwx=AA=wnkbqrckXCu4JnBvJ=iDv=6MNrygVc73fNw@mail.gmail.com>
References: <1428911141-6534-1-git-send-email-janusz.dziedzic@tieto.com>
 <1428911141-6534-2-git-send-email-janusz.dziedzic@tieto.com>
 <CAFuUQkhQeCwP098DH7_R4mNCvrJ7WxdT7wnHi52DSOKm8c0k1Q@mail.gmail.com>
 <CALhHN=pefUssihniviRiBWg+EU2wYp3excwodJBDt1+H0tiiHQ@mail.gmail.com>
 <CAFuUQkieJ0CC83wPFm=c_gA5a6OzdbWBF-0EaDL0N=nNAsU2_g@mail.gmail.com>
 <CALhHN=pDDwx=AA=wnkbqrckXCu4JnBvJ=iDv=6MNrygVc73fNw@mail.gmail.com>
Message-ID: <CAFuUQkhhUVshtsuuEVJuTEAwejq6D2fPUnF5rsSnSynaCni4Fg@mail.gmail.com>

On Wed, Apr 15, 2015 at 9:35 PM, Janusz Dziedzic
<janusz.dziedzic at tieto.com> wrote:
> On 15 April 2015 at 19:10, YanBo <dreamfly281 at gmail.com> wrote:
>> On Tue, Apr 14, 2015 at 10:00 PM, Janusz Dziedzic
>> <janusz.dziedzic at tieto.com> wrote:
>>> On 15 April 2015 at 00:45, YanBo <dreamfly281 at gmail.com> wrote:
>>>> On Mon, Apr 13, 2015 at 12:45 AM, Janusz Dziedzic
>>>> <janusz.dziedzic at tieto.com> wrote:
>>>>> Don't disable PS while we are not connected.
>>>>> In other case we will get higher power consumption.
>>>>>
>>>>> Signed-off-by: Janusz Dziedzic <janusz.dziedzic at tieto.com>
>>>>> ---
>>>>>  drivers/net/wireless/ath/ath10k/mac.c | 8 +++++++-
>>>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>>>>> index 52c5b1f..b896dd4 100644
>>>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>>>> @@ -1730,7 +1730,13 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif *arvif)
>>>>>                 enable_ps = false;
>>>>>         }
>>>>>
>>>>> -       if (enable_ps) {
>>>>> +       if (!arvif->is_started) {
>>>>> +               /* enable power save mode while not connected,
>>>>> +                * in other case after iface up we will get
>>>>> +                * higher power consumption - firmware design
>>>>> +                */
>>>>> +               psmode = WMI_STA_PS_MODE_ENABLED;
>>>>> +       } else if (enable_ps) {
>>>>>                 psmode = WMI_STA_PS_MODE_ENABLED;
>>>>>                 param = WMI_STA_PS_PARAM_INACTIVITY_TIME;
>>>>>
>>>>> --
>>>>
>>>> What the expectation behavior after we enable the
>>>> WMI_STA_PS_MODE_ENABLED at Idle status?
>>>> Is there any effect for TX or RX chain after set it?
>>>>
>>>
>>> First I think that WMI_STA_PS_MODE_ENABLED is important only when we
>>> are connected.
>>> But, I see current consumption drop in my test environtment from 88mA
>>> to 33mA when:
>>> 1) load driver, iface up
>>> 2) disconnect network, iface down, iface up
>>> So, seems WMI_STA_PS_MODE_ENABLED do something more in FW (not only
>>> standard PS enable/disable when
>>> connected to AP). Probably someone from FW team should answer that, if
>>> that is a feature or a bug.
>>>
>> I guess the chip enter Idle  mode power save  after set this,  did you
>> run the the
>> test on QCA61XX or QCA 98XX?   Can it still auto scan to get all the APs around
>> it, cause for IMPS mode it will only looks in its existing profile
>> list and sends a probe request,
>> with SSID specified in profile for what I know
>>
> I see iw scan works correctly after iface up (same scan results like ath9k):
>
> In my laptop I have 3 cards
> wlan0 - ath9k
> wlan1 - QCA9888
> wlan4 - QCA6174
>
> janusz at dell6430:~$ sudo iw wlan0 scan dump|grep SSID |wc -l
> 0
> janusz at dell6430:~$ sudo iw wlan0 scan |grep SSID| wc -l
> 21
> janusz at dell6430:~$ sudo ifconfig wlan0 down
>
> janusz at dell6430:~$ sudo iw wlan1 scan dump|grep SSID|wc -l
> 0
> janusz at dell6430:~$ sudo iw wlan1 scan |grep SSID|wc -l
> 21
> janusz at dell6430:~$ sudo ifconfig wlan1 down
>
> janusz at dell6430:~$ sudo iw wlan4 scan dump|grep SSID|wc -l
> 0
> janusz at dell6430:~$ sudo iw wlan4 scan |grep SSID|wc -l
> 22
>
> Should I run any other scan tests?
>

Thanks for the verification, I also get the confirmation that the card will
leave IMPS mode when scanning, so it works as expected.

BR /Yanbo


From kvalo at qca.qualcomm.com  Thu Apr 16 23:33:21 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 17 Apr 2015 09:33:21 +0300
Subject: [PATCH] ath10k: fix error handling in pci_probe
In-Reply-To: <1428670887-7533-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 10 Apr 2015 13:01:27 +0000")
References: <1428670887-7533-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87vbgv4632.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> If chip_id wasn't recognized clean up code wasn't
> executed properly. It would skip freeing memory
> causing a leak and irqs causing possibly MSI
> warning splats later or even kernel crashes.
>
> Fixes: 1a7fecb766c8 ("ath10k: reset chip before reading chip_id in probe")
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Thu Apr 16 23:34:32 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 17 Apr 2015 09:34:32 +0300
Subject: [PATCH] ath10k: add extra check for frame tracing
In-Reply-To: <1428670948-7665-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 10 Apr 2015 13:02:28 +0000")
References: <1428670948-7665-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87r3rj4613.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> Frames are logged via tracing in two slices:
> header and payload, separately. This is done for
> performance reasons when one wants to, e.g.
> analyse metadata only of frames only.
>
> If for some reason device delivered a frame buffer
> which was sized below what 802.11 header implied
> tracing logic would blow doing an invalid memory
> accesses.
>
> I've hit this problem when running IBSS on QCA988X
> with 999.999.0.636 and tracing at the same time.
>
> Fixes: 5ce8e7fdcc7a ("ath10k: handle ieee80211 header and payload tracing separately")
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Thu Apr 16 23:35:23 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 17 Apr 2015 09:35:23 +0300
Subject: [PATCH] ath10k: change static wep key handling for client mode
In-Reply-To: <1428671158-8159-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 10 Apr 2015 13:05:58 +0000")
References: <1428671158-8159-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87mw2745zo.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> mac80211 sets static WEP keys as groupwise while
> firmware requires them to be installed twice as
> both pairwise and groupwise.
>
> Until now these keys were installed once as
> pairwise only and, due to that special handling,
> needed additional tricks to support 802.1x as
> well.
>
> Without this patch in some cases (when AP and
> ath10k client use different default tx keys)
> multicast communication was broken.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Thu Apr 16 23:37:51 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 17 Apr 2015 09:37:51 +0300
Subject: [PATCH 0/4] ath10k: ibss crypto fixes
In-Reply-To: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 10 Apr 2015 13:23:19 +0000")
References: <1428672203-8604-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87iocv45vk.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> I've mainly tested this on kvalo/pending branch.
> Currently master branch contains 0f611d28fc2e
> ("mac80211: count interfaces correctly for
> combination checks") which breaks IBSS in
> wpa_supplicant due to P2P Device and interface
> combinations. This has been pointed out in the
> following thread:
>
>  [1]: http://thread.gmane.org/gmane.linux.kernel.wireless.general/135570/focus=136643
>
> If someone's interested in running ath10k IBSS
> make sure to use kernel prior to 4.0, revert the
> mentioned mac80211 patch or apply wpa_supplicant
> workaround patch from [1].
>
>
> Janusz Dziedzic (1):
>   ath10k: enable ibss-rsn
>
> Michal Kazior (3):
>   ath10k: don't use reassoc flag
>   ath10k: fix multiple key static wep with ibss
>   ath10k: set def key idx for ibss

Thanks, all four patches applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Thu Apr 16 23:44:43 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 17 Apr 2015 09:44:43 +0300
Subject: [PATCH v2] ath10k: use MAC clock rate same as FW uses for survey
 accuracy
In-Reply-To: <6a113cdb1b0dbbb6d98ab6b363b4912474c32bac.1428701627.git.poh@qca.qualcomm.com>
 (Peter Oh's message of "Mon, 13 Apr 2015 11:01:20 -0700")
References: <6a113cdb1b0dbbb6d98ab6b363b4912474c32bac.1428701627.git.poh@qca.qualcomm.com>
Message-ID: <87egnj45k4.fsf@kamboji.qca.qualcomm.com>

Peter Oh <poh at qca.qualcomm.com> writes:

> WLAN survey data provides several informative values on each channels
> such as noise, active time, transmit time, and etc.
> Regarding the channel activity time data, it is reported from firmware
> in different form which is number of cycles instead of time itself.
> Hence host driver converts it to time unit by dividing it by clock rate
> that is used at baseband MAC.
>
> Using difference clock rate from that actual HW is using will result in
> inaccurate survey data. For instance, channel active time can be reported
> with bigger than 150ms even though we set Dwell time to 150ms.
> Therefore set the clock rate to 88000 (88 MHz) which is ath10k baseband
> MAC is using.
>
> Signed-off-by: Peter Oh <poh at qca.qualcomm.com>

Thanks, applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Thu Apr 16 23:45:45 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 17 Apr 2015 09:45:45 +0300
Subject: [PATCH 1/2] ath10k: Add the WMI Air Time Fairness service define
In-Reply-To: <1427739246-2734-1-git-send-email-yanbol@qca.qualcomm.com> (Yanbo
 Li's message of "Mon, 30 Mar 2015 11:14:05 -0700")
References: <1427739246-2734-1-git-send-email-yanbol@qca.qualcomm.com>
Message-ID: <87a8y745ie.fsf@kamboji.qca.qualcomm.com>

Yanbo Li <yanbol at qca.qualcomm.com> writes:

> Add the FW ATF (Air Time Fairness) service define to keep consistent
> with 10.2 FW capability
>
> Signed-off-by: Yanbo Li <yanbol at qca.qualcomm.com>

Thanks, both patches applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Fri Apr 17 00:06:28 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 17 Apr 2015 10:06:28 +0300
Subject: [PATCH] ath10k: implement more versatile set_bitrate_mask
In-Reply-To: <1428672772-9275-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 10 Apr 2015 13:32:52 +0000")
References: <1428672772-9275-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87618v44jv.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> Until now only a single fixed tx rate or nss was
> allowed to be set.
>
> The patch attempts to improve this by allowing
> most bitrate masks. The limitation is VHT MCS
> rates cannot be expressed separately using
> existing firmware interfaces and only the
> following VHT MCS ranges are supported: none, 0-7,
> 0-8, and 0-9.
>
> This keeps the old behaviour when requesting
> single tx rate or single nss. The new bitrate mask
> logic is only applied to other cases that would
> return -EINVAL until now.
>
> Depending on firmware revisions some combinations
> may crash firmware so use with care, please.
>
> This depends on "ath10k: don't use reassoc flag".
> Without it key cache would effectively be
> invalidated upon bitrate change leading to
> communication being no longer possible.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

To reduce support questions from the users it would be nice to give few
good examples how to use this with iw. And also it makes it easier to
test the patch. If you could send something I can add it to the commit
log.

> +static u16
> +ath10k_peer_assoc_h_vht_limit(u16 tx_mcs_set,
> +			      const u16 vht_mcs_limit[NL80211_VHT_NSS_MAX])
> +{
> +	int idx_limit;
> +	int nss;
> +	u16 mcs_map;
> +	u16 mcs;
> +
> +	for (nss = 0; nss < NL80211_VHT_NSS_MAX; nss++) {
> +		mcs_map = ath10k_mac_get_max_vht_mcs_map(tx_mcs_set, nss) &
> +			  vht_mcs_limit[nss];
> +
> +		if (mcs_map)
> +			idx_limit = fls(mcs_map) - 1;
> +		else
> +			idx_limit = -1;
> +
> +		switch (idx_limit) {
> +		case 0: /* fall through */
> +		case 1: /* fall through */
> +		case 2: /* fall through */
> +		case 3: /* fall through */
> +		case 4: /* fall through */
> +		case 5: /* fall through */
> +		case 6: /* fall through */
> +		default:
> +			/* see ath10k_mac_can_set_bitrate_mask() */
> +			WARN_ON(1);
> +			/* fall through */
> +		case -1:
> +			mcs = IEEE80211_VHT_MCS_NOT_SUPPORTED; break;
> +		case 7:
> +			mcs = IEEE80211_VHT_MCS_SUPPORT_0_7; break;
> +		case 8:
> +			mcs = IEEE80211_VHT_MCS_SUPPORT_0_8; break;
> +		case 9:
> +			mcs = IEEE80211_VHT_MCS_SUPPORT_0_9; break;
> +		}

I moved the breaks into their own lines, I think that just easier to
read. This is the diff:

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index ace273f7ec73..069f399e4c25 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2277,13 +2277,17 @@ ath10k_peer_assoc_h_vht_limit(u16 tx_mcs_set,
                        WARN_ON(1);
                        /* fall through */
                case -1:
-                       mcs = IEEE80211_VHT_MCS_NOT_SUPPORTED; break;
+                       mcs = IEEE80211_VHT_MCS_NOT_SUPPORTED;
+                       break;
                case 7:
-                       mcs = IEEE80211_VHT_MCS_SUPPORT_0_7; break;
+                       mcs = IEEE80211_VHT_MCS_SUPPORT_0_7;
+                       break;
                case 8:
-                       mcs = IEEE80211_VHT_MCS_SUPPORT_0_8; break;
+                       mcs = IEEE80211_VHT_MCS_SUPPORT_0_8;
+                       break;
                case 9:
-                       mcs = IEEE80211_VHT_MCS_SUPPORT_0_9; break;
+                       mcs = IEEE80211_VHT_MCS_SUPPORT_0_9;
+                       break;
                }
 
                tx_mcs_set &= ~(0x3 << (nss * 2));

-- 
Kalle Valo


From michal.kazior at tieto.com  Fri Apr 17 00:30:51 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 17 Apr 2015 09:30:51 +0200
Subject: [PATCH] ath10k: implement more versatile set_bitrate_mask
In-Reply-To: <87618v44jv.fsf@kamboji.qca.qualcomm.com>
References: <1428672772-9275-1-git-send-email-michal.kazior@tieto.com>
 <87618v44jv.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CA+BoTQnNNKF7riAgcVj1LupABAGodm751jxOUuZgam8u=wthUA@mail.gmail.com>

On 17 April 2015 at 09:06, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> Until now only a single fixed tx rate or nss was
>> allowed to be set.
>>
>> The patch attempts to improve this by allowing
>> most bitrate masks. The limitation is VHT MCS
>> rates cannot be expressed separately using
>> existing firmware interfaces and only the
>> following VHT MCS ranges are supported: none, 0-7,
>> 0-8, and 0-9.
>>
>> This keeps the old behaviour when requesting
>> single tx rate or single nss. The new bitrate mask
>> logic is only applied to other cases that would
>> return -EINVAL until now.
>>
>> Depending on firmware revisions some combinations
>> may crash firmware so use with care, please.
>>
>> This depends on "ath10k: don't use reassoc flag".
>> Without it key cache would effectively be
>> invalidated upon bitrate change leading to
>> communication being no longer possible.
>>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>
> To reduce support questions from the users it would be nice to give few
> good examples how to use this with iw. And also it makes it easier to
> test the patch. If you could send something I can add it to the commit
> log.

Should work:

  iw wlan0 set bitrates legacy 1 6 12 ht-mcs 1 2 3
  iw wlan0 set bitrates legacy-5 mcs-5 7 8 9
  iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9

Won't work:

  iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-5
  iw wlan0 set bitrates vht-mcs-5 2:7-9

(note the invalid VHT MCS ranges)

Generally the patch removes a lot of limitations from 'set bitrates'
ath10k had. Before it was possible to do only things as described in
51ab1a0a09a8 ("ath10k: add set_bitrate_mask callback").


[...]
>> +             default:
>> +                     /* see ath10k_mac_can_set_bitrate_mask() */
>> +                     WARN_ON(1);
>> +                     /* fall through */
>> +             case -1:
>> +                     mcs = IEEE80211_VHT_MCS_NOT_SUPPORTED; break;
>> +             case 7:
>> +                     mcs = IEEE80211_VHT_MCS_SUPPORT_0_7; break;
>> +             case 8:
>> +                     mcs = IEEE80211_VHT_MCS_SUPPORT_0_8; break;
>> +             case 9:
>> +                     mcs = IEEE80211_VHT_MCS_SUPPORT_0_9; break;
>> +             }
>
> I moved the breaks into their own lines, I think that just easier to
> read. This is the diff:
[snip]

I'm okay with this.


Micha?


From michal.kazior at tieto.com  Fri Apr 17 02:19:16 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 17 Apr 2015 09:19:16 +0000
Subject: [PATCH v2 1/2] ath10k: share board file loading code across FW APIs
Message-ID: <1429262357-25139-1-git-send-email-michal.kazior@tieto.com>

There's no need to implement the same thing twice.
Reduce code duplication.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 68 +++++++++++++++-------------------
 1 file changed, 30 insertions(+), 38 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 2d64926c8228..70f5b7acc411 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -482,6 +482,30 @@ static int ath10k_fetch_cal_file(struct ath10k *ar)
 	return 0;
 }
 
+static int ath10k_core_fetch_board_file(struct ath10k *ar)
+{
+	int ret;
+
+	if (!ar->hw_params.fw.board) {
+		ath10k_err(ar, "failed to find board file fw entry\n");
+		return -EINVAL;
+	}
+
+	ar->board = ath10k_fetch_fw_file(ar,
+					 ar->hw_params.fw.dir,
+					 ar->hw_params.fw.board);
+	if (IS_ERR(ar->board)) {
+		ret = PTR_ERR(ar->board);
+		ath10k_err(ar, "failed to fetch board data: %d\n", ret);
+		return ret;
+	}
+
+	ar->board_data = ar->board->data;
+	ar->board_len = ar->board->size;
+
+	return 0;
+}
+
 static int ath10k_core_fetch_firmware_api_1(struct ath10k *ar)
 {
 	int ret = 0;
@@ -491,23 +515,6 @@ static int ath10k_core_fetch_firmware_api_1(struct ath10k *ar)
 		return -EINVAL;
 	}
 
-	if (ar->hw_params.fw.board == NULL) {
-		ath10k_err(ar, "board data file not defined");
-		return -EINVAL;
-	}
-
-	ar->board = ath10k_fetch_fw_file(ar,
-					 ar->hw_params.fw.dir,
-					 ar->hw_params.fw.board);
-	if (IS_ERR(ar->board)) {
-		ret = PTR_ERR(ar->board);
-		ath10k_err(ar, "could not fetch board data (%d)\n", ret);
-		goto err;
-	}
-
-	ar->board_data = ar->board->data;
-	ar->board_len = ar->board->size;
-
 	ar->firmware = ath10k_fetch_fw_file(ar,
 					    ar->hw_params.fw.dir,
 					    ar->hw_params.fw.fw);
@@ -706,27 +713,6 @@ static int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name)
 		goto err;
 	}
 
-	/* now fetch the board file */
-	if (ar->hw_params.fw.board == NULL) {
-		ath10k_err(ar, "board data file not defined");
-		ret = -EINVAL;
-		goto err;
-	}
-
-	ar->board = ath10k_fetch_fw_file(ar,
-					 ar->hw_params.fw.dir,
-					 ar->hw_params.fw.board);
-	if (IS_ERR(ar->board)) {
-		ret = PTR_ERR(ar->board);
-		ath10k_err(ar, "could not fetch board data '%s/%s' (%d)\n",
-			   ar->hw_params.fw.dir, ar->hw_params.fw.board,
-			   ret);
-		goto err;
-	}
-
-	ar->board_data = ar->board->data;
-	ar->board_len = ar->board->size;
-
 	return 0;
 
 err:
@@ -741,6 +727,12 @@ static int ath10k_core_fetch_firmware_files(struct ath10k *ar)
 	/* calibration file is optional, don't check for any errors */
 	ath10k_fetch_cal_file(ar);
 
+	ret = ath10k_core_fetch_board_file(ar);
+	if (ret) {
+		ath10k_err(ar, "failed to fetch board file: %d\n", ret);
+		return ret;
+	}
+
 	ar->fw_api = 5;
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "trying fw api %d\n", ar->fw_api);
 
-- 
2.1.4



From michal.kazior at tieto.com  Fri Apr 17 02:19:17 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 17 Apr 2015 09:19:17 +0000
Subject: [PATCH v2 2/2] ath10k: allow loading device specific board files
In-Reply-To: <1429262357-25139-1-git-send-email-michal.kazior@tieto.com>
References: <1429262357-25139-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <1429262357-25139-2-git-send-email-michal.kazior@tieto.com>

Some devices differ slightly and require different
board files. If wrong board data is used they
crash or behave incorrectly.

These devices can be differentiated by looking at
PCI subsystem device id. That is the case for
qca61x4 devices at least.

The board specific filename is constructed as:

 board-<bus>-<id>.bin

For PCI in particular it is:

 board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin

These files are looked in device/hw specific
directories. Hence for Killer 1525 (qca6174 hw2.1)
ath10k will request:

  /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin

To not break any existing setups (e.g. in case
some devices in the wild already have subsys ids)
if a board specific file isn't found a generic one
is used which is the one which would be used until
now. This guarantees that after upgrading a driver
device will not suddenly stop working due to
now-missing specific board file. If this is the
case a "fallback" string is appended to the info
string when driver boots.

Keep in mind this is distinct from cal-pci-*.bin
files which contain full calibration data and MAC
address. Cal data is aimed at systems where
calibration data is stored out of band, e.g. on
nand flash instead of device EEPROM - an approach
taken by some AP/router vendors.

Board files are more of a template and needs some
bits to be filled in by the OTP program using
device EEPROM contents.

One could argue to map subsystem ids to some board
design codename strings instead of using raw ids
when building the board filename. Using a mapping
however would make it a lot more cumbersome and
time consuming (due to how patches propagate over
various kernel trees) to add support for some new
device board designs. Adding a board file is a lot
quicker and doesn't require recompilation.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---

Notes:
    v2:
     * drop `0x` prefix
     * add device/vendor id's into the spec_board_id
       to avoid possible future namespace conflicts
     * improve commit log

 drivers/net/wireless/ath/ath10k/core.c  | 55 ++++++++++++++++++++++++++++-----
 drivers/net/wireless/ath/ath10k/core.h  |  3 ++
 drivers/net/wireless/ath/ath10k/debug.c |  6 +++-
 drivers/net/wireless/ath/ath10k/pci.c   |  6 ++++
 4 files changed, 62 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 70f5b7acc411..987b266278a8 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -482,10 +482,26 @@ static int ath10k_fetch_cal_file(struct ath10k *ar)
 	return 0;
 }
 
-static int ath10k_core_fetch_board_file(struct ath10k *ar)
+static int ath10k_core_fetch_spec_board_file(struct ath10k *ar)
 {
-	int ret;
+	char filename[100];
 
+	scnprintf(filename, sizeof(filename), "board-%s-%s.bin",
+		  ath10k_bus_str(ar->hif.bus), ar->spec_board_id);
+
+	ar->board = ath10k_fetch_fw_file(ar, ar->hw_params.fw.dir, filename);
+	if (IS_ERR(ar->board))
+		return PTR_ERR(ar->board);
+
+	ar->board_data = ar->board->data;
+	ar->board_len = ar->board->size;
+	ar->spec_board_loaded = true;
+
+	return 0;
+}
+
+static int ath10k_core_fetch_generic_board_file(struct ath10k *ar)
+{
 	if (!ar->hw_params.fw.board) {
 		ath10k_err(ar, "failed to find board file fw entry\n");
 		return -EINVAL;
@@ -494,14 +510,39 @@ static int ath10k_core_fetch_board_file(struct ath10k *ar)
 	ar->board = ath10k_fetch_fw_file(ar,
 					 ar->hw_params.fw.dir,
 					 ar->hw_params.fw.board);
-	if (IS_ERR(ar->board)) {
-		ret = PTR_ERR(ar->board);
-		ath10k_err(ar, "failed to fetch board data: %d\n", ret);
-		return ret;
-	}
+	if (IS_ERR(ar->board))
+		return PTR_ERR(ar->board);
 
 	ar->board_data = ar->board->data;
 	ar->board_len = ar->board->size;
+	ar->spec_board_loaded = false;
+
+	return 0;
+}
+
+static int ath10k_core_fetch_board_file(struct ath10k *ar)
+{
+	int ret;
+
+	if (strlen(ar->spec_board_id) > 0) {
+		ret = ath10k_core_fetch_spec_board_file(ar);
+		if (ret) {
+			ath10k_info(ar, "failed to load spec board file, falling back to generic: %d\n",
+				    ret);
+			goto generic;
+		}
+
+		ath10k_dbg(ar, ATH10K_DBG_BOOT, "found specific board file for %s\n",
+			   ar->spec_board_id);
+		return 0;
+	}
+
+generic:
+	ret = ath10k_core_fetch_generic_board_file(ar);
+	if (ret) {
+		ath10k_err(ar, "failed to fetch generic board data: %d\n", ret);
+		return ret;
+	}
 
 	return 0;
 }
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index b0e8905ca325..7bb113a443d7 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -592,6 +592,9 @@ struct ath10k {
 
 	const struct firmware *cal_file;
 
+	char spec_board_id[100];
+	bool spec_board_loaded;
+
 	int fw_api;
 	enum ath10k_cal_mode cal_mode;
 
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 1391f00f2b8f..8fa606a9c4dd 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -124,10 +124,14 @@ EXPORT_SYMBOL(ath10k_info);
 
 void ath10k_print_driver_info(struct ath10k *ar)
 {
-	ath10k_info(ar, "%s (0x%08x, 0x%08x) fw %s api %d htt %d.%d wmi %d cal %s max_sta %d\n",
+	ath10k_info(ar, "%s (0x%08x, 0x%08x%s%s%s) fw %s api %d htt %d.%d wmi %d cal %s max_sta %d\n",
 		    ar->hw_params.name,
 		    ar->target_version,
 		    ar->chip_id,
+		    (strlen(ar->spec_board_id) > 0 ? ", " : ""),
+		    ar->spec_board_id,
+		    (strlen(ar->spec_board_id) > 0 && !ar->spec_board_loaded
+		     ? " fallback" : ""),
 		    ar->hw->wiphy->fw_version,
 		    ar->fw_api,
 		    ar->htt.target_version_major,
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 1f770ac28df4..9dc0079a8ea6 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2627,6 +2627,12 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
 	ar_pci->dev = &pdev->dev;
 	ar_pci->ar = ar;
 
+	if (pdev->subsystem_vendor || pdev->subsystem_device)
+		scnprintf(ar->spec_board_id, sizeof(ar->spec_board_id),
+			  "%04x:%04x:%04x:%04x",
+			  pdev->vendor, pdev->device,
+			  pdev->subsystem_vendor, pdev->subsystem_device);
+
 	spin_lock_init(&ar_pci->ce_lock);
 	setup_timer(&ar_pci->rx_post_retry, ath10k_pci_rx_replenish_retry,
 		    (unsigned long)ar);
-- 
2.1.4



From Louis.Desfossez at UGent.be  Sat Apr 18 03:51:32 2015
From: Louis.Desfossez at UGent.be (Louis Desfossez)
Date: Sat, 18 Apr 2015 12:51:32 +0200
Subject: Set vht transmission parameters using radiotap header
Message-ID: <20150418125132.Horde.n2KkWFDIVCdVMjc0WZqgldA@webmail.ugent.be>

Using the click modular router project we are trying to inject packets  
on an Atheros QCA988x in monitor mode. Wireless parameters (nss, mcs,  
channel, guard interval, channel width and tx power) are set in the  
radiotap header.
Which parameters can currently be read by the ath10k/mac80211 driver  
and be set for transmission (ie. IEEE_RADIOTAP_DBM_TX_POWER,  
IEEE_RADIOTAP_CHANNEL)?
Is there a possibility to handle the vht information (ie.  
IEEE80211_RADIOTAP_VHT_MCS, IEEE80211_RADIOTAP_VHT_NSS)?



From kamran.nishat at gmail.com  Sat Apr 18 12:57:17 2015
From: kamran.nishat at gmail.com (Kamran Nishat)
Date: Sun, 19 Apr 2015 00:57:17 +0500
Subject: A-MPDUs in 20/40 mode
Message-ID: <CADxDmp4USuF-qFY50NFfKcYcwd-fHs9AT662aWi8UEsBcapixw@mail.gmail.com>

 Hi,
 according to wireshark (radiotap.mcs.bw field) some MPDUs in an
A-MPDU are recieved at 40Mhz while others are reiceved at 20Mhz. AP is
working in 20/40 mixed mode. I dont think bandwidth change within an
A-MPDU is possible. Is there a bug in wireshark or in my
inderstanding?

kamran


From adrian.chadd at gmail.com  Sat Apr 18 16:57:09 2015
From: adrian.chadd at gmail.com (Adrian Chadd)
Date: Sat, 18 Apr 2015 16:57:09 -0700
Subject: A-MPDUs in 20/40 mode
In-Reply-To: <CADxDmp4USuF-qFY50NFfKcYcwd-fHs9AT662aWi8UEsBcapixw@mail.gmail.com>
References: <CADxDmp4USuF-qFY50NFfKcYcwd-fHs9AT662aWi8UEsBcapixw@mail.gmail.com>
Message-ID: <CAJ-VmonxThhkHaHe_vRH0eNToPtt9ZfhsyJ2LkgkKhf-A3HZ0w@mail.gmail.com>

Hi,

So only the /final/ details in the last RX descriptor is valid. It's
possible that the rest of them are corrupted/previous packets.



-a


On 18 April 2015 at 12:57, Kamran Nishat <kamran.nishat at gmail.com> wrote:
>  Hi,
>  according to wireshark (radiotap.mcs.bw field) some MPDUs in an
> A-MPDU are recieved at 40Mhz while others are reiceved at 20Mhz. AP is
> working in 20/40 mixed mode. I dont think bandwidth change within an
> A-MPDU is possible. Is there a bug in wireshark or in my
> inderstanding?
>
> kamran


From michal.kazior at tieto.com  Sun Apr 19 22:43:30 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 20 Apr 2015 07:43:30 +0200
Subject: Set vht transmission parameters using radiotap header
In-Reply-To: <20150418125132.Horde.n2KkWFDIVCdVMjc0WZqgldA@webmail.ugent.be>
References: <20150418125132.Horde.n2KkWFDIVCdVMjc0WZqgldA@webmail.ugent.be>
Message-ID: <CA+BoTQ=0MM0=wiR9G3g03t3tTCNFMh+Yw4aq2vTnoCr_P4wyuQ@mail.gmail.com>

On 18 April 2015 at 12:51, Louis Desfossez <Louis.Desfossez at ugent.be> wrote:
> Using the click modular router project we are trying to inject packets on an
> Atheros QCA988x in monitor mode. Wireless parameters (nss, mcs, channel,
> guard interval, channel width and tx power) are set in the radiotap header.
> Which parameters can currently be read by the ath10k/mac80211 driver and be
> set for transmission (ie. IEEE_RADIOTAP_DBM_TX_POWER,
> IEEE_RADIOTAP_CHANNEL)?
> Is there a possibility to handle the vht information (ie.
> IEEE80211_RADIOTAP_VHT_MCS, IEEE80211_RADIOTAP_VHT_NSS)?

By the looks of ieee80211_parse_tx_radiotap() it seems that most
radiotap is ignored on Tx path.

Anyway I hope you're aware upstream ath10k doesn't support packet injection.

Also due to firmware design there's no way to specify Tx rate for each
frame. Using per-vdev fixed rate param would require really nasty
hacks in driver. I'm not even sure if it's possible with official
firmware to change mgmt and multicast tx rate (I think CT firmware
from Ben has that). I guess using `iw wlanX set bitrates` explicitly
would be better and cleaner - but first you need to get injection to
work at all.


Micha?


From michal.kazior at tieto.com  Mon Apr 20 02:20:41 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 20 Apr 2015 09:20:41 +0000
Subject: [PATCH] ath10k: fix qca61x4 hw2.1 support
Message-ID: <1429521641-21993-1-git-send-email-michal.kazior@tieto.com>

During initialization firmware does some sort of
memory switch between DRAM and IRAM. If
configuration value for bank switching isn't
correct device crashes during init.

The new value prevents firmware 11.0.0.302 (and
possibly others) for qca61x4 hw2.1 from crashing
during init.

Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
---
 drivers/net/wireless/ath/ath10k/pci.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 262a84f67f62..b1e522ccb525 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1539,12 +1539,11 @@ static int ath10k_pci_get_num_banks(struct ath10k *ar)
 		switch (MS(ar->chip_id, SOC_CHIP_ID_REV)) {
 		case QCA6174_HW_1_0_CHIP_ID_REV:
 		case QCA6174_HW_1_1_CHIP_ID_REV:
+		case QCA6174_HW_2_1_CHIP_ID_REV:
+		case QCA6174_HW_2_2_CHIP_ID_REV:
 			return 3;
 		case QCA6174_HW_1_3_CHIP_ID_REV:
 			return 2;
-		case QCA6174_HW_2_1_CHIP_ID_REV:
-		case QCA6174_HW_2_2_CHIP_ID_REV:
-			return 6;
 		case QCA6174_HW_3_0_CHIP_ID_REV:
 		case QCA6174_HW_3_1_CHIP_ID_REV:
 		case QCA6174_HW_3_2_CHIP_ID_REV:
-- 
2.1.4



From greearb at candelatech.com  Mon Apr 20 09:44:15 2015
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 20 Apr 2015 09:44:15 -0700
Subject: Set vht transmission parameters using radiotap header
In-Reply-To: <CA+BoTQ=0MM0=wiR9G3g03t3tTCNFMh+Yw4aq2vTnoCr_P4wyuQ@mail.gmail.com>
References: <20150418125132.Horde.n2KkWFDIVCdVMjc0WZqgldA@webmail.ugent.be>
 <CA+BoTQ=0MM0=wiR9G3g03t3tTCNFMh+Yw4aq2vTnoCr_P4wyuQ@mail.gmail.com>
Message-ID: <55352CDF.6090901@candelatech.com>

On 04/19/2015 10:43 PM, Michal Kazior wrote:
> On 18 April 2015 at 12:51, Louis Desfossez <Louis.Desfossez at ugent.be> wrote:
>> Using the click modular router project we are trying to inject packets on an
>> Atheros QCA988x in monitor mode. Wireless parameters (nss, mcs, channel,
>> guard interval, channel width and tx power) are set in the radiotap header.
>> Which parameters can currently be read by the ath10k/mac80211 driver and be
>> set for transmission (ie. IEEE_RADIOTAP_DBM_TX_POWER,
>> IEEE_RADIOTAP_CHANNEL)?
>> Is there a possibility to handle the vht information (ie.
>> IEEE80211_RADIOTAP_VHT_MCS, IEEE80211_RADIOTAP_VHT_NSS)?
> 
> By the looks of ieee80211_parse_tx_radiotap() it seems that most
> radiotap is ignored on Tx path.
> 
> Anyway I hope you're aware upstream ath10k doesn't support packet injection.
> 
> Also due to firmware design there's no way to specify Tx rate for each
> frame. Using per-vdev fixed rate param would require really nasty
> hacks in driver. I'm not even sure if it's possible with official
> firmware to change mgmt and multicast tx rate (I think CT firmware
> from Ben has that). I guess using `iw wlanX set bitrates` explicitly
> would be better and cleaner - but first you need to get injection to
> work at all.

My CT firmware does allow hard-coding the unicast, broadcast, and control-packet
rates..but it is not a per-pkt or even per-peer setting.  I could probably make
it per-peer easily enough if someone cared.

I think it would take a good deal of firmware changes to allow per-pkt
rate-control from the host, but it seems the firmware was at least originally
designed to support this option.

I personally would love to move all rate-ctrl out of firmware and onto
the host, but it is probably not something I would try myself, and currently
there is no good way to share firmware development effort.

An interim solution might be to hack my CT firmware to return more tx-status
info so that a host based rate-ctrl could do frequent updates to the
firmware's rate-ctrl settings to sort of fake host-based rate-ctrl.

I might attempt those firmware changes if someone else wanted to handle
the bulk of the driver work.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From kvalo at qca.qualcomm.com  Tue Apr 21 08:04:15 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 21 Apr 2015 18:04:15 +0300
Subject: [PATCH] ath10k: implement more versatile set_bitrate_mask
In-Reply-To: <CA+BoTQnNNKF7riAgcVj1LupABAGodm751jxOUuZgam8u=wthUA@mail.gmail.com>
 (Michal Kazior's message of "Fri, 17 Apr 2015 09:30:51 +0200")
References: <1428672772-9275-1-git-send-email-michal.kazior@tieto.com>
 <87618v44jv.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQnNNKF7riAgcVj1LupABAGodm751jxOUuZgam8u=wthUA@mail.gmail.com>
Message-ID: <87vbgpzfo0.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

>> To reduce support questions from the users it would be nice to give few
>> good examples how to use this with iw. And also it makes it easier to
>> test the patch. If you could send something I can add it to the commit
>> log.
>
> Should work:
>
>   iw wlan0 set bitrates legacy 1 6 12 ht-mcs 1 2 3
>   iw wlan0 set bitrates legacy-5 mcs-5 7 8 9
>   iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9
>
> Won't work:
>
>   iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-5
>   iw wlan0 set bitrates vht-mcs-5 2:7-9
>
> (note the invalid VHT MCS ranges)

Thanks, I added these to the commit log.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Tue Apr 21 10:37:10 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 21 Apr 2015 20:37:10 +0300
Subject: [PATCH v2 1/2] ath10k: share board file loading code across FW
 APIs
In-Reply-To: <1429262357-25139-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 17 Apr 2015 09:19:16 +0000")
References: <1429262357-25139-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87fv7tz8l5.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> There's no need to implement the same thing twice.
> Reduce code duplication.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, both patches applied.

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Tue Apr 21 10:38:30 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 21 Apr 2015 20:38:30 +0300
Subject: [PATCH] ath10k: fix qca61x4 hw2.1 support
In-Reply-To: <1429521641-21993-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Mon, 20 Apr 2015 09:20:41 +0000")
References: <1429521641-21993-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <87bnihz8ix.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> During initialization firmware does some sort of
> memory switch between DRAM and IRAM. If
> configuration value for bank switching isn't
> correct device crashes during init.
>
> The new value prevents firmware 11.0.0.302 (and
> possibly others) for qca61x4 hw2.1 from crashing
> during init.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From Nick.Shu at spirent.com  Tue Apr 21 14:28:42 2015
From: Nick.Shu at spirent.com (Shu, Nick)
Date: Tue, 21 Apr 2015 21:28:42 +0000
Subject: Question about ath10k throughput
Message-ID: <153F35912E69C446A72CF7D6417EBADE6E7B5667@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>

Hi, Group:
I'm doing throughout measurement on QCA9880 chip, running ath10k 3.17 driver with firmware.
I'm able to set channel width to 80MHz, enabled all three streams, MCS index to 9 for max. data throughput.
I verified all initial setting are correct.
But when test starts, MCS dropped (as the results of packet error?).
Is there any app command to send to driver to lock the MCS index during the test, so we can see better throughput?
What is the best practical number we can get for ath10k chip? 800? 900?

Thanks!
Nick Shu
Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.

Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.

Or if within the US,

Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300


From greearb at candelatech.com  Tue Apr 21 14:38:06 2015
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 21 Apr 2015 14:38:06 -0700
Subject: Question about ath10k throughput
In-Reply-To: <153F35912E69C446A72CF7D6417EBADE6E7B5667@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
References: <153F35912E69C446A72CF7D6417EBADE6E7B5667@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
Message-ID: <5536C33E.6000109@candelatech.com>

On 04/21/2015 02:28 PM, Shu, Nick wrote:
> Hi, Group:
> I'm doing throughout measurement on QCA9880 chip, running ath10k 3.17 driver with firmware.
> I'm able to set channel width to 80MHz, enabled all three streams, MCS index to 9 for max. data throughput.
> I verified all initial setting are correct.
> But when test starts, MCS dropped (as the results of packet error?).
> Is there any app command to send to driver to lock the MCS index during the test, so we can see better throughput?
> What is the best practical number we can get for ath10k chip? 800? 900?

Please let us know more about your test setup:

Traffic protocol type (TCP, UDP, etc)

Over-the-air tests, or using cables + attenuators?

Is this in normal environment, or in an RF isolation chamber?

We've seen as much as 950Mbps UDP download using a certain Netgear AP,
but it is not reproducible.  We normally do this type of test using
sma cables + attenuators, and get mostly similar results whether in
isolation chamber or not when cabled up as long as the RF spectrum is
relatively quiet.

More often we see TCP in the 400-600 Mbps range and UDP in 700-800 Mbps
range..and with TCP, it can also be tricky to get good throughput
in our experience.

Increasing number of virtual stations decreases total throughput on most APs.

I have tried forcing the rate-control to run at specific (high) rates,
but it has not increased throughput in tests so far, so I have not played
with it that much.

Thanks,
Ben


> 
> Thanks!
> Nick Shu
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.
> 
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
> 
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
> 
> Or if within the US,
> 
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From Nick.Shu at spirent.com  Tue Apr 21 14:59:24 2015
From: Nick.Shu at spirent.com (Shu, Nick)
Date: Tue, 21 Apr 2015 21:59:24 +0000
Subject: Question about ath10k throughput
In-Reply-To: <5536C33E.6000109@candelatech.com>
References: <153F35912E69C446A72CF7D6417EBADE6E7B5667@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
 <5536C33E.6000109@candelatech.com>
Message-ID: <153F35912E69C446A72CF7D6417EBADE6E7B5688@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>

Thanks, Ben:
We use our test application to generate traffic (TCP or UDP), sending from wifi NIC (ONLY 1 CLIENT, not multiple vStas). RF cables are used to connect from NIC antenna port (x3) to Cisco AP (model#3702E) antenna port (AP is placed inside an isolation chamber). Scan results for that AP shows the signal strength is -18 dBm  (strong enough).
AP is connected back to test server through Ethernet cable, then Network host is route back the data packet to test application.
So the data throughput is calculated as: number of bytes * 2 (round trip) * 8 = Mbps.

So far, we can only get like 400-500 Mbps for UDP.
Should we set AP to open? Without encryption?

Thanks!
Nick





-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Tuesday, April 21, 2015 4:38 PM
To: Shu, Nick
Cc: ath10k at lists.infradead.org
Subject: Re: Question about ath10k throughput

On 04/21/2015 02:28 PM, Shu, Nick wrote:
> Hi, Group:
> I'm doing throughout measurement on QCA9880 chip, running ath10k 3.17 driver with firmware.
> I'm able to set channel width to 80MHz, enabled all three streams, MCS index to 9 for max. data throughput.
> I verified all initial setting are correct.
> But when test starts, MCS dropped (as the results of packet error?).
> Is there any app command to send to driver to lock the MCS index during the test, so we can see better throughput?
> What is the best practical number we can get for ath10k chip? 800? 900?

Please let us know more about your test setup:

Traffic protocol type (TCP, UDP, etc)

Over-the-air tests, or using cables + attenuators?

Is this in normal environment, or in an RF isolation chamber?

We've seen as much as 950Mbps UDP download using a certain Netgear AP, but it is not reproducible.  We normally do this type of test using sma cables + attenuators, and get mostly similar results whether in isolation chamber or not when cabled up as long as the RF spectrum is relatively quiet.

More often we see TCP in the 400-600 Mbps range and UDP in 700-800 Mbps range..and with TCP, it can also be tricky to get good throughput in our experience.

Increasing number of virtual stations decreases total throughput on most APs.

I have tried forcing the rate-control to run at specific (high) rates, but it has not increased throughput in tests so far, so I have not played with it that much.

Thanks,
Ben


> 
> Thanks!
> Nick Shu
> Spirent Communications e-mail confidentiality.
> ----------------------------------------------------------------------
> -- This e-mail contains confidential and / or privileged information 
> belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.
> 
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
> 
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
> 
> Or if within the US,
> 
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


--
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Tue Apr 21 15:17:32 2015
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 21 Apr 2015 15:17:32 -0700
Subject: Question about ath10k throughput
In-Reply-To: <153F35912E69C446A72CF7D6417EBADE6E7B5688@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
References: <153F35912E69C446A72CF7D6417EBADE6E7B5667@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
 <5536C33E.6000109@candelatech.com>
 <153F35912E69C446A72CF7D6417EBADE6E7B5688@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
Message-ID: <5536CC7C.5000400@candelatech.com>

On 04/21/2015 02:59 PM, Shu, Nick wrote:
> Thanks, Ben:
> We use our test application to generate traffic (TCP or UDP), sending from wifi NIC (ONLY 1 CLIENT, not multiple vStas). RF cables are used to connect from NIC antenna port (x3) to Cisco AP (model#3702E) antenna port (AP is placed inside an isolation chamber). Scan results for that AP shows the signal strength is -18 dBm  (strong enough).
> AP is connected back to test server through Ethernet cable, then Network host is route back the data packet to test application.
> So the data throughput is calculated as: number of bytes * 2 (round trip) * 8 = Mbps.
> 
> So far, we can only get like 400-500 Mbps for UDP.
> Should we set AP to open? Without encryption?

I don't see why you do the 2x to get 'round-trip'...I think for issues related
to wifi throughput, just talk about the amount of data flowing across the
wifi network interface itself.

Receiving on a station (download), when using CT firmware and with sw-crypt enabled,
does decryption on the CPU, and this is normally a CPU bound issue at around
500Mbps even on expensive E5 processors.

Upload uses HW encryption, so should run faster with modest host CPU usage.

I would try Open auth testing when verifying wifi throughput..then compare that
against your encrypted throughput to see if you are CPU bound (or, at least
not RF bound).

If you are doing true TCP protocol, then it will back off on drops (and require
TCP ack frames and so forth).  You will get quite a bit more bulk throughput
with UDP.

I would also try multiple different APs to try to find the best one.

Big expensive names on the AP don't always mean so much for basic throughput
tests in our experience.

Having the AP inside an isolation chamber is helpful, but you really
need your station system inside a chamber as well for a truly isolated test, otherwise
the station system may be picking up interference that causes lost frames
and so forth (and AP might pick up similar interference through cables
connected to your test equipment).

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From Nick.Shu at spirent.com  Tue Apr 21 16:07:04 2015
From: Nick.Shu at spirent.com (Shu, Nick)
Date: Tue, 21 Apr 2015 23:07:04 +0000
Subject: Question about ath10k throughput
In-Reply-To: <5536CC7C.5000400@candelatech.com>
References: <153F35912E69C446A72CF7D6417EBADE6E7B5667@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
 <5536C33E.6000109@candelatech.com>
 <153F35912E69C446A72CF7D6417EBADE6E7B5688@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>,
 <5536CC7C.5000400@candelatech.com>
Message-ID: <153F35912E69C446A72CF7D6417EBADE6E7B66B4@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>

Hi, Ben:
The data packet do go through the wifi interface twice, so I times 2.
Its hard to put DUT into the chamber, cause its too big.
I'm using your patched driver and firmware, that disabled HW encryption, so you said this will add CPU load?
Our application can be set to run traffic in one direction, so I will test again to check the throughout in downlink, uplink, and bidirection for comparison.
Will also try different AP, NetGear 1900 and Asus one.

Thanks!
Nick
________________________________________
From: Ben Greear [greearb at candelatech.com]
Sent: Tuesday, April 21, 2015 4:17 PM
To: Shu, Nick
Cc: ath10k at lists.infradead.org
Subject: Re: Question about ath10k throughput

On 04/21/2015 02:59 PM, Shu, Nick wrote:
> Thanks, Ben:
> We use our test application to generate traffic (TCP or UDP), sending from wifi NIC (ONLY 1 CLIENT, not multiple vStas). RF cables are used to connect from NIC antenna port (x3) to Cisco AP (model#3702E) antenna port (AP is placed inside an isolation chamber). Scan results for that AP shows the signal strength is -18 dBm  (strong enough).
> AP is connected back to test server through Ethernet cable, then Network host is route back the data packet to test application.
> So the data throughput is calculated as: number of bytes * 2 (round trip) * 8 = Mbps.
>
> So far, we can only get like 400-500 Mbps for UDP.
> Should we set AP to open? Without encryption?

I don't see why you do the 2x to get 'round-trip'...I think for issues related
to wifi throughput, just talk about the amount of data flowing across the
wifi network interface itself.

Receiving on a station (download), when using CT firmware and with sw-crypt enabled,
does decryption on the CPU, and this is normally a CPU bound issue at around
500Mbps even on expensive E5 processors.

Upload uses HW encryption, so should run faster with modest host CPU usage.

I would try Open auth testing when verifying wifi throughput..then compare that
against your encrypted throughput to see if you are CPU bound (or, at least
not RF bound).

If you are doing true TCP protocol, then it will back off on drops (and require
TCP ack frames and so forth).  You will get quite a bit more bulk throughput
with UDP.

I would also try multiple different APs to try to find the best one.

Big expensive names on the AP don't always mean so much for basic throughput
tests in our experience.

Having the AP inside an isolation chamber is helpful, but you really
need your station system inside a chamber as well for a truly isolated test, otherwise
the station system may be picking up interference that causes lost frames
and so forth (and AP might pick up similar interference through cables
connected to your test equipment).

Thanks,
Ben


--
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.

Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.

Or if within the US,

Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300


From greearb at candelatech.com  Tue Apr 21 16:15:53 2015
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 21 Apr 2015 16:15:53 -0700
Subject: Question about ath10k throughput
In-Reply-To: <153F35912E69C446A72CF7D6417EBADE6E7B66B4@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
References: <153F35912E69C446A72CF7D6417EBADE6E7B5667@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
 <5536C33E.6000109@candelatech.com>
 <153F35912E69C446A72CF7D6417EBADE6E7B5688@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>,
 <5536CC7C.5000400@candelatech.com>
 <153F35912E69C446A72CF7D6417EBADE6E7B66B4@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
Message-ID: <5536DA29.8080601@candelatech.com>

On 04/21/2015 04:07 PM, Shu, Nick wrote:
> Hi, Ben:
> The data packet do go through the wifi interface twice, so I times 2.
> Its hard to put DUT into the chamber, cause its too big.
> I'm using your patched driver and firmware, that disabled HW encryption, so you said this will add CPU load?
> Our application can be set to run traffic in one direction, so I will test again to check the throughout in downlink, uplink, and bidirection for comparison.
> Will also try different AP, NetGear 1900 and Asus one.

In general, bi-directional traffic on wifi is a lot slower than uni-directional,
even if you add up both directions in bi-directional traffic.

I think this is mostly because the AP and station radios contend for airtime, and
you end up taking less advantage of block-acks and A-MPDUS.  Maybe more retransmits
and backoffs too..  Maybe others will have a better idea.

Disabling HW encryption makes the CPU do the decryption, so yeah, that is CPU intensive.

'perf top' or similar should show your cpu usage hotspots.

Thanks,
Ben



> 
> Thanks!
> Nick
> ________________________________________
> From: Ben Greear [greearb at candelatech.com]
> Sent: Tuesday, April 21, 2015 4:17 PM
> To: Shu, Nick
> Cc: ath10k at lists.infradead.org
> Subject: Re: Question about ath10k throughput
> 
> On 04/21/2015 02:59 PM, Shu, Nick wrote:
>> Thanks, Ben:
>> We use our test application to generate traffic (TCP or UDP), sending from wifi NIC (ONLY 1 CLIENT, not multiple vStas). RF cables are used to connect from NIC antenna port (x3) to Cisco AP (model#3702E) antenna port (AP is placed inside an isolation chamber). Scan results for that AP shows the signal strength is -18 dBm  (strong enough).
>> AP is connected back to test server through Ethernet cable, then Network host is route back the data packet to test application.
>> So the data throughput is calculated as: number of bytes * 2 (round trip) * 8 = Mbps.
>>
>> So far, we can only get like 400-500 Mbps for UDP.
>> Should we set AP to open? Without encryption?
> 
> I don't see why you do the 2x to get 'round-trip'...I think for issues related
> to wifi throughput, just talk about the amount of data flowing across the
> wifi network interface itself.
> 
> Receiving on a station (download), when using CT firmware and with sw-crypt enabled,
> does decryption on the CPU, and this is normally a CPU bound issue at around
> 500Mbps even on expensive E5 processors.
> 
> Upload uses HW encryption, so should run faster with modest host CPU usage.
> 
> I would try Open auth testing when verifying wifi throughput..then compare that
> against your encrypted throughput to see if you are CPU bound (or, at least
> not RF bound).
> 
> If you are doing true TCP protocol, then it will back off on drops (and require
> TCP ack frames and so forth).  You will get quite a bit more bulk throughput
> with UDP.
> 
> I would also try multiple different APs to try to find the best one.
> 
> Big expensive names on the AP don't always mean so much for basic throughput
> tests in our experience.
> 
> Having the AP inside an isolation chamber is helpful, but you really
> need your station system inside a chamber as well for a truly isolated test, otherwise
> the station system may be picking up interference that causes lost frames
> and so forth (and AP might pick up similar interference through cables
> connected to your test equipment).
> 
> Thanks,
> Ben
> 
> 
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.
> 
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
> 
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
> 
> Or if within the US,
> 
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From michal.kazior at tieto.com  Tue Apr 21 22:03:59 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 22 Apr 2015 07:03:59 +0200
Subject: Question about ath10k throughput
In-Reply-To: <153F35912E69C446A72CF7D6417EBADE6E7B5667@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
References: <153F35912E69C446A72CF7D6417EBADE6E7B5667@SPCCOREXCMBX01.AD.SPIRENTCOM.COM>
Message-ID: <CA+BoTQnKFLsE36-EuHpix_hmK5fq52pCOknmjq-s2W3mDie7WA@mail.gmail.com>

On 21 April 2015 at 23:28, Shu, Nick <Nick.Shu at spirent.com> wrote:
> Hi, Group:
> I'm doing throughout measurement on QCA9880 chip, running ath10k 3.17 driver with firmware.
> I'm able to set channel width to 80MHz, enabled all three streams, MCS index to 9 for max. data throughput.
> I verified all initial setting are correct.
> But when test starts, MCS dropped (as the results of packet error?).

> Is there any app command to send to driver to lock the MCS index during the test, so we can see better throughput?

You can try:

  iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 3:9

To reset:

  iw wlan0 set bitrates


> What is the best practical number we can get for ath10k chip? 800? 900?

On a cabled RF with attenuators I remember seeing ~900mbps of UDP
between two QCA988Xs and ~650mbps of UDP between QCA988X and QCA6174,


Micha?


From kvalo at qca.qualcomm.com  Tue Apr 21 23:27:17 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 22 Apr 2015 09:27:17 +0300
Subject: [PATCH] ath10k: implement more versatile set_bitrate_mask
In-Reply-To: <87vbgpzfo0.fsf@kamboji.qca.qualcomm.com> (Kalle Valo's message
 of "Tue, 21 Apr 2015 18:04:15 +0300")
References: <1428672772-9275-1-git-send-email-michal.kazior@tieto.com>
 <87618v44jv.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQnNNKF7riAgcVj1LupABAGodm751jxOUuZgam8u=wthUA@mail.gmail.com>
 <87vbgpzfo0.fsf@kamboji.qca.qualcomm.com>
Message-ID: <87383szni2.fsf@kamboji.qca.qualcomm.com>

Kalle Valo <kvalo at qca.qualcomm.com> writes:

> Michal Kazior <michal.kazior at tieto.com> writes:
>
>>> To reduce support questions from the users it would be nice to give few
>>> good examples how to use this with iw. And also it makes it easier to
>>> test the patch. If you could send something I can add it to the commit
>>> log.
>>
>> Should work:
>>
>>   iw wlan0 set bitrates legacy 1 6 12 ht-mcs 1 2 3
>>   iw wlan0 set bitrates legacy-5 mcs-5 7 8 9
>>   iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9
>>
>> Won't work:
>>
>>   iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-5
>>   iw wlan0 set bitrates vht-mcs-5 2:7-9
>>
>> (note the invalid VHT MCS ranges)
>
> Thanks, I added these to the commit log.

Actually, I had some problems:

# iw wlan0 set bitrates legacy-2.4 1 6 12 ht-mcs-2.4 1 2 3
command failed: Invalid argument (-22)
# iw wlan0 set bitrates legacy-5 1 6 12 ht-mcs-5 1 2 3
command failed: Invalid argument (-22)
# iw wlan0 set bitrates legacy-5 vht-mcs-5 7 8 9
command failed: Invalid argument (-22)
# iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9
# 

The first one I understand as this CUS223 board only supports 5G. But
why did the second and third command fail?

-- 
Kalle Valo


From michal.kazior at tieto.com  Wed Apr 22 00:33:06 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Wed, 22 Apr 2015 09:33:06 +0200
Subject: [PATCH] ath10k: implement more versatile set_bitrate_mask
In-Reply-To: <87383szni2.fsf@kamboji.qca.qualcomm.com>
References: <1428672772-9275-1-git-send-email-michal.kazior@tieto.com>
 <87618v44jv.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQnNNKF7riAgcVj1LupABAGodm751jxOUuZgam8u=wthUA@mail.gmail.com>
 <87vbgpzfo0.fsf@kamboji.qca.qualcomm.com>
 <87383szni2.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CA+BoTQkao3kNSCfqi5KdroHL+iHH2fYjZP=oDShjD2VEOM1KnQ@mail.gmail.com>

On 22 April 2015 at 08:27, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Kalle Valo <kvalo at qca.qualcomm.com> writes:
>
>> Michal Kazior <michal.kazior at tieto.com> writes:
>>
>>>> To reduce support questions from the users it would be nice to give few
>>>> good examples how to use this with iw. And also it makes it easier to
>>>> test the patch. If you could send something I can add it to the commit
>>>> log.
>>>
>>> Should work:
>>>
>>>   iw wlan0 set bitrates legacy 1 6 12 ht-mcs 1 2 3
>>>   iw wlan0 set bitrates legacy-5 mcs-5 7 8 9

Oh, I just noticed I typo'ed: s/mcs-5/ht-mcs-5/.


>>>   iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9
>>>
>>> Won't work:
>>>
>>>   iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-5
>>>   iw wlan0 set bitrates vht-mcs-5 2:7-9
>>>
>>> (note the invalid VHT MCS ranges)
>>
>> Thanks, I added these to the commit log.
>
> Actually, I had some problems:
>
> # iw wlan0 set bitrates legacy-2.4 1 6 12 ht-mcs-2.4 1 2 3
> command failed: Invalid argument (-22)
> # iw wlan0 set bitrates legacy-5 1 6 12 ht-mcs-5 1 2 3
> command failed: Invalid argument (-22)

There's no 1mbps (CCK) on 5GHz. If you remove the "1" from legacy-5 it
should work.


> # iw wlan0 set bitrates legacy-5 vht-mcs-5 7 8 9
> command failed: Invalid argument (-22)

There's a couple of problems here:

 * The syntax for VHT MCS is different: vht-mcs-<2.4|5>
<NSS:MCSx,MCSy... | NSS:MCSx-MCSy>*
   You used syntax from HT MCS: ht-mcs-<2.4|5> <MCS index>*
   The correct way to express this would be:
      iw wlan0 set bitrates legacy-5 vht-mcs-5 1:7,8,9
   or
      iw wlan0 set bitrates legacy-5 vht-mcs-5 1:7-9
   assuming you wanted NSS=1 (VHT MCS don't imply NSS just like HT MCS do)

* As per commit log you can't use just any VHT MCS; you're limited to
none, 0-7, 0-8, 0-9. You can set a *single* VHT MCS as per
51ab1a0a09a8 ("ath10k: add set_bitrate_mask callback") though.


Micha?


From acarbonara13 at gmail.com  Wed Apr 22 13:15:12 2015
From: acarbonara13 at gmail.com (Amato Carbonara)
Date: Wed, 22 Apr 2015 16:15:12 -0400
Subject: Upgrade firmware of QCA-9880
Message-ID: <CAOt_L38ntK_iE9UNbU_GYLHmhWJYaBbKkc6Ow_hC=o7VSD_7mg@mail.gmail.com>

I am currently running:
driver=ath10k_pci driverversion=3.13.0-49-generic firmware=10.1.467.2-1

I would like to update the firmware to 10.2.4 (latest release).  I am
unable to update the software by copying the file
"firmware-4.bin_10.2.4.48" from
https://github.com/kvalo/ath10k-firmware/tree/master/10.2.4

I copy the file from github into /lib/firmware/ath10k/QCA988X/hw2.0/

I have kept the original file name, changed it to "firmware-4.bin" and
also changed it to "firmware-2.bin" but the firmware does not upgrade
to 10.2.4

Can you please assist in telling me how I go from 10.1.467.2-1 to 10.2.4?

Thank you,
Amato


From michal.kazior at tieto.com  Wed Apr 22 22:23:00 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 23 Apr 2015 07:23:00 +0200
Subject: Upgrade firmware of QCA-9880
In-Reply-To: <CAOt_L38ntK_iE9UNbU_GYLHmhWJYaBbKkc6Ow_hC=o7VSD_7mg@mail.gmail.com>
References: <CAOt_L38ntK_iE9UNbU_GYLHmhWJYaBbKkc6Ow_hC=o7VSD_7mg@mail.gmail.com>
Message-ID: <CA+BoTQ=+pxnd_S1p-AE1ovMGubbwtAEAH1LVmjFND1EuzG7hAw@mail.gmail.com>

On 22 April 2015 at 22:15, Amato Carbonara <acarbonara13 at gmail.com> wrote:
> I am currently running:
> driver=ath10k_pci driverversion=3.13.0-49-generic firmware=10.1.467.2-1
>
> I would like to update the firmware to 10.2.4 (latest release).  I am
> unable to update the software by copying the file
> "firmware-4.bin_10.2.4.48" from
> https://github.com/kvalo/ath10k-firmware/tree/master/10.2.4
>
> I copy the file from github into /lib/firmware/ath10k/QCA988X/hw2.0/
>
> I have kept the original file name, changed it to "firmware-4.bin" and
> also changed it to "firmware-2.bin" but the firmware does not upgrade
> to 10.2.4

10.2.4 uses a different firmware filename for a reason.

10.2.4 has some ABI differences compared to 10.1 and the driver must
be aware of them in order to be able to use it. You seem to have
kernel 3.13 (or at least ath10k from that kernel release for that
matter). This is pretty ancient. If you want to run 10.2.4 you need to
switch to kernel version 4.0 at least.

In case you're interested the older 10.2
(https://github.com/kvalo/ath10k-firmware/tree/master/10.2) requires
kernel 3.18 at least.


Micha?


From cedgar at student.ethz.ch  Thu Apr 23 05:47:36 2015
From: cedgar at student.ethz.ch (Costa Molero  Edgar)
Date: Thu, 23 Apr 2015 12:47:36 +0000
Subject: =?windows-1256?Q?Getting_the_Packet_error_rate_from_debug_files.=FE?=
Message-ID: <BB63CF2605733841BD56CD9C38AC1F7E1E676869@MBX23.d.ethz.ch>

Hi all,

I am trying to somehow compute the packet error rate (PER) using all the available information in the /sys/kernel/debug/ieee80211/phyX/ directory.

After using iperf I try to put together information from the following sources:

* iw wlanX station dump
* fw_stats file
* /sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/macaddr/

Does anyone know where I can find that parameter ?

Thanks,
Edgar

From acarbonara13 at gmail.com  Thu Apr 23 07:51:19 2015
From: acarbonara13 at gmail.com (Amato Carbonara)
Date: Thu, 23 Apr 2015 10:51:19 -0400
Subject: Upgrade firmware of QCA-9880
In-Reply-To: <CA+BoTQ=+pxnd_S1p-AE1ovMGubbwtAEAH1LVmjFND1EuzG7hAw@mail.gmail.com>
References: <CAOt_L38ntK_iE9UNbU_GYLHmhWJYaBbKkc6Ow_hC=o7VSD_7mg@mail.gmail.com>
 <CA+BoTQ=+pxnd_S1p-AE1ovMGubbwtAEAH1LVmjFND1EuzG7hAw@mail.gmail.com>
Message-ID: <CAOt_L391ZBncREtznWWoPNrfKS1YMGjF-x6Jm=Afb0T-c2mozQ@mail.gmail.com>

Thank you!  I upgraded to kernel 4.0 and successfully installed
firmware 10.2.4.48

On Thu, Apr 23, 2015 at 1:23 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 22 April 2015 at 22:15, Amato Carbonara <acarbonara13 at gmail.com> wrote:
>> I am currently running:
>> driver=ath10k_pci driverversion=3.13.0-49-generic firmware=10.1.467.2-1
>>
>> I would like to update the firmware to 10.2.4 (latest release).  I am
>> unable to update the software by copying the file
>> "firmware-4.bin_10.2.4.48" from
>> https://github.com/kvalo/ath10k-firmware/tree/master/10.2.4
>>
>> I copy the file from github into /lib/firmware/ath10k/QCA988X/hw2.0/
>>
>> I have kept the original file name, changed it to "firmware-4.bin" and
>> also changed it to "firmware-2.bin" but the firmware does not upgrade
>> to 10.2.4
>
> 10.2.4 uses a different firmware filename for a reason.
>
> 10.2.4 has some ABI differences compared to 10.1 and the driver must
> be aware of them in order to be able to use it. You seem to have
> kernel 3.13 (or at least ath10k from that kernel release for that
> matter). This is pretty ancient. If you want to run 10.2.4 you need to
> switch to kernel version 4.0 at least.
>
> In case you're interested the older 10.2
> (https://github.com/kvalo/ath10k-firmware/tree/master/10.2) requires
> kernel 3.18 at least.
>
>
> Micha?


From acarbonara13 at gmail.com  Thu Apr 23 08:12:11 2015
From: acarbonara13 at gmail.com (Amato Carbonara)
Date: Thu, 23 Apr 2015 11:12:11 -0400
Subject: Using ath10k for WiFi capturing non-11ac traffic
In-Reply-To: <CAOt_L39edL7vNzcTcnXEVfgwa7TOAj5LWAvqjgpG--_GnEOCEw@mail.gmail.com>
References: <CAOt_L393JBszKfVNTaXnM3xdRA=D-WOeaSk9KsnxkxsS49syCw@mail.gmail.com>
 <CA+BoTQmh2zQRpzq2=d9KKQy_Zn7TAFa3qL-LeaRZJ8e6Xheo6g@mail.gmail.com>
 <CAOt_L3-cv7npPmWdheLjhXBiiOQRjC=GYoEZw2OSwgf-kEsUWg@mail.gmail.com>
 <552DAE9D.7090405@candelatech.com>
 <CAOt_L3_FG53W5xK1csb=+VXDy2wdW-V3nbg8mtFaHarEOdkLCg@mail.gmail.com>
 <552E7C91.5030607@candelatech.com>
 <CAOt_L3_nN-U41wm+=Skb7RixZr=8x-Y_VEO1vEQohFDJMa66fg@mail.gmail.com>
 <552E86BA.9000206@candelatech.com>
 <CAOt_L3-N8eaZpKzTHny9KSZxxAgvHFk0t2MpcgMkmE5DdEGrpA@mail.gmail.com>
 <552EBD48.5000605@candelatech.com>
 <CAOt_L39edL7vNzcTcnXEVfgwa7TOAj5LWAvqjgpG--_GnEOCEw@mail.gmail.com>
Message-ID: <CAOt_L38w-VS911KsgNeVpo6FVwAvFcCmxTT=TMYX-vkY57CLZQ@mail.gmail.com>

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

On Thu, Apr 16, 2015 at 9:16 AM, Amato Carbonara <acarbonara13 at 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 at candelatech.com> wrote:
>> Here's another funny thing I just noticed.
>>
>> When trying to capture high-speed IBSS traffic, I get almost no data packets
>> at all delivered...maybe because the are A-MPDU or something like that and are
>> too big?
>>
>> Anyway, curious if you have tried high-speed captures in networks with block-ack
>> and a-mpdu enabled....
>>
>> Thanks,
>> Ben
>>
>>
>> On 04/15/2015 08:46 AM, Amato Carbonara wrote:
>>> Thanks Ben. I plan to upgrade to latest ath10k firmware and retest. I need to find some time to experiment.
>>>
>>> On Apr 15, 2015 11:41 AM, "Ben Greear" <greearb at candelatech.com <mailto:greearb at candelatech.com>> wrote:
>>>
>>>     On 04/15/2015 08:07 AM, Amato Carbonara wrote:
>>>     > Hi Ben,
>>>     >   I performed my captures when the WiFi adapter running the ath10k was
>>>     > not connected to the WiFi network.  In other words, the capture shows
>>>     > traffic between 2 different devices.  The ath10k device is in
>>>     > promiscuous mode and capturing all the traffic between the devices.
>>>
>>>     Yes, I did the same, and still no BlockAck action frames are captured.
>>>
>>>     Firmware has special handling for these frames, so probably it eats
>>>     them before passing on to the host.
>>>
>>>     Thanks,
>>>     Ben
>>>
>>>     >
>>>     > On Wed, Apr 15, 2015 at 10:58 AM, Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>> wrote:
>>>     >>
>>>     >>
>>>     >> On 04/15/2015 07:28 AM, Amato Carbonara wrote:
>>>     >>>
>>>     >>> Hi Ben,
>>>     >>>    I have done numerous captures using the ath10k driver on different
>>>     >>> 802.11 variant networks, specifically 802.11n (20MHz and 40MHz) and
>>>     >>> 802.11ac.  In all these captures, I have captured the Block-Ack frames
>>>     >>> (Wireshark filter wlan.fc.type_subtype == 0x0019), but do not see any
>>>     >>> Block-ACK Request or Response frames.  In fact, none of my captures
>>>     >>> using the ath10k drivers show any Action frames (Wireshark filter
>>>     >>> wlan.fc.type_subtype == 0x000d).  This is very peculiar since the IEEE
>>>     >>> specification 802.11-2012 section 9.21.2 states: "If the intended
>>>     >>> recipient STA is capable of participating, the originator sends an
>>>     >>> ADDBA Request frame".  Therefor, the ADDBA must be sent in order for
>>>     >>> Block-Acks to occur.  I have also noticed missing Association Response
>>>     >>> frames from the STA.
>>>     >>>
>>>     >>> Currently, I am using firmware 10.1.467.2-1 to perform my captures.
>>>     >>
>>>     >>
>>>     >> I think the ath10k firmware must just consume the block-ack request/response
>>>     >> frames internally and
>>>     >> never send them up to the host.  It does send an htt message about blockack
>>>     >> control messages being
>>>     >> received.
>>>     >>
>>>     >> Probably something I could fix in my 10.1 firmware...but first I need to
>>>     >> figure out why ath9k (mac80211 stack, actually) ignores the block-ack
>>>     >> messages that my ibss ath10k
>>>     >> interface sends....
>>>     >>
>>>     >> Thanks,
>>>     >> Ben
>>>     >>
>>>     >>
>>>     >>>
>>>     >>> Has anyone else tried using a different firmware version, for example
>>>     >>> 10.2.4, to perform WiFi captures?
>>>     >>>
>>>     >>> On Tue, Apr 14, 2015 at 8:19 PM, Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>>>     >>> wrote:
>>>     >>>>
>>>     >>>> Out of curiosity, have you been able to capture Action frames
>>>     >>>> (specifically,
>>>     >>>> block-ack add/del frames) with ath10k?  I just wasted a large amount of
>>>     >>>> time wondering
>>>     >>>> why the frames are not seen...but ath9k monitor port sees them just fine.
>>>     >>>>
>>>     >>>> Thanks,
>>>     >>>> Ben
>>>     >>>>
>>>     >>>>
>>>     >>>> On 04/14/2015 11:04 AM, Amato Carbonara wrote:
>>>     >>>>>
>>>     >>>>> Hello Michal,
>>>     >>>>>    I was able to decrypt all traffic types (11a, 11n at 20MHz, 11n at
>>>     >>>>> 40MHz and 11ac at 80MHz) using the 10.1.467.2-1 firmware on the
>>>     >>>>> QCA9880 chipset.  The problem was not with Wireshark.  I had to
>>>     >>>>> install backports for the at10k drivers to make it work.  Procedures
>>>     >>>>> are documented here:
>>>     >>>>> https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/backports
>>>     >>>>>
>>>     >>>>> Thank you for your help,
>>>     >>>>> Amato
>>>     >>>>>
>>>     >>>>> On Tue, Apr 14, 2015 at 1:38 AM, Michal Kazior <michal.kazior at tieto.com <mailto:michal.kazior at tieto.com>>
>>>     >>>>> wrote:
>>>     >>>>>>
>>>     >>>>>> On 6 April 2015 at 21:49, Amato Carbonara <acarbonara13 at gmail.com <mailto:acarbonara13 at gmail.com>>
>>>     >>>>>> wrote:
>>>     >>>>>>>
>>>     >>>>>>> Hello,
>>>     >>>>>>>    I have installed a WiFi adapter with the Qualcomm-Atheros QCA-9880
>>>     >>>>>>> chipset using the at10k drivers.  I am using this WiFi adapter to
>>>     >>>>>>> capture WLAN traffic.  The recommended firmware for capturing WiFi
>>>     >>>>>>> traffic is 10.1.467.2-1 per the website.  See following link:
>>>     >>>>>>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor
>>>     >>>>>>
>>>     >>>>>>
>>>     >>>>>> Generally the 10.x line is preferred for sniffing. You could also try
>>>     >>>>>> 10.2.4.
>>>     >>>>>>
>>>     >>>>>>
>>>     >>>>>>> I have successfully installed the above firmware and have been using
>>>     >>>>>>> the adapter/driver to capture and decrypt all 802.11ac traffic.
>>>     >>>>>>> However, I have noticed some strange behavior when trying to decrypt
>>>     >>>>>>> other types of traffic such as:
>>>     >>>>>>>    1) 802.11a = not able to decrypt any traffic
>>>     >>>>>>>    2) 802.11n at 20MHz = able to decrypt only partial traffic
>>>     >>>>>>>    3) 802.11n at 40MHz = able to decrypt only partial traffic
>>>     >>>>>>>
>>>     >>>>>>> I have tried using the different "iw" and "iwconfig" commands to set
>>>     >>>>>>> the frequency and channel bandwidth (for example, iw dev wlan1 set
>>>     >>>>>>> freq 5180 HT20).  Has anyone else seen this issue of not being able to
>>>     >>>>>>> decrypt all/some of the WiFi traffic?
>>>     >>>>>>
>>>     >>>>>>
>>>     >>>>>> `iwconfig` is an old program. You shouldn't use it. Just stick with
>>>     >>>>>> `iw`.
>>>     >>>>>>
>>>     >>>>>> To decrypt traffic you need to see keying handshake (both after
>>>     >>>>>> association and later for each rekeying). If sniffer misses that you
>>>     >>>>>> won't be able to decipher data either from the start or you'll stop
>>>     >>>>>> being able to decrypt multicast data after GTK rekeying.
>>>     >>>>>>
>>>     >>>>>> Another thing is I've had numerous random problems with wireshark
>>>     >>>>>> refusing to decrypt frames reliably. I recall some older version would
>>>     >>>>>> get stuck and need the key configuration (in preferences window) to be
>>>     >>>>>> re-applied or the decrypt checkbox to be re-checked. YMMV.
>>>     >>>>>>
>>>     >>>>>>
>>>     >>>>>> Micha?
>>>     >>>>>
>>>     >>>>>
>>>     >>>>> _______________________________________________
>>>     >>>>> ath10k mailing list
>>>     >>>>> ath10k at lists.infradead.org <mailto:ath10k at lists.infradead.org>
>>>     >>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>     >>>>>
>>>     >>>>
>>>     >>>>
>>>     >>>> --
>>>     >>>> Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>>>     >>>> Candela Technologies Inc  http://www.candelatech.com
>>>     >>>>
>>>     >>>
>>>     >>> _______________________________________________
>>>     >>> ath10k mailing list
>>>     >>> ath10k at lists.infradead.org <mailto:ath10k at lists.infradead.org>
>>>     >>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>     >>>
>>>     >>
>>>     >> --
>>>     >> Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>>>     >> Candela Technologies Inc  http://www.candelatech.com
>>>     >
>>>
>>>
>>>     --
>>>     Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>>>     Candela Technologies Inc  http://www.candelatech.com
>>>
>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>


From cedgar at student.ethz.ch  Thu Apr 23 08:16:31 2015
From: cedgar at student.ethz.ch (Costa Molero  Edgar)
Date: Thu, 23 Apr 2015 15:16:31 +0000
Subject: Modifing and installing ath10k driver for kernel 4.0
Message-ID: <BB63CF2605733841BD56CD9C38AC1F7E1E678CA8@MBX23.d.ethz.ch>

Hi all,

In order to use the latest firmware version (10.2.4.48) for my access point  I installed the kernel version 4.0 in my Ubuntu 14.04 LTS laptop.

The problem is that with the ath10k driver it comes the option debug is not enabled, and my domain regulatory database do not allow me to use 80Mhz channels.

Before upgrading the kernel, I was using the latest backports release 3.19-r1-1-1. To install that driver I downloaded it then I enabled all the configuration options I needed for my project (debug, debugfs, etc) and I also modified the regulatory database by changing the content of the file /net/wireless/db.txt.

I never compiled a linux kernel. And therefore I don't quite understand what should I do know to modify the current driver version. (I just want to change the db.txt file and enable debug) Then I want to compile the driver and install it. Could some one give me some hints ?

Should not the driver source code be located at that  directory ? /usr/src/linux-headers-4.0.0-040000-generic/drivers/net/wireless/ath/ath10k# , and also the db.txt located here :/usr/src/linux-headers-4.0.0-040000-generic/net/wireless# .

Sorry for the long question and hope someone can guide me a little bit.

Edgar

From acarbonara13 at gmail.com  Thu Apr 23 12:11:49 2015
From: acarbonara13 at gmail.com (Amato Carbonara)
Date: Thu, 23 Apr 2015 15:11:49 -0400
Subject: Upgrade firmware of QCA-9880
In-Reply-To: <CAH1sOKXs3Hv6kYGSU+EKkgyusuTFF2BtWx52Shjp=G_G9ZPbUQ@mail.gmail.com>
References: <CAOt_L38ntK_iE9UNbU_GYLHmhWJYaBbKkc6Ow_hC=o7VSD_7mg@mail.gmail.com>
 <CA+BoTQ=+pxnd_S1p-AE1ovMGubbwtAEAH1LVmjFND1EuzG7hAw@mail.gmail.com>
 <CAOt_L391ZBncREtznWWoPNrfKS1YMGjF-x6Jm=Afb0T-c2mozQ@mail.gmail.com>
 <CAH1sOKXs3Hv6kYGSU+EKkgyusuTFF2BtWx52Shjp=G_G9ZPbUQ@mail.gmail.com>
Message-ID: <CAOt_L3-iuET+O0HqhPzy9rnzGJT-e2Q_v1g+dB9G+H6R1MHuoA@mail.gmail.com>

The bin files exist at:
https://github.com/kvalo/ath10k-firmware/tree/master

Directions to install the drivers exist at:
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware

I hope that helps.

On Thu, Apr 23, 2015 at 1:33 PM, bharath yadav
<uddandibharath7 at gmail.com> wrote:
> Hi.,
>
>    How to build ath10k driver from kernel version 4.0 ,I got confused with
> that it is some what different from other stable releases if run make it is
> creating some image.there is no defconfig option available in that
>
> Please tell me how to build ath10k from kernel 4.0 i am new to linux
>
> Thanks
>
> On Thu, Apr 23, 2015 at 8:21 PM, Amato Carbonara <acarbonara13 at gmail.com>
> wrote:
>>
>> Thank you!  I upgraded to kernel 4.0 and successfully installed
>> firmware 10.2.4.48
>>
>> On Thu, Apr 23, 2015 at 1:23 AM, Michal Kazior <michal.kazior at tieto.com>
>> wrote:
>> > On 22 April 2015 at 22:15, Amato Carbonara <acarbonara13 at gmail.com>
>> > wrote:
>> >> I am currently running:
>> >> driver=ath10k_pci driverversion=3.13.0-49-generic firmware=10.1.467.2-1
>> >>
>> >> I would like to update the firmware to 10.2.4 (latest release).  I am
>> >> unable to update the software by copying the file
>> >> "firmware-4.bin_10.2.4.48" from
>> >> https://github.com/kvalo/ath10k-firmware/tree/master/10.2.4
>> >>
>> >> I copy the file from github into /lib/firmware/ath10k/QCA988X/hw2.0/
>> >>
>> >> I have kept the original file name, changed it to "firmware-4.bin" and
>> >> also changed it to "firmware-2.bin" but the firmware does not upgrade
>> >> to 10.2.4
>> >
>> > 10.2.4 uses a different firmware filename for a reason.
>> >
>> > 10.2.4 has some ABI differences compared to 10.1 and the driver must
>> > be aware of them in order to be able to use it. You seem to have
>> > kernel 3.13 (or at least ath10k from that kernel release for that
>> > matter). This is pretty ancient. If you want to run 10.2.4 you need to
>> > switch to kernel version 4.0 at least.
>> >
>> > In case you're interested the older 10.2
>> > (https://github.com/kvalo/ath10k-firmware/tree/master/10.2) requires
>> > kernel 3.18 at least.
>> >
>> >
>> > Micha?
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
>


From me at bobcopeland.com  Fri Apr 24 05:50:55 2015
From: me at bobcopeland.com (Bob Copeland)
Date: Fri, 24 Apr 2015 08:50:55 -0400
Subject: attempting mesh on ath10k
Message-ID: <20150424125055.GA27722@localhost>

Hi all,

I have played around a little bit with the raw mode patches trying to
get mesh working on ath10k.  I've hacked the driver slightly to use an
AP vif in the firmware in "mesh" mode, which seems to produce proper looking
beacons over the air.

However, when I bring up a second mesh node, the ath10k device crashes
upon trying to send the first mesh peering action frame.  Here's what
dmesg looks like:

[   43.860000] ath10k_pci 0000:01:00.0: wmi event debug mesg len 140
[   44.310000] XXX trying to create peer 00:03:7f:10:4e:2d
[   44.310000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 peer_addr 00:03:7f:10:4e:2d
[   44.320000] XXX sending WMI cmd 36892
[   44.320000] XXX sending WMI cmd nowait 36892
[   44.330000] XXX waiting for peer create 00:03:7f:10:4e:2d
[   44.330000] XXX peer 00:03:7f:10:4e:2d added
[   44.340000] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 00:03:7f:10:4e:2d (new)
[   44.350000] XXX sending WMI cmd 36896
[   44.350000] XXX sending WMI cmd nowait 36896
[   44.350000] ath10k_pci 0000:01:00.0: received event id 36891 not implemented
[   44.360000] mesh: sending popen to 00:03:7f:10:4e:2d
[   44.380000] ath10k_pci 0000:01:00.0: wmi mgmt tx skb 86fb4e40 len 84 ftype 00 stype d0
[   44.390000] XXX sending WMI cmd 36905
[   44.390000] XXX sending WMI cmd nowait 36905
[   44.390000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 839037ff-ad03-4442-9114-f99e03204c
[   44.400000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 a
[   44.410000] ath10k_pci 0000:01:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1
[   44.420000] ath10k_pci 0000:01:00.0: firmware register dump:
[   44.430000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 0x009A98BE 0x00955B31
[   44.440000] ath10k_pci 0000:01:00.0: [04]: 0x009A98BE 0x00060330 0x0000001E 0x00000B00
[   44.440000] ath10k_pci 0000:01:00.0: [08]: 0x00447730 0x009C3014 0x00446970 0x00000078
[   44.450000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0xFFFFFFFF 0x00958360 0x0095836B
[   44.460000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A6CCF 0x00000000 0x00000000
[   44.470000] ath10k_pci 0000:01:00.0: [20]: 0x409A98BE 0x0040AB14 0x0040FAA8 0x0043E677
[   44.480000] ath10k_pci 0000:01:00.0: [24]: 0x809A9958 0x0040AB74 0x0043E7CC 0xC09A98BE
[   44.480000] ath10k_pci 0000:01:00.0: [28]: 0x8099F2E9 0x0040AB94 0x009C3014 0x0040AD04
[   44.490000] ath10k_pci 0000:01:00.0: [32]: 0x8098933F 0x0040ABB4 0x0043D0D8 0x0040AD04
[   44.500000] ath10k_pci 0000:01:00.0: [36]: 0x809B38C0 0x0040ABD4 0x009C3014 0x0043D0D8
[   44.510000] ath10k_pci 0000:01:00.0: [40]: 0x809AFD68 0x0040AD94 0x00400000 0x00416688
[   44.520000] ath10k_pci 0000:01:00.0: [44]: 0x809BDA75 0x0040ADE4 0x0040AE08 0x00411D44
[   44.520000] ath10k_pci 0000:01:00.0: [48]: 0x809486FA 0x0040AE04 0x00000001 0x00000000
[   44.530000] ath10k_pci 0000:01:00.0: [52]: 0x80948E2C 0x0040AEA4 0x0041E424 0x00412350
[   44.540000] ath10k_pci 0000:01:00.0: [56]: 0x809BCF0D 0x0040AEC4 0x0041E424 0x00000001

My hacky compat-wireless snapshot is over here, any suggestions on what to
try next to debug further are welcome:

    https://github.com/bcopeland/ath10k-mesh

[Also I tried skipping the mgmt tx datapath and use normal datapath,
as seen in the final patch, but that doesn't change things, it crashes
either way.]

Maybe I'm not setting up peers correctly or something like that?

-- 
Bob Copeland %% http://bobcopeland.com/


From kvalo at qca.qualcomm.com  Fri Apr 24 07:31:36 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Fri, 24 Apr 2015 17:31:36 +0300
Subject: [PATCH] ath10k: implement more versatile set_bitrate_mask
In-Reply-To: <CA+BoTQkao3kNSCfqi5KdroHL+iHH2fYjZP=oDShjD2VEOM1KnQ@mail.gmail.com>
 (Michal Kazior's message of "Wed, 22 Apr 2015 09:33:06 +0200")
References: <1428672772-9275-1-git-send-email-michal.kazior@tieto.com>
 <87618v44jv.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQnNNKF7riAgcVj1LupABAGodm751jxOUuZgam8u=wthUA@mail.gmail.com>
 <87vbgpzfo0.fsf@kamboji.qca.qualcomm.com>
 <87383szni2.fsf@kamboji.qca.qualcomm.com>
 <CA+BoTQkao3kNSCfqi5KdroHL+iHH2fYjZP=oDShjD2VEOM1KnQ@mail.gmail.com>
Message-ID: <87fv7ptx6f.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> On 22 April 2015 at 08:27, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>> Kalle Valo <kvalo at qca.qualcomm.com> writes:
>>
>>> Michal Kazior <michal.kazior at tieto.com> writes:
>>>
>>>>> To reduce support questions from the users it would be nice to give few
>>>>> good examples how to use this with iw. And also it makes it easier to
>>>>> test the patch. If you could send something I can add it to the commit
>>>>> log.
>>>>
>>>> Should work:
>>>>
>>>>   iw wlan0 set bitrates legacy 1 6 12 ht-mcs 1 2 3
>>>>   iw wlan0 set bitrates legacy-5 mcs-5 7 8 9
>
> Oh, I just noticed I typo'ed: s/mcs-5/ht-mcs-5/.
>
>
>>>>   iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9
>>>>
>>>> Won't work:
>>>>
>>>>   iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-5
>>>>   iw wlan0 set bitrates vht-mcs-5 2:7-9
>>>>
>>>> (note the invalid VHT MCS ranges)
>>>
>>> Thanks, I added these to the commit log.
>>
>> Actually, I had some problems:
>>
>> # iw wlan0 set bitrates legacy-2.4 1 6 12 ht-mcs-2.4 1 2 3
>> command failed: Invalid argument (-22)
>> # iw wlan0 set bitrates legacy-5 1 6 12 ht-mcs-5 1 2 3
>> command failed: Invalid argument (-22)
>
> There's no 1mbps (CCK) on 5GHz. If you remove the "1" from legacy-5 it
> should work.

I fixed the commit now to:

----------------------------------------------------------------------
These work:

  iw wlan0 set bitrates legacy-5 6 12 ht-mcs-5 1 2 3
  iw wlan0 set bitrates legacy-5 ht-mcs-5 7 8 9
  iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9

These won't work:

  iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-5
  iw wlan0 set bitrates vht-mcs-5 2:7-9

(note the invalid VHT MCS ranges)
----------------------------------------------------------------------

>> # iw wlan0 set bitrates legacy-5 vht-mcs-5 7 8 9
>> command failed: Invalid argument (-22)
>
> There's a couple of problems here:
>
>  * The syntax for VHT MCS is different: vht-mcs-<2.4|5>
> <NSS:MCSx,MCSy... | NSS:MCSx-MCSy>*
>    You used syntax from HT MCS: ht-mcs-<2.4|5> <MCS index>*
>    The correct way to express this would be:
>       iw wlan0 set bitrates legacy-5 vht-mcs-5 1:7,8,9
>    or
>       iw wlan0 set bitrates legacy-5 vht-mcs-5 1:7-9
>    assuming you wanted NSS=1 (VHT MCS don't imply NSS just like HT MCS do)
>
> * As per commit log you can't use just any VHT MCS; you're limited to
> none, 0-7, 0-8, 0-9. You can set a *single* VHT MCS as per
> 51ab1a0a09a8 ("ath10k: add set_bitrate_mask callback") though.

Thanks, I understand better now.

-- 
Kalle Valo


From yeohchunyeow at gmail.com  Fri Apr 24 10:55:32 2015
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Sat, 25 Apr 2015 01:55:32 +0800
Subject: attempting mesh on ath10k
In-Reply-To: <20150424125055.GA27722@localhost>
References: <20150424125055.GA27722@localhost>
Message-ID: <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>

Hi, Bob

I have tried converting the "adhoc" mode on the
firmware-2.bin_999.999.0.636 as mesh interface.

You can find my patches here:
https://github.com/chunyeow/ath/commits/mesh

But probably too many workaround and won't be able to interoperate
with other mesh interface.

I have also found out the immediate crashes when peer mesh STA is
added by the firmware if using "AP" mode.
https://github.com/chunyeow/ath/commit/c09a7ef83a5912d1965756b9ce4c9a22ae1dcf08

Hi, Ben

You have any updates on CT firmware to support the mesh mode?

Please advice. Thanks

---
Chun-Yeow


On Fri, Apr 24, 2015 at 8:50 PM, Bob Copeland <me at bobcopeland.com> wrote:
> Hi all,
>
> I have played around a little bit with the raw mode patches trying to
> get mesh working on ath10k.  I've hacked the driver slightly to use an
> AP vif in the firmware in "mesh" mode, which seems to produce proper looking
> beacons over the air.
>
> However, when I bring up a second mesh node, the ath10k device crashes
> upon trying to send the first mesh peering action frame.  Here's what
> dmesg looks like:
>
> [   43.860000] ath10k_pci 0000:01:00.0: wmi event debug mesg len 140
> [   44.310000] XXX trying to create peer 00:03:7f:10:4e:2d
> [   44.310000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 peer_addr 00:03:7f:10:4e:2d
> [   44.320000] XXX sending WMI cmd 36892
> [   44.320000] XXX sending WMI cmd nowait 36892
> [   44.330000] XXX waiting for peer create 00:03:7f:10:4e:2d
> [   44.330000] XXX peer 00:03:7f:10:4e:2d added
> [   44.340000] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 00:03:7f:10:4e:2d (new)
> [   44.350000] XXX sending WMI cmd 36896
> [   44.350000] XXX sending WMI cmd nowait 36896
> [   44.350000] ath10k_pci 0000:01:00.0: received event id 36891 not implemented
> [   44.360000] mesh: sending popen to 00:03:7f:10:4e:2d
> [   44.380000] ath10k_pci 0000:01:00.0: wmi mgmt tx skb 86fb4e40 len 84 ftype 00 stype d0
> [   44.390000] XXX sending WMI cmd 36905
> [   44.390000] XXX sending WMI cmd nowait 36905
> [   44.390000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 839037ff-ad03-4442-9114-f99e03204c
> [   44.400000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 a
> [   44.410000] ath10k_pci 0000:01:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1
> [   44.420000] ath10k_pci 0000:01:00.0: firmware register dump:
> [   44.430000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 0x009A98BE 0x00955B31
> [   44.440000] ath10k_pci 0000:01:00.0: [04]: 0x009A98BE 0x00060330 0x0000001E 0x00000B00
> [   44.440000] ath10k_pci 0000:01:00.0: [08]: 0x00447730 0x009C3014 0x00446970 0x00000078
> [   44.450000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0xFFFFFFFF 0x00958360 0x0095836B
> [   44.460000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A6CCF 0x00000000 0x00000000
> [   44.470000] ath10k_pci 0000:01:00.0: [20]: 0x409A98BE 0x0040AB14 0x0040FAA8 0x0043E677
> [   44.480000] ath10k_pci 0000:01:00.0: [24]: 0x809A9958 0x0040AB74 0x0043E7CC 0xC09A98BE
> [   44.480000] ath10k_pci 0000:01:00.0: [28]: 0x8099F2E9 0x0040AB94 0x009C3014 0x0040AD04
> [   44.490000] ath10k_pci 0000:01:00.0: [32]: 0x8098933F 0x0040ABB4 0x0043D0D8 0x0040AD04
> [   44.500000] ath10k_pci 0000:01:00.0: [36]: 0x809B38C0 0x0040ABD4 0x009C3014 0x0043D0D8
> [   44.510000] ath10k_pci 0000:01:00.0: [40]: 0x809AFD68 0x0040AD94 0x00400000 0x00416688
> [   44.520000] ath10k_pci 0000:01:00.0: [44]: 0x809BDA75 0x0040ADE4 0x0040AE08 0x00411D44
> [   44.520000] ath10k_pci 0000:01:00.0: [48]: 0x809486FA 0x0040AE04 0x00000001 0x00000000
> [   44.530000] ath10k_pci 0000:01:00.0: [52]: 0x80948E2C 0x0040AEA4 0x0041E424 0x00412350
> [   44.540000] ath10k_pci 0000:01:00.0: [56]: 0x809BCF0D 0x0040AEC4 0x0041E424 0x00000001
>
> My hacky compat-wireless snapshot is over here, any suggestions on what to
> try next to debug further are welcome:
>
>     https://github.com/bcopeland/ath10k-mesh
>
> [Also I tried skipping the mgmt tx datapath and use normal datapath,
> as seen in the final patch, but that doesn't change things, it crashes
> either way.]
>
> Maybe I'm not setting up peers correctly or something like that?
>
> --
> Bob Copeland %% http://bobcopeland.com/
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From g.martino at gmx.com  Fri Apr 24 18:15:48 2015
From: g.martino at gmx.com (Gabriele Martino)
Date: Sat, 25 Apr 2015 01:15:48 +0000 (UTC)
Subject: QCA6174 hw2.1?
References: <trinity-d51578c9-4e28-4805-b58e-fdd5388949da-1426217948333@msvc-mesg-gmx002>
 <CA+BoTQnGQC9sy_Qhiv4peeRsF2dY+2yd12GTgJpyRhrgMTg+Yw@mail.gmail.com>
 <trinity-2097dd2e-b8b3-40c5-9eed-c0dc7d8690af-1426260485155@3capp-mailcom-lxa11>
 <CA+BoTQnKJE0w0SZrh-p2KaKe62t4=cRLnjeKu+t9aeE+LFce-w@mail.gmail.com>
Message-ID: <loom.20150425T025815-684@post.gmane.org>

Michal Kazior <michal.kazior <at> tieto.com> writes:

> 
> https://gist.github.com/kazikcz/c970cbf3a863ebbc4495
> https://gist.github.com/kazikcz/64313b9e2470660faae1
> 
> Here are two simple and crude tools I have to deal with ath10k FW API
> blobs. Use with care.
> 
> You can use the disassemble.py to extract the otp.bin from hw3 ath10k
> FW API blob:
> 
>   python disassemble.py < /lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin
> 
> Then you can use the assemble.py to generate hw2.1 ath10k FW ABI blob:
> 
>   mkdir -p /lib/firmware/ath10k/QCA6174/hw2.1/
>   python assemble.py killer1252-testfw 0 path/to/qca61x420.bin
> path/to/otp.bin 4 > /lib/firmware/ath10k/QCA6174/hw2.1/firmware-4.bin
>   cp path/to/eeprom_ar6320_2p1_NFA354xp.bin
> /lib/firmware/ath10k/QCA6174/hw2.1/board.bin
> 
> (mind the email line wrapping)
> 

I'm trying to generate the blob, but I found two big issues.
The first: I have too many board files, which one should I use?
eeprom_ar6320_2p1_NFA324i_5.bin
eeprom_ar6320_2p1_NFA344i.bin
eeprom_ar6320_2p1_NFA344i_highTX.bin
eeprom_ar6320_2p1_NFA345i.bin
eeprom_ar6320_2p1_NFA345i_highTX.bin
eeprom_ar6320_2p1_NFA354xp.bin
eeprom_ar6320_2p1_NFA355i.bin
eeprom_qca9377_1p0_NFA435_olpc.bin

The controller is a
"Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 20)"
declared as Killer N1525 on Alienware 15.

Whatever, I can try them one by one later.
I picked up the first and built the firmware blob.
But here's the second issue: it wants the calibration data.

[    2.067447] ath10k_pci 0000:03:00.0: enabling device (0000 -> 0002)
[    2.068679] ath10k_pci 0000:03:00.0: pci irq msi-x interrupts 8 irq_mode
0 reset_mode 0
[    2.215280] ath10k_pci 0000:03:00.0: Direct firmware load for ath10k/cal-pci-
0000:03:00.0.bin failed with error -2
[    2.924276] ath3k: probe of 1-9:1.0 failed with error -22
[    2.924299] usbcore: registered new interface driver ath3k
[    3.289023] ath10k_pci 0000:03:00.0: unable to write to the device
[    3.289026] ath10k_pci 0000:03:00.0: failed to download normal firmware: -110
[    3.289052] ath10k_pci 0000:03:00.0: could not init core (-110)
[    3.289099] ath10k_pci 0000:03:00.0: could not probe fw (-110)

How can I generate the cal-pci-0000:03:00.0.bin file?
I'm using the 4.0.0-gentoo kernel on x86_64.

Regards,
Gabriele



From greearb at candelatech.com  Fri Apr 24 18:38:02 2015
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 24 Apr 2015 18:38:02 -0700
Subject: attempting mesh on ath10k
In-Reply-To: <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>
References: <20150424125055.GA27722@localhost>
 <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>
Message-ID: <553AEFFA.6010709@candelatech.com>

On 04/24/2015 10:55 AM, Yeoh Chun-Yeow wrote:
> Hi, Bob
>
> I have tried converting the "adhoc" mode on the
> firmware-2.bin_999.999.0.636 as mesh interface.
>
> You can find my patches here:
> https://github.com/chunyeow/ath/commits/mesh
>
> But probably too many workaround and won't be able to interoperate
> with other mesh interface.
>
> I have also found out the immediate crashes when peer mesh STA is
> added by the firmware if using "AP" mode.
> https://github.com/chunyeow/ath/commit/c09a7ef83a5912d1965756b9ce4c9a22ae1dcf08
>
> Hi, Ben
>
> You have any updates on CT firmware to support the mesh mode?
>
> Please advice. Thanks

I have IBSS support working, and at least non-encrypted raw transmit
can work in my firmware, though raw tx requires Michal's RFC patch
he posted some time ago.

Don't know about mesh, but if you can crash my firmware, please send
me the debug info and I'll see if I can figure out why.

I am not sure raw tx with encryption is possible...and at the least,
it is probably not something I'll attempt to do for fun anytime soon.

Thanks,
Ben


>
> ---
> Chun-Yeow
>
>
> On Fri, Apr 24, 2015 at 8:50 PM, Bob Copeland <me at bobcopeland.com> wrote:
>> Hi all,
>>
>> I have played around a little bit with the raw mode patches trying to
>> get mesh working on ath10k.  I've hacked the driver slightly to use an
>> AP vif in the firmware in "mesh" mode, which seems to produce proper looking
>> beacons over the air.
>>
>> However, when I bring up a second mesh node, the ath10k device crashes
>> upon trying to send the first mesh peering action frame.  Here's what
>> dmesg looks like:
>>
>> [   43.860000] ath10k_pci 0000:01:00.0: wmi event debug mesg len 140
>> [   44.310000] XXX trying to create peer 00:03:7f:10:4e:2d
>> [   44.310000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 peer_addr 00:03:7f:10:4e:2d
>> [   44.320000] XXX sending WMI cmd 36892
>> [   44.320000] XXX sending WMI cmd nowait 36892
>> [   44.330000] XXX waiting for peer create 00:03:7f:10:4e:2d
>> [   44.330000] XXX peer 00:03:7f:10:4e:2d added
>> [   44.340000] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 00:03:7f:10:4e:2d (new)
>> [   44.350000] XXX sending WMI cmd 36896
>> [   44.350000] XXX sending WMI cmd nowait 36896
>> [   44.350000] ath10k_pci 0000:01:00.0: received event id 36891 not implemented
>> [   44.360000] mesh: sending popen to 00:03:7f:10:4e:2d
>> [   44.380000] ath10k_pci 0000:01:00.0: wmi mgmt tx skb 86fb4e40 len 84 ftype 00 stype d0
>> [   44.390000] XXX sending WMI cmd 36905
>> [   44.390000] XXX sending WMI cmd nowait 36905
>> [   44.390000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 839037ff-ad03-4442-9114-f99e03204c
>> [   44.400000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 a
>> [   44.410000] ath10k_pci 0000:01:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1
>> [   44.420000] ath10k_pci 0000:01:00.0: firmware register dump:
>> [   44.430000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 0x009A98BE 0x00955B31
>> [   44.440000] ath10k_pci 0000:01:00.0: [04]: 0x009A98BE 0x00060330 0x0000001E 0x00000B00
>> [   44.440000] ath10k_pci 0000:01:00.0: [08]: 0x00447730 0x009C3014 0x00446970 0x00000078
>> [   44.450000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0xFFFFFFFF 0x00958360 0x0095836B
>> [   44.460000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A6CCF 0x00000000 0x00000000
>> [   44.470000] ath10k_pci 0000:01:00.0: [20]: 0x409A98BE 0x0040AB14 0x0040FAA8 0x0043E677
>> [   44.480000] ath10k_pci 0000:01:00.0: [24]: 0x809A9958 0x0040AB74 0x0043E7CC 0xC09A98BE
>> [   44.480000] ath10k_pci 0000:01:00.0: [28]: 0x8099F2E9 0x0040AB94 0x009C3014 0x0040AD04
>> [   44.490000] ath10k_pci 0000:01:00.0: [32]: 0x8098933F 0x0040ABB4 0x0043D0D8 0x0040AD04
>> [   44.500000] ath10k_pci 0000:01:00.0: [36]: 0x809B38C0 0x0040ABD4 0x009C3014 0x0043D0D8
>> [   44.510000] ath10k_pci 0000:01:00.0: [40]: 0x809AFD68 0x0040AD94 0x00400000 0x00416688
>> [   44.520000] ath10k_pci 0000:01:00.0: [44]: 0x809BDA75 0x0040ADE4 0x0040AE08 0x00411D44
>> [   44.520000] ath10k_pci 0000:01:00.0: [48]: 0x809486FA 0x0040AE04 0x00000001 0x00000000
>> [   44.530000] ath10k_pci 0000:01:00.0: [52]: 0x80948E2C 0x0040AEA4 0x0041E424 0x00412350
>> [   44.540000] ath10k_pci 0000:01:00.0: [56]: 0x809BCF0D 0x0040AEC4 0x0041E424 0x00000001
>>
>> My hacky compat-wireless snapshot is over here, any suggestions on what to
>> try next to debug further are welcome:
>>
>>      https://github.com/bcopeland/ath10k-mesh
>>
>> [Also I tried skipping the mgmt tx datapath and use normal datapath,
>> as seen in the final patch, but that doesn't change things, it crashes
>> either way.]
>>
>> Maybe I'm not setting up peers correctly or something like that?
>>
>> --
>> Bob Copeland %% http://bobcopeland.com/
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From me at corinlawson.com.au  Fri Apr 24 20:47:29 2015
From: me at corinlawson.com.au (Corin Lawson)
Date: Sat, 25 Apr 2015 13:47:29 +1000
Subject: QCA6174 hw2.1?
In-Reply-To: <loom.20150425T025815-684@post.gmane.org>
References: <trinity-d51578c9-4e28-4805-b58e-fdd5388949da-1426217948333@msvc-mesg-gmx002>
 <CA+BoTQnGQC9sy_Qhiv4peeRsF2dY+2yd12GTgJpyRhrgMTg+Yw@mail.gmail.com>
 <trinity-2097dd2e-b8b3-40c5-9eed-c0dc7d8690af-1426260485155@3capp-mailcom-lxa11>
 <CA+BoTQnKJE0w0SZrh-p2KaKe62t4=cRLnjeKu+t9aeE+LFce-w@mail.gmail.com>
 <loom.20150425T025815-684@post.gmane.org>
Message-ID: <CAJAVYN208PQpnt5oQPi1hdYW71WMVJReBNSY-OqZ9aCb0yuiaA@mail.gmail.com>

Hi Gabriele,

I have had success with eeprom_ar6320_2p1_NFA344i.bin.

I am also using Gentoo (but v3.19.3) but I have also applied these
patches/commits:

- http://permalink.gmane.org/gmane.linux.kernel.wireless.general/137030
- https://github.com/kvalo/ath/commit/d63955b33b3bee45d784ffdfafeb93076c765660

Also, I didn't use that disassemble.py script, I used:

- https://gist.github.com/kazikcz/8e5845ad84ca251aa295

I also had problems with calibration, I had to pass skip_otp=y to the module:

    $ cat /etc/modprobe.d/ath10k.conf
    options ath10k_core skip_otp=y

FWIW:

    $ lspci -vs 05:00.0
    05:00.0 Network controller: Qualcomm Atheros Device 003e (rev 20)
            Subsystem: Bigfoot Networks, Inc. Device 1525
            Flags: bus master, fast devsel, latency 0, IRQ 31
            Memory at f7800000 (64-bit, non-prefetchable) [size=2M]
            Capabilities: <access denied>
            Kernel driver in use: ath10k_pci
            Kernel modules: ath10k_pci

I give a huge thanks to the individuals on this mailing list for
helping me; I'm just happy to give back where I can :)

I would interested in knowing from where you got your drivers/board
files. I had to download mine from my laptop manufacturer's (MSI)
website.

Note: I understand that ath10k doesn't support encryption yet. But I
haven't successfully been able to connect to my open AP as yet...

Cheers,
Corin

On Sat, Apr 25, 2015 at 11:15 AM, Gabriele Martino <g.martino at gmx.com> wrote:
>
> Michal Kazior <michal.kazior <at> tieto.com> writes:
>
> >
> > https://gist.github.com/kazikcz/c970cbf3a863ebbc4495
> > https://gist.github.com/kazikcz/64313b9e2470660faae1
> >
> > Here are two simple and crude tools I have to deal with ath10k FW API
> > blobs. Use with care.
> >
> > You can use the disassemble.py to extract the otp.bin from hw3 ath10k
> > FW API blob:
> >
> >   python disassemble.py < /lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin
> >
> > Then you can use the assemble.py to generate hw2.1 ath10k FW ABI blob:
> >
> >   mkdir -p /lib/firmware/ath10k/QCA6174/hw2.1/
> >   python assemble.py killer1252-testfw 0 path/to/qca61x420.bin
> > path/to/otp.bin 4 > /lib/firmware/ath10k/QCA6174/hw2.1/firmware-4.bin
> >   cp path/to/eeprom_ar6320_2p1_NFA354xp.bin
> > /lib/firmware/ath10k/QCA6174/hw2.1/board.bin
> >
> > (mind the email line wrapping)
> >
>
> I'm trying to generate the blob, but I found two big issues.
> The first: I have too many board files, which one should I use?
> eeprom_ar6320_2p1_NFA324i_5.bin
> eeprom_ar6320_2p1_NFA344i.bin
> eeprom_ar6320_2p1_NFA344i_highTX.bin
> eeprom_ar6320_2p1_NFA345i.bin
> eeprom_ar6320_2p1_NFA345i_highTX.bin
> eeprom_ar6320_2p1_NFA354xp.bin
> eeprom_ar6320_2p1_NFA355i.bin
> eeprom_qca9377_1p0_NFA435_olpc.bin
>
> The controller is a
> "Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 20)"
> declared as Killer N1525 on Alienware 15.
>
> Whatever, I can try them one by one later.
> I picked up the first and built the firmware blob.
> But here's the second issue: it wants the calibration data.
>
> [    2.067447] ath10k_pci 0000:03:00.0: enabling device (0000 -> 0002)
> [    2.068679] ath10k_pci 0000:03:00.0: pci irq msi-x interrupts 8 irq_mode
> 0 reset_mode 0
> [    2.215280] ath10k_pci 0000:03:00.0: Direct firmware load for ath10k/cal-pci-
> 0000:03:00.0.bin failed with error -2
> [    2.924276] ath3k: probe of 1-9:1.0 failed with error -22
> [    2.924299] usbcore: registered new interface driver ath3k
> [    3.289023] ath10k_pci 0000:03:00.0: unable to write to the device
> [    3.289026] ath10k_pci 0000:03:00.0: failed to download normal firmware: -110
> [    3.289052] ath10k_pci 0000:03:00.0: could not init core (-110)
> [    3.289099] ath10k_pci 0000:03:00.0: could not probe fw (-110)
>
> How can I generate the cal-pci-0000:03:00.0.bin file?
> I'm using the 4.0.0-gentoo kernel on x86_64.
>
> Regards,
> Gabriele
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From sunder.kumaresan at aricent.com  Sat Apr 25 02:14:37 2015
From: sunder.kumaresan at aricent.com (Sunder Kumaresan)
Date: Sat, 25 Apr 2015 09:14:37 +0000
Subject: Ath10 Firmware
Message-ID: <1f50fb125dfb4dc883c338ddf2582444@BGHMBXV02.AD.ARICENT.COM>


Hi,

Will Ath10 firmware work for  big endian processor ?   is it endian agnostic ? It works for little endian processor.

Best Regards,
Sunder

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."


From oscarrydberg at gmail.com  Sat Apr 25 11:22:31 2015
From: oscarrydberg at gmail.com (Oscar Rydberg)
Date: Sat, 25 Apr 2015 18:22:31 +0000 (UTC)
Subject: First QCA6174 firmware release
References: <54DB5CD8.80302@dreyero.de>
Message-ID: <loom.20150425T202151-34@post.gmane.org>

Olaf Dreyer <olaf <at> dreyero.de> writes:

> 
> I have a new Acer Aspire VN7-591 Laptop with a Qualcom Atheros 
QCNF344
> wireless chip, which is shown by lspci as:
> 
> Qualcomm Atheros Device 003e (rev 20)
> Subsystem: Foxconn International, Inc. Device e08e
> 
> I have installed the linux-next kernel from today 8:00 UTC.
> I was able to load the ath10k_pci driver, but the driver complains 
about
> missing firmware.
> I installed a firmware from here: https://github.com/kvalo/ath10k-
firmware
> under /lib/firmware/ath10k/QCA6174/hw2.1/
> But also the card is not working.
> 
> The output from dmesg is:
> [ 9360.538767] ath10k_pci 0000:07:00.0: pci irq msi interrupts 1
> irq_mode 0 reset_mode 0
> [ 9360.788588] ath10k_pci 0000:07:00.0: Direct firmware load for
> ath10k/cal-pci-0000:07:00.0.bin failed with error -2
> [ 9362.729118] ath10k_pci 0000:07:00.0: unable to write to the 
device
> [ 9362.729120] ath10k_pci 0000:07:00.0: failed to download normal
> firmware: -110
> [ 9362.729121] ath10k_pci 0000:07:00.0: could not init core (-110)
> [ 9362.729156] ath10k_pci 0000:07:00.0: could not probe fw (-110)
> 
> I would like to know, as Austin Hendrix wrote it at 8 Feb 14:12 
2015
> too, where can I find the firmware on the
> internet / my Windows7 partition and how can I prepare the needed 
files.
> 
> Many thanks,
> 
> Olaf
> 

Hi did you advance anything on this?

Trying to run a QCA6164 card myself on a Lenovo 3-14 laptop.
Sems I've gotten as far as you. 
Prepared Ath10k hw2.1 board.bin and firmware-4.bin for hw2.1 using 
windows binary driver. (And assemble.py, disassemble.py tools linked 
elsewhere)

Board.bin seems to load and execute fine. But after that when 
loading firmware-4.bin, it ends up with Unable to write to the 
device.

I see it starts sending firmware-4.bin and first 256 bytes ce_send 
fine.
2nd ce_send 256 bytes seem to also ce_send fine, however after that 
bmi_wait times out. (-110)





From me at corinlawson.com.au  Sat Apr 25 20:51:13 2015
From: me at corinlawson.com.au (Corin Lawson)
Date: Sun, 26 Apr 2015 13:51:13 +1000
Subject: QCA6174 hw2.1?
In-Reply-To: <553B8F89.4040908@gmx.com>
References: <trinity-d51578c9-4e28-4805-b58e-fdd5388949da-1426217948333@msvc-mesg-gmx002>
 <CA+BoTQnGQC9sy_Qhiv4peeRsF2dY+2yd12GTgJpyRhrgMTg+Yw@mail.gmail.com>
 <trinity-2097dd2e-b8b3-40c5-9eed-c0dc7d8690af-1426260485155@3capp-mailcom-lxa11>
 <CA+BoTQnKJE0w0SZrh-p2KaKe62t4=cRLnjeKu+t9aeE+LFce-w@mail.gmail.com>
 <loom.20150425T025815-684@post.gmane.org>
 <CAJAVYN208PQpnt5oQPi1hdYW71WMVJReBNSY-OqZ9aCb0yuiaA@mail.gmail.com>
 <553B8F89.4040908@gmx.com>
Message-ID: <CAJAVYN1XKYdGqx4pzg3C9kSxj6_qwr4raoDJm7e+VLy1P=dsdw@mail.gmail.com>

Hi Gabriele,

I think we have the same card (the vendor and device ids are the
determining factor):

    $ lspci -n -s 05:00.0
    05:00.0 0280: 168c:003e (rev 20)

Without the skip_otp option I get this in dmesg:

    [18396.622576] ath10k_pci 0000:05:00.0: pci irq msi interrupts 1
irq_mode 0 reset_mode 0
    [18396.768593] ath10k_pci 0000:05:00.0: Direct firmware load for
ath10k/cal-pci-0000:05:00.0.bin failed with error -2
    [18396.847975] ath10k_pci 0000:05:00.0: otp calibration failed: 3
    [18396.847977] ath10k_pci 0000:05:00.0: failed to run otp: -22
    [18396.847978] ath10k_pci 0000:05:00.0: could not init core (-22)
    [18396.847995] ath10k_pci 0000:05:00.0: could not probe fw (-22)

Which is different to your messages. I'm taking a guess here, but
those DMAR messages seem to indicate that the firmware is attempting
to write to the wrong part of memory (i.e. wrong firmware).

Using kvalo's kernel fork is probably a good step (it contains those
necessary patches). If you still don't get it working, then my only
other idea is to try that dissect.py gist I mentioned previously. Here
are the commands that worked for me:

    # python dissect.py <
drivers/Production/Windows8.1-x64/k1525w81/qca61x420.bin
    # python assemble.py killer-n1525-fw 0 fw-2.bin fw-1.bin 4 >
/lib/firmware/ath10k/QCA6174/hw2.1/firmware-4.bin

The dissect.py script produced fw-1.bin which is the otp file and
fw-2.bin which is the correct firmware (don't quote me on that, but it
worked for me). As for your board.bin file, you need to check the .inf
file that comes with your drivers. I'm not sure what the structure of
that file is... for all I know I could be using the wrong board
file...

I hope this helps, otherwise you've reached the limits of my
experience :) Maybe someone else on the list has a better idea?

Cheers,
Corin


On Sat, Apr 25, 2015 at 10:58 PM, Gabriele Martino <g.martino at gmx.com> wrote:
> On 25/04/2015 05:47, Corin Lawson wrote:
>> I also had problems with calibration, I had to pass skip_otp=y to the module:
>>
>>     $ cat /etc/modprobe.d/ath10k.conf
>>     options ath10k_core skip_otp=y
> Hi Corin,
> I removed ath10k_pci, ath10k_core and ath before loading ath10k_core
> with skip_otp=1, but nothing happened:
>
> [ 1808.473874] ath10k_pci 0000:03:00.0: pci irq msi-x interrupts 8
> irq_mode 0 reset_mode 0
> [ 1808.618770] ath10k_pci 0000:03:00.0: Direct firmware load for
> ath10k/cal-pci-0000:03:00.0.bin failed with error -2
> [ 1808.687492] dmar: DRHD: handling fault status reg 2
> [ 1808.687506] dmar: DMAR:[DMA Write] Request device [03:00.0] fault
> addr 7ee00000
>                DMAR:[fault reason 05] PTE Write access is not set
> [ 1809.688015] ath10k_pci 0000:03:00.0: unable to write to the device
> [ 1809.688018] ath10k_pci 0000:03:00.0: failed to download normal
> firmware: -110
> [ 1809.688020] ath10k_pci 0000:03:00.0: could not init core (-110)
> [ 1809.688054] ath10k_pci 0000:03:00.0: could not probe fw (-110)
>
> I assembled the otp.bin with fw.bin to get the blob, so I'm not sure
> skip_otp will fix this...
> Now I'm cloning the kvalo's kernel tree, this should be faster than
> picking the single patches.
>
>> FWIW:
>>
>>     $ lspci -vs 05:00.0
>>     05:00.0 Network controller: Qualcomm Atheros Device 003e (rev 20)
>>             Subsystem: Bigfoot Networks, Inc. Device 1525
>>             Flags: bus master, fast devsel, latency 0, IRQ 31
>>             Memory at f7800000 (64-bit, non-prefetchable) [size=2M]
>>             Capabilities: <access denied>
>>             Kernel driver in use: ath10k_pci
>>             Kernel modules: ath10k_pci
> Well, mine seems a bit different:
>
> 03:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless
> Network Adapter (rev 20)
>         Subsystem: Bigfoot Networks, Inc. Killer N1525 Wireless-AC
>         Flags: bus master, fast devsel, latency 0, IRQ 32
>         Memory at f6800000 (64-bit, non-prefetchable) [size=2M]
>         Capabilities: [40] Power Management version 3
>         Capabilities: [50] MSI: Enable+ Count=8/8 Maskable+ 64bit-
>         Capabilities: [70] Express Endpoint, MSI 00
>         Capabilities: [100] Advanced Error Reporting
>         Capabilities: [148] Virtual Channel
>         Capabilities: [168] Device Serial Number 00-00-00-00-00-00-00-00
>         Capabilities: [178] Latency Tolerance Reporting
>         Capabilities: [180] L1 PM Substates
>         Kernel driver in use: ath10k_pci
>         Kernel modules: ath10k_pci
>
>> I would interested in knowing from where you got your drivers/board
>> files. I had to download mine from my laptop manufacturer's (MSI)
>> website.
> I mounted the preinstalled Windows 8 partition on /mnt and run:
> find /mnt -iname '*.bin'
>
> The same files can be found inside the driver installer on the Alienware
> (Dell) website.
>
> Regards,
> Gabriele
>


From g.martino at gmx.com  Sun Apr 26 07:10:54 2015
From: g.martino at gmx.com (Gabriele Martino)
Date: Sun, 26 Apr 2015 16:10:54 +0200
Subject: QCA6174 hw2.1?
In-Reply-To: <CAJAVYN1XKYdGqx4pzg3C9kSxj6_qwr4raoDJm7e+VLy1P=dsdw@mail.gmail.com>
References: <trinity-d51578c9-4e28-4805-b58e-fdd5388949da-1426217948333@msvc-mesg-gmx002>
 <CA+BoTQnGQC9sy_Qhiv4peeRsF2dY+2yd12GTgJpyRhrgMTg+Yw@mail.gmail.com>
 <trinity-2097dd2e-b8b3-40c5-9eed-c0dc7d8690af-1426260485155@3capp-mailcom-lxa11>
 <CA+BoTQnKJE0w0SZrh-p2KaKe62t4=cRLnjeKu+t9aeE+LFce-w@mail.gmail.com>
 <loom.20150425T025815-684@post.gmane.org>
 <CAJAVYN208PQpnt5oQPi1hdYW71WMVJReBNSY-OqZ9aCb0yuiaA@mail.gmail.com>
 <553B8F89.4040908@gmx.com>
 <CAJAVYN1XKYdGqx4pzg3C9kSxj6_qwr4raoDJm7e+VLy1P=dsdw@mail.gmail.com>
Message-ID: <553CF1EE.50807@gmx.com>

Hi Corin,
the "dissect.py" script seems to work better than the "disassemble.py":

[ 6483.455435] ath10k_pci 0000:03:00.0: pci irq msi-x interrupts 8
irq_mode 0 reset_mode 0
[ 6483.600747] ath10k_pci 0000:03:00.0: Direct firmware load for
ath10k/cal-pci-0000:03:00.0.bin failed with error -2
[ 6484.772417] ath10k_pci 0000:03:00.0: firmware crashed! (uuid n/a)
[ 6484.772433] ath10k_pci 0000:03:00.0: qca6174 hw2.1 (0x05010000,
0x003405ff) fw killer-n1525-fw api 4 htt 0.0 wmi 4 cal otp max_sta 32
[ 6484.772435] ath10k_pci 0000:03:00.0: debug 1 debugfs 0 tracing 0 dfs
0 testmode 0
[ 6484.773333] ath10k_pci 0000:03:00.0: firmware register dump:
[ 6484.773333] ath10k_pci 0000:03:00.0: [00]: 0x05010000 0x000015B3
0x0095186B 0x00955B31
[ 6484.773333] ath10k_pci 0000:03:00.0: [04]: 0x0095186B 0x00060130
0x00000010 0x0040AF04
[ 6484.773333] ath10k_pci 0000:03:00.0: [08]: 0x00000018 0x00000001
0x00000001 0x00412250
[ 6484.773333] ath10k_pci 0000:03:00.0: [12]: 0x00000009 0x00000000
0x0096C09C 0x0096C0A7
[ 6484.773333] ath10k_pci 0000:03:00.0: [16]: 0x0096BDBC 0x009286B6
0x00000000 0x00000000
[ 6484.773333] ath10k_pci 0000:03:00.0: [20]: 0x4095186B 0x0040E160
0x0041F82C 0x00000001
[ 6484.773333] ath10k_pci 0000:03:00.0: [24]: 0x80936238 0x0040E1C0
0x00000000 0xC095186B
[ 6484.773333] ath10k_pci 0000:03:00.0: [28]: 0x80936361 0x0040E1E0
0x00000000 0x0041C8DC
[ 6484.773333] ath10k_pci 0000:03:00.0: [32]: 0x80934A67 0x0040E200
0x00436DF0 0x0040E250
[ 6484.773333] ath10k_pci 0000:03:00.0: [36]: 0x809A5C92 0x0040E250
0x004275B0 0x00000001
[ 6484.773333] ath10k_pci 0000:03:00.0: [40]: 0x809A5CEA 0x0040E290
0x00426F40 0x00000004
[ 6484.773333] ath10k_pci 0000:03:00.0: [44]: 0x809A5DCA 0x0040E2B0
0x00426F40 0x0041C8DC
[ 6484.773333] ath10k_pci 0000:03:00.0: [48]: 0x800A0909 0x0040E2D0
0x00426F40 0x004275A0
[ 6484.773333] ath10k_pci 0000:03:00.0: [52]: 0x800A024A 0x0040E2F0
0x0041ABB0 0x00420440
[ 6484.773333] ath10k_pci 0000:03:00.0: [56]: 0x809287D9 0x0040E310
0x00000000 0x00400000
[ 6485.765040] ath10k_pci 0000:03:00.0: failed to receive control
response completion, polling..
[ 6486.765027] ath10k_pci 0000:03:00.0: ctl_resp never came in (-110)
[ 6486.765032] ath10k_pci 0000:03:00.0: failed to connect to HTC: -110
[ 6486.828658] ath10k_pci 0000:03:00.0: could not init core (-110)
[ 6486.828689] ath10k_pci 0000:03:00.0: could not probe fw (-110)
[ 6486.831175] ath10k_pci 0000:03:00.0: cannot restart a device that
hasn't been started

Well, at least it loads correctly. This should be the firmware crash
fixed in the patches, it's time to test kvalo's kernel sources.


On 26/04/2015 05:51, Corin Lawson wrote:
> Hi Gabriele,
>
> I think we have the same card (the vendor and device ids are the
> determining factor):
>
>     $ lspci -n -s 05:00.0
>     05:00.0 0280: 168c:003e (rev 20)
>
> Without the skip_otp option I get this in dmesg:
>
>     [18396.622576] ath10k_pci 0000:05:00.0: pci irq msi interrupts 1
> irq_mode 0 reset_mode 0
>     [18396.768593] ath10k_pci 0000:05:00.0: Direct firmware load for
> ath10k/cal-pci-0000:05:00.0.bin failed with error -2
>     [18396.847975] ath10k_pci 0000:05:00.0: otp calibration failed: 3
>     [18396.847977] ath10k_pci 0000:05:00.0: failed to run otp: -22
>     [18396.847978] ath10k_pci 0000:05:00.0: could not init core (-22)
>     [18396.847995] ath10k_pci 0000:05:00.0: could not probe fw (-22)
>
> Which is different to your messages. I'm taking a guess here, but
> those DMAR messages seem to indicate that the firmware is attempting
> to write to the wrong part of memory (i.e. wrong firmware).
>
> Using kvalo's kernel fork is probably a good step (it contains those
> necessary patches). If you still don't get it working, then my only
> other idea is to try that dissect.py gist I mentioned previously. Here
> are the commands that worked for me:
>
>     # python dissect.py <
> drivers/Production/Windows8.1-x64/k1525w81/qca61x420.bin
>     # python assemble.py killer-n1525-fw 0 fw-2.bin fw-1.bin 4 >
> /lib/firmware/ath10k/QCA6174/hw2.1/firmware-4.bin
>
> The dissect.py script produced fw-1.bin which is the otp file and
> fw-2.bin which is the correct firmware (don't quote me on that, but it
> worked for me). As for your board.bin file, you need to check the .inf
> file that comes with your drivers. I'm not sure what the structure of
> that file is... for all I know I could be using the wrong board
> file...
>
> I hope this helps, otherwise you've reached the limits of my
> experience :) Maybe someone else on the list has a better idea?
>
> Cheers,
> Corin
>
>
> On Sat, Apr 25, 2015 at 10:58 PM, Gabriele Martino <g.martino at gmx.com> wrote:
>> On 25/04/2015 05:47, Corin Lawson wrote:
>>> I also had problems with calibration, I had to pass skip_otp=y to the module:
>>>
>>>     $ cat /etc/modprobe.d/ath10k.conf
>>>     options ath10k_core skip_otp=y
>> Hi Corin,
>> I removed ath10k_pci, ath10k_core and ath before loading ath10k_core
>> with skip_otp=1, but nothing happened:
>>
>> [ 1808.473874] ath10k_pci 0000:03:00.0: pci irq msi-x interrupts 8
>> irq_mode 0 reset_mode 0
>> [ 1808.618770] ath10k_pci 0000:03:00.0: Direct firmware load for
>> ath10k/cal-pci-0000:03:00.0.bin failed with error -2
>> [ 1808.687492] dmar: DRHD: handling fault status reg 2
>> [ 1808.687506] dmar: DMAR:[DMA Write] Request device [03:00.0] fault
>> addr 7ee00000
>>                DMAR:[fault reason 05] PTE Write access is not set
>> [ 1809.688015] ath10k_pci 0000:03:00.0: unable to write to the device
>> [ 1809.688018] ath10k_pci 0000:03:00.0: failed to download normal
>> firmware: -110
>> [ 1809.688020] ath10k_pci 0000:03:00.0: could not init core (-110)
>> [ 1809.688054] ath10k_pci 0000:03:00.0: could not probe fw (-110)
>>
>> I assembled the otp.bin with fw.bin to get the blob, so I'm not sure
>> skip_otp will fix this...
>> Now I'm cloning the kvalo's kernel tree, this should be faster than
>> picking the single patches.
>>
>>> FWIW:
>>>
>>>     $ lspci -vs 05:00.0
>>>     05:00.0 Network controller: Qualcomm Atheros Device 003e (rev 20)
>>>             Subsystem: Bigfoot Networks, Inc. Device 1525
>>>             Flags: bus master, fast devsel, latency 0, IRQ 31
>>>             Memory at f7800000 (64-bit, non-prefetchable) [size=2M]
>>>             Capabilities: <access denied>
>>>             Kernel driver in use: ath10k_pci
>>>             Kernel modules: ath10k_pci
>> Well, mine seems a bit different:
>>
>> 03:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless
>> Network Adapter (rev 20)
>>         Subsystem: Bigfoot Networks, Inc. Killer N1525 Wireless-AC
>>         Flags: bus master, fast devsel, latency 0, IRQ 32
>>         Memory at f6800000 (64-bit, non-prefetchable) [size=2M]
>>         Capabilities: [40] Power Management version 3
>>         Capabilities: [50] MSI: Enable+ Count=8/8 Maskable+ 64bit-
>>         Capabilities: [70] Express Endpoint, MSI 00
>>         Capabilities: [100] Advanced Error Reporting
>>         Capabilities: [148] Virtual Channel
>>         Capabilities: [168] Device Serial Number 00-00-00-00-00-00-00-00
>>         Capabilities: [178] Latency Tolerance Reporting
>>         Capabilities: [180] L1 PM Substates
>>         Kernel driver in use: ath10k_pci
>>         Kernel modules: ath10k_pci
>>
>>> I would interested in knowing from where you got your drivers/board
>>> files. I had to download mine from my laptop manufacturer's (MSI)
>>> website.
>> I mounted the preinstalled Windows 8 partition on /mnt and run:
>> find /mnt -iname '*.bin'
>>
>> The same files can be found inside the driver installer on the Alienware
>> (Dell) website.
>>
>> Regards,
>> Gabriele
>>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

-- 

*Gabriele Martino*

Linux Sysadmin & Web Development

g.martino at gmx.com




From me at bobcopeland.com  Sun Apr 26 07:15:53 2015
From: me at bobcopeland.com (Bob Copeland)
Date: Sun, 26 Apr 2015 10:15:53 -0400
Subject: attempting mesh on ath10k
In-Reply-To: <553AEFFA.6010709@candelatech.com>
References: <20150424125055.GA27722@localhost>
 <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>
 <553AEFFA.6010709@candelatech.com>
Message-ID: <20150426141552.GA25938@localhost>

On Fri, Apr 24, 2015 at 06:38:02PM -0700, Ben Greear wrote:
> I have IBSS support working, and at least non-encrypted raw transmit
> can work in my firmware, though raw tx requires Michal's RFC patch
> he posted some time ago.

(Michal's RFC patch is in my repo.)

So I got a bit further.  I was still getting a crash with CT firmware, but,
suspecting that we pass something invalid in assoc message for mesh, I forced
peer->aid = 1 and then it no longer crashes shortly after adding the first
peer on either CT or QCA firmware.

I pushed that hack into my repo for now -- I think we want to rethink how and
when AIDs are generated in mesh.

# iw dev wlan0 station dump
Station 00:03:7f:10:4e:2d (on wlan0)
        inactive time:  400 ms
        rx bytes:       34019
        rx packets:     959
        tx bytes:       152
        tx packets:     3
        tx retries:     0
        tx failed:      0
        signal:         -27 dBm
        signal avg:     -26 dBm
        tx bitrate:     6.0 MBit/s
        rx bitrate:     9.0 MBit/s
        mesh llid:      220
        mesh plid:      455
        mesh plink:     ESTAB
        mesh local PS mode:     ACTIVE
        mesh peer PS mode:      ACTIVE
        mesh non-peer PS mode:  ACTIVE
        authorized:     yes
        authenticated:  yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no

So, progress!

There's still an issue with datapath -- while it looks like we can establish
plinks, I couldn't get unicast traffic flowing even if manually setting up
mpaths and arp table entries.  I haven't yet got all of my 5 ghz capable gear
in the same room to monitor and see where the problem lies.

-- 
Bob Copeland %% http://bobcopeland.com/


From greearb at candelatech.com  Sun Apr 26 08:42:37 2015
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 26 Apr 2015 08:42:37 -0700
Subject: attempting mesh on ath10k
In-Reply-To: <20150426141552.GA25938@localhost>
References: <20150424125055.GA27722@localhost>
 <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>
 <553AEFFA.6010709@candelatech.com> <20150426141552.GA25938@localhost>
Message-ID: <553D076D.6030804@candelatech.com>

On 04/26/2015 07:15 AM, Bob Copeland wrote:
> On Fri, Apr 24, 2015 at 06:38:02PM -0700, Ben Greear wrote:
>> I have IBSS support working, and at least non-encrypted raw transmit
>> can work in my firmware, though raw tx requires Michal's RFC patch
>> he posted some time ago.
>
> (Michal's RFC patch is in my repo.)
>
> So I got a bit further.  I was still getting a crash with CT firmware, but,
> suspecting that we pass something invalid in assoc message for mesh, I forced
> peer->aid = 1 and then it no longer crashes shortly after adding the first
> peer on either CT or QCA firmware.

Please send me the crash dump...and let me know the firmware version if the
info is not in the dump.

Thanks,
Ben

>
> I pushed that hack into my repo for now -- I think we want to rethink how and
> when AIDs are generated in mesh.
>
> # iw dev wlan0 station dump
> Station 00:03:7f:10:4e:2d (on wlan0)
>          inactive time:  400 ms
>          rx bytes:       34019
>          rx packets:     959
>          tx bytes:       152
>          tx packets:     3
>          tx retries:     0
>          tx failed:      0
>          signal:         -27 dBm
>          signal avg:     -26 dBm
>          tx bitrate:     6.0 MBit/s
>          rx bitrate:     9.0 MBit/s
>          mesh llid:      220
>          mesh plid:      455
>          mesh plink:     ESTAB
>          mesh local PS mode:     ACTIVE
>          mesh peer PS mode:      ACTIVE
>          mesh non-peer PS mode:  ACTIVE
>          authorized:     yes
>          authenticated:  yes
>          preamble:       long
>          WMM/WME:        yes
>          MFP:            no
>          TDLS peer:      no
>
> So, progress!
>
> There's still an issue with datapath -- while it looks like we can establish
> plinks, I couldn't get unicast traffic flowing even if manually setting up
> mpaths and arp table entries.  I haven't yet got all of my 5 ghz capable gear
> in the same room to monitor and see where the problem lies.
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From g.martino at gmx.com  Sun Apr 26 17:21:38 2015
From: g.martino at gmx.com (Gabriele Martino)
Date: Mon, 27 Apr 2015 02:21:38 +0200
Subject: QCA6174 hw2.1?
In-Reply-To: <553CF1EE.50807@gmx.com>
References: <trinity-d51578c9-4e28-4805-b58e-fdd5388949da-1426217948333@msvc-mesg-gmx002>
 <CA+BoTQnGQC9sy_Qhiv4peeRsF2dY+2yd12GTgJpyRhrgMTg+Yw@mail.gmail.com>
 <trinity-2097dd2e-b8b3-40c5-9eed-c0dc7d8690af-1426260485155@3capp-mailcom-lxa11>
 <CA+BoTQnKJE0w0SZrh-p2KaKe62t4=cRLnjeKu+t9aeE+LFce-w@mail.gmail.com>
 <loom.20150425T025815-684@post.gmane.org>
 <CAJAVYN208PQpnt5oQPi1hdYW71WMVJReBNSY-OqZ9aCb0yuiaA@mail.gmail.com>
 <553B8F89.4040908@gmx.com>
 <CAJAVYN1XKYdGqx4pzg3C9kSxj6_qwr4raoDJm7e+VLy1P=dsdw@mail.gmail.com>
 <553CF1EE.50807@gmx.com>
Message-ID: <553D8112.2050300@gmx.com>

Just tried the kvalo's kernel.
NetworkManager connected flawlessly at boot to my WPA2 home network on
2.4GHz. Will try 5GHz later.
iwconfig reports a fixed 1Mb/s bitrate, but I can copy files to my nas
(smb share) at about 3.3MB/s.
That's a reasonable speed for b/g wireless.

iwconfig:
wlp3s0    IEEE 802.11abgn  ESSID:"W-I-SEE-YOU-N" 
          Mode:Managed  Frequency:2.412 GHz  Access Point:
40:16:7E:2C:79:90  
          Bit Rate=1 Mb/s   Tx-Power=20 dBm  
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          Link Quality=59/70  Signal level=-51 dBm 
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:42   Missed beacon:0

iwlist scan (part of):
wlp3s0    Scan completed :
          Cell 01 - Address: 40:16:7E:2C:79:90
                    Channel:1
                    Frequency:2.412 GHz (Channel 1)
                    Quality=60/70  Signal level=-50 dBm 
                    Encryption key:on
                    ESSID:"W-I-SEE-YOU-N"
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s
                    Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s
                    Mode:Master
                    Extra:tsf=00000005244f5a5d
                    Extra: Last beacon: 33ms ago
                    IE: Unknown: 000D572D492D5345452D594F552D4E
                    IE: Unknown: 010882848B962430486C
                    IE: Unknown: 030101
                    IE: Unknown: 2A0104
                    IE: Unknown: 2F0104
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : CCMP
                        Pairwise Ciphers (1) : CCMP
                        Authentication Suites (1) : PSK

dmesg output:
[    2.212106] ath10k_pci 0000:03:00.0: enabling device (0000 -> 0002)
[    2.212558] ath10k_pci 0000:03:00.0: pci irq msi-x interrupts 8
irq_mode 0 reset_mode 0
[    2.368318] ath10k_pci 0000:03:00.0: Direct firmware load for
ath10k/cal-pci-0000:03:00.0.bin failed with error -2
[    2.368971] ath10k_pci 0000:03:00.0: Direct firmware load for
ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2
[    2.368974] ath10k_pci 0000:03:00.0: failed to load spec board file,
falling back to generic: -2
[    2.369252] ath10k_pci 0000:03:00.0: Direct firmware load for
ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2
[    2.369270] ath10k_pci 0000:03:00.0: could not fetch firmware file
'ath10k/QCA6174/hw2.1/firmware-5.bin': -2
[    3.559021] ath10k_pci 0000:03:00.0: qca6174 hw2.1 (0x05010000,
0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt
3.0 wmi 4 cal otp max_sta 32
[    3.559024] ath10k_pci 0000:03:00.0: debug 1 debugfs 0 tracing 0 dfs
0 testmode 0
[    3.623733] ath: EEPROM regdomain: 0x6c
[    3.623735] ath: EEPROM indicates we should expect a direct regpair map
[    3.623736] ath: Country alpha2 being used: 00
[    3.623737] ath: Regpair used: 0x6c
[    3.638102] ath10k_pci 0000:03:00.0 wlp3s0: renamed from wlan0
[    7.523617] ath10k_pci 0000:03:00.0: no channel configured; ignoring
frame(s)!
[    7.627173] ath10k_pci 0000:03:00.0: no channel configured; ignoring
frame(s)!
[   12.149947] wlp3s0: authenticate with 40:16:7e:2c:79:90
[   12.183915] wlp3s0: send auth to 40:16:7e:2c:79:90 (try 1/3)
[   12.185559] wlp3s0: authenticated
[   12.186043] wlp3s0: associate with 40:16:7e:2c:79:90 (try 1/3)
[   12.189402] wlp3s0: RX AssocResp from 40:16:7e:2c:79:90 (capab=0x411
status=0 aid=3)
[   12.192174] wlp3s0: associated
[  313.912952] wlp3s0: AP 40:16:7e:2c:79:90 changed bandwidth, new
config is 2412 MHz, width 1 (2412/0 MHz)
[  313.912955] wlp3s0: AP 40:16:7e:2c:79:90 changed bandwidth in a way
we can't support - disconnect
[  318.709453] wlp3s0: authenticate with 40:16:7e:2c:79:90
[  318.750807] wlp3s0: send auth to 40:16:7e:2c:79:90 (try 1/3)
[  318.752541] wlp3s0: authenticated
[  318.753030] wlp3s0: associate with 40:16:7e:2c:79:90 (try 1/3)
[  318.756524] wlp3s0: RX AssocResp from 40:16:7e:2c:79:90 (capab=0x411
status=0 aid=1)
[  318.759082] wlp3s0: associated

I'm using the board file "eeprom_qca9377_1p0_NFA435_olpc.bin".

Regards,
Gabriele


On 26/04/2015 16:10, Gabriele Martino wrote:
> Hi Corin,
> the "dissect.py" script seems to work better than the "disassemble.py":
>
> [ 6483.455435] ath10k_pci 0000:03:00.0: pci irq msi-x interrupts 8
> irq_mode 0 reset_mode 0
> [ 6483.600747] ath10k_pci 0000:03:00.0: Direct firmware load for
> ath10k/cal-pci-0000:03:00.0.bin failed with error -2
> [ 6484.772417] ath10k_pci 0000:03:00.0: firmware crashed! (uuid n/a)
> [ 6484.772433] ath10k_pci 0000:03:00.0: qca6174 hw2.1 (0x05010000,
> 0x003405ff) fw killer-n1525-fw api 4 htt 0.0 wmi 4 cal otp max_sta 32
> [ 6484.772435] ath10k_pci 0000:03:00.0: debug 1 debugfs 0 tracing 0 dfs
> 0 testmode 0
> [ 6484.773333] ath10k_pci 0000:03:00.0: firmware register dump:
> [ 6484.773333] ath10k_pci 0000:03:00.0: [00]: 0x05010000 0x000015B3
> 0x0095186B 0x00955B31
> [ 6484.773333] ath10k_pci 0000:03:00.0: [04]: 0x0095186B 0x00060130
> 0x00000010 0x0040AF04
> [ 6484.773333] ath10k_pci 0000:03:00.0: [08]: 0x00000018 0x00000001
> 0x00000001 0x00412250
> [ 6484.773333] ath10k_pci 0000:03:00.0: [12]: 0x00000009 0x00000000
> 0x0096C09C 0x0096C0A7
> [ 6484.773333] ath10k_pci 0000:03:00.0: [16]: 0x0096BDBC 0x009286B6
> 0x00000000 0x00000000
> [ 6484.773333] ath10k_pci 0000:03:00.0: [20]: 0x4095186B 0x0040E160
> 0x0041F82C 0x00000001
> [ 6484.773333] ath10k_pci 0000:03:00.0: [24]: 0x80936238 0x0040E1C0
> 0x00000000 0xC095186B
> [ 6484.773333] ath10k_pci 0000:03:00.0: [28]: 0x80936361 0x0040E1E0
> 0x00000000 0x0041C8DC
> [ 6484.773333] ath10k_pci 0000:03:00.0: [32]: 0x80934A67 0x0040E200
> 0x00436DF0 0x0040E250
> [ 6484.773333] ath10k_pci 0000:03:00.0: [36]: 0x809A5C92 0x0040E250
> 0x004275B0 0x00000001
> [ 6484.773333] ath10k_pci 0000:03:00.0: [40]: 0x809A5CEA 0x0040E290
> 0x00426F40 0x00000004
> [ 6484.773333] ath10k_pci 0000:03:00.0: [44]: 0x809A5DCA 0x0040E2B0
> 0x00426F40 0x0041C8DC
> [ 6484.773333] ath10k_pci 0000:03:00.0: [48]: 0x800A0909 0x0040E2D0
> 0x00426F40 0x004275A0
> [ 6484.773333] ath10k_pci 0000:03:00.0: [52]: 0x800A024A 0x0040E2F0
> 0x0041ABB0 0x00420440
> [ 6484.773333] ath10k_pci 0000:03:00.0: [56]: 0x809287D9 0x0040E310
> 0x00000000 0x00400000
> [ 6485.765040] ath10k_pci 0000:03:00.0: failed to receive control
> response completion, polling..
> [ 6486.765027] ath10k_pci 0000:03:00.0: ctl_resp never came in (-110)
> [ 6486.765032] ath10k_pci 0000:03:00.0: failed to connect to HTC: -110
> [ 6486.828658] ath10k_pci 0000:03:00.0: could not init core (-110)
> [ 6486.828689] ath10k_pci 0000:03:00.0: could not probe fw (-110)
> [ 6486.831175] ath10k_pci 0000:03:00.0: cannot restart a device that
> hasn't been started
>
> Well, at least it loads correctly. This should be the firmware crash
> fixed in the patches, it's time to test kvalo's kernel sources.
>
>
> On 26/04/2015 05:51, Corin Lawson wrote:
>> Hi Gabriele,
>>
>> I think we have the same card (the vendor and device ids are the
>> determining factor):
>>
>>     $ lspci -n -s 05:00.0
>>     05:00.0 0280: 168c:003e (rev 20)
>>
>> Without the skip_otp option I get this in dmesg:
>>
>>     [18396.622576] ath10k_pci 0000:05:00.0: pci irq msi interrupts 1
>> irq_mode 0 reset_mode 0
>>     [18396.768593] ath10k_pci 0000:05:00.0: Direct firmware load for
>> ath10k/cal-pci-0000:05:00.0.bin failed with error -2
>>     [18396.847975] ath10k_pci 0000:05:00.0: otp calibration failed: 3
>>     [18396.847977] ath10k_pci 0000:05:00.0: failed to run otp: -22
>>     [18396.847978] ath10k_pci 0000:05:00.0: could not init core (-22)
>>     [18396.847995] ath10k_pci 0000:05:00.0: could not probe fw (-22)
>>
>> Which is different to your messages. I'm taking a guess here, but
>> those DMAR messages seem to indicate that the firmware is attempting
>> to write to the wrong part of memory (i.e. wrong firmware).
>>
>> Using kvalo's kernel fork is probably a good step (it contains those
>> necessary patches). If you still don't get it working, then my only
>> other idea is to try that dissect.py gist I mentioned previously. Here
>> are the commands that worked for me:
>>
>>     # python dissect.py <
>> drivers/Production/Windows8.1-x64/k1525w81/qca61x420.bin
>>     # python assemble.py killer-n1525-fw 0 fw-2.bin fw-1.bin 4 >
>> /lib/firmware/ath10k/QCA6174/hw2.1/firmware-4.bin
>>
>> The dissect.py script produced fw-1.bin which is the otp file and
>> fw-2.bin which is the correct firmware (don't quote me on that, but it
>> worked for me). As for your board.bin file, you need to check the .inf
>> file that comes with your drivers. I'm not sure what the structure of
>> that file is... for all I know I could be using the wrong board
>> file...
>>
>> I hope this helps, otherwise you've reached the limits of my
>> experience :) Maybe someone else on the list has a better idea?
>>
>> Cheers,
>> Corin
>>
>>
>> On Sat, Apr 25, 2015 at 10:58 PM, Gabriele Martino <g.martino at gmx.com> wrote:
>>> On 25/04/2015 05:47, Corin Lawson wrote:
>>>> I also had problems with calibration, I had to pass skip_otp=y to the module:
>>>>
>>>>     $ cat /etc/modprobe.d/ath10k.conf
>>>>     options ath10k_core skip_otp=y
>>> Hi Corin,
>>> I removed ath10k_pci, ath10k_core and ath before loading ath10k_core
>>> with skip_otp=1, but nothing happened:
>>>
>>> [ 1808.473874] ath10k_pci 0000:03:00.0: pci irq msi-x interrupts 8
>>> irq_mode 0 reset_mode 0
>>> [ 1808.618770] ath10k_pci 0000:03:00.0: Direct firmware load for
>>> ath10k/cal-pci-0000:03:00.0.bin failed with error -2
>>> [ 1808.687492] dmar: DRHD: handling fault status reg 2
>>> [ 1808.687506] dmar: DMAR:[DMA Write] Request device [03:00.0] fault
>>> addr 7ee00000
>>>                DMAR:[fault reason 05] PTE Write access is not set
>>> [ 1809.688015] ath10k_pci 0000:03:00.0: unable to write to the device
>>> [ 1809.688018] ath10k_pci 0000:03:00.0: failed to download normal
>>> firmware: -110
>>> [ 1809.688020] ath10k_pci 0000:03:00.0: could not init core (-110)
>>> [ 1809.688054] ath10k_pci 0000:03:00.0: could not probe fw (-110)
>>>
>>> I assembled the otp.bin with fw.bin to get the blob, so I'm not sure
>>> skip_otp will fix this...
>>> Now I'm cloning the kvalo's kernel tree, this should be faster than
>>> picking the single patches.
>>>
>>>> FWIW:
>>>>
>>>>     $ lspci -vs 05:00.0
>>>>     05:00.0 Network controller: Qualcomm Atheros Device 003e (rev 20)
>>>>             Subsystem: Bigfoot Networks, Inc. Device 1525
>>>>             Flags: bus master, fast devsel, latency 0, IRQ 31
>>>>             Memory at f7800000 (64-bit, non-prefetchable) [size=2M]
>>>>             Capabilities: <access denied>
>>>>             Kernel driver in use: ath10k_pci
>>>>             Kernel modules: ath10k_pci
>>> Well, mine seems a bit different:
>>>
>>> 03:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless
>>> Network Adapter (rev 20)
>>>         Subsystem: Bigfoot Networks, Inc. Killer N1525 Wireless-AC
>>>         Flags: bus master, fast devsel, latency 0, IRQ 32
>>>         Memory at f6800000 (64-bit, non-prefetchable) [size=2M]
>>>         Capabilities: [40] Power Management version 3
>>>         Capabilities: [50] MSI: Enable+ Count=8/8 Maskable+ 64bit-
>>>         Capabilities: [70] Express Endpoint, MSI 00
>>>         Capabilities: [100] Advanced Error Reporting
>>>         Capabilities: [148] Virtual Channel
>>>         Capabilities: [168] Device Serial Number 00-00-00-00-00-00-00-00
>>>         Capabilities: [178] Latency Tolerance Reporting
>>>         Capabilities: [180] L1 PM Substates
>>>         Kernel driver in use: ath10k_pci
>>>         Kernel modules: ath10k_pci
>>>
>>>> I would interested in knowing from where you got your drivers/board
>>>> files. I had to download mine from my laptop manufacturer's (MSI)
>>>> website.
>>> I mounted the preinstalled Windows 8 partition on /mnt and run:
>>> find /mnt -iname '*.bin'
>>>
>>> The same files can be found inside the driver installer on the Alienware
>>> (Dell) website.
>>>
>>> Regards,
>>> Gabriele
>>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k

-- 

*Gabriele Martino*

Linux Sysadmin & Web Development

g.martino at gmx.com




From michal.kazior at tieto.com  Sun Apr 26 22:26:07 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 27 Apr 2015 07:26:07 +0200
Subject: Ath10 Firmware
In-Reply-To: <1f50fb125dfb4dc883c338ddf2582444@BGHMBXV02.AD.ARICENT.COM>
References: <1f50fb125dfb4dc883c338ddf2582444@BGHMBXV02.AD.ARICENT.COM>
Message-ID: <CA+BoTQ=pemhq4jBDCpodYhBgs6xAZZLeU0qohUraKPAKmzf8pA@mail.gmail.com>

On 25 April 2015 at 11:14, Sunder Kumaresan
<sunder.kumaresan at aricent.com> wrote:
>
> Hi,
>
> Will Ath10 firmware work for  big endian processor ?   is it endian agnostic ? It works for little endian processor.

You probably mean ath10k driver - not firmware. Firmware is run on the
device chip itself and you can't really change that in any way.

As far as the driver goes it is endian agnostic - some routers
supported by OpenWRT have big-endian MIPS CPUs and ath10k works there
just fine.


Micha?


From michal.kazior at tieto.com  Sun Apr 26 22:34:27 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 27 Apr 2015 07:34:27 +0200
Subject: First QCA6174 firmware release
In-Reply-To: <loom.20150425T202151-34@post.gmane.org>
References: <54DB5CD8.80302@dreyero.de>
 <loom.20150425T202151-34@post.gmane.org>
Message-ID: <CA+BoTQm5Z4QWkouK_D54y8zmz7F3XTCn3j8cFiKhj0K6xKA=tQ@mail.gmail.com>

On 25 April 2015 at 20:22, Oscar Rydberg <oscarrydberg at gmail.com> wrote:
> Olaf Dreyer <olaf <at> dreyero.de> writes:
>
>>
>> I have a new Acer Aspire VN7-591 Laptop with a Qualcom Atheros
> QCNF344
>> wireless chip, which is shown by lspci as:
>>
>> Qualcomm Atheros Device 003e (rev 20)
>> Subsystem: Foxconn International, Inc. Device e08e
>>
>> I have installed the linux-next kernel from today 8:00 UTC.
>> I was able to load the ath10k_pci driver, but the driver complains
> about
>> missing firmware.
>> I installed a firmware from here: https://github.com/kvalo/ath10k-
> firmware
>> under /lib/firmware/ath10k/QCA6174/hw2.1/
>> But also the card is not working.
>>
>> The output from dmesg is:
>> [ 9360.538767] ath10k_pci 0000:07:00.0: pci irq msi interrupts 1
>> irq_mode 0 reset_mode 0
>> [ 9360.788588] ath10k_pci 0000:07:00.0: Direct firmware load for
>> ath10k/cal-pci-0000:07:00.0.bin failed with error -2
>> [ 9362.729118] ath10k_pci 0000:07:00.0: unable to write to the
> device
>> [ 9362.729120] ath10k_pci 0000:07:00.0: failed to download normal
>> firmware: -110
>> [ 9362.729121] ath10k_pci 0000:07:00.0: could not init core (-110)
>> [ 9362.729156] ath10k_pci 0000:07:00.0: could not probe fw (-110)
>>
>> I would like to know, as Austin Hendrix wrote it at 8 Feb 14:12
> 2015
>> too, where can I find the firmware on the
>> internet / my Windows7 partition and how can I prepare the needed
> files.
>>
>> Many thanks,
>>
>> Olaf
>>
>
> Hi did you advance anything on this?
>
> Trying to run a QCA6164 card myself on a Lenovo 3-14 laptop.
> Sems I've gotten as far as you.
> Prepared Ath10k hw2.1 board.bin and firmware-4.bin for hw2.1 using
> windows binary driver. (And assemble.py, disassemble.py tools linked
> elsewhere)
>
> Board.bin seems to load and execute fine. But after that when
> loading firmware-4.bin, it ends up with Unable to write to the
> device.
>
> I see it starts sending firmware-4.bin and first 256 bytes ce_send
> fine.
> 2nd ce_send 256 bytes seem to also ce_send fine, however after that
> bmi_wait times out. (-110)

You're most likely trying to push something that isn't an actual
firmware blob to the device. You might be interested in the other
thread: http://lists.infradead.org/pipermail/ath10k/2015-April/005072.html


Micha?


From venkatch at gmail.com  Sun Apr 26 22:48:39 2015
From: venkatch at gmail.com (Venkat Ch)
Date: Mon, 27 Apr 2015 11:18:39 +0530
Subject: Tips to debug Firmware crash
Message-ID: <CABHL29Hq8e+sgyfqtN-EbEpM1cC9XF_bO3F_rj68Piq-kKg4=w@mail.gmail.com>

Hi All,

  I am an active developer of Atheros drivers for the last 10 years. I
have been working on QCA 10.2.2 driver for the last few months and
trying to understand the architecture of this offloading model. Though
this forum is nothing to do with Atheros provided drivers, I took the
liberty of posting the question to see if Ath10k community could help
me. Sorry if I violated any guidelines.

There is some problem at firmware level about which I am clueless.
Whenever there is a crash in firmware the 5GHz interface goes down
completely and there will not be any transmissions or receptions from
the interface from then. What all I see on the console is  some log
message "Target Asserted" . I don't get any stack trace to see in
which function it crashed.

 Can any of you please let me know if there is a way to dump the stack
trace and debug the firmware crash?


Thanks & Regards
Venkat


-- 
If you rest, you rust


From kvalo at qca.qualcomm.com  Mon Apr 27 01:50:47 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Mon, 27 Apr 2015 11:50:47 +0300
Subject: [PATCH] ath10k: implement more versatile set_bitrate_mask
In-Reply-To: <1428672772-9275-1-git-send-email-michal.kazior@tieto.com>
 (Michal Kazior's message of "Fri, 10 Apr 2015 13:32:52 +0000")
References: <1428672772-9275-1-git-send-email-michal.kazior@tieto.com>
Message-ID: <878udeq7iw.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> Until now only a single fixed tx rate or nss was
> allowed to be set.
>
> The patch attempts to improve this by allowing
> most bitrate masks. The limitation is VHT MCS
> rates cannot be expressed separately using
> existing firmware interfaces and only the
> following VHT MCS ranges are supported: none, 0-7,
> 0-8, and 0-9.
>
> This keeps the old behaviour when requesting
> single tx rate or single nss. The new bitrate mask
> logic is only applied to other cases that would
> return -EINVAL until now.
>
> Depending on firmware revisions some combinations
> may crash firmware so use with care, please.
>
> This depends on "ath10k: don't use reassoc flag".
> Without it key cache would effectively be
> invalidated upon bitrate change leading to
> communication being no longer possible.
>
> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>

Thanks, applied.

-- 
Kalle Valo


From michal.kazior at tieto.com  Mon Apr 27 04:03:11 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 27 Apr 2015 13:03:11 +0200
Subject: Modifing and installing ath10k driver for kernel 4.0
In-Reply-To: <BB63CF2605733841BD56CD9C38AC1F7E1E678CA8@MBX23.d.ethz.ch>
References: <BB63CF2605733841BD56CD9C38AC1F7E1E678CA8@MBX23.d.ethz.ch>
Message-ID: <CA+BoTQmGCnAepE0OWEiO1ASrLEbsmrKqf2zS-s2WpAbkhX4vaw@mail.gmail.com>

On 23 April 2015 at 17:16, Costa Molero  Edgar <cedgar at student.ethz.ch> wrote:
> Hi all,
>
> In order to use the latest firmware version (10.2.4.48) for my access point  I installed the kernel version 4.0 in my Ubuntu 14.04 LTS laptop.
>
> The problem is that with the ath10k driver it comes the option debug is not enabled, and my domain regulatory database do not allow me to use 80Mhz channels.
>
> Before upgrading the kernel, I was using the latest backports release 3.19-r1-1-1. To install that driver I downloaded it then I enabled all the configuration options I needed for my project (debug, debugfs, etc) and I also modified the regulatory database by changing the content of the file /net/wireless/db.txt.
>
> I never compiled a linux kernel. And therefore I don't quite understand what should I do know to modify the current driver version. (I just want to change the db.txt file and enable debug) Then I want to compile the driver and install it. Could some one give me some hints ?
>
> Should not the driver source code be located at that  directory ? /usr/src/linux-headers-4.0.0-040000-generic/drivers/net/wireless/ath/ath10k# , and also the db.txt located here :/usr/src/linux-headers-4.0.0-040000-generic/net/wireless# .

This directory, as the path name implies, contains just kernel
headers. These are generally used whfor compiling DKMS (additional
out-of-tree modules, e.g. nvidia gpu blob).

If you want to compile an entire kernel I suggest you look into your
distro wiki. All distros have different ways of doing things if you
want to keep your installation clean.

You can still use backports though. All you need is to build backports
package yourself[1] from whatever kernel tree you desire, e.g.
github.com/kvalo/ath instead of using the pre-built one.

[1]: https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking


Micha?


From me at bobcopeland.com  Mon Apr 27 06:00:16 2015
From: me at bobcopeland.com (Bob Copeland)
Date: Mon, 27 Apr 2015 09:00:16 -0400
Subject: attempting mesh on ath10k
In-Reply-To: <20150426141552.GA25938@localhost>
References: <20150424125055.GA27722@localhost>
 <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>
 <553AEFFA.6010709@candelatech.com>
 <20150426141552.GA25938@localhost>
Message-ID: <20150427130016.GA28926@localhost>

On Sun, Apr 26, 2015 at 10:15:52AM -0400, Bob Copeland wrote:
> So, progress!
> 
> There's still an issue with datapath -- while it looks like we can establish
> plinks, I couldn't get unicast traffic flowing even if manually setting up
> mpaths and arp table entries.  I haven't yet got all of my 5 ghz capable gear
> in the same room to monitor and see where the problem lies.

Now I had a chance to monitor it, and in so doing, rediscovered this patch of
Chun-Yeow's:

http://lists.infradead.org/pipermail/ath10k/2014-September/003206.html

In fact my broadcasts were truncated and the above change makes the broadcast
ARPs look correct over the air.  The (non-ath10k) target mesh STA replies with
broadcast PREQ but that is not received / processed / replied-to by the
ath10k device.

Perhaps there is a BSSID filter enabled or something like that (in mesh
there's no BSSID, just individual addresses on group addressed frames).

-- 
Bob Copeland %% http://bobcopeland.com/


From moritz.morawietz at informatik.uni-oldenburg.de  Mon Apr 27 07:00:14 2015
From: moritz.morawietz at informatik.uni-oldenburg.de (Moritz Morawietz)
Date: Mon, 27 Apr 2015 16:00:14 +0200
Subject: QCA6174 hw2.1?
In-Reply-To: <553D8112.2050300@gmx.com>
References: <trinity-d51578c9-4e28-4805-b58e-fdd5388949da-1426217948333@msvc-mesg-gmx002>
 <CA+BoTQnGQC9sy_Qhiv4peeRsF2dY+2yd12GTgJpyRhrgMTg+Yw@mail.gmail.com>
 <trinity-2097dd2e-b8b3-40c5-9eed-c0dc7d8690af-1426260485155@3capp-mailcom-lxa11>
 <CA+BoTQnKJE0w0SZrh-p2KaKe62t4=cRLnjeKu+t9aeE+LFce-w@mail.gmail.com>
 <loom.20150425T025815-684@post.gmane.org>
 <CAJAVYN208PQpnt5oQPi1hdYW71WMVJReBNSY-OqZ9aCb0yuiaA@mail.gmail.com>
 <553B8F89.4040908@gmx.com>
 <CAJAVYN1XKYdGqx4pzg3C9kSxj6_qwr4raoDJm7e+VLy1P=dsdw@mail.gmail.com>
 <553CF1EE.50807@gmx.com> <553D8112.2050300@gmx.com>
Message-ID: <CA+-y_t-L5tAYRfT5+WzbB_EvZbWDO3hys9GD8Ms7fFhT_9cy_Q@mail.gmail.com>

Hi!

I have the same problems with my card (also a Killer N1525). It seems
you've done it, but i can't figure out how.

Do i need to build and use kvalo's kernel, or is it enough to build
the modules ath10k_core & ath10k_pci?
I'm a bit afraid of compiling the whole kernel ^^
output of uname -a:
Linux companion 4.0.0-2-ARCH #1 SMP PREEMPT Tue Apr 14 07:14:46 CEST
2015 x86_64 GNU/Linux

I have the disassembly.py, but cannot find the dissect.py, can you
provide the link? Or, even better, the assembled files?


Many thanks for help!

Moritz

2015-04-27 2:21 GMT+02:00 Gabriele Martino <g.martino at gmx.com>:
> Just tried the kvalo's kernel.
> NetworkManager connected flawlessly at boot to my WPA2 home network on
> 2.4GHz. Will try 5GHz later.
> iwconfig reports a fixed 1Mb/s bitrate, but I can copy files to my nas
> (smb share) at about 3.3MB/s.
> That's a reasonable speed for b/g wireless.
>
> iwconfig:
> wlp3s0    IEEE 802.11abgn  ESSID:"W-I-SEE-YOU-N"
>           Mode:Managed  Frequency:2.412 GHz  Access Point:
> 40:16:7E:2C:79:90
>           Bit Rate=1 Mb/s   Tx-Power=20 dBm
>           Retry short limit:7   RTS thr:off   Fragment thr:off
>           Encryption key:off
>           Power Management:on
>           Link Quality=59/70  Signal level=-51 dBm
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:0  Invalid misc:42   Missed beacon:0
>
> iwlist scan (part of):
> wlp3s0    Scan completed :
>           Cell 01 - Address: 40:16:7E:2C:79:90
>                     Channel:1
>                     Frequency:2.412 GHz (Channel 1)
>                     Quality=60/70  Signal level=-50 dBm
>                     Encryption key:on
>                     ESSID:"W-I-SEE-YOU-N"
>                     Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
>                               24 Mb/s; 36 Mb/s; 54 Mb/s
>                     Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s
>                     Mode:Master
>                     Extra:tsf=00000005244f5a5d
>                     Extra: Last beacon: 33ms ago
>                     IE: Unknown: 000D572D492D5345452D594F552D4E
>                     IE: Unknown: 010882848B962430486C
>                     IE: Unknown: 030101
>                     IE: Unknown: 2A0104
>                     IE: Unknown: 2F0104
>                     IE: IEEE 802.11i/WPA2 Version 1
>                         Group Cipher : CCMP
>                         Pairwise Ciphers (1) : CCMP
>                         Authentication Suites (1) : PSK
>
> dmesg output:
> [    2.212106] ath10k_pci 0000:03:00.0: enabling device (0000 -> 0002)
> [    2.212558] ath10k_pci 0000:03:00.0: pci irq msi-x interrupts 8
> irq_mode 0 reset_mode 0
> [    2.368318] ath10k_pci 0000:03:00.0: Direct firmware load for
> ath10k/cal-pci-0000:03:00.0.bin failed with error -2
> [    2.368971] ath10k_pci 0000:03:00.0: Direct firmware load for
> ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2
> [    2.368974] ath10k_pci 0000:03:00.0: failed to load spec board file,
> falling back to generic: -2
> [    2.369252] ath10k_pci 0000:03:00.0: Direct firmware load for
> ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2
> [    2.369270] ath10k_pci 0000:03:00.0: could not fetch firmware file
> 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2
> [    3.559021] ath10k_pci 0000:03:00.0: qca6174 hw2.1 (0x05010000,
> 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt
> 3.0 wmi 4 cal otp max_sta 32
> [    3.559024] ath10k_pci 0000:03:00.0: debug 1 debugfs 0 tracing 0 dfs
> 0 testmode 0
> [    3.623733] ath: EEPROM regdomain: 0x6c
> [    3.623735] ath: EEPROM indicates we should expect a direct regpair map
> [    3.623736] ath: Country alpha2 being used: 00
> [    3.623737] ath: Regpair used: 0x6c
> [    3.638102] ath10k_pci 0000:03:00.0 wlp3s0: renamed from wlan0
> [    7.523617] ath10k_pci 0000:03:00.0: no channel configured; ignoring
> frame(s)!
> [    7.627173] ath10k_pci 0000:03:00.0: no channel configured; ignoring
> frame(s)!
> [   12.149947] wlp3s0: authenticate with 40:16:7e:2c:79:90
> [   12.183915] wlp3s0: send auth to 40:16:7e:2c:79:90 (try 1/3)
> [   12.185559] wlp3s0: authenticated
> [   12.186043] wlp3s0: associate with 40:16:7e:2c:79:90 (try 1/3)
> [   12.189402] wlp3s0: RX AssocResp from 40:16:7e:2c:79:90 (capab=0x411
> status=0 aid=3)
> [   12.192174] wlp3s0: associated
> [  313.912952] wlp3s0: AP 40:16:7e:2c:79:90 changed bandwidth, new
> config is 2412 MHz, width 1 (2412/0 MHz)
> [  313.912955] wlp3s0: AP 40:16:7e:2c:79:90 changed bandwidth in a way
> we can't support - disconnect
> [  318.709453] wlp3s0: authenticate with 40:16:7e:2c:79:90
> [  318.750807] wlp3s0: send auth to 40:16:7e:2c:79:90 (try 1/3)
> [  318.752541] wlp3s0: authenticated
> [  318.753030] wlp3s0: associate with 40:16:7e:2c:79:90 (try 1/3)
> [  318.756524] wlp3s0: RX AssocResp from 40:16:7e:2c:79:90 (capab=0x411
> status=0 aid=1)
> [  318.759082] wlp3s0: associated
>
> I'm using the board file "eeprom_qca9377_1p0_NFA435_olpc.bin".
>
> Regards,
> Gabriele
>
>
> On 26/04/2015 16:10, Gabriele Martino wrote:
>> Hi Corin,
>> the "dissect.py" script seems to work better than the "disassemble.py":
>>
>> [ 6483.455435] ath10k_pci 0000:03:00.0: pci irq msi-x interrupts 8
>> irq_mode 0 reset_mode 0
>> [ 6483.600747] ath10k_pci 0000:03:00.0: Direct firmware load for
>> ath10k/cal-pci-0000:03:00.0.bin failed with error -2
>> [ 6484.772417] ath10k_pci 0000:03:00.0: firmware crashed! (uuid n/a)
>> [ 6484.772433] ath10k_pci 0000:03:00.0: qca6174 hw2.1 (0x05010000,
>> 0x003405ff) fw killer-n1525-fw api 4 htt 0.0 wmi 4 cal otp max_sta 32
>> [ 6484.772435] ath10k_pci 0000:03:00.0: debug 1 debugfs 0 tracing 0 dfs
>> 0 testmode 0
>> [ 6484.773333] ath10k_pci 0000:03:00.0: firmware register dump:
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [00]: 0x05010000 0x000015B3
>> 0x0095186B 0x00955B31
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [04]: 0x0095186B 0x00060130
>> 0x00000010 0x0040AF04
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [08]: 0x00000018 0x00000001
>> 0x00000001 0x00412250
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [12]: 0x00000009 0x00000000
>> 0x0096C09C 0x0096C0A7
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [16]: 0x0096BDBC 0x009286B6
>> 0x00000000 0x00000000
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [20]: 0x4095186B 0x0040E160
>> 0x0041F82C 0x00000001
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [24]: 0x80936238 0x0040E1C0
>> 0x00000000 0xC095186B
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [28]: 0x80936361 0x0040E1E0
>> 0x00000000 0x0041C8DC
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [32]: 0x80934A67 0x0040E200
>> 0x00436DF0 0x0040E250
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [36]: 0x809A5C92 0x0040E250
>> 0x004275B0 0x00000001
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [40]: 0x809A5CEA 0x0040E290
>> 0x00426F40 0x00000004
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [44]: 0x809A5DCA 0x0040E2B0
>> 0x00426F40 0x0041C8DC
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [48]: 0x800A0909 0x0040E2D0
>> 0x00426F40 0x004275A0
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [52]: 0x800A024A 0x0040E2F0
>> 0x0041ABB0 0x00420440
>> [ 6484.773333] ath10k_pci 0000:03:00.0: [56]: 0x809287D9 0x0040E310
>> 0x00000000 0x00400000
>> [ 6485.765040] ath10k_pci 0000:03:00.0: failed to receive control
>> response completion, polling..
>> [ 6486.765027] ath10k_pci 0000:03:00.0: ctl_resp never came in (-110)
>> [ 6486.765032] ath10k_pci 0000:03:00.0: failed to connect to HTC: -110
>> [ 6486.828658] ath10k_pci 0000:03:00.0: could not init core (-110)
>> [ 6486.828689] ath10k_pci 0000:03:00.0: could not probe fw (-110)
>> [ 6486.831175] ath10k_pci 0000:03:00.0: cannot restart a device that
>> hasn't been started
>>
>> Well, at least it loads correctly. This should be the firmware crash
>> fixed in the patches, it's time to test kvalo's kernel sources.
>>
>>
>> On 26/04/2015 05:51, Corin Lawson wrote:
>>> Hi Gabriele,
>>>
>>> I think we have the same card (the vendor and device ids are the
>>> determining factor):
>>>
>>>     $ lspci -n -s 05:00.0
>>>     05:00.0 0280: 168c:003e (rev 20)
>>>
>>> Without the skip_otp option I get this in dmesg:
>>>
>>>     [18396.622576] ath10k_pci 0000:05:00.0: pci irq msi interrupts 1
>>> irq_mode 0 reset_mode 0
>>>     [18396.768593] ath10k_pci 0000:05:00.0: Direct firmware load for
>>> ath10k/cal-pci-0000:05:00.0.bin failed with error -2
>>>     [18396.847975] ath10k_pci 0000:05:00.0: otp calibration failed: 3
>>>     [18396.847977] ath10k_pci 0000:05:00.0: failed to run otp: -22
>>>     [18396.847978] ath10k_pci 0000:05:00.0: could not init core (-22)
>>>     [18396.847995] ath10k_pci 0000:05:00.0: could not probe fw (-22)
>>>
>>> Which is different to your messages. I'm taking a guess here, but
>>> those DMAR messages seem to indicate that the firmware is attempting
>>> to write to the wrong part of memory (i.e. wrong firmware).
>>>
>>> Using kvalo's kernel fork is probably a good step (it contains those
>>> necessary patches). If you still don't get it working, then my only
>>> other idea is to try that dissect.py gist I mentioned previously. Here
>>> are the commands that worked for me:
>>>
>>>     # python dissect.py <
>>> drivers/Production/Windows8.1-x64/k1525w81/qca61x420.bin
>>>     # python assemble.py killer-n1525-fw 0 fw-2.bin fw-1.bin 4 >
>>> /lib/firmware/ath10k/QCA6174/hw2.1/firmware-4.bin
>>>
>>> The dissect.py script produced fw-1.bin which is the otp file and
>>> fw-2.bin which is the correct firmware (don't quote me on that, but it
>>> worked for me). As for your board.bin file, you need to check the .inf
>>> file that comes with your drivers. I'm not sure what the structure of
>>> that file is... for all I know I could be using the wrong board
>>> file...
>>>
>>> I hope this helps, otherwise you've reached the limits of my
>>> experience :) Maybe someone else on the list has a better idea?
>>>
>>> Cheers,
>>> Corin
>>>
>>>
>>> On Sat, Apr 25, 2015 at 10:58 PM, Gabriele Martino <g.martino at gmx.com> wrote:
>>>> On 25/04/2015 05:47, Corin Lawson wrote:
>>>>> I also had problems with calibration, I had to pass skip_otp=y to the module:
>>>>>
>>>>>     $ cat /etc/modprobe.d/ath10k.conf
>>>>>     options ath10k_core skip_otp=y
>>>> Hi Corin,
>>>> I removed ath10k_pci, ath10k_core and ath before loading ath10k_core
>>>> with skip_otp=1, but nothing happened:
>>>>
>>>> [ 1808.473874] ath10k_pci 0000:03:00.0: pci irq msi-x interrupts 8
>>>> irq_mode 0 reset_mode 0
>>>> [ 1808.618770] ath10k_pci 0000:03:00.0: Direct firmware load for
>>>> ath10k/cal-pci-0000:03:00.0.bin failed with error -2
>>>> [ 1808.687492] dmar: DRHD: handling fault status reg 2
>>>> [ 1808.687506] dmar: DMAR:[DMA Write] Request device [03:00.0] fault
>>>> addr 7ee00000
>>>>                DMAR:[fault reason 05] PTE Write access is not set
>>>> [ 1809.688015] ath10k_pci 0000:03:00.0: unable to write to the device
>>>> [ 1809.688018] ath10k_pci 0000:03:00.0: failed to download normal
>>>> firmware: -110
>>>> [ 1809.688020] ath10k_pci 0000:03:00.0: could not init core (-110)
>>>> [ 1809.688054] ath10k_pci 0000:03:00.0: could not probe fw (-110)
>>>>
>>>> I assembled the otp.bin with fw.bin to get the blob, so I'm not sure
>>>> skip_otp will fix this...
>>>> Now I'm cloning the kvalo's kernel tree, this should be faster than
>>>> picking the single patches.
>>>>
>>>>> FWIW:
>>>>>
>>>>>     $ lspci -vs 05:00.0
>>>>>     05:00.0 Network controller: Qualcomm Atheros Device 003e (rev 20)
>>>>>             Subsystem: Bigfoot Networks, Inc. Device 1525
>>>>>             Flags: bus master, fast devsel, latency 0, IRQ 31
>>>>>             Memory at f7800000 (64-bit, non-prefetchable) [size=2M]
>>>>>             Capabilities: <access denied>
>>>>>             Kernel driver in use: ath10k_pci
>>>>>             Kernel modules: ath10k_pci
>>>> Well, mine seems a bit different:
>>>>
>>>> 03:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless
>>>> Network Adapter (rev 20)
>>>>         Subsystem: Bigfoot Networks, Inc. Killer N1525 Wireless-AC
>>>>         Flags: bus master, fast devsel, latency 0, IRQ 32
>>>>         Memory at f6800000 (64-bit, non-prefetchable) [size=2M]
>>>>         Capabilities: [40] Power Management version 3
>>>>         Capabilities: [50] MSI: Enable+ Count=8/8 Maskable+ 64bit-
>>>>         Capabilities: [70] Express Endpoint, MSI 00
>>>>         Capabilities: [100] Advanced Error Reporting
>>>>         Capabilities: [148] Virtual Channel
>>>>         Capabilities: [168] Device Serial Number 00-00-00-00-00-00-00-00
>>>>         Capabilities: [178] Latency Tolerance Reporting
>>>>         Capabilities: [180] L1 PM Substates
>>>>         Kernel driver in use: ath10k_pci
>>>>         Kernel modules: ath10k_pci
>>>>
>>>>> I would interested in knowing from where you got your drivers/board
>>>>> files. I had to download mine from my laptop manufacturer's (MSI)
>>>>> website.
>>>> I mounted the preinstalled Windows 8 partition on /mnt and run:
>>>> find /mnt -iname '*.bin'
>>>>
>>>> The same files can be found inside the driver installer on the Alienware
>>>> (Dell) website.
>>>>
>>>> Regards,
>>>> Gabriele
>>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>
> --
>
> *Gabriele Martino*
>
> Linux Sysadmin & Web Development
>
> g.martino at gmx.com
>
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From greearb at candelatech.com  Mon Apr 27 07:17:13 2015
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 27 Apr 2015 07:17:13 -0700
Subject: Tips to debug Firmware crash
In-Reply-To: <CABHL29Hq8e+sgyfqtN-EbEpM1cC9XF_bO3F_rj68Piq-kKg4=w@mail.gmail.com>
References: <CABHL29Hq8e+sgyfqtN-EbEpM1cC9XF_bO3F_rj68Piq-kKg4=w@mail.gmail.com>
Message-ID: <553E44E9.7020007@candelatech.com>



On 04/26/2015 10:48 PM, Venkat Ch wrote:
> Hi All,
>
>    I am an active developer of Atheros drivers for the last 10 years. I
> have been working on QCA 10.2.2 driver for the last few months and
> trying to understand the architecture of this offloading model. Though
> this forum is nothing to do with Atheros provided drivers, I took the
> liberty of posting the question to see if Ath10k community could help
> me. Sorry if I violated any guidelines.
>
> There is some problem at firmware level about which I am clueless.
> Whenever there is a crash in firmware the 5GHz interface goes down
> completely and there will not be any transmissions or receptions from
> the interface from then. What all I see on the console is  some log
> message "Target Asserted" . I don't get any stack trace to see in
> which function it crashed.
>
>   Can any of you please let me know if there is a way to dump the stack
> trace and debug the firmware crash?

I have tools to debug my modified 10.1 'CT' firmware and get backtraces and decode
the log messages and such.  I can't publish the details due to NDA, but I can
give vague descriptions of the problem and usually figure out a way to fix it.

For 10.2, you would need to talk to someone with that firmware source code,
as I have not been given access to it.

Thanks,
Ben


>
>
> Thanks & Regards
> Venkat
>
>

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From kvalo at qca.qualcomm.com  Mon Apr 27 07:24:38 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Mon, 27 Apr 2015 17:24:38 +0300
Subject: [PATCH] ath10k: add ATH10K_FW_FEATURE_IGNORE_OTP_RESULT
Message-ID: <20150427142438.25600.26537.stgit@potku.adurom.net>

qca6174 otp binary seems to always return an error to the host, even if the
calibration succeeded. Add a firmware feature flag to detect if the firmware
image which have this problem and workaround the issue in ath10k by ignoring
the error code.

I was also considering making this hw specific flag but as this is strictly a
firmware issue it's best to handle this via a firmware feature flag so that it
will be easy to disable the workaround.

Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c |    4 +++-
 drivers/net/wireless/ath/ath10k/core.h |    3 +++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 987b266278a8..bcccae19325d 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -387,7 +387,9 @@ static int ath10k_download_and_run_otp(struct ath10k *ar)
 
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot otp execute result %d\n", result);
 
-	if (!skip_otp && result != 0) {
+	if (!(skip_otp || test_bit(ATH10K_FW_FEATURE_IGNORE_OTP_RESULT,
+				   ar->fw_features))
+	    && result != 0) {
 		ath10k_err(ar, "otp calibration failed: %d", result);
 		return -EINVAL;
 	}
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 8444adf42195..827b3d79ed0c 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -460,6 +460,9 @@ enum ath10k_fw_features {
 	 */
 	ATH10K_FW_FEATURE_WOWLAN_SUPPORT = 6,
 
+	/* Don't trust error code from otp.bin */
+	ATH10K_FW_FEATURE_IGNORE_OTP_RESULT,
+
 	/* keep last */
 	ATH10K_FW_FEATURE_COUNT,
 };



From g.martino at gmx.com  Mon Apr 27 08:04:49 2015
From: g.martino at gmx.com (Gabriele Martino)
Date: Mon, 27 Apr 2015 17:04:49 +0200
Subject: QCA6174 hw2.1?
In-Reply-To: <CA+-y_t-L5tAYRfT5+WzbB_EvZbWDO3hys9GD8Ms7fFhT_9cy_Q@mail.gmail.com>
References: <trinity-d51578c9-4e28-4805-b58e-fdd5388949da-1426217948333@msvc-mesg-gmx002>
 <CA+BoTQnGQC9sy_Qhiv4peeRsF2dY+2yd12GTgJpyRhrgMTg+Yw@mail.gmail.com>
 <trinity-2097dd2e-b8b3-40c5-9eed-c0dc7d8690af-1426260485155@3capp-mailcom-lxa11>
 <CA+BoTQnKJE0w0SZrh-p2KaKe62t4=cRLnjeKu+t9aeE+LFce-w@mail.gmail.com>
 <loom.20150425T025815-684@post.gmane.org>
 <CAJAVYN208PQpnt5oQPi1hdYW71WMVJReBNSY-OqZ9aCb0yuiaA@mail.gmail.com>
 <553B8F89.4040908@gmx.com>
 <CAJAVYN1XKYdGqx4pzg3C9kSxj6_qwr4raoDJm7e+VLy1P=dsdw@mail.gmail.com>
 <553CF1EE.50807@gmx.com> <553D8112.2050300@gmx.com>
 <CA+-y_t-L5tAYRfT5+WzbB_EvZbWDO3hys9GD8Ms7fFhT_9cy_Q@mail.gmail.com>
Message-ID: <553E5011.2050404@gmx.com>

On 27/04/2015 16:00, Moritz Morawietz wrote:
> Hi!
>
> I have the same problems with my card (also a Killer N1525). It seems
> you've done it, but i can't figure out how.
>
> Do i need to build and use kvalo's kernel, or is it enough to build
> the modules ath10k_core & ath10k_pci?
> I'm a bit afraid of compiling the whole kernel ^^
> output of uname -a:
> Linux companion 4.0.0-2-ARCH #1 SMP PREEMPT Tue Apr 14 07:14:46 CEST
> 2015 x86_64 GNU/Linux
The modules should be enough. Tell us if it works.
Compiling a whole kernel isn't too hard if you already have a working
configuration.

> I have the disassembly.py, but cannot find the dissect.py, can you
> provide the link? Or, even better, the assembled files?
I won't upload the assembled files now, I don't know if I can get
licensing issues.
You can find the dissect.py script here:
http://lists.infradead.org/pipermail/ath10k/2015-April/005074.html

Good luck!

Regards,
Gabriele



From greearb at candelatech.com  Mon Apr 27 11:14:50 2015
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 27 Apr 2015 11:14:50 -0700
Subject: ath10k CT firmware crash help.
Message-ID: <553E7C9A.1000503@candelatech.com>

Hello!

I have been trying to make progress on a particular firmware crash
in my 10.1 CT firmware, but I am not having much luck.

For anyone using my firmware, I would appreciate if you could keep
a look-out for crashes that match the crash signature
at the bottom of this page:

http://www.candelatech.com/ath10k.php

In general, I am interested in all firmware crashes from my
firmware, but I am especially interested to know if the CE engine
assert happens on other's platforms.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From michal.kazior at tieto.com  Mon Apr 27 22:47:40 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Tue, 28 Apr 2015 07:47:40 +0200
Subject: attempting mesh on ath10k
In-Reply-To: <20150427130016.GA28926@localhost>
References: <20150424125055.GA27722@localhost>
 <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>
 <553AEFFA.6010709@candelatech.com>
 <20150426141552.GA25938@localhost>
 <20150427130016.GA28926@localhost>
Message-ID: <CA+BoTQmrboeJOw0J67PWkbjteh38xrWntivvBKSWY1MBQ=B6Dg@mail.gmail.com>

On 27 April 2015 at 15:00, Bob Copeland <me at bobcopeland.com> wrote:
> On Sun, Apr 26, 2015 at 10:15:52AM -0400, Bob Copeland wrote:
>> So, progress!
>>
>> There's still an issue with datapath -- while it looks like we can establish
>> plinks, I couldn't get unicast traffic flowing even if manually setting up
>> mpaths and arp table entries.  I haven't yet got all of my 5 ghz capable gear
>> in the same room to monitor and see where the problem lies.
>
> Now I had a chance to monitor it, and in so doing, rediscovered this patch of
> Chun-Yeow's:
>
> http://lists.infradead.org/pipermail/ath10k/2014-September/003206.html
>
> In fact my broadcasts were truncated and the above change makes the broadcast
> ARPs look correct over the air.  The (non-ath10k) target mesh STA replies with
> broadcast PREQ but that is not received / processed / replied-to by the
> ath10k device.
>
> Perhaps there is a BSSID filter enabled or something like that (in mesh
> there's no BSSID, just individual addresses on group addressed frames).

In that case try creating a monitor interface and bring it up. This
should prompt ath10k to create monitor vdev and subsequently disable
most Rx filters in firmware.


Micha?


From moritz.morawietz at informatik.uni-oldenburg.de  Tue Apr 28 04:55:06 2015
From: moritz.morawietz at informatik.uni-oldenburg.de (Moritz Morawietz)
Date: Tue, 28 Apr 2015 13:55:06 +0200
Subject: QCA6174 hw2.1?
In-Reply-To: <CAJAVYN2WGEwrajUKFOpYPC7YWnovSs3pmQfjmP74hfwW-epJ2Q@mail.gmail.com>
References: <trinity-d51578c9-4e28-4805-b58e-fdd5388949da-1426217948333@msvc-mesg-gmx002>
 <CA+BoTQnGQC9sy_Qhiv4peeRsF2dY+2yd12GTgJpyRhrgMTg+Yw@mail.gmail.com>
 <trinity-2097dd2e-b8b3-40c5-9eed-c0dc7d8690af-1426260485155@3capp-mailcom-lxa11>
 <CA+BoTQnKJE0w0SZrh-p2KaKe62t4=cRLnjeKu+t9aeE+LFce-w@mail.gmail.com>
 <loom.20150425T025815-684@post.gmane.org>
 <CAJAVYN208PQpnt5oQPi1hdYW71WMVJReBNSY-OqZ9aCb0yuiaA@mail.gmail.com>
 <553B8F89.4040908@gmx.com>
 <CAJAVYN1XKYdGqx4pzg3C9kSxj6_qwr4raoDJm7e+VLy1P=dsdw@mail.gmail.com>
 <553CF1EE.50807@gmx.com> <553D8112.2050300@gmx.com>
 <CA+-y_t-L5tAYRfT5+WzbB_EvZbWDO3hys9GD8Ms7fFhT_9cy_Q@mail.gmail.com>
 <553E5011.2050404@gmx.com>
 <CAJAVYN2WGEwrajUKFOpYPC7YWnovSs3pmQfjmP74hfwW-epJ2Q@mail.gmail.com>
Message-ID: <CA+-y_t8pm+GPEaKX6cYta-Q4kiAd6mFKLO37nmS6pwPV63_VyA@mail.gmail.com>

Many thanks for your fast help!

I've made some progress, but ran into other problems.
If i compile ath10_pci, ath10k_core and ath from kvalo's tree and load
them, i get following dmesg output:

[    2.980448] ath10k_pci 0000:06:00.0: enabling device (0000 -> 0002)
[    2.980750] ath10k_pci 0000:06:00.0: pci irq msi-x interrupts 8
irq_mode 0 reset_mode 0
[    3.158860] ath10k_pci 0000:06:00.0: Direct firmware load for
ath10k/cal-pci-0000:06:00.0.bin failed with error -2
[    3.159611] ath10k_pci 0000:06:00.0: Direct firmware load for
ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with
error -2
[    3.159613] ath10k_pci 0000:06:00.0: failed to load spec board
file, falling back to generic: -2
[    3.159922] ath10k_pci 0000:06:00.0: Direct firmware load for
ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2
[    3.159924] ath10k_pci 0000:06:00.0: could not fetch firmware file
'ath10k/QCA6174/hw2.1/firmware-5.bin': -2
[    4.360946] ath10k_pci 0000:06:00.0: qca6174 hw2.1 (0x05010000,
0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt
3.1 wmi 4 cal otp max_sta 32
[    4.360950] ath10k_pci 0000:06:00.0: debug 1 debugfs 1 tracing 1
dfs 0 testmode 0
[    4.430068] ath: EEPROM regdomain: 0x6c
[    4.430070] ath: EEPROM indicates we should expect a direct regpair map
[    4.430072] ath: Country alpha2 being used: 00
[    4.430072] ath: Regpair used: 0x6c
[    4.430078] ath10k_pci 0000:06:00.0: failed to register ieee80211: -22
[    4.430097] ath10k_pci 0000:06:00.0: could not register to mac80211 (-22)

So I compiled mac80211, and tried to load it. What i get is a load of
that messages:

[  226.812494] mac80211: Unknown symbol cfg80211_cqm_rssi_notify (err -22)
[  226.812497] mac80211: disagrees about version of symbol cfg80211_auth_timeout
[  226.812497] mac80211: Unknown symbol cfg80211_auth_timeout (err -22)
[  226.812498] mac80211: disagrees about version of symbol
cfg80211_rx_unprot_mlme_mgmt
[  226.812499] mac80211: Unknown symbol cfg80211_rx_unprot_mlme_mgmt (err -22)

Because mac80211 depends on cfg80211, i compilied and tested it. The
error messages reduced to

[  632.208849] mac80211: Unknown symbol rhashtable_insert_rehash (err 0)
[  632.208881] mac80211: Unknown symbol rhashtable_insert_slow (err 0)

Know I'm stuck. I'll try to compile and use the whole kernel (it's
compiling right now), but would prefer to just change the modules.

The firmware-4.bin is assembled like described in this thread, as
board.bin i used eeprom_qca9377_1p0_NFA435_olpc.bin.

Any Ideas? :)

Happy greetings
Moritz

2015-04-27 23:56 GMT+02:00 Corin Lawson <me at corinlawson.com.au>:
> Gabriele is right it is only the modules that need to be built kvalo's
> kernel
>
> On 28 Apr 2015 1:05 am, "Gabriele Martino" <g.martino at gmx.com> wrote:
>>
>> On 27/04/2015 16:00, Moritz Morawietz wrote:
>> > Hi!
>> >
>> > I have the same problems with my card (also a Killer N1525). It seems
>> > you've done it, but i can't figure out how.
>> >
>> > Do i need to build and use kvalo's kernel, or is it enough to build
>> > the modules ath10k_core & ath10k_pci?
>> > I'm a bit afraid of compiling the whole kernel ^^
>> > output of uname -a:
>> > Linux companion 4.0.0-2-ARCH #1 SMP PREEMPT Tue Apr 14 07:14:46 CEST
>> > 2015 x86_64 GNU/Linux
>> The modules should be enough. Tell us if it works.
>> Compiling a whole kernel isn't too hard if you already have a working
>> configuration.
>>
>> > I have the disassembly.py, but cannot find the dissect.py, can you
>> > provide the link? Or, even better, the assembled files?
>> I won't upload the assembled files now, I don't know if I can get
>> licensing issues.
>> You can find the dissect.py script here:
>> http://lists.infradead.org/pipermail/ath10k/2015-April/005074.html
>>
>> Good luck!
>>
>> Regards,
>> Gabriele
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k


From me at bobcopeland.com  Tue Apr 28 05:25:55 2015
From: me at bobcopeland.com (Bob Copeland)
Date: Tue, 28 Apr 2015 08:25:55 -0400
Subject: attempting mesh on ath10k
In-Reply-To: <CA+BoTQmrboeJOw0J67PWkbjteh38xrWntivvBKSWY1MBQ=B6Dg@mail.gmail.com>
References: <20150424125055.GA27722@localhost>
 <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>
 <553AEFFA.6010709@candelatech.com>
 <20150426141552.GA25938@localhost>
 <20150427130016.GA28926@localhost>
 <CA+BoTQmrboeJOw0J67PWkbjteh38xrWntivvBKSWY1MBQ=B6Dg@mail.gmail.com>
Message-ID: <20150428122554.GA4527@localhost>

On Tue, Apr 28, 2015 at 07:47:40AM +0200, Michal Kazior wrote:
> > Perhaps there is a BSSID filter enabled or something like that (in mesh
> > there's no BSSID, just individual addresses on group addressed frames).
> 
> In that case try creating a monitor interface and bring it up. This
> should prompt ath10k to create monitor vdev and subsequently disable
> most Rx filters in firmware.

Indeed, that did the trick, thanks!  So mesh is functional now with raw mode
patch and a few hacks:

root at archer:~# iw dev
phy#0
        Interface mon0
                ifindex 8
                wdev 0x2
                addr e8:de:27:d6:9c:d0
                type monitor
        Interface wlan0
                ifindex 4
                wdev 0x1
                addr e8:de:27:d6:9c:d0
                type mesh point
                channel 149 (5745 MHz), width: 20 MHz (no HT), center1: 5745 MHz

root at archer:~# ping 10.10.10.13
PING 10.10.10.13 (10.10.10.13): 56 data bytes
64 bytes from 10.10.10.13: seq=0 ttl=64 time=10.031 ms
64 bytes from 10.10.10.13: seq=1 ttl=64 time=1.074 ms
64 bytes from 10.10.10.13: seq=2 ttl=64 time=1.074 ms
64 bytes from 10.10.10.13: seq=3 ttl=64 time=1.082 ms
64 bytes from 10.10.10.13: seq=4 ttl=64 time=1.032 ms
64 bytes from 10.10.10.13: seq=5 ttl=64 time=2.905 ms
64 bytes from 10.10.10.13: seq=6 ttl=64 time=1.093 ms
64 bytes from 10.10.10.13: seq=7 ttl=64 time=1.205 ms
64 bytes from 10.10.10.13: seq=8 ttl=64 time=1.057 ms
64 bytes from 10.10.10.13: seq=9 ttl=64 time=1.039 ms
64 bytes from 10.10.10.13: seq=10 ttl=64 time=1.107 ms
64 bytes from 10.10.10.13: seq=11 ttl=64 time=1.040 ms
^C
--- 10.10.10.13 ping statistics ---
12 packets transmitted, 12 packets received, 0% packet loss
round-trip min/avg/max = 1.032/1.978/10.031 ms

root at archer:~# iw dev wlan0 mpath dump
DEST ADDR         NEXT HOP          IFACE       SN      METRIC  QLEN
EXPTIME         DTIM    DRET    FLAGS
00:03:7f:10:4e:2d 00:03:7f:10:4e:2d wlan0       2427    1366    0
0       100     0       0x4

-- 
Bob Copeland %% http://bobcopeland.com/


From me at bobcopeland.com  Tue Apr 28 05:41:16 2015
From: me at bobcopeland.com (Bob Copeland)
Date: Tue, 28 Apr 2015 08:41:16 -0400
Subject: attempting mesh on ath10k
In-Reply-To: <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>
References: <20150424125055.GA27722@localhost>
 <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>
Message-ID: <20150428124116.GC4527@localhost>

On Sat, Apr 25, 2015 at 01:55:32AM +0800, Chun-Yeow Yeoh wrote:
> Hi, Bob
> 
> I have tried converting the "adhoc" mode on the
> firmware-2.bin_999.999.0.636 as mesh interface.
> 
> You can find my patches here:
> https://github.com/chunyeow/ath/commits/mesh
> 
> But probably too many workaround and won't be able to interoperate
> with other mesh interface.

Yeah, I think adhoc will not work so well due to TSF sync and the
distributed beacon algorithm.  So I'm happy that AP approach seems
viable; of course dedicated mesh vdev type would be nice :)

-- 
Bob Copeland %% http://bobcopeland.com/


From yeohchunyeow at gmail.com  Tue Apr 28 05:50:01 2015
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Tue, 28 Apr 2015 20:50:01 +0800
Subject: attempting mesh on ath10k
In-Reply-To: <20150428124116.GC4527@localhost>
References: <20150424125055.GA27722@localhost>
 <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>
 <20150428124116.GC4527@localhost>
Message-ID: <CAEFj987sVTAn8ABk70AhtDcr2wA+RTH6eXKtgOk26h=pZ5A-JA@mail.gmail.com>

Great works, Bob.

Which AP firmware that you have tested with?

----
Chun-Yeow

On Tue, Apr 28, 2015 at 8:41 PM, Bob Copeland <me at bobcopeland.com> wrote:
> On Sat, Apr 25, 2015 at 01:55:32AM +0800, Chun-Yeow Yeoh wrote:
>> Hi, Bob
>>
>> I have tried converting the "adhoc" mode on the
>> firmware-2.bin_999.999.0.636 as mesh interface.
>>
>> You can find my patches here:
>> https://github.com/chunyeow/ath/commits/mesh
>>
>> But probably too many workaround and won't be able to interoperate
>> with other mesh interface.
>
> Yeah, I think adhoc will not work so well due to TSF sync and the
> distributed beacon algorithm.  So I'm happy that AP approach seems
> viable; of course dedicated mesh vdev type would be nice :)
>
> --
> Bob Copeland %% http://bobcopeland.com/


From me at bobcopeland.com  Tue Apr 28 05:57:49 2015
From: me at bobcopeland.com (Bob Copeland)
Date: Tue, 28 Apr 2015 08:57:49 -0400
Subject: attempting mesh on ath10k
In-Reply-To: <CAEFj987sVTAn8ABk70AhtDcr2wA+RTH6eXKtgOk26h=pZ5A-JA@mail.gmail.com>
References: <20150424125055.GA27722@localhost>
 <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>
 <20150428124116.GC4527@localhost>
 <CAEFj987sVTAn8ABk70AhtDcr2wA+RTH6eXKtgOk26h=pZ5A-JA@mail.gmail.com>
Message-ID: <20150428125748.GE4527@localhost>

On Tue, Apr 28, 2015 at 08:50:01PM +0800, Chun-Yeow Yeoh wrote:
> Great works, Bob.
> 
> Which AP firmware that you have tested with?

That is with:

[   16.670000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
0x043202ff) fw 10.2.4.45 api 4 htt 2.1 wmi 5 cal otp max_sta 128

I think it should work with CT too.  I need to go back and validate
that, and also make sure I can repro the AID crash on CT.  A confounding
factor is that every time I build new drivers for OpenWRT, it overwrites
the firmware again...

-- 
Bob Copeland %% http://bobcopeland.com/


From greearb at candelatech.com  Tue Apr 28 07:47:56 2015
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 28 Apr 2015 07:47:56 -0700
Subject: attempting mesh on ath10k
In-Reply-To: <20150428125748.GE4527@localhost>
References: <20150424125055.GA27722@localhost>
 <CAEFj986N0UnCnzFWLTd=MkSWRU0jOG36N4SVepkmXPnaLX__0g@mail.gmail.com>
 <20150428124116.GC4527@localhost>
 <CAEFj987sVTAn8ABk70AhtDcr2wA+RTH6eXKtgOk26h=pZ5A-JA@mail.gmail.com>
 <20150428125748.GE4527@localhost>
Message-ID: <553F9D9C.9080004@candelatech.com>



On 04/28/2015 05:57 AM, Bob Copeland wrote:
> On Tue, Apr 28, 2015 at 08:50:01PM +0800, Chun-Yeow Yeoh wrote:
>> Great works, Bob.
>>
>> Which AP firmware that you have tested with?
>
> That is with:
>
> [   16.670000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
> 0x043202ff) fw 10.2.4.45 api 4 htt 2.1 wmi 5 cal otp max_sta 128
>
> I think it should work with CT too.  I need to go back and validate
> that, and also make sure I can repro the AID crash on CT.  A confounding
> factor is that every time I build new drivers for OpenWRT, it overwrites
> the firmware again...


If you feel adventurous, and want to apply some of my ath10k patches,
I have a way to dump some of the interesting registers in CT firmware,
including the rx-filter register.

Maybe I can figure out what needs to be twiddled w/out having to add
a monitor device.

I could also potentially add a vdev type or flag for mesh interface,
but that would definitely require driver hacks to enable the new
flag and it would not be compatible with other upstream firmware.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From kvalo at qca.qualcomm.com  Tue Apr 28 08:08:16 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Tue, 28 Apr 2015 18:08:16 +0300
Subject: Modifing and installing ath10k driver for kernel 4.0
In-Reply-To: <CA+BoTQmGCnAepE0OWEiO1ASrLEbsmrKqf2zS-s2WpAbkhX4vaw@mail.gmail.com>
 (Michal Kazior's message of "Mon, 27 Apr 2015 13:03:11 +0200")
References: <BB63CF2605733841BD56CD9C38AC1F7E1E678CA8@MBX23.d.ethz.ch>
 <CA+BoTQmGCnAepE0OWEiO1ASrLEbsmrKqf2zS-s2WpAbkhX4vaw@mail.gmail.com>
Message-ID: <87383k70kf.fsf@kamboji.qca.qualcomm.com>

Michal Kazior <michal.kazior at tieto.com> writes:

> You can still use backports though. All you need is to build backports
> package yourself[1] from whatever kernel tree you desire, e.g.
> github.com/kvalo/ath instead of using the pre-built one.
>
> [1]: https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking

I also wrote something about ath10k and backports:

https://wireless.wiki.kernel.org/en/users/drivers/ath10k/backports

-- 
Kalle Valo


From kvalo at qca.qualcomm.com  Wed Apr 29 01:21:48 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Wed, 29 Apr 2015 11:21:48 +0300
Subject: ath.git master branch rebased to 4.1-rc1-wl-ath
Message-ID: <87zj5r2vkz.fsf@kamboji.qca.qualcomm.com>

Hi,

I just rebased the master branch to 4.1-rc1-wl-ath so please be careful
when updating your working trees.

-- 
Kalle Valo


From cedgar at student.ethz.ch  Wed Apr 29 05:53:36 2015
From: cedgar at student.ethz.ch (Costa Molero  Edgar)
Date: Wed, 29 Apr 2015 12:53:36 +0000
Subject: Modifing and installing ath10k driver for kernel 4.0
In-Reply-To: <87383k70kf.fsf@kamboji.qca.qualcomm.com>
References: <BB63CF2605733841BD56CD9C38AC1F7E1E678CA8@MBX23.d.ethz.ch>
 <CA+BoTQmGCnAepE0OWEiO1ASrLEbsmrKqf2zS-s2WpAbkhX4vaw@mail.gmail.com>,
 <87383k70kf.fsf@kamboji.qca.qualcomm.com>
Message-ID: <BB63CF2605733841BD56CD9C38AC1F7E1F34B2F7@MBX13.d.ethz.ch>

> You can still use backports though. All you need is to build backports
> package yourself[1] from whatever kernel tree you desire, e.g.
> github.com/kvalo/ath instead of using the pre-built one.
>
> [1]: https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking

> I also wrote something about ath10k and backports:

> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/backports


Thanks, for the answers. 

I already tried before writing my message to compile my custom ath10k backports. However when I was following your guide I was not able to create the backports output tree. The gentree.py script was giving me a dependency problem :

You need to have installed: spatch >= 1.0.0-rc24
Try installing the package: coccinelle

So, I did installed the latest coccinelle version but the dependency was still there. After one day struggling I found that its a bug and can be solved with this patch :

---
 lib/bpreqs.py |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/bpreqs.py b/lib/bpreqs.py
index 6c46670..4399c6d 100644
--- a/lib/bpreqs.py
+++ b/lib/bpreqs.py
 <at>  <at>  -98,7 +98,7  <at>  <at>  class Req:
                 if (rc == ""):
                     rc = 0
                 else:
-                    rc = int(rc) - 20
+                    rc = int(rc) - 40
                 extra = int(rc)
             else:
                 extra = int(rel_specs['EXTRAVERSION']) + 10
--

I still have a question regarding backports, and kernel releases. I am quite new in all this world so that's why I was a little bit confused.  Correct me if I am wrong. Backports are used to install the newest (or whatever version ) of drivers in the current kernel you have, right ? So you get the same result than compiling the entire kernel with your modified driver ? 

Edgar


From enochs.brandon at gmail.com  Wed Apr 29 13:24:08 2015
From: enochs.brandon at gmail.com (Brandon Enochs)
Date: Wed, 29 Apr 2015 16:24:08 -0400
Subject: Netlink Antenna Support
Message-ID: <CAP-AUyhhuXGL_U2rx5_h1Qp3+fR8KSGkrnp2iXoeeZ5h1+K9YA@mail.gmail.com>

Does anyone know if the ath10k driver will, at some point, support
netlink antenna masking?  The ath9k card supported this.  Further,
will multiple antenna/signal strength pairs be supported like in the
ath9k driver?

Thanks,
Brandon


From greearb at candelatech.com  Wed Apr 29 15:53:05 2015
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 29 Apr 2015 15:53:05 -0700
Subject: Netlink Antenna Support
In-Reply-To: <CAP-AUyhhuXGL_U2rx5_h1Qp3+fR8KSGkrnp2iXoeeZ5h1+K9YA@mail.gmail.com>
References: <CAP-AUyhhuXGL_U2rx5_h1Qp3+fR8KSGkrnp2iXoeeZ5h1+K9YA@mail.gmail.com>
Message-ID: <554160D1.70809@candelatech.com>

On 04/29/2015 01:24 PM, Brandon Enochs wrote:
> Does anyone know if the ath10k driver will, at some point, support
> netlink antenna masking?  The ath9k card supported this.  Further,
> will multiple antenna/signal strength pairs be supported like in the
> ath9k driver?

ath10k supports setting the antennas in use (nss).  You can use chains: 0, 0+1, or 0+1+2,
just like ath9k.

I don't think ath10k has any logic to report any of the details about antenna signal
strength for received frames.

Thanks,
Ben

> 
> Thanks,
> Brandon
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From g.martino at gmx.com  Wed Apr 29 17:07:06 2015
From: g.martino at gmx.com (Gabriele Martino)
Date: Thu, 30 Apr 2015 02:07:06 +0200
Subject: QCA6174 hw2.1?
In-Reply-To: <CA+-y_t8pm+GPEaKX6cYta-Q4kiAd6mFKLO37nmS6pwPV63_VyA@mail.gmail.com>
References: <trinity-d51578c9-4e28-4805-b58e-fdd5388949da-1426217948333@msvc-mesg-gmx002>
 <CA+BoTQnGQC9sy_Qhiv4peeRsF2dY+2yd12GTgJpyRhrgMTg+Yw@mail.gmail.com>
 <trinity-2097dd2e-b8b3-40c5-9eed-c0dc7d8690af-1426260485155@3capp-mailcom-lxa11>
 <CA+BoTQnKJE0w0SZrh-p2KaKe62t4=cRLnjeKu+t9aeE+LFce-w@mail.gmail.com>
 <loom.20150425T025815-684@post.gmane.org>
 <CAJAVYN208PQpnt5oQPi1hdYW71WMVJReBNSY-OqZ9aCb0yuiaA@mail.gmail.com>
 <553B8F89.4040908@gmx.com>
 <CAJAVYN1XKYdGqx4pzg3C9kSxj6_qwr4raoDJm7e+VLy1P=dsdw@mail.gmail.com>
 <553CF1EE.50807@gmx.com> <553D8112.2050300@gmx.com>
 <CA+-y_t-L5tAYRfT5+WzbB_EvZbWDO3hys9GD8Ms7fFhT_9cy_Q@mail.gmail.com>
 <553E5011.2050404@gmx.com>
 <CAJAVYN2WGEwrajUKFOpYPC7YWnovSs3pmQfjmP74hfwW-epJ2Q@mail.gmail.com>
 <CA+-y_t8pm+GPEaKX6cYta-Q4kiAd6mFKLO37nmS6pwPV63_VyA@mail.gmail.com>
Message-ID: <5541722A.2060109@gmx.com>

On 28/04/2015 13:55, Moritz Morawietz wrote:
> Many thanks for your fast help!
>
> I've made some progress, but ran into other problems.
> If i compile ath10_pci, ath10k_core and ath from kvalo's tree and load
> them, i get following dmesg output:
>
> [    2.980448] ath10k_pci 0000:06:00.0: enabling device (0000 -> 0002)
> [    2.980750] ath10k_pci 0000:06:00.0: pci irq msi-x interrupts 8
> irq_mode 0 reset_mode 0
> [    3.158860] ath10k_pci 0000:06:00.0: Direct firmware load for
> ath10k/cal-pci-0000:06:00.0.bin failed with error -2
> [    3.159611] ath10k_pci 0000:06:00.0: Direct firmware load for
> ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with
> error -2
> [    3.159613] ath10k_pci 0000:06:00.0: failed to load spec board
> file, falling back to generic: -2
> [    3.159922] ath10k_pci 0000:06:00.0: Direct firmware load for
> ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2
> [    3.159924] ath10k_pci 0000:06:00.0: could not fetch firmware file
> 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2
> [    4.360946] ath10k_pci 0000:06:00.0: qca6174 hw2.1 (0x05010000,
> 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt
> 3.1 wmi 4 cal otp max_sta 32
> [    4.360950] ath10k_pci 0000:06:00.0: debug 1 debugfs 1 tracing 1
> dfs 0 testmode 0
> [    4.430068] ath: EEPROM regdomain: 0x6c
> [    4.430070] ath: EEPROM indicates we should expect a direct regpair map
> [    4.430072] ath: Country alpha2 being used: 00
> [    4.430072] ath: Regpair used: 0x6c
> [    4.430078] ath10k_pci 0000:06:00.0: failed to register ieee80211: -22
> [    4.430097] ath10k_pci 0000:06:00.0: could not register to mac80211 (-22)
>
> So I compiled mac80211, and tried to load it. What i get is a load of
> that messages:
>
> [  226.812494] mac80211: Unknown symbol cfg80211_cqm_rssi_notify (err -22)
> [  226.812497] mac80211: disagrees about version of symbol cfg80211_auth_timeout
> [  226.812497] mac80211: Unknown symbol cfg80211_auth_timeout (err -22)
> [  226.812498] mac80211: disagrees about version of symbol
> cfg80211_rx_unprot_mlme_mgmt
> [  226.812499] mac80211: Unknown symbol cfg80211_rx_unprot_mlme_mgmt (err -22)
>
> Because mac80211 depends on cfg80211, i compilied and tested it. The
> error messages reduced to
>
> [  632.208849] mac80211: Unknown symbol rhashtable_insert_rehash (err 0)
> [  632.208881] mac80211: Unknown symbol rhashtable_insert_slow (err 0)
>
> Know I'm stuck. I'll try to compile and use the whole kernel (it's
> compiling right now), but would prefer to just change the modules.
I could find some references to "rhashtable_insert_rehash" with grep:
/usr/src/linux/lib/rhashtable.c:int rhashtable_insert_rehash(struct
rhashtable *ht)
/usr/src/linux/lib/rhashtable.c:EXPORT_SYMBOL_GPL(rhashtable_insert_rehash);

This file is present in 3.18.11 kernel (I don't have older sources on
this laptop).
Which distribution and kernel are you using?
You are compiling 4.0 (-> 3.20) modules, so you're likely to get strange
issues if your kernel is too old.

Regards,
Gabriele



From neym at vorklift.com  Wed Apr 29 17:22:25 2015
From: neym at vorklift.com (Michael Ney)
Date: Wed, 29 Apr 2015 20:22:25 -0400
Subject: Netlink Antenna Support
In-Reply-To: <554160D1.70809@candelatech.com>
References: <CAP-AUyhhuXGL_U2rx5_h1Qp3+fR8KSGkrnp2iXoeeZ5h1+K9YA@mail.gmail.com>
 <554160D1.70809@candelatech.com>
Message-ID: <A2FA0C75-C20E-4DCF-A456-84C8B3665E47@vorklift.com>

Per-antenna rssi is provided by ath10k firmware, but is not currently processed by the driver; the driver only reports the combined rssi (rssi_comb field). You can look at the rx_ppdu_start structure in rx_desc.h to see the rssi data available. I have verified that the pri20_mhz appears to report correctly on the CT firmware (eyeballed, not empirical), but I have not looked at any of the extension channel rssi's.

I think all that should be needed for the primary channel rssi's would be to implement something similar to ath9k's common.c "ath9k_cmn_process_rssi" function for iterating over the chains into ath10k's htt_rx.c "ath10k_htt_rx_h_signal" function.

Michael

> On Apr 29, 2015, at 6:53 PM, Ben Greear <greearb at candelatech.com> wrote:
> 
> On 04/29/2015 01:24 PM, Brandon Enochs wrote:
>> Does anyone know if the ath10k driver will, at some point, support
>> netlink antenna masking?  The ath9k card supported this.  Further,
>> will multiple antenna/signal strength pairs be supported like in the
>> ath9k driver?
> 
> ath10k supports setting the antennas in use (nss).  You can use chains: 0, 0+1, or 0+1+2,
> just like ath9k.
> 
> I don't think ath10k has any logic to report any of the details about antenna signal
> strength for received frames.
> 
> Thanks,
> Ben
> 
>> 
>> Thanks,
>> Brandon
>> 
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>> 
> 
> 
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k



From yeohchunyeow at gmail.com  Wed Apr 29 19:29:04 2015
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 30 Apr 2015 10:29:04 +0800
Subject: Compex WLE900N5-23
Message-ID: <CAEFj985e=6y2RQcHy-3RgaYx63hMdfJ+CdgaqpPdjuehLj=sKA@mail.gmail.com>

Hi, all

I am using the above WiFi card and found out that it can only use the
firmware-2.bin_10.1.467.2-1 (10.1), but not 10.2 or 10.3 (firmware
crashed) for AP mode.

Is that any reason of this?

--------
Chun-Yeow


From kvalo at qca.qualcomm.com  Wed Apr 29 20:02:28 2015
From: kvalo at qca.qualcomm.com (Kalle Valo)
Date: Thu, 30 Apr 2015 06:02:28 +0300
Subject: Compex WLE900N5-23
In-Reply-To: <CAEFj985e=6y2RQcHy-3RgaYx63hMdfJ+CdgaqpPdjuehLj=sKA@mail.gmail.com>
 (Yeoh Chun-Yeow's message of "Thu, 30 Apr 2015 10:29:04 +0800")
References: <CAEFj985e=6y2RQcHy-3RgaYx63hMdfJ+CdgaqpPdjuehLj=sKA@mail.gmail.com>
Message-ID: <87lhha1fp7.fsf@kamboji.qca.qualcomm.com>

Yeoh Chun-Yeow <yeohchunyeow at gmail.com> writes:

> I am using the above WiFi card and found out that it can only use the
> firmware-2.bin_10.1.467.2-1 (10.1), but not 10.2 or 10.3 (firmware
> crashed) for AP mode.
>
> Is that any reason of this?

I can't think of any reason from top of my head. Can you send full
(complete) kernel logs and information what kernel and ath10k version
you are using?

-- 
Kalle Valo


From yeohchunyeow at gmail.com  Wed Apr 29 21:27:40 2015
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 30 Apr 2015 12:27:40 +0800
Subject: Compex WLE900N5-23
In-Reply-To: <87lhha1fp7.fsf@kamboji.qca.qualcomm.com>
References: <CAEFj985e=6y2RQcHy-3RgaYx63hMdfJ+CdgaqpPdjuehLj=sKA@mail.gmail.com>
 <87lhha1fp7.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CAEFj986cHR5J-LS+tz7tmoFAcHdkyZu9c2RqhnkAou1uK72c8w@mail.gmail.com>

Kernel version: 3.18.11 (OpenWRT based platform latest trunk)

[   12.690000] Loading modules backported from Linux version
master-2015-03-09-0-g141f155
[   12.700000] Backport generated by backports.git backports-20150129-0-gdd4a670

This is the configuration:
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
hw_mode=a
channel=36

ieee80211n=1
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=42
ieee80211ac=1
vht_capab=[RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC1][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7]

interface=wlan0
ctrl_interface=/var/run/hostapd
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
auth_algs=1
wpa=0
ssid=ath10k
bridge=br-lan
bssid=04:f0:21:0c:a5:44

Attached is the kernel log. Let me know what can I do.

----
Chun-Yeow

On Thu, Apr 30, 2015 at 11:02 AM, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Yeoh Chun-Yeow <yeohchunyeow at gmail.com> writes:
>
>> I am using the above WiFi card and found out that it can only use the
>> firmware-2.bin_10.1.467.2-1 (10.1), but not 10.2 or 10.3 (firmware
>> crashed) for AP mode.
>>
>> Is that any reason of this?
>
> I can't think of any reason from top of my head. Can you send full
> (complete) kernel logs and information what kernel and ath10k version
> you are using?
>
> --
> Kalle Valo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel.log
Type: text/x-log
Size: 24113 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20150430/ce241028/attachment-0001.bin>

From michal.kazior at tieto.com  Wed Apr 29 22:11:40 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 30 Apr 2015 07:11:40 +0200
Subject: Compex WLE900N5-23
In-Reply-To: <CAEFj986cHR5J-LS+tz7tmoFAcHdkyZu9c2RqhnkAou1uK72c8w@mail.gmail.com>
References: <CAEFj985e=6y2RQcHy-3RgaYx63hMdfJ+CdgaqpPdjuehLj=sKA@mail.gmail.com>
 <87lhha1fp7.fsf@kamboji.qca.qualcomm.com>
 <CAEFj986cHR5J-LS+tz7tmoFAcHdkyZu9c2RqhnkAou1uK72c8w@mail.gmail.com>
Message-ID: <CA+BoTQnJRUYzyGPpz1RVptfgLM1+Y1bpkGBG-OvXMZJqbC_Snw@mail.gmail.com>

On 30 April 2015 at 06:27, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
> Kernel version: 3.18.11 (OpenWRT based platform latest trunk)
>
> [   12.690000] Loading modules backported from Linux version
> master-2015-03-09-0-g141f155
> [   12.700000] Backport generated by backports.git backports-20150129-0-gdd4a670
[...]
> Attached is the kernel log. Let me know what can I do.
>
> ----
> Chun-Yeow

Hmm.. So it looks like the device worked for a few minutes first
before crashing, right? Then it crashed, restarted and crashed
immediately after that after which everything went bad bad.

The -16 diag errors suggests that the device CE goes down. The logs
are a bit lacking (debug logs would be much better) and I'm not really
sure whether your device gets a cold reset or only a warm reset.The
latter could explain why it can't resume regular operation.


Micha?


From michal.kazior at tieto.com  Wed Apr 29 22:53:32 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 30 Apr 2015 07:53:32 +0200
Subject: Modifing and installing ath10k driver for kernel 4.0
In-Reply-To: <BB63CF2605733841BD56CD9C38AC1F7E1F34B2F7@MBX13.d.ethz.ch>
References: <BB63CF2605733841BD56CD9C38AC1F7E1E678CA8@MBX23.d.ethz.ch>
 <CA+BoTQmGCnAepE0OWEiO1ASrLEbsmrKqf2zS-s2WpAbkhX4vaw@mail.gmail.com>
 <87383k70kf.fsf@kamboji.qca.qualcomm.com>
 <BB63CF2605733841BD56CD9C38AC1F7E1F34B2F7@MBX13.d.ethz.ch>
Message-ID: <CA+BoTQmJdo8ikcSN4BvXC7CW=3w9So8qFjovNgykdWtj39P9nw@mail.gmail.com>

On 29 April 2015 at 14:53, Costa Molero  Edgar <cedgar at student.ethz.ch> wrote:
>> You can still use backports though. All you need is to build backports
>> package yourself[1] from whatever kernel tree you desire, e.g.
>> github.com/kvalo/ath instead of using the pre-built one.
>>
>> [1]: https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking
>
>> I also wrote something about ath10k and backports:
>
>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/backports
>
>
> Thanks, for the answers.
>
> I already tried before writing my message to compile my custom ath10k backports. However when I was following your guide I was not able to create the backports output tree. The gentree.py script was giving me a dependency problem :
>
> You need to have installed: spatch >= 1.0.0-rc24
> Try installing the package: coccinelle
>
> So, I did installed the latest coccinelle version but the dependency was still there. After one day struggling I found that its a bug and can be solved with this patch :
>
> ---
>  lib/bpreqs.py |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/bpreqs.py b/lib/bpreqs.py
> index 6c46670..4399c6d 100644
> --- a/lib/bpreqs.py
> +++ b/lib/bpreqs.py
>  <at>  <at>  -98,7 +98,7  <at>  <at>  class Req:
>                  if (rc == ""):
>                      rc = 0
>                  else:
> -                    rc = int(rc) - 20
> +                    rc = int(rc) - 40
>                  extra = int(rc)
>              else:
>                  extra = int(rel_specs['EXTRAVERSION']) + 10
> --
>
> I still have a question regarding backports, and kernel releases. I am quite new in all this world so that's why I was a little bit confused.  Correct me if I am wrong. Backports are used to install the newest (or whatever version ) of drivers in the current kernel you have, right ? So you get the same result than compiling the entire kernel with your modified driver ?

It really depends on what you define as a "result". But basically what
you're saying is correct - backports allow you to use newer drivers
with older kernels.

There tends to be some churn across kernel subsystems so it's not
uncommon for driver to depend on other changes in kernel, e.g. ath10k
depends on mac80211 which depends on cfg80211 which depends on netlink
(this is very simplified, there are also some little kernel utilities
and helper functions, pci subsystem, etc that drivers can depend on).
Also dependencies can be code and behavioral. The latter means that,
e.g. even if using ath10k directory from kernel A in kernel B doesn't
yield compilation warnings/errors it doesn't mean it will work
*correctly*.


Michal


From yeohchunyeow at gmail.com  Wed Apr 29 23:46:34 2015
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 30 Apr 2015 14:46:34 +0800
Subject: Compex WLE900N5-23
In-Reply-To: <CA+BoTQnJRUYzyGPpz1RVptfgLM1+Y1bpkGBG-OvXMZJqbC_Snw@mail.gmail.com>
References: <CAEFj985e=6y2RQcHy-3RgaYx63hMdfJ+CdgaqpPdjuehLj=sKA@mail.gmail.com>
 <87lhha1fp7.fsf@kamboji.qca.qualcomm.com>
 <CAEFj986cHR5J-LS+tz7tmoFAcHdkyZu9c2RqhnkAou1uK72c8w@mail.gmail.com>
 <CA+BoTQnJRUYzyGPpz1RVptfgLM1+Y1bpkGBG-OvXMZJqbC_Snw@mail.gmail.com>
Message-ID: <CAEFj984ibOKiLESUDi9gO66iS7WAbvrJeH-2kDA3PNZU9p2Aqg@mail.gmail.com>

Hi, Michal

Attached is the partial log. Hopefully it is useful for you.

Thanks

----
Chun-Yeow

On Thu, Apr 30, 2015 at 1:11 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 30 April 2015 at 06:27, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
>> Kernel version: 3.18.11 (OpenWRT based platform latest trunk)
>>
>> [   12.690000] Loading modules backported from Linux version
>> master-2015-03-09-0-g141f155
>> [   12.700000] Backport generated by backports.git backports-20150129-0-gdd4a670
> [...]
>> Attached is the kernel log. Let me know what can I do.
>>
>> ----
>> Chun-Yeow
>
> Hmm.. So it looks like the device worked for a few minutes first
> before crashing, right? Then it crashed, restarted and crashed
> immediately after that after which everything went bad bad.
>
> The -16 diag errors suggests that the device CE goes down. The logs
> are a bit lacking (debug logs would be much better) and I'm not really
> sure whether your device gets a cold reset or only a warm reset.The
> latter could explain why it can't resume regular operation.
>
>
> Micha?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel.log
Type: text/x-log
Size: 91632 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20150430/cd13abf9/attachment-0001.bin>

From michal.kazior at tieto.com  Thu Apr 30 00:05:19 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 30 Apr 2015 09:05:19 +0200
Subject: Compex WLE900N5-23
In-Reply-To: <CAEFj984ibOKiLESUDi9gO66iS7WAbvrJeH-2kDA3PNZU9p2Aqg@mail.gmail.com>
References: <CAEFj985e=6y2RQcHy-3RgaYx63hMdfJ+CdgaqpPdjuehLj=sKA@mail.gmail.com>
 <87lhha1fp7.fsf@kamboji.qca.qualcomm.com>
 <CAEFj986cHR5J-LS+tz7tmoFAcHdkyZu9c2RqhnkAou1uK72c8w@mail.gmail.com>
 <CA+BoTQnJRUYzyGPpz1RVptfgLM1+Y1bpkGBG-OvXMZJqbC_Snw@mail.gmail.com>
 <CAEFj984ibOKiLESUDi9gO66iS7WAbvrJeH-2kDA3PNZU9p2Aqg@mail.gmail.com>
Message-ID: <CA+BoTQkhVx4LComy6KU_DEeoO5yzEudkNUVaVJMNXQHB3aGjeg@mail.gmail.com>

On 30 April 2015 at 08:46, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
> Hi, Michal
>
> Attached is the partial log. Hopefully it is useful for you.

Thanks.

It looks like the device goes through the cold reset. I would expect
the device to work after that. Maybe WLE900N5-23 board is wired
differently or 10.2 doesn't reset a few HW registers anymore.

Anyway, the device seems to crash after it's started and upped. It
gets to transmit 2 beacons and then it crashes. I didn't see any Rx
(WMI nor HTT) events which leads me to think that the HW MAC Rx may
contain some invalid/stale DMA pointers which subsequently lead to CE
failure and device CPU crash. If you could run the device on a x86
with IOMMU enabled it'd be probably possible to narrow down the search
by looking at DMAR error addresses. Hmm.. I recall there are a few HW
MAC Rx rings. Maybe 10.2 uses more than 10.1 did but doesn't reset
them properly?

I assume you need to reboot the machine before it starts to work
again, no? Or does driver reload alone help? Did you try to `echo 1 >
/sys/bus/pci/devices/xxxx:xx:xx.x/remove` and `echo 1 >
/sys/bus/pci/rescan`? Or did you try to swap fw from 10.2 to 10.1
(needs driver reload) after the "bad bad crashes" start to appear?


Micha?


From yeohchunyeow at gmail.com  Thu Apr 30 03:31:01 2015
From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 30 Apr 2015 18:31:01 +0800
Subject: Compex WLE900N5-23
In-Reply-To: <CA+BoTQkhVx4LComy6KU_DEeoO5yzEudkNUVaVJMNXQHB3aGjeg@mail.gmail.com>
References: <CAEFj985e=6y2RQcHy-3RgaYx63hMdfJ+CdgaqpPdjuehLj=sKA@mail.gmail.com>
 <87lhha1fp7.fsf@kamboji.qca.qualcomm.com>
 <CAEFj986cHR5J-LS+tz7tmoFAcHdkyZu9c2RqhnkAou1uK72c8w@mail.gmail.com>
 <CA+BoTQnJRUYzyGPpz1RVptfgLM1+Y1bpkGBG-OvXMZJqbC_Snw@mail.gmail.com>
 <CAEFj984ibOKiLESUDi9gO66iS7WAbvrJeH-2kDA3PNZU9p2Aqg@mail.gmail.com>
 <CA+BoTQkhVx4LComy6KU_DEeoO5yzEudkNUVaVJMNXQHB3aGjeg@mail.gmail.com>
Message-ID: <CAEFj987NuHtuOkU6Yp_jjSq1-c9QrR14VYndbVy5CW5iKDnxwA@mail.gmail.com>

Hi, Michal

> I assume you need to reboot the machine before it starts to work
> again, no? Or does driver reload alone help?

The system looks very sluggish once the firmware start to crash. But
not required reboot.

> Did you try to `echo 1 >
> /sys/bus/pci/devices/xxxx:xx:xx.x/remove` and `echo 1 >
> /sys/bus/pci/rescan`?
> Or did you try to swap fw from 10.2 to 10.1
> (needs driver reload) after the "bad bad crashes" start to appear?
>

I try to load 10.1 after the firmware crashed on 10.2 and it is
working. See log below.

So no changes at all for this board to use 10.2 firmware?

----
Chun-Yeow


[  169.530000] ieee80211 phy0: Hardware restart was requested
[  172.110000] ath10k_pci 0000:00:00.0: device successfully recovered
[  172.450000] ath10k_pci 0000:00:00.0: firmware crashed! (uuid
529a0c02-8d7b-4830-87ef-e491503db08c)
[  172.460000] ath10k_pci 0000:00:00.0: qca988x hw2.0 (0x4100016c,
0x043202ff) fw 10.2-00082-4-2 api 3 htt 2.1 wmi 3 cal otp max_sta 128
[  172.480000] ath10k_pci 0000:00:00.0: debug 1 debugfs 1 tracing 0
dfs 1 testmode 1
[  172.500000] ath10k_warn: 12 callbacks suppressed
[  172.500000] ath10k_pci 0000:00:00.0: failed to read diag value at
0x10100804: -16
[  172.510000] ath10k_pci 0000:00:00.0: failed to get memcpy hi
address for firmware address 4: -16
[  172.520000] ath10k_pci 0000:00:00.0: failed to read firmware dump area: -16
[  172.620000] ieee80211 phy0: Hardware restart was requested
[  172.620000] ath10k_pci 0000:00:00.0: failed to to request monitor
vdev 1 stop: -143
[  172.630000] ath10k_pci 0000:00:00.0: failed to synchronize monitor
vdev 1 stop: -143
[  172.640000] ath10k_pci 0000:00:00.0: failed to stop monitor vdev: -143
[  172.850000] ath10k_pci 0000:00:00.0: failed to read diag value at
0x10100800: -16
[  172.860000] ath10k_pci 0000:00:00.0: failed to poke copy engine: -16
[  172.970000] ath10k_pci 0000:00:00.0: failed to read diag value at
0x10100800: -16
[  172.980000] ath10k_pci 0000:00:00.0: failed to poke copy engine: -16
[  173.090000] ath10k_pci 0000:00:00.0: failed to read diag value at
0x10100800: -16
[  175.240000] ath10k_pci 0000:00:00.0: device successfully recovered
[  175.360000] br-lan: port 2(wlan0) entered disabled state
[  175.370000] device wlan0 left promiscuous mode
[  175.370000] br-lan: port 2(wlan0) entered disabled state
[  199.310000] pci 0000:00:00.0: [168c:003c] type 00 class 0x028000
[  199.310000] pci 0000:00:00.0: reg 0x10: [mem 0x10000000-0x101fffff 64bit]
[  199.310000] pci 0000:00:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
[  199.310000] pci 0000:00:00.0: supports D1 D2
[  199.310000] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
[  199.310000] pci 0000:00:00.0: BAR 0: assigned [mem
0x10000000-0x101fffff 64bit]
[  199.320000] pci 0000:00:00.0: BAR 6: assigned [mem
0x10200000-0x1020ffff pref]
[  199.320000] ath10k_pci 0000:00:00.0: pci irq legacy interrupts 0
irq_mode 0 reset_mode 0
[  199.540000] ath10k_pci 0000:00:00.0: Direct firmware load for
ath10k/cal-pci-0000:00:00.0.bin failed with error -2
[  199.550000] ath10k_pci 0000:00:00.0: Falling back to user helper
[  199.640000] firmware ath10k!cal-pci-0000:00:00.0.bin:
firmware_loading_store: map pages failed
[  199.650000] ath10k_pci 0000:00:00.0: Direct firmware load for
ath10k/QCA988X/hw2.0/firmware-4.bin failed with error -2
[  199.660000] ath10k_pci 0000:00:00.0: Falling back to user helper
[  199.760000] firmware ath10k!QCA988X!hw2.0!firmware-4.bin:
firmware_loading_store: map pages failed
[  199.770000] ath10k_pci 0000:00:00.0: could not fetch firmware file
'ath10k/QCA988X/hw2.0/firmware-4.bin': -11
[  199.780000] ath10k_pci 0000:00:00.0: Direct firmware load for
ath10k/QCA988X/hw2.0/firmware-3.bin failed with error -2
[  199.790000] ath10k_pci 0000:00:00.0: Falling back to user helper
[  199.880000] firmware ath10k!QCA988X!hw2.0!firmware-3.bin:
firmware_loading_store: map pages failed
[  199.890000] ath10k_pci 0000:00:00.0: could not fetch firmware file
'ath10k/QCA988X/hw2.0/firmware-3.bin': -11
[  201.060000] ath10k_pci 0000:00:00.0: qca988x hw2.0 (0x4100016c,
0x043202ff) fw 10.1.467.2-1 api 2 htt 2.1 wmi 2 cal otp max_sta 128
[  201.070000] ath10k_pci 0000:00:00.0: debug 1 debugfs 1 tracing 0
dfs 1 testmode 1
[  201.180000] ath: EEPROM regdomain: 0x0
[  201.180000] ath: EEPROM indicates default country code should be used
[  201.180000] ath: doing EEPROM country->regdmn map search
[  201.180000] ath: country maps to regdmn code: 0x3a
[  201.180000] ath: Country alpha2 being used: US
[  201.180000] ath: Regpair used: 0x3a
[  202.310000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready


From michal.kazior at tieto.com  Thu Apr 30 03:50:22 2015
From: michal.kazior at tieto.com (Michal Kazior)
Date: Thu, 30 Apr 2015 12:50:22 +0200
Subject: Compex WLE900N5-23
In-Reply-To: <CAEFj987NuHtuOkU6Yp_jjSq1-c9QrR14VYndbVy5CW5iKDnxwA@mail.gmail.com>
References: <CAEFj985e=6y2RQcHy-3RgaYx63hMdfJ+CdgaqpPdjuehLj=sKA@mail.gmail.com>
 <87lhha1fp7.fsf@kamboji.qca.qualcomm.com>
 <CAEFj986cHR5J-LS+tz7tmoFAcHdkyZu9c2RqhnkAou1uK72c8w@mail.gmail.com>
 <CA+BoTQnJRUYzyGPpz1RVptfgLM1+Y1bpkGBG-OvXMZJqbC_Snw@mail.gmail.com>
 <CAEFj984ibOKiLESUDi9gO66iS7WAbvrJeH-2kDA3PNZU9p2Aqg@mail.gmail.com>
 <CA+BoTQkhVx4LComy6KU_DEeoO5yzEudkNUVaVJMNXQHB3aGjeg@mail.gmail.com>
 <CAEFj987NuHtuOkU6Yp_jjSq1-c9QrR14VYndbVy5CW5iKDnxwA@mail.gmail.com>
Message-ID: <CA+BoTQnSDjOXDmSmVcBHTtCbz4Z4XHbr1XM=d03P2R2U7DCjBg@mail.gmail.com>

On 30 April 2015 at 12:31, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
> Hi, Michal
>
>> I assume you need to reboot the machine before it starts to work
>> again, no? Or does driver reload alone help?
>
> The system looks very sluggish once the firmware start to crash. But
> not required reboot.

I assume it's due to crash-restart going over and over which involves
taking RTNL - this could reduce system responsiveness.


>> Did you try to `echo 1 >
>> /sys/bus/pci/devices/xxxx:xx:xx.x/remove` and `echo 1 >
>> /sys/bus/pci/rescan`?
>> Or did you try to swap fw from 10.2 to 10.1
>> (needs driver reload) after the "bad bad crashes" start to appear?
>>
>
> I try to load 10.1 after the firmware crashed on 10.2 and it is
> working. See log below.
>
> So no changes at all for this board to use 10.2 firmware?
[...]

Did you try to reload the driver alone (without changing firmware)?
I'd like to know if it's actually 10.2 -> 10.1 that makes the crashing
go away.


Micha?


From moritz.morawietz at informatik.uni-oldenburg.de  Thu Apr 30 06:03:21 2015
From: moritz.morawietz at informatik.uni-oldenburg.de (Moritz Morawietz)
Date: Thu, 30 Apr 2015 15:03:21 +0200
Subject: QCA6174 hw2.1?
In-Reply-To: <5541722A.2060109@gmx.com>
References: <trinity-d51578c9-4e28-4805-b58e-fdd5388949da-1426217948333@msvc-mesg-gmx002>
 <CA+BoTQnGQC9sy_Qhiv4peeRsF2dY+2yd12GTgJpyRhrgMTg+Yw@mail.gmail.com>
 <trinity-2097dd2e-b8b3-40c5-9eed-c0dc7d8690af-1426260485155@3capp-mailcom-lxa11>
 <CA+BoTQnKJE0w0SZrh-p2KaKe62t4=cRLnjeKu+t9aeE+LFce-w@mail.gmail.com>
 <loom.20150425T025815-684@post.gmane.org>
 <CAJAVYN208PQpnt5oQPi1hdYW71WMVJReBNSY-OqZ9aCb0yuiaA@mail.gmail.com>
 <553B8F89.4040908@gmx.com>
 <CAJAVYN1XKYdGqx4pzg3C9kSxj6_qwr4raoDJm7e+VLy1P=dsdw@mail.gmail.com>
 <553CF1EE.50807@gmx.com> <553D8112.2050300@gmx.com>
 <CA+-y_t-L5tAYRfT5+WzbB_EvZbWDO3hys9GD8Ms7fFhT_9cy_Q@mail.gmail.com>
 <553E5011.2050404@gmx.com>
 <CAJAVYN2WGEwrajUKFOpYPC7YWnovSs3pmQfjmP74hfwW-epJ2Q@mail.gmail.com>
 <CA+-y_t8pm+GPEaKX6cYta-Q4kiAd6mFKLO37nmS6pwPV63_VyA@mail.gmail.com>
 <5541722A.2060109@gmx.com>
Message-ID: <CA+-y_t9Zq649otKN3B6tYrJ6_By7H3PEMtB4=aEeDXEG9C=1Rw@mail.gmail.com>

I used  4.0.0-2. Also i had one kernel build where it worked, but,
because I didn't knew that you have to install nvidia drivers again, I
deletet it. I am not sure how i did it, so I'm currently trying again.
Maybe I need to understand the patching mechanisms, guess that would
help :D I did something with git?

Thank you a lot for your help so far!

2015-04-30 2:07 GMT+02:00 Gabriele Martino <g.martino at gmx.com>:
> On 28/04/2015 13:55, Moritz Morawietz wrote:
>> Many thanks for your fast help!
>>
>> I've made some progress, but ran into other problems.
>> If i compile ath10_pci, ath10k_core and ath from kvalo's tree and load
>> them, i get following dmesg output:
>>
>> [    2.980448] ath10k_pci 0000:06:00.0: enabling device (0000 -> 0002)
>> [    2.980750] ath10k_pci 0000:06:00.0: pci irq msi-x interrupts 8
>> irq_mode 0 reset_mode 0
>> [    3.158860] ath10k_pci 0000:06:00.0: Direct firmware load for
>> ath10k/cal-pci-0000:06:00.0.bin failed with error -2
>> [    3.159611] ath10k_pci 0000:06:00.0: Direct firmware load for
>> ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with
>> error -2
>> [    3.159613] ath10k_pci 0000:06:00.0: failed to load spec board
>> file, falling back to generic: -2
>> [    3.159922] ath10k_pci 0000:06:00.0: Direct firmware load for
>> ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2
>> [    3.159924] ath10k_pci 0000:06:00.0: could not fetch firmware file
>> 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2
>> [    4.360946] ath10k_pci 0000:06:00.0: qca6174 hw2.1 (0x05010000,
>> 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt
>> 3.1 wmi 4 cal otp max_sta 32
>> [    4.360950] ath10k_pci 0000:06:00.0: debug 1 debugfs 1 tracing 1
>> dfs 0 testmode 0
>> [    4.430068] ath: EEPROM regdomain: 0x6c
>> [    4.430070] ath: EEPROM indicates we should expect a direct regpair map
>> [    4.430072] ath: Country alpha2 being used: 00
>> [    4.430072] ath: Regpair used: 0x6c
>> [    4.430078] ath10k_pci 0000:06:00.0: failed to register ieee80211: -22
>> [    4.430097] ath10k_pci 0000:06:00.0: could not register to mac80211 (-22)
>>
>> So I compiled mac80211, and tried to load it. What i get is a load of
>> that messages:
>>
>> [  226.812494] mac80211: Unknown symbol cfg80211_cqm_rssi_notify (err -22)
>> [  226.812497] mac80211: disagrees about version of symbol cfg80211_auth_timeout
>> [  226.812497] mac80211: Unknown symbol cfg80211_auth_timeout (err -22)
>> [  226.812498] mac80211: disagrees about version of symbol
>> cfg80211_rx_unprot_mlme_mgmt
>> [  226.812499] mac80211: Unknown symbol cfg80211_rx_unprot_mlme_mgmt (err -22)
>>
>> Because mac80211 depends on cfg80211, i compilied and tested it. The
>> error messages reduced to
>>
>> [  632.208849] mac80211: Unknown symbol rhashtable_insert_rehash (err 0)
>> [  632.208881] mac80211: Unknown symbol rhashtable_insert_slow (err 0)
>>
>> Know I'm stuck. I'll try to compile and use the whole kernel (it's
>> compiling right now), but would prefer to just change the modules.
> I could find some references to "rhashtable_insert_rehash" with grep:
> /usr/src/linux/lib/rhashtable.c:int rhashtable_insert_rehash(struct
> rhashtable *ht)
> /usr/src/linux/lib/rhashtable.c:EXPORT_SYMBOL_GPL(rhashtable_insert_rehash);
>
> This file is present in 3.18.11 kernel (I don't have older sources on
> this laptop).
> Which distribution and kernel are you using?
> You are compiling 4.0 (-> 3.20) modules, so you're likely to get strange
> issues if your kernel is too old.
>
> Regards,
> Gabriele
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


From mindfsck at gmail.com  Thu Apr 30 11:26:09 2015
From: mindfsck at gmail.com (mindfsck)
Date: Thu, 30 Apr 2015 20:26:09 +0200
Subject: Rate marked as a VHT rate but data is invalid: MCS: 10, NSS: 2
Message-ID: <554273C1.7050203@gmail.com>

Hello,

I got my Broadcom card somehow working always for a handful seconds 
following this guide:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1383184/comments/115

So first of all a big thank you! :)

When I googled my problem (this emails' subject line) I found mostly 
ath9k from 2013...
Maybe someone here can point me to a fix or workaround (if available)?
I can change kernel code, apply patches, test things etc.

Here is the kernel log:
--
[    5.319175] ath10k_pci 0000:03:00.0: pci irq msi-x interrupts 8 
irq_mode 0 reset_mode 0
[    5.505523] ath10k_pci 0000:03:00.0: Direct firmware load for 
ath10k/cal-pci-0000:03:00.0.bin failed with error -2
[    5.505773] ath10k_pci 0000:03:00.0: Direct firmware load for 
ath10k/QCA6174/hw2.1/board-pci-168c:003e:11ad:0804.bin failed with error -2
[    5.505775] ath10k_pci 0000:03:00.0: failed to load spec board file, 
falling back to generic: -2
[    5.505946] ath10k_pci 0000:03:00.0: Direct firmware load for 
ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2
[    5.505948] ath10k_pci 0000:03:00.0: could not fetch firmware file 
'ath10k/QCA6174/hw2.1/firmware-5.bin': -2

...

[   10.315505] ahci 0000:00:1f.2: port does not support device sleep
[   14.314165] wlan1: authenticate with 00:1b:2f:61:b5:e8
[   14.391351] wlan1: send auth to 00:1b:2f:61:b5:e8 (try 1/3)
[   14.393075] wlan1: authenticated
[   14.393232] ath10k_pci 0000:03:00.0 wlan1: disabling HT as WMM/QoS is 
not supported by the AP
[   14.393235] ath10k_pci 0000:03:00.0 wlan1: disabling VHT as WMM/QoS 
is not supported by the AP
[   14.394803] wlan1: associate with 00:1b:2f:61:b5:e8 (try 1/3)
[   14.397284] wlan1: RX AssocResp from 00:1b:2f:61:b5:e8 (capab=0x431 
status=0 aid=3)
[   14.420679] wlan1: associated
[   14.420709] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[   14.552494] ------------[ cut here ]------------
[   14.552520] WARNING: CPU: 2 PID: 0 at net/mac80211/rx.c:3578 
ieee80211_rx+0x26c/0x940 [mac80211]()
[   14.552522] Rate marked as a VHT rate but data is invalid: MCS: 10, 
NSS: 2
[   14.552523] Modules linked in: ctr ccm bbswitch(OE) rfcomm bnep 
binfmt_misc arc4 snd_hda_codec_hdmi rtsx_usb_ms memstick rtsx_usb_sdmmc 
rtsx_usb ath10k_pci ath10k_core joydev ath mac80211 acer_wmi 
hid_multitouch sparse_keymap i915 cfg80211 intel_rapl iosf_mbi 
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm uvcvideo 
btusb crct10dif_pclmul snd_hda_codec_realtek videobuf2_vmalloc 
crc32_pclmul snd_hda_codec_generic videobuf2_memops btbcm 
ghash_clmulni_intel btintel videobuf2_core bluetooth v4l2_common 
videodev aesni_intel aes_x86_64 lrw gf128mul media snd_soc_rt5640 
snd_hda_intel glue_helper snd_soc_rl6231 ablk_helper snd_hda_controller 
snd_soc_core cryptd snd_hda_codec serio_raw snd_compress snd_hda_core 
snd_pcm_dmaengine snd_hwdep dw_dmac snd_pcm dw_dmac_core video wmi 
drm_kms_helper snd_seq_midi
[   14.552554]  snd_seq_midi_event snd_rawmidi snd_seq drm 
snd_seq_device snd_timer i2c_hid mei_me snd hid snd_soc_sst_acpi 
nls_iso8859_1 shpchp mei parport_pc lpc_ich 8250_dw spi_pxa2xx_platform 
i2c_designware_platform i2c_designware_core acpi_pad soundcore 
soc_button_array ppdev mac_hid i2c_algo_bit lp parport r8169 ahci 
sdhci_acpi sdhci libahci mii
[   14.552571] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G OE   
4.1.0-rc1-wl-ath #1
[   14.552573] Hardware name: Acer Aspire VN7-571G/Aspire VN7-571G, BIOS 
V1.11 11/21/2014
[   14.552574]  ffffffffc09d775d ffff88025ec83be8 ffffffff817cca61 
0000000000005e80
[   14.552576]  ffff88025ec83c38 ffff88025ec83c28 ffffffff8107846a 
ffff88025ec83c8c
[   14.552578]  ffff88009a1cc6a0 ffff88023d8a6d00 ffff88009a1cd3a0 
0000000000000000
[   14.552580] Call Trace:
[   14.552581]  <IRQ>  [<ffffffff817cca61>] dump_stack+0x45/0x57
[   14.552588]  [<ffffffff8107846a>] warn_slowpath_common+0x8a/0xc0
[   14.552589]  [<ffffffff810784e6>] warn_slowpath_fmt+0x46/0x50
[   14.552600]  [<ffffffffc098c184>] ? __iterate_interfaces+0xc4/0x120 
[mac80211]
[   14.552609]  [<ffffffffc09837ec>] ieee80211_rx+0x26c/0x940 [mac80211]
[   14.552618]  [<ffffffffc098c1f1>] ? 
ieee80211_iterate_active_interfaces_atomic+0x11/0x20 [mac80211]
[   14.552623]  [<ffffffffc07dd9d7>] ? ath10k_get_arvif+0x47/0x80 
[ath10k_core]
[   14.552628]  [<ffffffffc07e6490>] ath10k_process_rx+0x90/0x1b0 
[ath10k_core]
[   14.552632]  [<ffffffffc07e65f4>] ath10k_htt_rx_h_deliver+0x44/0x90 
[ath10k_core]
[   14.552635]  [<ffffffffc07e7442>] 
ath10k_htt_txrx_compl_task+0x332/0xe10 [ath10k_core]
[   14.552638]  [<ffffffffc0498887>] ? 
ath10k_pci_ce_recv_data+0x167/0x1c0 [ath10k_pci]
[   14.552640]  [<ffffffffc049b157>] ? 
ath10k_ce_per_engine_service+0xb7/0xd0 [ath10k_pci]
[   14.552643]  [<ffffffff8107c5b6>] tasklet_action+0xe6/0xf0
[   14.552645]  [<ffffffff8107c98b>] __do_softirq+0x11b/0x2c0
[   14.552647]  [<ffffffff8107cd2d>] irq_exit+0xfd/0x110
[   14.552649]  [<ffffffff817d6b58>] do_IRQ+0x58/0xf0
[   14.552651]  [<ffffffff817d49ee>] common_interrupt+0x6e/0x6e
[   14.552652]  <EOI>  [<ffffffff816697d6>] ? cpuidle_enter_state+0x66/0x160
[   14.552657]  [<ffffffff816697c1>] ? cpuidle_enter_state+0x51/0x160
[   14.552659]  [<ffffffff81669907>] cpuidle_enter+0x17/0x20
[   14.552662]  [<ffffffff810bcca9>] cpu_startup_entry+0x3d9/0x480
[   14.552665]  [<ffffffff8104cb1e>] start_secondary+0x17e/0x1a0
[   14.552666] ---[ end trace a13a65cd6d415bc7 ]---
[   15.316292] systemd-logind[932]: Failed to start unit 
user at 1000.service: Unknown unit: user at 1000.service
[   15.316326] systemd-logind[932]: Failed to start user service: 
Unknown unit: user at 1000.service
[   15.319291] systemd-logind[932]: New session c2 of user mf.
[   96.139737] systemd-logind[932]: New session c3 of user mf.
[   96.139759] systemd-logind[932]: Linked /tmp/.X11-unix/X0 to 
/run/user/1000/X11-display.

...

[  210.696624] ath10k_pci 0000:03:00.0: firmware crashed! (uuid 
14ca9744-7171-4365-9612-3f5ede30cbec)
[  210.696635] ath10k_pci 0000:03:00.0: qca6174 hw2.1 (0x05010000, 
0x003405ff, 168c:003e:11ad:0804 fallback) fw killer-n1525-fw api 4 htt 
3.0 wmi 4 cal otp max_sta 32
[  210.696637] ath10k_pci 0000:03:00.0: debug 0 debugfs 1 tracing 1 dfs 
0 testmode 0
[  210.698647] ath10k_pci 0000:03:00.0: firmware register dump:
[  210.698648] ath10k_pci 0000:03:00.0: [00]: 0x05010000 0x00000000 
0x0099BFAA 0x00000000
[  210.698650] ath10k_pci 0000:03:00.0: [04]: 0x00000000 0x00000000 
0x00000000 0x00000000
[  210.698651] ath10k_pci 0000:03:00.0: [08]: 0x00000000 0x00000000 
0x00000000 0x00000000
[  210.698652] ath10k_pci 0000:03:00.0: [12]: 0x00000000 0x00000000 
0x00000000 0x00000000
[  210.698653] ath10k_pci 0000:03:00.0: [16]: 0x00000000 0x00000000 
0x00000000 0x0099BFAA
[  210.698655] ath10k_pci 0000:03:00.0: [20]: 0x00000000 0x004018F0 
0x00000000 0x00000000
[  210.698656] ath10k_pci 0000:03:00.0: [24]: 0x00000000 0x00000000 
0x00000000 0x00000000
[  210.698657] ath10k_pci 0000:03:00.0: [28]: 0x00000000 0x00000000 
0x00000000 0x00000000
[  210.698658] ath10k_pci 0000:03:00.0: [32]: 0x00000000 0x00000000 
0x00000000 0x00000000
[  210.698659] ath10k_pci 0000:03:00.0: [36]: 0x00000000 0x00000000 
0x00000000 0x00000000
[  210.698660] ath10k_pci 0000:03:00.0: [40]: 0x00000000 0x00000000 
0x00000000 0x00000000
[  210.698661] ath10k_pci 0000:03:00.0: [44]: 0x00000000 0x00000000 
0x00000000 0x00000000
[  210.698663] ath10k_pci 0000:03:00.0: [48]: 0x00000000 0x00000000 
0x00000000 0x00000000
[  210.698664] ath10k_pci 0000:03:00.0: [52]: 0x00000000 0x00000000 
0x00000000 0x00000000
[  210.698665] ath10k_pci 0000:03:00.0: [56]: 0x00000000 0x00000000 
0x00000000 0x00000000
[  210.742185] ath10k_pci 0000:03:00.0: device has crashed during init
[  210.766216] ath10k_pci 0000:03:00.0: device has crashed during init
[  210.766218] ath10k_pci 0000:03:00.0: failed to wait for target init: -70
[  210.766650] ieee80211 phy0: Hardware restart was requested
[  210.766663] ath10k_pci 0000:03:00.0: failed to synchronize monitor 
vdev 1 stop: -108
[  210.766664] ath10k_pci 0000:03:00.0: failed to stop monitor vdev: -108
[  210.806322] ath10k_pci 0000:03:00.0: device has crashed during init
[  210.830324] ath10k_pci 0000:03:00.0: device has crashed during init
[  210.830327] ath10k_pci 0000:03:00.0: failed to wait for target init: -70
[  212.227905] ath10k_pci 0000:03:00.0: device successfully recovered
[  216.232179] ath10k_pci 0000:03:00.0: firmware crashed! (uuid 
9c23d4de-4420-4632-8665-62e3a7076276)
[  216.232190] ath10k_pci 0000:03:00.0: qca6174 hw2.1 (0x05010000, 
0x003405ff, 168c:003e:11ad:0804 fallback) fw killer-n1525-fw api 4 htt 
3.0 wmi 4 cal otp max_sta 32
[  216.232192] ath10k_pci 0000:03:00.0: debug 0 debugfs 1 tracing 1 dfs 
0 testmode 0
[  216.234197] ath10k_pci 0000:03:00.0: firmware register dump:

...

--

Thanks.


From ck+ath10k at bl4ckb0x.de  Thu Apr 30 17:09:46 2015
From: ck+ath10k at bl4ckb0x.de (Conrad Kostecki)
Date: Fri, 01 May 2015 02:09:46 +0200
Subject: failed to set kickout threshold on vdev 0: -11
Message-ID: <ee86758838b649211fa41226c162e7b4@bl4ckb0x.de>

Hi!
I am having some problems with my two ath10k card since kernel 4.0..

After booting a fresh system, I am unable to start hostapd, as it fails 
to start up the cards:

[ 3529.630065] ath10k_pci 0000:07:00.0: failed to set kickout threshold 
on vdev 0: -11
[ 3529.630076] ath10k_pci 0000:07:00.0: failed to set vdev 0 kickout 
parameters: -11
[ 3538.630064] ath10k_pci 0000:07:00.0: could not suspend target (-11)
[ 3696.390142] ath10k_pci 0000:0c:00.0: failed to set kickout threshold 
on vdev 0: -11
[ 3696.390153] ath10k_pci 0000:0c:00.0: failed to set vdev 0 kickout 
parameters: -11
[ 3705.390129] ath10k_pci 0000:0c:00.0: could not suspend target (-11)

After trying again 2-3 times, it's starting working and hostapd is 
starting up.

OS: Gentoo
Kernel: 4.0.1
ath10k_pci 0000:0c:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 
10.2-00082-4-2 api 4 htt 2.1 wmi 3 cal otp max_sta 128
ath10k_pci 0000:07:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 
10.2-00082-4-2 api 4 htt 2.1 wmi 3 cal otp max_sta 128

What's going on? Anybody some ideas?

Cheers
Conrad


