* [PATCH] mac80211_hwsim: fix command documentation indentation
From: Johannes Berg @ 2017-03-02 8:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/mac80211_hwsim.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.h b/drivers/net/wireless/mac80211_hwsim.h
index 39f22467ca2a..3f5eda591dba 100644
--- a/drivers/net/wireless/mac80211_hwsim.h
+++ b/drivers/net/wireless/mac80211_hwsim.h
@@ -57,12 +57,12 @@ enum hwsim_tx_control_flags {
* @HWSIM_CMD_REGISTER: request to register and received all broadcasted
* frames by any mac80211_hwsim radio device.
* @HWSIM_CMD_FRAME: send/receive a broadcasted frame from/to kernel/user
- * space, uses:
+ * space, uses:
* %HWSIM_ATTR_ADDR_TRANSMITTER, %HWSIM_ATTR_ADDR_RECEIVER,
* %HWSIM_ATTR_FRAME, %HWSIM_ATTR_FLAGS, %HWSIM_ATTR_RX_RATE,
* %HWSIM_ATTR_SIGNAL, %HWSIM_ATTR_COOKIE, %HWSIM_ATTR_FREQ (optional)
* @HWSIM_CMD_TX_INFO_FRAME: Transmission info report from user space to
- * kernel, uses:
+ * kernel, uses:
* %HWSIM_ATTR_ADDR_TRANSMITTER, %HWSIM_ATTR_FLAGS,
* %HWSIM_ATTR_TX_INFO, %HWSIM_ATTR_SIGNAL, %HWSIM_ATTR_COOKIE
* @HWSIM_CMD_NEW_RADIO: create a new radio with the given parameters,
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.
From: Johannes Berg @ 2017-03-02 8:36 UTC (permalink / raw)
To: agreen, linux-wireless; +Cc: Jesse Jones
In-Reply-To: <58B487A8.7000602@cococorp.com>
Hi Alexis,
> This is loosely based on RFC5148, specifically event-triggered
> message generation as described in section 5.2.
I'm confused. I see how that generally seems to apply to any mobile
network, but it *does* state up-front that
In some instances, these problems can be solved in these lower
layers, but in other instances, some help at the network and higher
layers is necessary.
I believe 802.11 *does* in fact solve these issues at lower layers.
Can you explain how you observed any problem in this area?
> The frames are not duplicated, but, hopefully offset enough so they
> don't collide at the receiver
That wasn't my question - my question regarding duplicating was if this
was intended to *suppress* duplicates, but it sounds like not.
> (and, since, these are management frames, there is no retransmission
> and we may lose the information contained in them).
That statement isn't true in general, though it does seem that some of
the frames you're touching are actually *multicast* frames and as such
don't have any retries.
> If the two (or more) devices that reply are synchronized well enough,
> carrier sense will tell them that air is clear and messages will go
> out at the same time. It doesn't happen too often, but we found it
> noticeable enough in our testing.
I'm still curious how it happens at all, since NAV synchronisation
should prevent it at a much lower level?
johannes
^ permalink raw reply
* Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO
From: Johannes Berg @ 2017-03-02 8:23 UTC (permalink / raw)
To: Benjamin Beichler, Ben Greear, Andrew Zaborowski; +Cc: linux-wireless
In-Reply-To: <60000eb2-f404-aab7-5493-9b952adb1dde@uni-rostock.de>
On Wed, 2017-03-01 at 18:04 +0100, Benjamin Beichler wrote:
> Am 01.03.2017 um 16:35 schrieb Ben Greear:
> > That is actually not possible. The permanent MAC-Addresses of hwsim
> >
> > > radios are directly created by there internal ID, which is only
> > > increased for new radios and definitely not reassigned.
> > >
> > > But I would be happy, if this were possible, since it would make
> > > some
> > > simulation related stuff easier (currently we need to unload and
> > > load
> > > the hwsim module over and over again for every run).
> >
> > Ahh, you are right. But you can specify the wiphy name, and then
> > you
> > can use that to query the debugfs to find the MAC addr, and then
> > sync
> > your user-space with that info.
> >
> > It should also be easy enough to specify the MAC address when
> > creating
> > the radio.
> >
> > And, you should be able to create virtual STA, AP, etc, with any
> > specified
> > MAC address, so the MAC of the radio really should not matter much?
> >
>
> That is another problem ... this won't work currently, since the
> frame
> delivery compares the receiver address with the permanent MAC
> addresses
> of all hwsim phys. I work as an idle task on patch, which makes this
> lookup (currently implemented as linear search) as a hashmap mapping
> an
> MAC to a wiphy struct , including scenarios with differing MAC
> addresses
> of vifs.
That's probably something we really ought to fix :)
johannes
^ permalink raw reply
* Re: [v4] ath10k: search SMBIOS for OEM board file extension
From: Kalle Valo @ 2017-03-02 8:53 UTC (permalink / raw)
To: Waldemar Rymarkiewicz; +Cc: linux-wireless, kvalo, jouni, Waldemar Rymarkiewicz
In-Reply-To: <20170224223003.32156-1-ext.waldemar.rymarkiewicz@tieto.com>
Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com> wrote:
> Board Data File (BDF) is loaded upon driver boot-up procedure. The right
> board data file is identified, among others, by device and sybsystem ids.
>
> The problem, however, can occur when the (default) board data file cannot
> fulfill with the vendor requirements and it is necessary to use a different
> board data file.
>
> To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name
> Extension to specify the extension/variant name. The driver will take the
> extension suffix into consideration and will load the right (non-default)
> board data file if necessary.
>
> If it is unnecessary to use extension board data file, please leave the
> SMBIOS field blank and default configuration will be used.
>
> Example:
> If a default board data file for a specific board is identified by a string
> "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
> subsystem-device=0310"
> then the OEM specific data file, if used, could be identified by variant
> suffix:
> "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
> subsystem-device=0310,variant=DE_1AB"
>
> If board data file name extension is set but board-2.bin does not contain
> board data file for the variant, the driver will fallback to the default
> board data file not to break backward compatibility.
>
> This was first applied in commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM
> board file extension") but later reverted in commit 005c3490e9db ("Revert
> "ath10k: Search SMBIOS for OEM board file extension"") due to a regression.
> This patch is now otherwise the same as commit f2593cb1b291 except the
> regression fixed.
>
> Signed-off-by: Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com>
Patch applied to wireless-drivers.git, thanks.
1657b8f84ed9 ath10k: search SMBIOS for OEM board file extension
--
https://patchwork.kernel.org/patch/9591335/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC v2 2/2] cfg80211: support 4-way handshake offloading for 802.1X
From: Johannes Berg @ 2017-03-02 8:59 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless; +Cc: Avraham Stern
In-Reply-To: <177c53b2-cd5f-97a9-26b0-b590071785cb@broadcom.com>
> > + int (*del_pmk)(struct wiphy *wiphy, struct
> > net_device *dev,
> > + const u8 *aa);
>
> Minor nit, but prefer clr_pmk to clear the pmk.
Why? You don't have "the PMK" that you can clear, you have "a PMK" (for
the network) and after deleting it you don't have it anymore. You don't
have a "cleared PMK" afterwards, you just don't have any. I think the
delete makes more sense?
> > + * @NL80211_CMD_DEL_PMK: For offloaded 4-Way handshake, delete the
> > previously
> > + * configured PMK for the authenticator address identified
> > by
> > + * &NL80211_ATTR_MAC.
>
> Maybe better to indicate it is for 802.1X.
I guess that makes sense.
> > + NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_1X,
>
> So do we need this flag. Is the fact that the driver implements the
> set_pmk and del_pmk (or clr_pmk) callbacks not sufficient provided
> they are listed in the "supported commands" message of wiphy dump
> (not in this patch). Which reminds me, is "supported commands" no
> longer preferred because that list does not seem complete?
It's complicated... We've kinda naturally gravitated towards extended
feature flags because they're so easy to handle now (only need to
define the bit) - and with mac80211 in the picture, relying on the
handlers only often didn't work, so it requires extra code in the CMD()
advertising - and anyway it already requires extra code there unlike
the feature flags...
So overall - while this isn't stated policy (yet?) - I think we prefer
the feature bits.
johannes
^ permalink raw reply
* Re: [PATCHv2 3/4] cfg80211: Add Support set btcoex priority value
From: Johannes Berg @ 2017-03-02 8:50 UTC (permalink / raw)
To: c_traja, linux-wireless; +Cc: ath10k
In-Reply-To: <1488029873-14600-4-git-send-email-c_traja@qti.qualcomm.com>
Is there much point in having 4 rather than just 2 patches?
> + int (*set_btcoex)(struct wiphy *wiphy, bool enabled,
> + int btcoex_priority);
Shouldn't that be u32 as a bitmap?
> + bool btcoex_priority_support;
Why not use an extended nl80211 feature flag directly?
> + * @NL80211_ATTR_BTCOEX_PRIORITY: This is for the driver which
> + * support btcoex priority feature. It used with
> %NL80211_CMD_SET_BTCOEX.
> + * This will have u32 BITMAP value which represents
> + * frame(bk, be, vi, vo, mgmt, beacon) type and that will have
> more
> + * priority than a BT traffic.
I think you need to define the bits somewhere in an enum - i.e. which
one is VO, VI, ...
> + int btcoex_priority = -1;
That -1 is pretty useless, if the driver doesn't support it, hopefully
it won't look at the value at all?
johannes
^ permalink raw reply
* Re: [PATCHv2 3/4] cfg80211: Add Support set btcoex priority value
From: Johannes Berg @ 2017-03-02 8:51 UTC (permalink / raw)
To: c_traja, linux-wireless; +Cc: ath10k
In-Reply-To: <1488029873-14600-4-git-send-email-c_traja@qti.qualcomm.com>
This patch will also (and correctly so) cause compilation warnings in
mac80211, so you really should have just two patches.
johannes
^ permalink raw reply
* Re: [PATCHv2 1/4] cfg80211: Add support to enable or disable btcoex
From: Johannes Berg @ 2017-03-02 8:45 UTC (permalink / raw)
To: c_traja, linux-wireless; +Cc: ath10k
In-Reply-To: <1488029873-14600-2-git-send-email-c_traja@qti.qualcomm.com>
You need to fix the build-bot warning, it's legitimate (though hard to
spot):
> + TP_printk(WIPHY_PR_FMT, ", enabled=%d",
> + WIPHY_PR_ARG, __entry->enabled)
> +);
You have a stray comma there after WIPHY_PR_FMT.
johannes
^ permalink raw reply
* Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.
From: Johannes Berg @ 2017-03-02 8:39 UTC (permalink / raw)
To: Ben Greear, linux-wireless
In-Reply-To: <18699231-6ea2-5209-a384-d8f2c2adcdb9@candelatech.com>
> Looks like there are two conventions used (see
> HWSIM_CMD_TX_INFO_FRAME, and HWSIM_CMD_NEW_RADIO). I guess you want
> it indented like the NEW_RADIO command?
Huh, sorry - yes, indented like NEW_RADIO please, I'll fix the others.
johannes
^ permalink raw reply
* Re: WARNING: CPU: 1 PID: 23668 at drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1539 iwl_mvm_rm_sta+0x3ce/0x450
From: Jens Axboe @ 2017-03-02 4:10 UTC (permalink / raw)
To: Luca Coelho; +Cc: luciano.coelho, sara.sharon, liad.kaufman, linux-wireless
In-Reply-To: <f2bedfee-e74f-47d6-9088-94171f0e5538@email.android.com>
On 03/01/2017 08:33 PM, Luca Coelho wrote:
> Hi Jens,
>
> On Mar 1, 2017 20:25, Jens Axboe <axboe@kernel.dk> wrote:
>
> Not that folks have been jumping all over this, but in case someone is
> curious, it triggered twice here today. For those two times, the value
> of mvm->pending_frames[sta_id] was 80 and 39, respectively.
>
> Sorry for the delay, I'm on vacation now with limited internet access.
> But we'll take a look into this early next week at the latest.
>
> Thanks a lot for the detailed report!
No worries, thanks for responding. I just wanted to ensure this wasn't
dropped on the floor.
BTW, a few more values of ->pending_frames[sta_id]:
$ dmesg | grep "ret="
[ 2334.308254] ret=39
[ 7915.311828] ret=80
[31602.317204] ret=41
[32139.510993] ret=54
[33292.917759] ret=96
it seems to often happen around resume.
--
Jens Axboe
^ permalink raw reply
* Re: pull-request: mac80211 2017-02-28
From: David Miller @ 2017-03-01 23:09 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20170228095019.10637-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 28 Feb 2017 10:50:18 +0100
> First round of fixes - we actually have quite a few.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
> I had another question - I have this average.h API change pending
> (you saw it before). It seems it might be a good time to get it in
> now, since no new users should be showing up. If I put it in only
> with the next merge window, new users might show up and break.
Ok, you can feel free to send this now for 'net' if you like.
^ permalink raw reply
* Re: [PATCH v2] mac80211: mesh - always do every discovery retry
From: Chun-Yeow Yeoh @ 2017-03-02 1:28 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, Alexis Green, Alexis Green
> Instead of stopping path discovery when a path is found continue
> attempting to find paths until we hit the dot11MeshHWMPmaxPREQretries
> limit.
I am not too sure whether by simply broadcasting the PREQ frame could
actually solve the problem and this may cause problem of PREQ flooding
in your network when the number of nodes scale. Please take note that
all nodes need to rebroadcast the PREQ frame until target STA. Path
discovery should stop once the path is established. By attempting 2nd,
3rd or 4th doesn't guarantee the next path will be "good".
> This is important because path messages are not reliable and it is
> relatively common to have a short bad path to the destination along with a
> longer but better path. With the original code rather often a path message
> along the long path would be lost so we would stick with the bad path.
> With this change we have a greater chance to get messages over the longer
> path allowing us to select the long path if it's better.
Reduce the mesh_hwmp_active_path_timeout or mesh_path_refresh_time to
reestablish your path link as soon as possible. Also, if you would
like to have such aggressive behavior, you can reduce the
mesh_hwmp_preq_min_interval to have more aggressive PREQ sending in
your network.
----
Chun-Yeow
^ permalink raw reply
* Re: WARNING: CPU: 1 PID: 23668 at drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1539 iwl_mvm_rm_sta+0x3ce/0x450
From: Jens Axboe @ 2017-03-01 23:25 UTC (permalink / raw)
To: sara.sharon; +Cc: linux-wireless, luciano.coelho, liad.kaufman
In-Reply-To: <9c4d1814-d6f2-e9c2-0b66-bbfadc002b15@kernel.dk>
On 02/28/2017 01:41 PM, Jens Axboe wrote:
> On 02/28/2017 11:02 AM, Jens Axboe wrote:
>> Hi,
>>
>> I'm hitting this one a lot with current -git, which is this one:
>>
>> if (iwl_mvm_is_dqa_supported(mvm)) {
>> iwl_mvm_disable_sta_queues(mvm, vif, mvm_sta);
>> /*
>> * If pending_frames is set at this point - it must be
>> * driver internal logic error, since queues are empty
>> * and removed successuly.
>> * warn on it but set it to 0 anyway to avoid station
>> * not being removed later in the function
>> */
>> WARN_ON(atomic_xchg(&mvm->pending_frames[sta_id], 0));
>> }
>>
>> It's hit 4 times over the last day. The bug is probably older than the
>> commit that added this warning:
>>
>> commit 94c3e614df2117626fccfac8f821c66e30556384
>> Author: Sara Sharon <sara.sharon@intel.com>
>> Date: Wed Dec 7 15:04:37 2016 +0200
>>
>> iwlwifi: mvm: fix pending frame counter calculation
>>
>> but the pestering is new.
>
> Forgot to include the traces, find them below.
Not that folks have been jumping all over this, but in case someone is
curious, it triggered twice here today. For those two times, the value
of mvm->pending_frames[sta_id] was 80 and 39, respectively.
--
Jens Axboe
^ permalink raw reply
* [mwifiex] seemingly random crashes on 8897
From: Martin Pietryka @ 2017-03-01 19:15 UTC (permalink / raw)
To: linux-wireless, akarwar
Hi all,
we are running a 4.1 kernel and we have some instabilities using the
8897 over PCIe on an imx7 cpu.
We have observed crashes which look like the logs at the end. I'm not
sure if they are all somehow related.
As already mentioned we are using the 4.1 kernel from NXP with some
patches for the mwifiex driver backported from a more recent kernel,
these additional patches are the following:
* mwifiex: enable MSI interrupt support in pcie
* mwifiex: using right tid for addressing ra_list
* mwifiex: do not short circuit exit from mwifiex_set_mgmt_ies
I know that in the a more recent drivers there were some changes to the
interrupt handling, etc. So maybe there is an issue here. Especially
with MSI enabled.
Anybody got an idea?
Best regards,
Martin
Sometimes we see lots of these messages, WiFi continues to work:
[ 4108.037449] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4108.398976] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
[ 4119.549181] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4119.899053] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
[ 4193.769062] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4194.141753] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
[ 4413.821362] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4414.491489] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
[ 4490.359042] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4490.705755] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
[ 4587.521240] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4587.877673] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
[ 4601.168747] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4601.680754] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
One of the crashes
[ 123.004165] mwifiex_pcie 0000:01:00.0: mwifiex_cmd_timeout_func:
Timeout cmd id = 0x10, act = 0x1
[ 123.013072] mwifiex_pcie 0000:01:00.0: num_data_h2c_failure = 0
[ 123.019026] mwifiex_pcie 0000:01:00.0: num_cmd_h2c_failure = 0
[ 123.024886] mwifiex_pcie 0000:01:00.0: is_cmd_timedout = 1
[ 123.030378] mwifiex_pcie 0000:01:00.0: num_tx_timeout = 0
[ 123.035798] mwifiex_pcie 0000:01:00.0: last_cmd_index = 0
[ 123.041205] mwifiex_pcie 0000:01:00.0: last_cmd_id: 10 00 07 01 07 01
07 01 cf 00
[ 123.048709] mwifiex_pcie 0000:01:00.0: last_cmd_act: 01 00 00 00 00
00 00 00 00 34
[ 123.056301] mwifiex_pcie 0000:01:00.0: last_cmd_resp_index = 4
[ 123.062142] mwifiex_pcie 0000:01:00.0: last_cmd_resp_id: 07 81 07 81
07 01 07 01 07 81
[ 123.070078] mwifiex_pcie 0000:01:00.0: last_event_index = 1
[ 123.075672] mwifiex_pcie 0000:01:00.0: last_event: 33 00 0a 00 33 00
33 00 33 00
[ 123.083075] mwifiex_pcie 0000:01:00.0: data_sent=0 cmd_sent=1
[ 123.088841] mwifiex_pcie 0000:01:00.0: ps_mode=1 ps_state=0
[ 123.094470] mwifiex_pcie 0000:01:00.0: == mwifiex firmware dump start ==
[ 123.102229] mwifiex_pcie 0000:01:00.0: ITCM_SIZE=0x10000
[ 123.107778] mwifiex_pcie 0000:01:00.0: Start ITCM output, please wait...
[ 125.579854] mwifiex_pcie 0000:01:00.0: ITCM done: size=0x10000
[ 125.586025] mwifiex_pcie 0000:01:00.0: DTCM_SIZE=0x8000
[ 125.591300] mwifiex_pcie 0000:01:00.0: Start DTCM output, please wait...
[ 126.842731] mwifiex_pcie 0000:01:00.0: DTCM done: size=0x8000
[ 126.848813] mwifiex_pcie 0000:01:00.0: SQRAM_SIZE=0xa0000
[ 126.854653] mwifiex_pcie 0000:01:00.0: Start SQRAM output, please wait...
[ 151.729030] mwifiex_pcie 0000:01:00.0: SQRAM done: size=0xa0000
[ 151.735299] mwifiex_pcie 0000:01:00.0: IRAM_SIZE=0x58000
[ 151.740729] mwifiex_pcie 0000:01:00.0: Start IRAM output, please wait...
[ 165.469182] mwifiex_pcie 0000:01:00.0: IRAM done: size=0x58000
[ 165.475357] mwifiex_pcie 0000:01:00.0: APU_SIZE=0x350
[ 165.480449] mwifiex_pcie 0000:01:00.0: Start APU output, please wait...
[ 165.519799] mwifiex_pcie 0000:01:00.0: APU done: size=0x350
[ 165.525712] mwifiex_pcie 0000:01:00.0: CIU_SIZE=0x1000
[ 165.530873] mwifiex_pcie 0000:01:00.0: Start CIU output, please wait...
[ 165.692101] mwifiex_pcie 0000:01:00.0: CIU done: size=0x1000
[ 165.698105] mwifiex_pcie 0000:01:00.0: ICU_SIZE=0x110
[ 165.703175] mwifiex_pcie 0000:01:00.0: Start ICU output, please wait...
[ 165.720419] mwifiex_pcie 0000:01:00.0: ICU done: size=0x110
[ 165.726270] mwifiex_pcie 0000:01:00.0: MAC_SIZE=0x1dc0
[ 165.731432] mwifiex_pcie 0000:01:00.0: Start MAC output, please wait...
[ 166.027001] mwifiex_pcie 0000:01:00.0: MAC done: size=0x1dc0
[ 166.032971] mwifiex_pcie 0000:01:00.0: Firmware dump Finished!
[ 166.039021] mwifiex_pcie 0000:01:00.0: == mwifiex firmware dump end ==
Another crash with a differenc cmd id:
[ 66.523837] mwifiex_pcie 0000:01:00.0: mwifiex_cmd_timeout_func:
Timeout cmd id = 0x107, act = 0x0
[ 66.532817] mwifiex_pcie 0000:01:00.0: num_data_h2c_failure = 0
[ 66.538762] mwifiex_pcie 0000:01:00.0: num_cmd_h2c_failure = 0
[ 66.544624] mwifiex_pcie 0000:01:00.0: is_cmd_timedout = 1
[ 66.550122] mwifiex_pcie 0000:01:00.0: num_tx_timeout = 0
[ 66.555546] mwifiex_pcie 0000:01:00.0: last_cmd_index = 1
[ 66.560953] mwifiex_pcie 0000:01:00.0: last_cmd_id: 07 01 07 01 07 01
10 00 ce 00
[ 66.568464] mwifiex_pcie 0000:01:00.0: last_cmd_act: 00 00 00 00 00
00 01 00 00 10
[ 66.576056] mwifiex_pcie 0000:01:00.0: last_cmd_resp_index = 0
[ 66.581895] mwifiex_pcie 0000:01:00.0: last_cmd_resp_id: 07 01 07 81
07 81 07 01 07 01
[ 66.589834] mwifiex_pcie 0000:01:00.0: last_event_index = 0
[ 66.595431] mwifiex_pcie 0000:01:00.0: last_event: 0a 00 58 00 58 00
58 00 0a 00
[ 66.602833] mwifiex_pcie 0000:01:00.0: data_sent=0 cmd_sent=1
[ 66.608612] mwifiex_pcie 0000:01:00.0: ps_mode=1 ps_state=0
[ 66.614209] mwifiex_pcie 0000:01:00.0: cmd timeout
[ 66.619045] mwifiex_pcie 0000:01:00.0: == mwifiex firmware dump start ==
[ 66.635674] mwifiex_pcie 0000:01:00.0: ITCM_SIZE=0x10000
[ 66.641046] mwifiex_pcie 0000:01:00.0: Start ITCM output, please wait...
[ 68.915215] mwifiex_pcie 0000:01:00.0: ITCM done: size=0x10000
[ 68.921358] mwifiex_pcie 0000:01:00.0: DTCM_SIZE=0x8000
[ 68.926963] mwifiex_pcie 0000:01:00.0: Start DTCM output, please wait...
[ 70.059221] mwifiex_pcie 0000:01:00.0: DTCM done: size=0x8000
[ 70.065312] mwifiex_pcie 0000:01:00.0: SQRAM_SIZE=0xa0000
[ 70.070855] mwifiex_pcie 0000:01:00.0: Start SQRAM output, please wait...
[ 92.691599] mwifiex_pcie 0000:01:00.0: SQRAM done: size=0xa0000
[ 92.697994] mwifiex_pcie 0000:01:00.0: IRAM_SIZE=0x58000
[ 92.703405] mwifiex_pcie 0000:01:00.0: Start IRAM output, please wait...
[ 105.157862] mwifiex_pcie 0000:01:00.0: IRAM done: size=0x58000
[ 105.164083] mwifiex_pcie 0000:01:00.0: APU_SIZE=0x350
[ 105.169228] mwifiex_pcie 0000:01:00.0: Start APU output, please wait...
[ 105.204942] mwifiex_pcie 0000:01:00.0: APU done: size=0x350
[ 105.210823] mwifiex_pcie 0000:01:00.0: CIU_SIZE=0x1000
[ 105.216002] mwifiex_pcie 0000:01:00.0: Start CIU output, please wait...
[ 105.364402] mwifiex_pcie 0000:01:00.0: CIU done: size=0x1000
[ 105.370432] mwifiex_pcie 0000:01:00.0: ICU_SIZE=0x110
[ 105.375544] mwifiex_pcie 0000:01:00.0: Start ICU output, please wait...
[ 105.391618] mwifiex_pcie 0000:01:00.0: ICU done: size=0x110
[ 105.397459] mwifiex_pcie 0000:01:00.0: MAC_SIZE=0x1dc0
[ 105.402614] mwifiex_pcie 0000:01:00.0: Start MAC output, please wait...
[ 105.670126] mwifiex_pcie 0000:01:00.0: MAC done: size=0x1dc0
[ 105.676154] mwifiex_pcie 0000:01:00.0: Firmware dump Finished!
[ 105.681995] mwifiex_pcie 0000:01:00.0: == mwifiex firmware dump end ==
^ permalink raw reply
* Re: [PATCH v3] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules
From: Seth Forshee @ 2017-03-01 14:59 UTC (permalink / raw)
To: Ryan Mounce; +Cc: wireless-regdb, linux-wireless
In-Reply-To: <20170225031027.7871-1-ryan@mounce.com.au>
On Sat, Feb 25, 2017 at 01:40:27PM +1030, Ryan Mounce wrote:
> Sourced from the current legislation at
> https://www.legislation.gov.au/Details/F2016C00432
>
> The current rules exceed legal limits between 5250-5330MHz, and permit
> illegal operation in 5600-5650MHz (disallowed regardless of DFS).
>
> Frequency ranges and EIRP limits for all ranges have been updated to
> match items 59-63, 65 in the linked document. As the rules for AU have
> never previously mirrored local regulations, changes include a
> significant increase in the allowable 2.4GHz EIRP and smaller increases
> in most other bands.
>
> In order to allow 80MHz operation between 5650-5730MHz (bordering two
> bands) the lower, more restrictive band has been rounded up by 5MHz.
>
> Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
This looks good to me. I'll give it a few more days to see if anyone
else has comments.
Thanks,
Seth
^ permalink raw reply
* Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO
From: Benjamin Beichler @ 2017-03-01 17:04 UTC (permalink / raw)
To: Ben Greear, Andrew Zaborowski; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <4d3505b9-9714-8ad0-5159-794cb566dc3b@candelatech.com>
Am 01.03.2017 um 16:35 schrieb Ben Greear:
> That is actually not possible. The permanent MAC-Addresses of hwsim
>
>> radios are directly created by there internal ID, which is only
>> increased for new radios and definitely not reassigned.
>>
>> But I would be happy, if this were possible, since it would make some
>> simulation related stuff easier (currently we need to unload and load
>> the hwsim module over and over again for every run).
>
> Ahh, you are right. But you can specify the wiphy name, and then you
> can use that to query the debugfs to find the MAC addr, and then sync
> your user-space with that info.
>
> It should also be easy enough to specify the MAC address when creating
> the radio.
>
> And, you should be able to create virtual STA, AP, etc, with any
> specified
> MAC address, so the MAC of the radio really should not matter much?
>
That is another problem ... this won't work currently, since the frame
delivery compares the receiver address with the permanent MAC addresses
of all hwsim phys. I work as an idle task on patch, which makes this
lookup (currently implemented as linear search) as a hashmap mapping an
MAC to a wiphy struct , including scenarios with differing MAC addresses
of vifs.
> Thanks,
> Ben
>
kind regards
Benjamin
--
M.Sc. Benjamin Beichler
Universität Rostock, Fakultät für Informatik und Elektrotechnik
Institut für Angewandte Mikroelektronik und Datentechnik
University of Rostock, Department of CS and EE
Institute of Applied Microelectronics and CE
Richard-Wagner-Straße 31
18119 Rostock
Deutschland/Germany
phone: +49 (0) 381 498 - 7278
email: Benjamin.Beichler@uni-rostock.de
www: http://www.imd.uni-rostock.de/
^ permalink raw reply
* Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO
From: Ben Greear @ 2017-03-01 15:35 UTC (permalink / raw)
To: Benjamin Beichler, Andrew Zaborowski; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <4efcd470-86ee-2f3d-bbe2-1d82874edffd@uni-rostock.de>
On 03/01/2017 06:33 AM, Benjamin Beichler wrote:
>> You can specify the MAC address and name (ie, wiphy0) when creating a
>> hwsim radio.
>> You cannot specify the index. So, from a user-space perspective,
>> I think the name and MAC is more important than the index.
>>
> That is actually not possible. The permanent MAC-Addresses of hwsim
> radios are directly created by there internal ID, which is only
> increased for new radios and definitely not reassigned.
>
> But I would be happy, if this were possible, since it would make some
> simulation related stuff easier (currently we need to unload and load
> the hwsim module over and over again for every run).
Ahh, you are right. But you can specify the wiphy name, and then you
can use that to query the debugfs to find the MAC addr, and then sync
your user-space with that info.
It should also be easy enough to specify the MAC address when creating
the radio.
And, you should be able to create virtual STA, AP, etc, with any specified
MAC address, so the MAC of the radio really should not matter much?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO
From: Benjamin Beichler @ 2017-03-01 14:33 UTC (permalink / raw)
To: Ben Greear, Andrew Zaborowski; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <4549b209-df6c-0eaa-65e6-72562c61bf4b@candelatech.com>
> You can specify the MAC address and name (ie, wiphy0) when creating a
> hwsim radio.
> You cannot specify the index. So, from a user-space perspective,
> I think the name and MAC is more important than the index.
>
That is actually not possible. The permanent MAC-Addresses of hwsim
radios are directly created by there internal ID, which is only
increased for new radios and definitely not reassigned.
But I would be happy, if this were possible, since it would make some
simulation related stuff easier (currently we need to unload and load
the hwsim module over and over again for every run).
--
M.Sc. Benjamin Beichler
Universität Rostock, Fakultät für Informatik und Elektrotechnik
Institut für Angewandte Mikroelektronik und Datentechnik
University of Rostock, Department of CS and EE
Institute of Applied Microelectronics and CE
Richard-Wagner-Straße 31
18119 Rostock
Deutschland/Germany
phone: +49 (0) 381 498 - 7278
email: Benjamin.Beichler@uni-rostock.de
www: http://www.imd.uni-rostock.de/
^ permalink raw reply
* Re: FILS offloading
From: Malinen, Jouni @ 2017-03-01 14:30 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Gery Kahn, Jouni Malinen
In-Reply-To: <d4fb8ca8-9632-3154-488e-5d7232601ed6@broadcom.com>
On Wed, Mar 01, 2017 at 11:28:48AM +0100, Arend Van Spriel wrote:
> Not sure which email address to use ;-) I noticed a while ago that FILS
> offloading was on the agenda of wireless workshop in Santa Fe. Recently,
> looked at the FILS patches that were applied upstream and noticed:
> static bool nl80211_valid_auth_type(struct cfg80211_registered_device *rd=
ev,
> case NL80211_CMD_CONNECT:
> case NL80211_CMD_START_AP:
> /* FILS not supported yet */
..
> Are there any plans on QCA side to add FILS support for fullmac devices,
> ie. supporting CONNECT command.
We do indeed have a patch going through internal review for this (well,
for the station part NL80211_CMD_CONNECT, not _START_AP). I hope to get
that posted shortly for public review.
--=20
Jouni Malinen PGP id EFC895FA=
^ permalink raw reply
* Deleting old wireless-testing tags
From: Bob Copeland @ 2017-03-01 14:14 UTC (permalink / raw)
To: linux-wireless
Hi all,
wireless-testing will resume again next week when the merge window opens,
and with 203 w-t tags since I started maintaining it a little over a year
ago, it's about time for some house-keeping. I plan to delete some of the
older tags in the kernel.org copy.
Before I do so, quick straw poll of anyone using this kernel: are there
specific tags I should keep, or any specific time period I should keep them
around?
E.g. I believe lede/openwrt are using compat-wireless builds generated from
wireless-testing; it might be worth retaining those particular tags just for
reference. I guess a few folks may be using it as a development tree and
would want a couple of kernel release cycles maintained, and so on.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* FILS offloading
From: Arend Van Spriel @ 2017-03-01 10:28 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, Gery Kahn, Jouni Malinen
Hoi Jouni,
Not sure which email address to use ;-) I noticed a while ago that FILS
offloading was on the agenda of wireless workshop in Santa Fe. Recently,
looked at the FILS patches that were applied upstream and noticed:
static bool nl80211_valid_auth_type(struct cfg80211_registered_device *rdev,
enum nl80211_auth_type auth_type,
enum nl80211_commands cmd)
{
...
switch (cmd) {
...
case NL80211_CMD_CONNECT:
case NL80211_CMD_START_AP:
/* SAE not supported yet */
if (auth_type == NL80211_AUTHTYPE_SAE)
return false;
/* FILS not supported yet */
if (auth_type == NL80211_AUTHTYPE_FILS_SK ||
auth_type == NL80211_AUTHTYPE_FILS_SK_PFS ||
auth_type == NL80211_AUTHTYPE_FILS_PK)
return false;
return true;
default:
return false;
}
}
Are there any plans on QCA side to add FILS support for fullmac devices,
ie. supporting CONNECT command.
Regards,
Arend
^ permalink raw reply
* Re: ath9k driver : Support for Continuous Test Tone mode
From: Julien Massot @ 2017-03-01 9:03 UTC (permalink / raw)
To: Senthilganapathy Paramasivam; +Cc: linux-wireless
In-Reply-To: <CAPK922czwT9jmpkn0xXGJxwL74hzsKWjxkYEhZf15v2oHKPV3g@mail.gmail.com>
Hi Senthil,
On Tue, Feb 28, 2017 at 9:02 PM, Senthilganapathy Paramasivam
<senthilgp2020@gmail.com> wrote:
>
> Hi ,
> One of our wireless embedded product is operating on Linux Kernel : 3.12.=
19.
>
> This product has a 802.11 a/b/g/n Full-size Mini PCIe Card
> EWM-W158F01E Which is based on atheros AR9592-AR1B Chipset. ath9k
> driver supports this chip set.
>
> One of the compliance testing requirement is :
> In the minimum transfer rate for power measurements, and at the
> maximum rate for the other measurements, with the transmitter
> operating with continuous transmission.
>
> I am looking for the test mode support in ath9k driver and user space
> utility to invoke the test mode.
>
> 1. Configuring the atheros 9k driver in CONFIG_ATH9K_TX99 test mode
> https://github.com/torvalds/linux/commit/ef6b19e40f525777a0052956bf7d9a19=
85f74993
> as per the log message the supported kernel is from 3.14-rc1
> Latest Kernel 3.12.70 also does not have support for TX99 mode.
You may want to try backport driver
https://backports.wiki.kernel.org/index.php/Main_Page
>
>
> 2. User space utility to send the continuous tone
> Some of the references using a special tool called Atheros test tool
> for the user space utility.
> There is a reference to a windows based utility "Atheros Radio test too=
l".
> Some documents refer to linux based atheros test tool but they are
> based on wireless extensions.
> Searching for a similar utility did not yield any results.
Please take a look at this commit message
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
=3D89f927af7f3389e20c8ad24abfb3d1369f3ffc10
I tested it successfully using an AR9462 adapter and a kernel 4.0.
>From what I understood from tx99_power parameter
doing;
echo 10 > /sys/kernel/debug/ieee80211/phy0/ath9k/tx99_power
will set the tx power to 5 dBm
Please try this shell script:
http://pastebin.com/ANZwVmbp
./test-wifi.sh 1 HT40+
First arg is the channel number,second one is the HT mode.
This script set the txpower to 20dBm.
I'm almost sure that there is a version of ART for Linux somewhere but you
may need to sign NDA, or special licence with QCA.
Best Regards,
Julien
--=20
*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------
*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*
^ permalink raw reply
* Re: [RFC 0/5] iwlwifi: enhance final opmode work
From: Johannes Berg @ 2017-03-01 7:12 UTC (permalink / raw)
To: Luis R. Rodriguez, luciano.coelho, emmanuel.grumbach, tj, arjan,
ming.lei, zajec5
Cc: jeyu, rusty, pmladek, gregkh, linuxwifi, linux-wireless,
linux-kernel
In-Reply-To: <20170217020903.6370-1-mcgrof@kernel.org>
> One of the limitations of using async_schedule() though is we cannot
> request_module() synchronously on async calls given that the module
> initialization code will call async_synchronize_full() if the module
> being initialized happened to have used async work on its
> initialization routine, otherwise we'd deadlock.
>
> So, I either I change back to workqueus or we live happy with either:
I really think you should avoid breaking this API and change back.
Drivers have been using it, how to avoid the use-after-free with a
completion is well known, and there's generally no issue.
Making things "easier" while requiring lots of churn everywhere isn't
always a good thing.
If you end up introducing some new API then perhaps that new API would
make sense to use async_schedule(), but I don't really see all that
much point in changing all of this now.
johannes
^ permalink raw reply
* [PATCH] iw: Add support for NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES netlink attribute
From: Alexis Green @ 2017-02-28 23:50 UTC (permalink / raw)
To: linux-wireless
This attributes allows configuring mesh to either do only minimum
number of discovery attempts (up to MaxPREretries) or always do
MaxPREretries number of tries even when getting responses.
Signed-off-by: Alexis Green <agreen@uniumwifi.com>
---
mesh.c | 3 +++
nl80211.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/mesh.c b/mesh.c
index 97f236b..b828408 100644
--- a/mesh.c
+++ b/mesh.c
@@ -264,6 +264,9 @@ const static struct mesh_param_descr _mesh_param_descrs[] =
_my_nla_put_u16, _parse_u16, _print_u16_in_TUs},
{"mesh_plink_timeout", NL80211_MESHCONF_PLINK_TIMEOUT,
_my_nla_put_u32, _parse_u32, _print_u32_in_seconds},
+ {"mesh_hwmp_always_max_discoveries",
+ NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
+ _my_nla_put_u8, _parse_u8_as_bool, _print_u8},
};
static void print_all_mesh_param_descr(void)
diff --git a/nl80211.h b/nl80211.h
index 56368e9..bb53e8b 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -3352,6 +3352,8 @@ enum nl80211_mesh_power_mode {
* established peering with for longer than this time (in seconds), then
* remove it from the STA's list of peers. You may set this to 0 to disable
* the removal of the STA. Default is 30 minutes.
+ * @NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES: whether to always perform
+ * number of discovery attempts equal to MaxPREQretries (default is FALSE)
*
* @__NL80211_MESHCONF_ATTR_AFTER_LAST: internal use
*/
@@ -3385,6 +3387,7 @@ enum nl80211_meshconf_params {
NL80211_MESHCONF_POWER_MODE,
NL80211_MESHCONF_AWAKE_WINDOW,
NL80211_MESHCONF_PLINK_TIMEOUT,
+ NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
/* keep last */
__NL80211_MESHCONF_ATTR_AFTER_LAST,
--
2.5.0.rc3
^ permalink raw reply related
* [PATCH v2] mac80211: mesh - always do every discovery retry
From: Alexis Green @ 2017-02-28 23:50 UTC (permalink / raw)
To: linux-wireless
Changes since v1: Make this behavior optional and configurable via
netlink.
Instead of stopping path discovery when a path is found continue
attempting to find paths until we hit the dot11MeshHWMPmaxPREQretries
limit.
This is important because path messages are not reliable and it is
relatively common to have a short bad path to the destination along with a
longer but better path. With the original code rather often a path message
along the long path would be lost so we would stick with the bad path.
With this change we have a greater chance to get messages over the longer
path allowing us to select the long path if it's better.
The standard doesn't seem to address this issue. All it says (13.10.8.5)
is that discovery should be limited to dot11MeshHWMPmaxPREQretries.
Signed-off-by: Alexis Green <agreen@uniumwifi.com>
---
include/net/cfg80211.h | 3 ++
include/uapi/linux/nl80211.h | 3 ++
net/mac80211/cfg.c | 2 ++
net/mac80211/debugfs_netdev.c | 3 ++
net/mac80211/mesh_hwmp.c | 65 +++++++++++++++++++++++++++++--------------
net/wireless/mesh.c | 1 +
net/wireless/nl80211.c | 8 +++++-
net/wireless/trace.h | 5 +++-
8 files changed, 67 insertions(+), 23 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 86c12f8..fb32abf 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1382,6 +1382,8 @@ struct bss_parameters {
* @plink_timeout: If no tx activity is seen from a STA we've established
* peering with for longer than this time (in seconds), then remove it
* from the STA's list of peers. Default is 30 minutes.
+ * @always_max_discoveries: whether to always perform number of discovery
+ * attemts equal to dot11MeshHWMPmaxPREQretries
*/
struct mesh_config {
u16 dot11MeshRetryTimeout;
@@ -1412,6 +1414,7 @@ struct mesh_config {
enum nl80211_mesh_power_mode power_mode;
u16 dot11MeshAwakeWindowDuration;
u32 plink_timeout;
+ bool always_max_discoveries;
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 9a499b1..58f8f0c 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3449,6 +3449,8 @@ enum nl80211_mesh_power_mode {
* established peering with for longer than this time (in seconds), then
* remove it from the STA's list of peers. You may set this to 0 to disable
* the removal of the STA. Default is 30 minutes.
+ * @NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES: whether to always perform
+ * number of discovery attempts equal to MaxPREQretries (default is FALSE)
*
* @__NL80211_MESHCONF_ATTR_AFTER_LAST: internal use
*/
@@ -3482,6 +3484,7 @@ enum nl80211_meshconf_params {
NL80211_MESHCONF_POWER_MODE,
NL80211_MESHCONF_AWAKE_WINDOW,
NL80211_MESHCONF_PLINK_TIMEOUT,
+ NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
/* keep last */
__NL80211_MESHCONF_ATTR_AFTER_LAST,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 9c7490c..9581873 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1956,6 +1956,8 @@ static int ieee80211_update_mesh_config(struct wiphy *wiphy,
nconf->dot11MeshAwakeWindowDuration;
if (_chg_mesh_attr(NL80211_MESHCONF_PLINK_TIMEOUT, mask))
conf->plink_timeout = nconf->plink_timeout;
+ if (_chg_mesh_attr(NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES, mask))
+ conf->always_max_discoveries = nconf->always_max_discoveries;
ieee80211_mbss_info_change_notify(sdata, BSS_CHANGED_BEACON);
return 0;
}
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index 8f5fff8..ceec6e8 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -642,6 +642,8 @@ IEEE80211_IF_FILE(dot11MeshHWMPconfirmationInterval,
IEEE80211_IF_FILE(power_mode, u.mesh.mshcfg.power_mode, DEC);
IEEE80211_IF_FILE(dot11MeshAwakeWindowDuration,
u.mesh.mshcfg.dot11MeshAwakeWindowDuration, DEC);
+IEEE80211_IF_FILE(always_max_discoveries,
+ u.mesh.mshcfg.always_max_discoveries, DEC);
#endif
#define DEBUGFS_ADD_MODE(name, mode) \
@@ -763,6 +765,7 @@ static void add_mesh_config(struct ieee80211_sub_if_data *sdata)
MESHPARAMS_ADD(dot11MeshHWMPconfirmationInterval);
MESHPARAMS_ADD(power_mode);
MESHPARAMS_ADD(dot11MeshAwakeWindowDuration);
+ MESHPARAMS_ADD(always_max_discoveries);
#undef MESHPARAMS_ADD
}
#endif
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index d07ee3c..7c019f9 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -1198,34 +1198,57 @@ void mesh_path_timer(unsigned long data)
{
struct mesh_path *mpath = (void *) data;
struct ieee80211_sub_if_data *sdata = mpath->sdata;
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ bool multiple_discoveries = ifmsh->mshcfg.always_max_discoveries;
int ret;
if (sdata->local->quiescing)
return;
spin_lock_bh(&mpath->state_lock);
- if (mpath->flags & MESH_PATH_RESOLVED ||
- (!(mpath->flags & MESH_PATH_RESOLVING))) {
- mpath->flags &= ~(MESH_PATH_RESOLVING | MESH_PATH_RESOLVED);
- spin_unlock_bh(&mpath->state_lock);
- } else if (mpath->discovery_retries < max_preq_retries(sdata)) {
- ++mpath->discovery_retries;
- mpath->discovery_timeout *= 2;
- mpath->flags &= ~MESH_PATH_REQ_QUEUED;
- spin_unlock_bh(&mpath->state_lock);
- mesh_queue_preq(mpath, 0);
+ if (!multiple_discoveries) {
+ if (mpath->flags & MESH_PATH_RESOLVED ||
+ (!(mpath->flags & MESH_PATH_RESOLVING))) {
+ mpath->flags &= ~(MESH_PATH_RESOLVING |
+ MESH_PATH_RESOLVED);
+ spin_unlock_bh(&mpath->state_lock);
+ return;
+ } else if (mpath->discovery_retries < max_preq_retries(sdata)) {
+ ++mpath->discovery_retries;
+ mpath->discovery_timeout *= 2;
+ mpath->flags &= ~MESH_PATH_REQ_QUEUED;
+ spin_unlock_bh(&mpath->state_lock);
+ mesh_queue_preq(mpath, 0);
+ return;
+ }
} else {
- mpath->flags &= ~(MESH_PATH_RESOLVING |
- MESH_PATH_RESOLVED |
- MESH_PATH_REQ_QUEUED);
- mpath->exp_time = jiffies;
- spin_unlock_bh(&mpath->state_lock);
- if (!mpath->is_gate && mesh_gate_num(sdata) > 0) {
- ret = mesh_path_send_to_gates(mpath);
- if (ret)
- mhwmp_dbg(sdata, "no gate was reachable\n");
- } else
- mesh_path_flush_pending(mpath);
+ if (mpath->discovery_retries < max_preq_retries(sdata)) {
+ ++mpath->discovery_retries;
+ mpath->discovery_timeout *= 2;
+ mpath->flags &= ~MESH_PATH_REQ_QUEUED;
+ spin_unlock_bh(&mpath->state_lock);
+ mesh_queue_preq(mpath, 0);
+ return;
+ } else if (mpath->flags & MESH_PATH_RESOLVED ||
+ (!(mpath->flags & MESH_PATH_RESOLVING))) {
+ mpath->flags &= ~(MESH_PATH_RESOLVING |
+ MESH_PATH_RESOLVED);
+ spin_unlock_bh(&mpath->state_lock);
+ return;
+ }
+ }
+
+ mpath->flags &= ~(MESH_PATH_RESOLVING |
+ MESH_PATH_RESOLVED |
+ MESH_PATH_REQ_QUEUED);
+ mpath->exp_time = jiffies;
+ spin_unlock_bh(&mpath->state_lock);
+ if (!mpath->is_gate && mesh_gate_num(sdata) > 0) {
+ ret = mesh_path_send_to_gates(mpath);
+ if (ret)
+ mhwmp_dbg(sdata, "no gate was reachable\n");
+ } else {
+ mesh_path_flush_pending(mpath);
}
}
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index 2d8518a..f82fcd3 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -77,6 +77,7 @@ const struct mesh_config default_mesh_config = {
.power_mode = NL80211_MESH_POWER_ACTIVE,
.dot11MeshAwakeWindowDuration = MESH_DEFAULT_AWAKE_WINDOW,
.plink_timeout = MESH_DEFAULT_PLINK_TIMEOUT,
+ .always_max_discoveries = false,
};
const struct mesh_setup default_mesh_setup = {
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d516527..6e1181d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5729,7 +5729,9 @@ static int nl80211_get_mesh_config(struct sk_buff *skb,
nla_put_u16(msg, NL80211_MESHCONF_AWAKE_WINDOW,
cur_params.dot11MeshAwakeWindowDuration) ||
nla_put_u32(msg, NL80211_MESHCONF_PLINK_TIMEOUT,
- cur_params.plink_timeout))
+ cur_params.plink_timeout) ||
+ nla_put_u8(msg, NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
+ cur_params.always_max_discoveries))
goto nla_put_failure;
nla_nest_end(msg, pinfoattr);
genlmsg_end(msg, hdr);
@@ -5771,6 +5773,7 @@ static const struct nla_policy nl80211_meshconf_params_policy[NL80211_MESHCONF_A
[NL80211_MESHCONF_POWER_MODE] = { .type = NLA_U32 },
[NL80211_MESHCONF_AWAKE_WINDOW] = { .type = NLA_U16 },
[NL80211_MESHCONF_PLINK_TIMEOUT] = { .type = NLA_U32 },
+ [NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES] = { .type = NLA_U8 },
};
static const struct nla_policy
@@ -5995,6 +5998,9 @@ do { \
FILL_IN_MESH_PARAM_IF_SET(tb, cfg, plink_timeout, 0, 0xffffffff,
mask, NL80211_MESHCONF_PLINK_TIMEOUT,
nl80211_check_u32);
+ FILL_IN_MESH_PARAM_IF_SET(tb, cfg, always_max_discoveries, 0, 1, mask,
+ NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
+ nl80211_check_bool);
if (mask_out)
*mask_out = mask;
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index fd55786..cc4a966 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -67,7 +67,8 @@
__field(u16, ht_opmode) \
__field(u32, dot11MeshHWMPactivePathToRootTimeout) \
__field(u16, dot11MeshHWMProotInterval) \
- __field(u16, dot11MeshHWMPconfirmationInterval)
+ __field(u16, dot11MeshHWMPconfirmationInterval) \
+ __field(bool, always_max_discoveries)
#define MESH_CFG_ASSIGN \
do { \
__entry->dot11MeshRetryTimeout = conf->dot11MeshRetryTimeout; \
@@ -108,6 +109,8 @@
conf->dot11MeshHWMProotInterval; \
__entry->dot11MeshHWMPconfirmationInterval = \
conf->dot11MeshHWMPconfirmationInterval; \
+ __entry->always_max_discoveries = \
+ conf->always_max_discoveries; \
} while (0)
#define CHAN_ENTRY __field(enum nl80211_band, band) \
^ permalink raw reply related
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