* Re: [PATCH 1/2] ath10k: add per peer htt tx stats support for 10.4
From: Valo, Kalle @ 2016-10-12 4:59 UTC (permalink / raw)
To: Yeoh Chun-Yeow
Cc: Kolli, Anilkumar, akolli@codeaurora.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAEFj985tCc_4Q_zfwRtoT0fjfZv0u_c5E8SRSQVz=V4tiHh+GA@mail.gmail.com>
Yeoh Chun-Yeow <yeohchunyeow@gmail.com> writes:
> On Fri, Oct 7, 2016 at 10:58 PM, <akolli@qti.qualcomm.com> wrote:
>> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>>
>> Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
>> event, Firmware sends one HTT event for every four PPDUs.
>> HTT payload has success pkts/bytes, failed pkts/bytes, retry
>> pkts/bytes and rate info per ppdu.
>> Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
>> which are nowadays enabled by default.
>>
>> Parse peer stats and update the tx rate information per STA.
>>
>> tx rate, Peer stats are tested on QCA4019 with Firmware version
>> 10.4-3.2.1-00028.
>>
>
> Is QCA988X supported? I have tried to test with
> firmware-5.bin_10.2.4.70.56 but not working.
My understanding is that 10.2 branch does not have this feature,
unfortunately.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [v3] ath10k: cache calibration data when the core is stopped
From: Kalle Valo @ 2016-10-12 5:05 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless, Marty Faltesek
In-Reply-To: <1476115204-7385-1-git-send-email-kvalo@qca.qualcomm.com>
Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> From: Marty Faltesek <mfaltesek@google.com>
>
> Commit 0b8e3c4ca29f ("ath10k: move cal data len to hw_params") broke retrieving
> the calibration data from cal_data debugfs file. The length of file was always
> zero. The reason is:
>
> static ssize_t ath10k_debug_cal_data_read(struct file *file,
> char __user *user_buf,
> size_t count, loff_t *ppos)
> {
> struct ath10k *ar = file->private_data;
> void *buf = file->private_data;
>
>
> This is obviously bogus, private_data cannot contain both struct ath10k and the
> buffer. Fix it by caching calibration data to ar->debug.cal_data. This also
> allows it to be accessed when the device is not active (interface is down).
>
> The cal_data buffer is fixed size because during the first firmware probe we
> don't yet know what will be the lenght of the calibration data. It was simplest
> just to use a fixed length. There's a WARN_ON() in
> ath10k_debug_cal_data_fetch() if the buffer is too small.
>
> Tested with qca988x and firmware 10.2.4.70.56.
>
> Reported-by: Nikolay Martynov <mar.kolya@gmail.com>
> Fixes: 0b8e3c4ca29f ("ath10k: move cal data len to hw_params")
> Cc: stable@vger.kernel.org # 4.7+
> Signed-off-by: Marty Faltesek <mfaltesek@google.com>
> [kvalo@qca.qualcomm.com: improve commit log and minor other changes]
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
There were few checkpatch warnings, I fixed those in the pending branch.
drivers/net/wireless/ath/ath10k/debug.c:1472: code indent should use tabs where possible
drivers/net/wireless/ath/ath10k/debug.c:1504: code indent should use tabs where possible
drivers/net/wireless/ath/ath10k/debug.c:1504: please, no spaces at the start of a line
drivers/net/wireless/ath/ath10k/debug.c:1505: code indent should use tabs where possible
drivers/net/wireless/ath/ath10k/debug.c:1505: please, no spaces at the start of a line
--
https://patchwork.kernel.org/patch/9369685/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add per peer htt tx stats support for 10.4
From: Valo, Kalle @ 2016-10-12 4:59 UTC (permalink / raw)
To: Kolli, Anilkumar
Cc: ath10k@lists.infradead.org, akolli@codeaurora.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1475852332-18217-2-git-send-email-akolli@qti.qualcomm.com>
<akolli@qti.qualcomm.com> writes:
> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>
> Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
> event, Firmware sends one HTT event for every four PPDUs.
> HTT payload has success pkts/bytes, failed pkts/bytes, retry
> pkts/bytes and rate info per ppdu.
> Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
> which are nowadays enabled by default.
>
> Parse peer stats and update the tx rate information per STA.
>
> tx rate, Peer stats are tested on QCA4019 with Firmware version
> 10.4-3.2.1-00028.
>
> Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
This and patch 2 add few new warnings:
drivers/net/wireless/ath/ath10k/htt_rx.c: In function 'ath10k_htt_fetch_pee=
r_stats':
drivers/net/wireless/ath/ath10k/htt_rx.c:2279:3: warning: too many argument=
s for format [-Wformat-extra-args]
drivers/net/wireless/ath/ath10k/htt_rx.c:2285:17: warning: incorrect type i=
n assignment (different base types)
drivers/net/wireless/ath/ath10k/htt_rx.c:2285:17: expected unsigned int =
[unsigned] [usertype] peer_id
drivers/net/wireless/ath/ath10k/htt_rx.c:2285:17: got restricted __le16 =
[usertype] peer_id
drivers/net/wireless/ath/ath10k/debugfs_sta.c:84: space required before the=
open parenthesis '('
--=20
Kalle Valo=
^ permalink raw reply
* Re: Revert "ath9k_hw: implement temperature compensation support for AR9003+"
From: Kalle Valo @ 2016-10-12 5:21 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo
In-Reply-To: <20161011174649.19210-1-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> wrote:
> This reverts commit 171f6402e4aa5cd3b8407f82501f7ea21fa54ccc.
> Some users report that this commit causes a regression in performance
> under some conditions.
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
I added these to the commit log:
Fixes: 171f6402e4aa ("ath9k_hw: implement temperature compensation support for AR9003+")
Cc: <stable@vger.kernel.org> #4.8
My understanding is that the commit is not in 4.7, hence only cc stable 4.8.
--
https://patchwork.kernel.org/patch/9371479/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Luca Coelho @ 2016-10-12 6:11 UTC (permalink / raw)
To: Paul Bolle, Chris Rorvick, Intel Linux Wireless,
Emmanuel Grumbach, Johannes Berg, Kalle Valo, Oren Givon
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1476180668.17022.21.camel@tiscali.nl>
Hi Paul,
On Tue, 2016-10-11 at 12:11 +0200, Paul Bolle wrote:
> On Mon, 2016-10-10 at 17:02 +0300, Luca Coelho wrote:
> > On Mon, 2016-10-10 at 02:19 -0500, Chris Rorvick wrote:
> > This is not coming from the NIC itself, but from the platform's ACPI
> > tables. Can you tell us which platform you are using?
>
>
> On my machine I'm seeing the same error as Chris. So what exactly do
> you mean with "platform" here?
By "platform" I meant the PC you are using. The ACPI table is created
by the OEM, so different PCs have different tables.
>
> > > Name (SPLX, Package (0x04)
> > > {
> > > Zero,
> > > Package (0x03)
> > > {
> > > 0,
> > > 1200,
> > > 1000
> > > },
> > > Package (0x03)
> > > {
> > > 0,
> > > 1200,
> > > 1000
> > > },
> > > Package (0x03)
> > > {
> > > 0,
> > > 1200,
> > > 1000
> > > }
> > > })
> >
> >
> > This is not the structure that we are expecting. We expect this:
> >
> > Name (SPLX, Package (0x02)
> > {
> > Zero,
> > Package (0x03)
> > {
> > 0x07,
> > <value>,
> > <value>
> > }
> > })
> >
> > ...as you correctly pointed out. The data in the structure you have is
> > not for WiFi (actually I don't think 0 is a valid value, but I'll
> > double-check).
>
>
> For what it's worth, on my machine I have twenty (!) SPLX entries, all
> reading:
> Name (SPLX, Package (0x04)
> {
> Zero,
> Package (0x03)
> {
> 0x80000000,
> 0x80000000,
> 0x80000000
> },
>
> Package (0x03)
> {
> 0x80000000,
> 0x80000000,
> 0x80000000
> },
>
> Package (0x03)
> {
> 0x80000000,
> 0x80000000,
> 0x80000000
> }
> })
Thanks. So this is another case where the first value doesn't match
what we are expecting and we should just ignore that.
> > There are other things that look a bit inconsistent in this code...
> > I'll try to find the official ACPI table definitions for this entries
> > to make sure it's correct.
>
>
> When I looked into this error, some time ago, I searched around a bit
> for documentation on this splx stuff. Sadly, commit bcb079a14d75
> ("iwlwifi: pcie: retrieve and parse ACPI power limitations") provides
> very few clues and my searches turned up nothing useful. So a pointer
> or two would be really appreciated.
Yeah, I looked into that commit too and there's not much there. I'll
try to find the documentation and, if I can, I'll share it with you.
> > > --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
> > > +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
> > > @@ -540,7 +540,7 @@ static u64 splx_get_pwr_limit(struct iwl_trans *trans, union acpi_object *splx)
> > > splx->package.count != 2 ||
> > > splx->package.elements[0].type != ACPI_TYPE_INTEGER ||
> > > splx->package.elements[0].integer.value != 0) {
> > > - IWL_ERR(trans, "Unsupported splx structure\n");
> > > + IWL_WARN(trans, "Unsupported splx structure, not limiting WiFi power\n");
> > > return 0;
> > > }
> >
> >
> > If this is really bothering you, I guess I could apply this patch for
> > now. But as I said, this is not solving the actual problem.
>
>
> Bikeshedding: I think IWL_INFO() is more appropriate, as info doesn't
> imply one needs to act on this message, while warn does imply that
> action is needed.
Right, but in fact, the code considers that if the SPLX method exists,
it must return a value iwlwifi can understand, thus the error. That
assumption is wrong, so we should just ignore entries that don't match
and continue without printing anything out (as would happen if the splx
method were not even there).
In any case, I will rework this code, so I'd prefer if we skip this
patch entirely.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] mac80211: fix sequence number allocation regression
From: Johannes Berg @ 2016-10-12 6:49 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless
Cc: Toke Høiland-Jørgensen, Bob Copeland
In-Reply-To: <20161011092831.85565-1-nbd@nbd.name>
On Tue, 2016-10-11 at 11:28 +0200, Felix Fietkau wrote:
> The recent commit that moved around TX handlers dropped the sequence
> number allocation at the end of ieee80211_tx_dequeue and calls
> ieee80211_tx_h_sequence instead (for the non-fast-xmit case).
> However, it did not change the fast-xmit sequence allocation
> condition
> in ieee80211_xmit_fast_finish, which skipped seqno alloc if
> intermediate
> tx queues are being used.
>
> Drop the now obsolete condition.
Hm. I don't know what tree you're looking at, but it looks like I *did*
in fact resolve this correctly; the (now) erroneous condition doesn't
exist in mac80211 nor in mac80211-next (nor net, net-next, linux).
It does seem to exist in wireless-testing, but that's not something I
can control.
johannes
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Paul Bolle @ 2016-10-12 6:52 UTC (permalink / raw)
To: Luca Coelho, Chris Rorvick, Intel Linux Wireless,
Emmanuel Grumbach, Johannes Berg, Kalle Valo, Oren Givon
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1476252719.7776.6.camel@coelho.fi>
Luca,
On Wed, 2016-10-12 at 09:11 +0300, Luca Coelho wrote:
> By "platform" I meant the PC you are using. The ACPI table is created
> by the OEM, so different PCs have different tables.
Like Chris I use a Dell XPS 13 (9350), but mine came with an AC 8260
out of it's assembly plant:
Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
> In any case, I will rework this code, so I'd prefer if we skip this
> patch entirely.
Feel free to prod me for testing whatever you come up with.
Paul Bolle
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Luca Coelho @ 2016-10-12 6:25 UTC (permalink / raw)
To: Chris Rorvick, Paul Bolle
Cc: Intel Linux Wireless, Emmanuel Grumbach, Johannes Berg,
Kalle Valo, Oren Givon, linux-wireless, netdev, linux-kernel
In-Reply-To: <CAEUsAPYDPCP0NBaTmy4xqFJhAS4xFQYinoNTknxFT23ef0dk4w@mail.gmail.com>
Hi Chris,
On Tue, 2016-10-11 at 09:09 -0500, Chris Rorvick wrote:
> On Tue, Oct 11, 2016 at 5:11 AM, Paul Bolle <pebolle@tiscali.nl> wrote:
> > > This is not coming from the NIC itself, but from the platform's ACPI
> > > tables. Can you tell us which platform you are using?
>
>
> Interesting. I'm running a Dell XPS 13 9350. I replaced the
> factory-provided Broadcom card with an AC 8260. I can update the
> commit log to reflect this.
Okay, so this makes sense. Those entries are probably formatted for
the Broadcom card, which the iwlwifi driver obviously doesn't
understand. The best we can do, as I already said, is to ignore values
we don't understand.
I will also check what is the correct procedure in such cases, because
it is possible, in theory, that the format *matches* but applies only
to another device.
> > > If this is really bothering you, I guess I could apply this patch for
> > > now. But as I said, this is not solving the actual problem.
> >
> >
> > Bikeshedding: I think IWL_INFO() is more appropriate, as info doesn't
> > imply one needs to act on this message, while warn does imply that
> > action is needed.
>
>
> Agreed. I still think making this a warning is appropriate, but it
> seems pretty clear this is not an error. This has nothing to do with
> how much it bothers me. An error tells the user something needs to be
> fixed, but in this case the interface is working fine. Making it a
> warning with an improved message will result in fewer people wasting
> their time.
Yes, so I'll try to stop wasting people's timing by trying to do the
correct thing without bothering the user at all. :)
Thanks for pointing this all out!
--
Cheers,
Luca.
^ permalink raw reply
* Re: [v2,1/2] ath10k: clean up HTT tx buffer allocation and free
From: Mohammed Shafi Shajakhan @ 2016-10-12 7:09 UTC (permalink / raw)
To: Kalle Valo; +Cc: Mohammed Shafi Shajakhan, ath10k, linux-wireless
In-Reply-To: <c617b703956d4a038349494b87f65d0a@euamsexm01a.eu.qualcomm.com>
Hi Kalle,
On Tue, Oct 11, 2016 at 01:36:22PM +0200, Kalle Valo wrote:
> Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> > From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >
> > cleanup 'ath10k_htt_tx_alloc' by introducing the API's
> > 'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
> > re-use them whereever needed
> >
> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> Applies but fails to build:
[shafi] sorry for the trouble again, I just figured out I had a private patch by
mistake and it worked for me, I will make sure that v3 is properly rebased
without any errors.
>
> drivers/net/wireless/ath/ath10k/htt_tx.c: In function ‘ath10k_htt_tx_free’:
> drivers/net/wireless/ath/ath10k/htt_tx.c:424:19: error: ‘struct ath10k_htt’ has no member named ‘txrx_compl_task’
> make[5]: *** [drivers/net/wireless/ath/ath10k/htt_tx.o] Error 1
> make[4]: *** [drivers/net/wireless/ath/ath10k] Error 2
> make[3]: *** [drivers/net/wireless/ath] Error 2
> make[2]: *** [drivers/net/wireless] Error 2
> make[1]: *** [drivers/net] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [drivers] Error 2
>
> 2 patches set to Changes Requested.
>
> 9363863 [v2,1/2] ath10k: clean up HTT tx buffer allocation and free
> 9363861 [v2,2/2] ath10k: Remove extraneous error message in tx alloc
>
> --
> https://patchwork.kernel.org/patch/9363863/
>
> Documentation about submitting wireless patches and checking status
> from patchwork:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>
^ permalink raw reply
* Re: [PATCHv2 1/3] mac80211: fix CMD_FRAME for AP_VLAN
From: Johannes Berg @ 2016-10-12 7:12 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1475493257-21841-1-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-03 at 13:14 +0200, Michael Braun wrote:
> When using IEEE 802.11r FT OVER-DS roaming with AP_VLAN, hostapd
> needs to
> send out a frame using CMD_FRAME for a station assigned to an AP_VLAN
> interface.
>
> Right now, the userspace needs to give the exact AP_VLAN interface
> index
> for CMD_FRAME; hostapd does not do this. Additionally, userspace
> cannot
> use GET_STATION to query the AP_VLAN ifidx, as while GET_STATION
> finds
> stations assigned to AP_VLAN even if the AP iface is queried, it does
> not
> return AP_VLAN ifidx (it returns the queried one).
>
> This breaks IEEE 802.11r over_ds with vlans, as the reply frame does
> not
> get out. This patch fixes this by using get_sta_bss for CMD_FRAME.
>
Applied, thanks.
johannes
^ permalink raw reply
* [PATCH] ath10k: Fix failure to send NULL func frame for 10.4
From: Mohammed Shafi Shajakhan @ 2016-10-12 7:29 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
This partially reverts 'commit 2cdce425aa33
("ath10k: Fix broken NULL func data frame status for 10.4")'
Unfortunately this breaks sending NULL func and the existing
issue of obtaining proper tx status for NULL function will be
fixed. Also update the comments for feature flag added to be
useless and not working
Fixes: 2cdce425aa33 "ath10k: Fix broken NULL func data frame status for
10.4"
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.h | 6 ++----
drivers/net/wireless/ath/ath10k/mac.c | 2 --
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index b367e9c..42c3f1b 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -552,10 +552,8 @@ enum ath10k_fw_features {
*/
ATH10K_FW_FEATURE_BTCOEX_PARAM = 14,
- /* Older firmware with HTT delivers incorrect tx status for null func
- * frames to driver, but this fixed in 10.2 and 10.4 firmware versions.
- * Also this workaround results in reporting of incorrect null func
- * status for 10.4. This flag is used to skip the workaround.
+ /* Unused flag and proven to be not working, enable this if you want
+ * to experiment sending NULL func data frames in HTT TX
*/
ATH10K_FW_FEATURE_SKIP_NULL_FUNC_WAR = 15,
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 4565321..86a6610 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3255,8 +3255,6 @@ ath10k_mac_tx_h_get_txmode(struct ath10k *ar,
if (ar->htt.target_version_major < 3 &&
(ieee80211_is_nullfunc(fc) || ieee80211_is_qos_nullfunc(fc)) &&
!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX,
- ar->running_fw->fw_file.fw_features) &&
- !test_bit(ATH10K_FW_FEATURE_SKIP_NULL_FUNC_WAR,
ar->running_fw->fw_file.fw_features))
return ATH10K_HW_TXRX_MGMT;
--
1.9.1
^ permalink raw reply related
* Re: [v2,1/2] ath10k: clean up HTT tx buffer allocation and free
From: Valo, Kalle @ 2016-10-12 7:35 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <20161012070918.GA2993@atheros-ThinkPad-T61>
Mohammed Shafi Shajakhan <mohammed@codeaurora.org> writes:
> Hi Kalle,
>
> On Tue, Oct 11, 2016 at 01:36:22PM +0200, Kalle Valo wrote:
>> Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
>> > From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>> >=20
>> > cleanup 'ath10k_htt_tx_alloc' by introducing the API's
>> > 'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
>> > re-use them whereever needed
>> >=20
>> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>>=20
>> Applies but fails to build:
>
> [shafi] sorry for the trouble again, I just figured out I had a private p=
atch by
> mistake and it worked for me, I will make sure that v3 is properly rebas=
ed
> without any errors.
Thanks. And no worries, I now have a script which does commit and build
tests semi-automatically and sends an email if it fails. Yay! This was a
good real life test for the script :)
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCHv3 2/3] mac80211: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-10-12 7:16 UTC (permalink / raw)
To: Michael Braun
Cc: linux-wireless, projekt-wlan, kvalo, akarwar, nishants,
Larry.Finger, Jes.Sorensen
In-Reply-To: <1475493257-21841-2-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-03 at 13:14 +0200, Michael Braun wrote:
> When using WPA security, the station and thus the required key is
> identified by its mac address when packets are received. So a
> station usually cannot spoof its source mac address.
>
> But when a station sends an A-MSDU frame, port control and crypto
> is done using the outer mac address, while the packets delivered
> and forwarded use the inner mac address.
> This might affect ARP/IP filtering on the AccessPoint.
>
> IEEE 802.11-2012 mandates that the outer source mac address should
> match the inner source address (section 8.3.2.2). For the destination
> mac address, matching is not required, as a wifi client may send all
> its traffic to the AP in order to have it forwarded.
This doesn't apply over my series now, so I'm dropping it - I have the
bare minimum mwifiex changes to let it compile, but no additional
checks.
Marvell folks: take note, you'll want to have these checks in your
driver, so need to pass the right check_da/check_sa arguments
(depending on the interface type) to the function. See
https://git.kernel.org/cgit/linux/kernel/git/jberg/mac80211.git/commit/?id=002a02b6d1be6aba55c7391a030c0358fada81c5
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix A-MSDU outer SA/DA
From: Johannes Berg @ 2016-10-12 7:57 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1476258794.5271.12.camel@sipsolutions.net>
On Wed, 2016-10-12 at 09:53 +0200, Johannes Berg wrote:
> On Mon, 2016-10-10 at 18:52 +0200, Michael Braun wrote:
> >
> > According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer
> > SA/DA of A-MSDU frames need to be changed depending on FromDS/ToDS
> > values.
>
> "Need to" is perhaps a bit strongly worded, but whatever :)
>
> I was going to write a long reply and whatever - but I think that's
> all moot. As far as I can tell, you got this completely wrong, as
> you're changing the *inner* headers, not the *outer* header as you
> should?
Oh, no, my mistake - this happens before 802.3->.11 conversion.
So this does look correct, but I don't like that you write to
amsdu_hdr.h_{source,dest} twice after the patch.
I think you should have da and sa variables and set those, and then
memcpy only once.
johannes
^ permalink raw reply
* Re: Revert "rtlwifi: rtl818x: constify local structures"
From: Kalle Valo @ 2016-10-12 8:00 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, linux-wireless, Larry Finger, Stable, Julia Lawall
In-Reply-To: <20161010152520.9812-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> This reverts commit d86e64768859fca82c78e52877ceeba04e25d27a.
>
> For drivers rtl8188ee, rtl8192ce, rtl8192ee, rtl8723ae, and rtl8821ae,
> the Coccinelle script missed the fact that the code changes the firmware
> name. When that happens, the kernel issues a BUG splat because
> it is unable to overwrite the old name.
>
> Although this bug only affects 5 of the 8 drivers it touched, I decided to
> revert the entire patch. Continuing to constantify the other three could
> too easily lead to introduction of future bugs.
>
> Fixes: d86e64768859 ("rtlwifi: rtl818x: constify local structures")
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org>
> Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Dropping as requested.
Patch set to Superseded.
--
https://patchwork.kernel.org/patch/9369621/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: Fix regression caused by commit d86e64768859
From: Kalle Valo @ 2016-10-12 7:53 UTC (permalink / raw)
To: Larry Finger
Cc: devel, linux-wireless, Stable [ 4 . 8+ ], Julia Lawall,
Thorsten Leemhuis
In-Reply-To: <20161010233211.13519-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> In commit d86e64768859 ("rtlwifi: rtl818x: constify local structures"),
> the configuration struct for most of the drivers was changed to be
> constant. The problem is that five of the modified drivers need to be
> able to update the firmware name based on the exact model of the card.
> As the file names were stored in one of the members of that struct,
> these drivers would fail with a kernel BUG splat when they tried to
> update the firmware name.
>
> Rather than reverting the previous commit, I used a suggestion by
> Johannes Berg and made the firmware file name pointers be local to
> the routines that update the software variables.
>
> The configuration struct of rtl8192cu, which was not touched in the
> previous patch, is now constantfied.
>
> Fixes: d86e64768859 ("rtlwifi: rtl818x: constify local structures")
> Suggested-by: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable [4.8+] <stable@vger.kernel.org>
This should be:
Cc: Stable <stable@vger.kernel.org> # 4.8
And the plus sign isn't needed as I'll push this to 4.9.
> Cc: Julia Lawall <Julia.Lawall@lip6.fr>
> ---
> Kalle,
>
> My apologies for letting these bugs to get by my review and testing.
No worries, this is business as usual :) Excellent that you noticed this
so early.
And this again shows that simple cleanup patches are not without cost,
there is a clear risk. Has anyone done any statistics how much cleanup
patches cause regressions? My guess is that in a 5% ballpark of the
cleanup patches have some sort of issues. Of course in this case the
cleanup patch revealed a design flaw in the driver, so in this case it
was very useful.
> As they affect kernel 4.8, please push this patch as soon as possible.
> To reiterate, this patch replaces the one entitled 'Revert "rtlwifi:
> rtl818x: constify local structures"'
Ok, understood. Many thanks for making this super clear for me, makes my
life a lot easier. I'm hoping that this will make it to 4.9-rc2.
CCing Thorsten to get this regression to his radar.
--
Kalle Valo
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Arend Van Spriel @ 2016-10-12 8:11 UTC (permalink / raw)
To: Jörg Krause
Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman,
linux-wireless, Franky Lin, Arend van Spriel
In-Reply-To: <F306F99A-DCEC-4C28-8805-AE0BA50D485F@embedded.rocks>
On 11-10-2016 8:14, Jörg Krause wrote:
>
>
> Hi Arend,
>
> Am 22. September 2016 16:00:36 MESZ, schrieb Arend Van Spriel <arend.vanspriel@broadcom.com>:
>> Op 22 sep. 2016 14:52 schreef "Jörg Krause"
>> <joerg.krause@embedded.rocks>:
>>>
>>> On Do, 2016-09-22 at 10:09 +0200, Arend Van Spriel wrote:
>>>> On 19-9-2016 8:36, Jörg Krause wrote:
>>>>>
>>>>> Hi Arend,
>>>>>
>>>>> On Wed, 2016-09-14 at 20:13 +0200, Arend Van Spriel wrote:
>>>>>>
>>>>>> On 14-9-2016 15:41, Jörg Krause wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Mon, 2016-08-29 at 23:15 +0200, Jörg Krause wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mi, 2016-08-24 at 20:35 +0200, Arend Van Spriel wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 22-8-2016 15:37, Jörg Krause wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I am back from vacation and I'd like to do more
>>>>>>>>>> investigations
>>>>>>>>>> about
>>>>>>>>>> this issue. Please see my comments below...
>>>>>>>>>>
>>>>>>>>>> On Sun, 2016-08-07 at 13:41 +0200, Arend van Spriel
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 06-08-16 16:12, Jörg Krause wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> A bit weird email format making it a bit hard to
>>>>>>>>>>> determine
>>>>>>>>>>> where
>>>>>>>>>>> your
>>>>>>>>>>> last reply starts...
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fr, 2016-08-05 at 17:56 -0700, Franky Lin wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause
>>>>>>>>>>>> <joerg.krause
>>>>>>>>>>>> @emb
>>>>>>>>>>>> ed
>>>>>>>>>>>> ded.
>>>>>>>>>>>> ro
>>>>>>>>>>>> cks>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van
>>>>>>>>>>>> Spriel
>>>>>>>>>>>> <
>>>>>>>>>>>> arend.vanspriel@broadcom.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Op 5 aug. 2016 22:46 schreef "Jörg Krause"
>>>>>>>>>>>> <joerg.krause@embedded.rocks>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm using a custom ARM board with an BCM43362 wifi
>>>>>>>>>>>> chip
>>>>>>>>>>>> from
>>>>>>>>>>>>
>>>>>>>>>>>> Broadcom.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The wifi chip is attached via SDIO to the
>> controller
>>>>>>>>>>>> with
>>>>>>>>>>>> a
>>>>>>>>>>>> clock of
>>>>>>>>>>>> 48MHz. Linux kernel version is 4.7.
>>>>>>>>>>>>
>>>>>>>>>>>> When measuring the network bandwidth with iperf3 I
>>>>>>>>>>>> get a
>>>>>>>>>>>> bandwith of
>>>>>>>>>>>> only around 5 Mbps. I found a similar thread at the
>>>>>>>>>>>> Broadcom
>>>>>>>>>>>>
>>>>>>>>>>>> community
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> [1] where the test was done with a M4 CPU +
>> BCM43362
>>>>>>>>>>>> and
>>>>>>>>>>>> an
>>>>>>>>>>>> average
>>>>>>>>>>>> result of 3.3 Mbps.
>>>>>>>>>>>>
>>>>>>>>>>>> Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a
>>>>>>>>>>>> TCP
>>>>>>>>>>>> data
>>>>>>>>>>>>
>>>>>>>>>>>> throughput
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> greater than 20 Mbps.
>>>>>>>>>>>>
>>>>>>>>>>>> Why is the throughput I measured much lower? Note
>>>>>>>>>>>> that I
>>>>>>>>>>>> measured
>>>>>>>>>>>> several times with almost no neighbor devices or
>>>>>>>>>>>> networks.
>>>>>>>>>>>>
>>>>>>>>>>>> This is a test sample measured with iperf3:
>>>>>>>>>>>>
>>>>>>>>>>>> $ iperf3 -c 192.168.2.1 -i 1 -t 10
>>>>>>>>>>>> Connecting to host 192.168.2.1, port 5201
>>>>>>>>>>>> [ 4] local 192.168.2.155 port 36442 connected
>> to
>>>>>>>>>>>> 192.168.2.1
>>>>>>>>>>>>
>>>>>>>>>>>> port
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 5201
>>>>>>>>>>>> [ ID]
>>>>>>>>>>>> Interval Transfer Bandwidth
>> Retr
>>>>>>>>>>>> Cwn
>>>>>>>>>>>> d
>>>>>>>>>>>> [ 4] 0.00-1.00 sec 615 KBytes 5.04
>>>>>>>>>>>> Mbits/sec 0 56.6
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 1.00-2.00 sec 622 KBytes 5.10
>>>>>>>>>>>> Mbits/sec 0 84.8
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 2.00-3.00 sec 625 KBytes 5.12
>>>>>>>>>>>> Mbits/sec 0 113
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 3.00-4.00 sec 571 KBytes 4.68
>>>>>>>>>>>> Mbits/sec 0 140
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 4.00-5.00 sec 594 KBytes 4.87
>>>>>>>>>>>> Mbits/sec 0 167
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 5.00-6.00 sec 628 KBytes 5.14
>>>>>>>>>>>> Mbits/sec 0 195
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 6.00-7.00 sec 619 KBytes 5.07
>>>>>>>>>>>> Mbits/sec 0 202
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 7.00-8.00 sec 608 KBytes 4.98
>>>>>>>>>>>> Mbits/sec 0 202
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 8.00-9.00 sec 602 KBytes 4.93
>>>>>>>>>>>> Mbits/sec 0 202
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 9.00-10.00 sec 537 KBytes 4.40
>>>>>>>>>>>> Mbits/sec 0 202
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> - - - - - - - - - - - - - - - - - - - - - - - -
>> -
>>>>>>>>>>>> [ ID]
>>>>>>>>>>>> Interval Transfer Bandwidth
>> Retr
>>>>>>>>>>>> [ 4] 0.00-10.00 sec 5.88 MBytes 4.93
>>>>>>>>>>>> Mbits/sec 0 sender
>>>>>>>>>>>> [ 4] 0.00-10.00 sec 5.68 MBytes 4.76
>>>>>>>>>>>> Mbits/sec receiver
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Not overly familiar with iperf3. Do these lines
>> mean
>>>>>>>>>>>> you
>>>>>>>>>>>> are
>>>>>>>>>>>> doing
>>>>>>>>>>>> bidirectional test, ie. upstream and downstream at
>>>>>>>>>>>> the
>>>>>>>>>>>> same
>>>>>>>>>>>> time.
>>>>>>>>>>>> Another
>>>>>>>>>>>> thing affecting tput could be power-save.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, iperf3 does not support bidrectional test.
>> Power-
>>>>>>>>>>>> save
>>>>>>>>>>>> is
>>>>>>>>>>>> turned
>>>>>>>>>>>> off.
>>>>>>>>>>>>
>>>>>>>>>>>> What does iw link say?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> but I guess it starts here!
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I compared the results with a Cubietruck I have:
>>>>>>>>>>>>
>>>>>>>>>>>> # iperf3 -s
>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>> ----
>>>>>>>>>>>> ----
>>>>>>>>>>>> Server listening on 5201
>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>> ----
>>>>>>>>>>>> ----
>>>>>>>>>>>> Accepted connection from 192.168.178.46, port 42906
>>>>>>>>>>>> [ 5] local 192.168.178.38 port 5201 connected to
>>>>>>>>>>>> 192.168.178.46
>>>>>>>>>>>> port
>>>>>>>>>>>> 42908
>>>>>>>>>>>> [ ID] Interval Transfer Bandwidth
>>>>>>>>>>>> [ 5] 0.00-1.00 sec 2.29 MBytes 19.2
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 1.00-2.00 sec 2.21 MBytes 18.5
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 2.00-3.00 sec 2.17 MBytes 18.2
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 3.00-4.00 sec 2.09 MBytes 17.6
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 4.00-5.00 sec 2.20 MBytes 18.5
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 5.00-6.00 sec 2.64 MBytes 22.1
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 6.00-7.00 sec 2.67 MBytes 22.4
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 7.00-8.00 sec 2.62 MBytes 22.0
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 8.00-9.00 sec 2.35 MBytes 19.8
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 9.00-10.00 sec 2.30 MBytes 19.3
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 10.00-10.03 sec 83.4 KBytes 23.5
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> - - - - - - - - - - - - - - - - - - - - - - - - -
>>>>>>>>>>>> [ ID]
>>>>>>>>>>>> Interval Transfer Bandwidth
>> Retr
>>>>>>>>>>>> [ 5] 0.00-10.03 sec 23.9 MBytes 20.0
>>>>>>>>>>>> Mbits/sec 0 sender
>>>>>>>>>>>> [ 5] 0.00-10.03 sec 23.6 MBytes 19.8
>>>>>>>>>>>> Mbits/sec receiver
>>>>>>>>>>>>
>>>>>>>>>>>> # iw dev wlan0 link
>>>>>>>>>>>> Connected to xx:xx:xx:xx:xx (on wlan0)
>>>>>>>>>>>> SSID: xxx
>>>>>>>>>>>> freq: 2437
>>>>>>>>>>>> tx bitrate: 65.0 MBit/s
>>>>>>>>>>>>
>>>>>>>>>>>> bss flags: short-preamble short-slot-
>>>>>>>>>>>> time
>>>>>>>>>>>> dtim period: 1
>>>>>>>>>>>> beacon int: 100
>>>>>>>>>>>
>>>>>>>>>>> Too bad RSSI is not in the output above. That may be
>>>>>>>>>>> due to
>>>>>>>>>>> a
>>>>>>>>>>> regression
>>>>>>>>>>> in our driver which has been fixed by commit
>>>>>>>>>>> 94abd778a7bb
>>>>>>>>>>> ("brcmfmac:
>>>>>>>>>>> add fallback for devices that do not report per-chain
>>>>>>>>>>> values").
>>>>>>>>>>> However,
>>>>>>>>>>> the tx bitrate seems within the same range as the
>> other
>>>>>>>>>>> platform.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The Cubietruck works also with the brcmfmac driver.
>>>>>>>>>>>>
>>>>>>>>>>>> May it depend on the NVRAM file?
>>>>>>>>>>>
>>>>>>>>>>> Not sure. Can you tell me a bit more about the custom
>>>>>>>>>>> ARM
>>>>>>>>>>> board.
>>>>>>>>>>> Does
>>>>>>>>>>> it
>>>>>>>>>>> use the same wifi module as Cubietruck, ie. the AMPAK
>>>>>>>>>>> AP6210?
>>>>>>>>>>> If
>>>>>>>>>>> you
>>>>>>>>>>> can
>>>>>>>>>>> make a wireshark sniff we can check the actual
>> bitrate
>>>>>>>>>>> and
>>>>>>>>>>> medium
>>>>>>>>>>> density in terms of packets. Another thing to look at
>>>>>>>>>>> is
>>>>>>>>>>> the
>>>>>>>>>>> SDIO
>>>>>>>>>>> host
>>>>>>>>>>> controller. In brcmf_sdiod_sgtable_alloc() some key
>>>>>>>>>>> values
>>>>>>>>>>> are
>>>>>>>>>>> used
>>>>>>>>>>> from
>>>>>>>>>>> the host controller. It only logs the number of
>> entries
>>>>>>>>>>> of
>>>>>>>>>>> the
>>>>>>>>>>> scatter-gather table, but could you add the other
>>>>>>>>>>> values in
>>>>>>>>>>> this
>>>>>>>>>>> function that are used to determine the number of
>>>>>>>>>>> entries.
>>>>>>>>>>
>>>>>>>>>> My board uses the BCM43362 chip solely (no Bluetooth)
>>>>>>>>>> attached to
>>>>>>>>>> the
>>>>>>>>>> SDIO interface of a NXP i.MX28 processor.
>>>>>>>>>>
>>>>>>>>>> I added some additional printk() to
>>>>>>>>>> brcmf_sdiod_sgtable_alloc().
>>>>>>>>>> These
>>>>>>>>>> are the values printed after modprobe brcmfmac:
>>>>>>>>>>
>>>>>>>>>> [ 8.926657] sg_support=1
>>>>>>>>>> [ 8.929440] max_blocks=511
>>>>>>>>>> [ 8.932213] max_request_size=261632
>>>>>>>>>> [ 8.935741] max_segment_count=52
>>>>>>>>>> [ 8.939005] max_segment_size=65280
>>>>>>>>>> [ 8.946095] nents=35
>>>>>>>>>
>>>>>>>>> Thanks. That looks good.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Additionally I attached a xz compresses wireshark sniff
>>>>>>>>>> while
>>>>>>>>>> running
>>>>>>>>>> iper3 between the BCM43362 running as in AP mode with
>>>>>>>>>> iperf3
>>>>>>>>>> as a
>>>>>>>>>> server and a PC in station mode running iperf3 as a
>>>>>>>>>> client.
>>>>>>>>>
>>>>>>>>> Looking at the sniff it seems you captured on the
>> ethernet
>>>>>>>>> side.
>>>>>>>>> That
>>>>>>>>> does not give me any 802.11 specific info. Can you make a
>>>>>>>>> wireless
>>>>>>>>> capture preferably without encryption.
>>>>>>>>
>>>>>>>> You,re right! Sorry for this mistake. I did a re-capture on
>>>>>>>> the
>>>>>>>> wireless side now.
>>>>>>>
>>>>>>> Anything new about this? Anything I can do to help?
>>>>>>
>>>>>> I missed your previous email. Was already wondering whether to
>>>>>> ping
>>>>>> you.
>>>>>> Digging around in my email folders I found it so will take a
>> look
>>>>>> at
>>>>>> it.
>>>>>
>>>>> Did you had some time to look at this?
>>>>
>>>> Ehm. I still only see TCP stuff. To capture 802.11 management
>> frames
>>>> you
>>>> need preferably a dedicated device using monitor mode [1].
>>>
>>> Stupid me! Now I used a monitor interface on a desktop to monitor the
>>> traffic between the BCM43362 operating in soft-AP mode and a notebook
>>> operating in managed mode.
>>>
>>> The BCM43362 runs the iperf server, the notebook the iperf client.
>>
>> Thanks.
>>
>> Week almost through so might next week.
>
> Did you had some time to look at this?
So the bcm43362 is your AP and running iperf server. What specs does the
ARM on your custom board have? The trace shows that it does not do
aggregation. What it does not show is whether A-MPDU was setup, ie.
ADDBA message exchange. So could you create a similar capture including
connection setup, ie. AUTH/ASSOC, etc.
Just to confirm. You are using the firmware from linux-firmware, right?
Or are you using firmware from the wiced dev kit?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] mac80211: fix A-MSDU outer SA/DA
From: Johannes Berg @ 2016-10-12 7:53 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1476118360-29009-1-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-10 at 18:52 +0200, Michael Braun wrote:
> According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer
> SA/DA of A-MSDU frames need to be changed depending on FromDS/ToDS
> values.
"Need to" is perhaps a bit strongly worded, but whatever :)
I was going to write a long reply and whatever - but I think that's all
moot. As far as I can tell, you got this completely wrong, as you're
changing the *inner* headers, not the *outer* header as you should?
johannes
^ permalink raw reply
* [bug report] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue
From: Dan Carpenter @ 2016-10-12 6:14 UTC (permalink / raw)
To: toke; +Cc: linux-wireless
Hello Toke Høiland-Jørgensen,
This is a semi-automatic email about new static checker warnings.
The patch bb42f2d13ffc: "mac80211: Move reorder-sensitive TX handlers
to after TXQ dequeue" from Sep 22, 2016, leads to the following
Smatch complaint:
net/mac80211/tx.c:3242 ieee80211_xmit_fast_finish()
error: we previously assumed 'key' could be null (see line 3209)
net/mac80211/tx.c
3208
3209 if (key)
^^^
Check.
3210 info->control.hw_key = &key->conf;
3211
3212 ieee80211_tx_stats(skb->dev, skb->len);
3213
3214 if (hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_QOS_DATA)) {
3215 tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
3216 *ieee80211_get_qos_ctl(hdr) = tid;
3217 hdr->seq_ctrl = ieee80211_tx_next_seq(sta, tid);
3218 } else {
3219 info->flags |= IEEE80211_TX_CTL_ASSIGN_SEQ;
3220 hdr->seq_ctrl = cpu_to_le16(sdata->sequence_number);
3221 sdata->sequence_number += 0x10;
3222 }
3223
3224 if (skb_shinfo(skb)->gso_size)
3225 sta->tx_stats.msdu[tid] +=
3226 DIV_ROUND_UP(skb->len, skb_shinfo(skb)->gso_size);
3227 else
3228 sta->tx_stats.msdu[tid]++;
3229
3230 info->hw_queue = sdata->vif.hw_queue[skb_get_queue_mapping(skb)];
3231
3232 /* statistics normally done by ieee80211_tx_h_stats (but that
3233 * has to consider fragmentation, so is more complex)
3234 */
3235 sta->tx_stats.bytes[skb_get_queue_mapping(skb)] += skb->len;
3236 sta->tx_stats.packets[skb_get_queue_mapping(skb)]++;
3237
3238 if (pn_offs) {
^^^^^^^
Maybe when pn_offs is non-zero that implies key is non-NULL?
3239 u64 pn;
3240 u8 *crypto_hdr = skb->data + pn_offs;
3241
3242 switch (key->conf.cipher) {
^^^^^
Unchecked dereference.
3243 case WLAN_CIPHER_SUITE_CCMP:
3244 case WLAN_CIPHER_SUITE_CCMP_256:
regards,
dan carpenter
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-12 9:05 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andy Lutomirski, David S. Miller, linux-wireless, netdev,
linux-kernel, Sergey Senozhatsky, linux-next, Stephen Rothwell,
Herbert Xu
In-Reply-To: <20161010153050.GA836@swordfish>
Hi,
Sorry - I meant to look into this yesterday but forgot.
> Andy, can this be related to CONFIG_VMAP_STACK?
I think it is.
> > current -git kills my system.
Can you elaborate on how exactly it kills your system?
> > adding
> >
> > if (!virt_addr_valid(&aad[2])) {
> > WARN_ON(1);
> > return -EINVAL;
> > }
That's pretty obviously false with VMAP_STACK, since the caller
(ieee80211_crypto_ccmp_decrypt) puts the aad on the stack. b_0 is also
on the stack, but maybe that doesn't matter.
Herbert, do you know what could cause this, and how we should fix it?
We can't really afford to do an allocation here, and we don't have
space in the skb (not even in skb->cb at that point), so if we really
have no way to continue using the stack we'd ... not sure, use a per-
CPU buffer perhaps.
We need 32 bytes for aad and 16 bytes for b_0, if that also can't be on
the stack any more.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: enable to inject a-msdu frames using monitor interface
From: Johannes Berg @ 2016-10-12 7:33 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1476118105-7641-1-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-10 at 18:48 +0200, Michael Braun wrote:
> Problem: When injecting an A-MSDU using a PF_PACKET socket, the qos
> flag
> IEEE80211_QOS_CTL_A_MSDU_PRESENT is cleared.
>
> How to reproduce: Inject a frame on a mac80211 hwsim monitor
> interface and
> have tshark sniffing on this monitor interface.
> You'll see the packet twice: Once with correct flag and once with
> flag
> cleared. On hwsim0, you'll only see the packet with a cleared flag.
>
> Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
> ---
> net/mac80211/wme.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
> index 9eb0aee..f6a708c 100644
> --- a/net/mac80211/wme.c
> +++ b/net/mac80211/wme.c
> @@ -248,6 +248,11 @@ void ieee80211_set_qos_hdr(struct
> ieee80211_sub_if_data *sdata,
> /* preserve EOSP bit */
> ack_policy = *p & IEEE80211_QOS_CTL_EOSP;
>
> + /* preserve A-MSDU bit for MONITOR interfaces to allow
> injecting
> + * A-MSDU frames
> + */
> + ack_policy |= *p & IEEE80211_QOS_CTL_A_MSDU_PRESENT;
Conceptually this seems OK, though I'd probably make some adjustments
to the commit log.
However, re-reading *p looks strange to me. Why don't we just refactor
this to preserve everything but the TID and ACK policy, after all, we
have just previous created this all zeroed in most cases, so it won't
really matter.
Like this:
diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
index f6a708c67219..3e3d3014e9ab 100644
--- a/net/mac80211/wme.c
+++ b/net/mac80211/wme.c
@@ -236,31 +236,35 @@ void ieee80211_set_qos_hdr(struct ieee80211_sub_if_data *sdata,
{
struct ieee80211_hdr *hdr = (void *)skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ u8 tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
+ u8 flags;
u8 *p;
- u8 ack_policy, tid;
if (!ieee80211_is_data_qos(hdr->frame_control))
return;
p = ieee80211_get_qos_ctl(hdr);
- tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
- /* preserve EOSP bit */
- ack_policy = *p & IEEE80211_QOS_CTL_EOSP;
+ /* set up the first byte */
- /* preserve A-MSDU bit for MONITOR interfaces to allow injecting
- * A-MSDU frames
+ /*
+ * preserve everything but the TID and ACK policy
+ * (which we both write here)
*/
- ack_policy |= *p & IEEE80211_QOS_CTL_A_MSDU_PRESENT;
+ flags = *p & ~(IEEE80211_QOS_CTL_TID_MASK |
+ IEEE80211_QOS_CTL_ACK_POLICY_MASK);
if (is_multicast_ether_addr(hdr->addr1) ||
sdata->noack_map & BIT(tid)) {
- ack_policy |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
+ flags |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
info->flags |= IEEE80211_TX_CTL_NO_ACK;
}
- /* qos header is 2 bytes */
- *p++ = ack_policy | tid;
+ *p = flags | tid;
+
+ /* set up the second byte */
+ p++;
+
if (ieee80211_vif_is_mesh(&sdata->vif)) {
/* preserve RSPI and Mesh PS Level bit */
*p &= ((IEEE80211_QOS_CTL_RSPI |
johannes
^ permalink raw reply related
* Re: [PATCH] cfg80211: Create structure for combination check/iter function parameters
From: Johannes Berg @ 2016-10-12 8:55 UTC (permalink / raw)
To: Purushottam Kushwaha; +Cc: linux-wireless, jouni, usdutt, amarnath
In-Reply-To: <1476101219-29599-1-git-send-email-pkushwah@qti.qualcomm.com>
On Mon, 2016-10-10 at 17:36 +0530, Purushottam Kushwaha wrote:
> Move growing parameter list to a structure for check/iter combination
> functions in cfg80211 and mac80211.
Looking at this, and how it changes brcmfmac, I'd prefer you did this
as the first patch in the series so we only have to touch that once.
Also, for the conversions, consider C99 initializers instead of the
memset() and setting values.
Then perhaps we can also consider squashing the first and third patch,
but let's keep them separate for now.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: enable to inject a-msdu frames using monitor interface
From: michael-dev @ 2016-10-12 11:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1476257614.5271.8.camel@sipsolutions.net>
Am 12.10.2016 09:33, schrieb Johannes Berg:
> However, re-reading *p looks strange to me. Why don't we just refactor
> this to preserve everything but the TID and ACK policy, after all, we
> have just previous created this all zeroed in most cases, so it won't
> really matter.
Looks good to me.
I've re-run the amsdu spoofing hwsim test as it includes an amsdu
injection test and as expected it still works.
Regards,
M. Braun
^ permalink raw reply
* [PATCH v2] mac80211: fix A-MSDU outer SA/DA
From: Michael Braun @ 2016-10-12 10:57 UTC (permalink / raw)
To: johannes; +Cc: Michael Braun, linux-wireless, projekt-wlan
According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer SA/DA
of A-MSDU frames need to be changed depending on FromDS/ToDS values.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
--
v2:
- avoid the extra write to amsdu_hdr
- avoid copy of asmdu_hdr into skb, use ptr instead
---
net/mac80211/tx.c | 45 ++++++++++++++++++++++++++++++++++++---------
1 file changed, 36 insertions(+), 9 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5023966..ebd2aa6 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3046,11 +3046,12 @@ static bool ieee80211_amsdu_prepare_head(struct ieee80211_sub_if_data *sdata,
struct ieee80211_local *local = sdata->local;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr;
- struct ethhdr amsdu_hdr;
+ struct ethhdr *amsdu_hdr;
int hdr_len = fast_tx->hdr_len - sizeof(rfc1042_header);
int subframe_len = skb->len - hdr_len;
void *data;
u8 *qc;
+ const u8 *src_addr, *dst_addr, *bssid;
if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE)
return false;
@@ -3058,19 +3059,45 @@ static bool ieee80211_amsdu_prepare_head(struct ieee80211_sub_if_data *sdata,
if (info->control.flags & IEEE80211_TX_CTRL_AMSDU)
return true;
- if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(amsdu_hdr),
+ if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(*amsdu_hdr),
&subframe_len))
return false;
- amsdu_hdr.h_proto = cpu_to_be16(subframe_len);
- memcpy(amsdu_hdr.h_source, skb->data + fast_tx->sa_offs, ETH_ALEN);
- memcpy(amsdu_hdr.h_dest, skb->data + fast_tx->da_offs, ETH_ALEN);
+ data = skb_push(skb, sizeof(*amsdu_hdr));
+ memmove(data, data + sizeof(*amsdu_hdr), hdr_len);
+ hdr = data;
+ amsdu_hdr = data + hdr_len;
+
+ /* according to IEEE 802.11-2012 8.3.2 table 8-19, the outer SA/DA
+ * fields needs to be changed to BSSID for A-MSDU frames depending
+ * on FromDS/ToDS values.
+ */
+ switch (sdata->vif.type) {
+ case NL80211_IFTYPE_STATION:
+ bssid = sdata->u.mgd.bssid;
+ break;
+ case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_AP_VLAN:
+ bssid = sdata->vif.addr;
+ break;
+ default:
+ bssid = NULL;
+ }
+
+ if (bssid && ieee80211_has_fromds(hdr->frame_control))
+ src_addr = bssid;
+ else
+ src_addr = skb->data + fast_tx->sa_offs;
+
+ if (bssid && ieee80211_has_tods(hdr->frame_control))
+ dst_addr = bssid;
+ else
+ dst_addr = skb->data + fast_tx->da_offs;
- data = skb_push(skb, sizeof(amsdu_hdr));
- memmove(data, data + sizeof(amsdu_hdr), hdr_len);
- memcpy(data + hdr_len, &amsdu_hdr, sizeof(amsdu_hdr));
+ amsdu_hdr->h_proto = cpu_to_be16(subframe_len);
+ memcpy(amsdu_hdr->h_source, src_addr, ETH_ALEN);
+ memcpy(amsdu_hdr->h_dest, dst_addr, ETH_ALEN);
- hdr = data;
qc = ieee80211_get_qos_ctl(hdr);
*qc |= IEEE80211_QOS_CTL_A_MSDU_PRESENT;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v6 2/4] mac80211: filter multicast data packets on AP / AP_VLAN
From: Johannes Berg @ 2016-10-12 12:16 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan, netdev
In-Reply-To: <1476119543-24509-2-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-10 at 19:12 +0200, Michael Braun wrote:
> This patch adds filtering for multicast data packets on AP_VLAN
> interfaces
>
[...]
Applied patches 1 and 2 for now, I'll look at the others again later.
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox