Re: [PATCH 2/2] ath10k: support MAC address randomization in scan

[Dan Williams]

On Tue, 2018-04-17 at 15:26 -0700, Brian Norris wrote:
> On Tue, Apr 17, 2018 at 2:49 PM, Arend van Spriel
>  wrote:
> > On 4/17/2018 6:07 PM, Brian Norris wrote:
> > > On Tue, Apr 17, 2018 at 10:22:13AM +0200, Arend van Spriel wrote:
> > > > I believe checking command support is not really recommended.
> > > > Instead, you
> > > > better check NL80211_ATTR_SCHED_SCAN_MAX_REQS being non-zero
> > > > (since kernel
> > > > 4.12 that is).
> > > 
> > > 
> > > Why not? Command support checking is what wpa_supplicant is
> > > doing.
> > 
> > 
> > That's not really a good argument. A couple (or more) years ago
> > wpa_supplicant was not doing nl80211 but wext and some other using
> > driver private ioctls, but that did not make it the best approach.
> 
> I see what you're saying (though your comparison doesn't seem that
> fair either; private ioctls are nothing like a well-defined nl80211
> support list), and I'm totally good on looking at the new flag
> eventually. But you still haven't answered my question ("why not?").
> Is there a problem with the "supported commands" list?
> 
> > The START_SCHED_SCAN command is indeed still provided to user-
> > space:
> 
> And as I see it, it probably needs to be for essentially forever. Or
> at least a significant amount of time after wpa_supplicant stops
> relying on it. (Hint: it's still using it today, with no reference to
> NL80211_ATTR_SCHED_SCAN_MAX_REQS.) There's a reason the kernel has
> ABI
> guarantees. I suspect you only get a chance to rewrite the world
> (WEXT
> -> nl80211) a few times in the life of kernel ABIs.

It sometimes feels like wpa_supplicant gets treated as a static entity
that can never be changed.  In fact, send a patch to Jouni implementing
the best practice, with a fallback to preserve compat for old kernels,
and I'm sure he'd entertain it.  Just because the supplicant does
something a certain way, doesn't mean it's the *best* way, but it too
evolves.

Dan

Re: second wifi card enforce CN reg dom

[Dan Williams]

On Thu, 2018-04-12 at 08:18 -0700, Steve deRosier wrote:
> On Thu, Apr 12, 2018 at 3:51 AM, Arend van Spriel
>  wrote:
> > On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
> > > 
> > > Hi.
> > > 
> > > This is beyond my comprehension that you could assert this is a
> > > non issue.
> > 
> > 
> > Well. I am just saying that it is by design. There is no way for
> > the
> > regulatory code to determine where you and your hardware actually
> > reside so
> > instead it takes a conservative approach.
> > 
> 
> To say it another way: mixing regulatory domains on your host system
> should result in a _smaller_ set of channels - ie only those channels
> at the intersection of the two.
> 
> And another wrinkle to consider - one of the 802.11 amendments (can't
> remember which one) actually causes the radio to listen to the 

802.11d I believe, from the early 2000s.

Dan

> beacons
> around it, determine what the local regulatory domain is based on the
> beacons it hears, and then lock to that regulatory domain. It's
> possible for that information to be propagated up to the card's host
> and the regulatory domain then would affect both cards. That's how
> it's supposed to work, though I don't factually know Linux does this
> in all cases.  Could it be you're somewhere where CN is the local
> regulatory domain and the TL-WN722N has this feature?
> 
> In any case, as Arend points out, despite the hand-wringing that
> regulatory domains cause users trying to do something particular,
> between certain rules and regulations and certain manufacturers bad
> interpretations and implementations around it, there's little that
> can
> be done about it. Fact is, your radio must comply to whatever
> regulatory domain you are in, otherwise it's breaking the rules. And
> people breaking the regulatory rules is part of what's gotten
> governments to pass even worse (for us OSS guys) laws that tighten
> those rules down further.
> 
> You asked who to contact. Its not the LKML - it's your relevant
> government body. And certain manufacturers who improperly interpret
> said rules because it's easier for them.
> 
> - Steve
> 
> --
> Steve deRosier
> Cal-Sierra Consulting LLC
> https://www.cal-sierra.com/

Re: [v2 PATCH] mwifiex: parse key management suite from RSN IE

[Dan Williams]

On Tue, 2018-04-10 at 02:19 +, Xinming Hu wrote:
> Hi Kalle,
> 
> > -Original Message-
> > From: Kalle Valo [mailto:kv...@codeaurora.org]
> > Sent: 2018年4月9日 18:51
> > To: Xinming Hu 
> > Cc: Linux Wireless ; Brian Norris
> > ; Dmitry Torokhov ;
> > raja...@google.com; Zhiyuan Yang ; Tim Song
> > ; Cathy Luo ; James Cao
> > ; Ganapathi Bhat ; Ellie
> > Reeves
> > 
> > Subject: Re: [v2 PATCH] mwifiex: parse key management suite from
> > RSN IE
> > 
> > Xinming Hu  writes:
> > 
> > > Association failed when using wpa_supplicant with configuration
> > > key_mgmt=WPA-PSK-SHA256, and it is noticed that wpa_supplicant
> > > set
> > > WLAN_AKM_SUITE_PSK_SHA256 in RSN IE, but miss it in start_ap
> > > parameters.
> > > 
> > > This patch parse key management suite from RSN IE, in case it is
> > > missed.
> > > 
> > > Signed-off-by: Xinming Hu 
> > 
> > Shouldn't you fix wpa_supplicant instead of adding a workaround to
> > the driver?
> > 
> 
> Yes, I am preparing a wpa_supplicant fix on this.
> Even so, driver fix is still need to compatible with old
> wpa_supplicant stable release

Typically the kernel does not add hacks to work around userspace
software bugs.  The userspace software needs to be fixed and upgraded.

Dan

Re: [PATCH] ath9k: introduce endian_check module parameter

[Dan Williams]

On Mon, 2018-02-26 at 17:44 +0100, Bas Vermeulen wrote:
> On 26-02-18 17:32, Larry Finger wrote:
> > On 02/26/2018 04:07 AM, Bas Vermeulen wrote:
> > > On 26-02-18 10:54, Kalle Valo wrote:
> > > > Bas Vermeulen  writes:
> > > > 
> > > > > A random (little endian eeprom'd) ar9278 card didn't work on
> > > > > my
> > > > > PowerMac G5 without allowing the driver to byte-swap the
> > > > > eeprom.
> > > > > 
> > > > > Introduce a module parameter endian_check to allow this to
> > > > > happen,
> > > > > and the PCIe card to function correctly on BE powerpc.
> > > > > 
> > > > > Signed-off-by: Bas Vermeulen 
> > > > > ---
> > > > >   drivers/net/wireless/ath/ath9k/init.c | 6 +-
> > > > >   1 file changed, 5 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/net/wireless/ath/ath9k/init.c 
> > > > > b/drivers/net/wireless/ath/ath9k/init.c
> > > > > index fa58a32227f5..421039dc060a 100644
> > > > > --- a/drivers/net/wireless/ath/ath9k/init.c
> > > > > +++ b/drivers/net/wireless/ath/ath9k/init.c
> > > > > @@ -67,6 +67,9 @@ static int ath9k_ps_enable;
> > > > >   module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
> > > > >   MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
> > > > > +static int ath9k_endian_check;
> > > > > +module_param_named(endian_check, ath9k_endian_check, int,
> > > > > 0444);
> > > > > +MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness 
> > > > > compatibility");
> > > > >   #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
> > > > >   int ath9k_use_chanctx;
> > > > > @@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc
> > > > > *sc)
> > > > >   ether_addr_copy(common->macaddr, mac);
> > > > >   ah->ah_flags &= ~AH_USE_EEPROM;
> > > > > -ah->ah_flags |= AH_NO_EEP_SWAP;
> > > > > +if (!ath9k_endian_check)
> > > > > +ah->ah_flags |= AH_NO_EEP_SWAP;
> > > > 
> > > > A bit annoying to have a module parameter, isn't there any
> > > > automatic 
> > > > way
> > > > to detect/try this? But on the other hand I guess this isn't a
> > > > common
> > > > problem as nobody has reported this before?
> > > 
> > > There is an automatic way to detect this, but that is disabled by
> > > the 
> > > AH_NO_EEP_SWAP flag.
> > > The platform initialisation does not set this flag if the 
> > > endian_check member of pdata is set
> > > to true, but there is no way to not set this when using a device 
> > > tree. I used a module
> > > parameter instead of a device tree variable because I don't know
> > > of a 
> > > way to modify the
> > > device tree my PowerMac boots with.
> > 
> > Shouldn't you be able to set ath9k_endian_check inside #ifdef 
> > __BIG_ENDIAN ... #endif in the initialization? I think that would 
> > achieve the same functionality without requiring the user to set a 
> > module parameter.
> 
> I could have done that, but didn't want to change the default
> behaviour. 
> This patch keeps the
> current behaviour on all platforms if the module parameter is not
> set. I 
> don't have the means
> to test mips and other platforms this could be used on. I don't mind 
> having to set a module
> parameter, I mind not being able to change the behaviour

Still, module parameters are an awful user experience because you need
to know that they exist, what they do, and whether you need it or not. 
It doesn't just work.

Is there no way to autodetect the endian-ness of the firmware itself,
and if the known machine endian-ness isn't the same then swap?  This
seems like a solvable problem.

Dan

[PATCH v6 00/13] spectre variant1 mitigations for tip/x86/pti

[Dan Williams]

Hi Thomas, Ingo,

Here is another spin of the Spectre variant1 mitigations.

Changes since v5 [1]:
* Use the _nospec suffix for all new infrastructure, i.e.
  s/ifence/barrier_nospec/, s/array_idx/array_index_nospec/,
  and s/array_idx_mask/array_index_mask_nospec/. (Ingo)

* Fix up array_index_mask_nospec() to have a proper kernel doc comment
  (Thomas)

* Fix up copyright attribution in include/linux/nospec.h (Ingo)

* Spell out 'index' and 'size' throughout the patch set rather than
  'idx' and 'sz'. (Ingo).

* Clarify placement of barrier_nospec() relative to stac() in
  __uaccess_begin_nospec() (Ingo)

* Drop the syscall fast path elimination patch out of this series since
  Andy is handling that separately. (Andy)

* Simplify the x86 array_index_mask_nospec() assembly, no need for a
  separate 32-bit version (Ingo)

* Clarify that the 'cmp, sbb' sequence in the get_user_ variants
  are effectively open coded array_index_nospec() instances where the
  array base is the user pointer and the array limit is the task address
  limit. (Ingo)

* Replace '' with ()
  throughout the series. (Ingo)

* Comment and whitespace fixups in asm/barrier.h (Ingo)

* Split the definition of barrier_nospec() into its own patch separate
  from its new usages with __uaccess_begin_nospec(). (Ingo)

* Split the __uaccess_begin_nospec() patch into one that cleans up open
  coded stac/clac usage and one that uses the new
  __uaccess_begin_nospec() helper. (Ingo)

* Change the contents of the 'bug/spectre_v1' sysfs file to:
  "Mitigation: __user pointer sanitization" since these changes do raise
  the kernel's defenses. (Ingo)

[1]: https://www.spinics.net/lists/linux-arch/msg44193.html

---

Dan Williams (12):
  array_index_nospec: sanitize speculative array de-references
  x86: implement array_index_mask_nospec
  x86: introduce barrier_nospec
  x86: introduce __uaccess_begin_nospec
  x86, usercopy: replace open coded stac/clac with __uaccess_{begin,end}
  x86, __get_user: use __uaccess_begin_nospec
  x86, get_user: use pointer masking to limit speculation
  x86: sanitize syscall table de-references under speculation
  vfs, fdtable: prevent bounds-check bypass via speculative execution
  kvm, x86: update spectre-v1 mitigation
  nl80211: sanitize array index in parse_txq_params
  x86/spectre: report get_user mitigation for spectre_v1

Mark Rutland (1):
  Documentation: document array_index_nospec


 Documentation/speculation.txt |   90 +
 arch/x86/entry/common.c   |5 ++
 arch/x86/include/asm/barrier.h|   28 
 arch/x86/include/asm/msr.h|3 -
 arch/x86/include/asm/uaccess.h|   15 +-
 arch/x86/include/asm/uaccess_32.h |6 +-
 arch/x86/include/asm/uaccess_64.h |   12 ++---
 arch/x86/kernel/cpu/bugs.c|2 -
 arch/x86/kvm/vmx.c|   14 --
 arch/x86/lib/getuser.S|   10 
 arch/x86/lib/usercopy_32.c|8 ++-
 include/linux/fdtable.h   |5 ++
 include/linux/nospec.h|   72 ++
 net/wireless/nl80211.c|9 ++--
 14 files changed, 251 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/speculation.txt
 create mode 100644 include/linux/nospec.h

[PATCH v6 12/13] nl80211: sanitize array index in parse_txq_params

[Dan Williams]

Wireless drivers rely on parse_txq_params to validate that
txq_params->ac is less than NL80211_NUM_ACS by the time the low-level
driver's ->conf_tx() handler is called. Use a new helper,
array_index_nospec(), to sanitize txq_params->ac with respect to
speculation. I.e. ensure that any speculation into ->conf_tx() handlers
is done with a value of txq_params->ac that is within the bounds of [0,
NL80211_NUM_ACS).

Reported-by: Christian Lamparter <chunk...@gmail.com>
Reported-by: Elena Reshetova <elena.reshet...@intel.com>
Acked-by: Johannes Berg <johan...@sipsolutions.net>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
---
 net/wireless/nl80211.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d396cb61a280..81bef0676e1d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2056,20 +2057,22 @@ static const struct nla_policy 
txq_params_policy[NL80211_TXQ_ATTR_MAX + 1] = {
 static int parse_txq_params(struct nlattr *tb[],
struct ieee80211_txq_params *txq_params)
 {
+   u8 ac;
+
if (!tb[NL80211_TXQ_ATTR_AC] || !tb[NL80211_TXQ_ATTR_TXOP] ||
!tb[NL80211_TXQ_ATTR_CWMIN] || !tb[NL80211_TXQ_ATTR_CWMAX] ||
!tb[NL80211_TXQ_ATTR_AIFS])
return -EINVAL;
 
-   txq_params->ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
+   ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
txq_params->txop = nla_get_u16(tb[NL80211_TXQ_ATTR_TXOP]);
txq_params->cwmin = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMIN]);
txq_params->cwmax = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMAX]);
txq_params->aifs = nla_get_u8(tb[NL80211_TXQ_ATTR_AIFS]);
 
-   if (txq_params->ac >= NL80211_NUM_ACS)
+   if (ac >= NL80211_NUM_ACS)
return -EINVAL;
-
+   txq_params->ac = array_index_nospec(ac, NL80211_NUM_ACS);
return 0;
 }
 

Re: [PATCH v5 00/12] spectre variant1 mitigations for tip/x86/pti

[Dan Williams]

[ adding lkml ]

I had inadvertently dropped lkml when sending this to Thomas. Archive here:

https://marc.info/?l=linux-wireless=151704026325010=2
https://marc.info/?l=linux-arch=151704027225013=2
https://marc.info/?l=linux-arch=151704027225014=2
https://marc.info/?l=linux-arch=151704027625015=2
https://marc.info/?l=linux-arch=151704028225016=2
https://marc.info/?l=linux-arch=151704028725019=2
https://marc.info/?l=linux-arch=151704086725186=2
https://marc.info/?l=linux-arch=151704030025025=2
https://marc.info/?l=linux-arch=151704030525028=2
https://marc.info/?l=linux-arch=151704031125029=2
https://marc.info/?l=linux-arch=151704032225034=2
https://marc.info/?l=linux-arch=151704032625035=2
https://marc.info/?l=linux-arch=151704032725037=2


On Fri, Jan 26, 2018 at 11:55 PM, Dan Williams <dan.j.willi...@intel.com> wrote:
> Hi Thomas,
>
> Here's another spin of the spectre-v1 mitigations for 4.16.
>
> Changes since v4.1: [1]
> * Tweak the sanitization scheme yet again to make it even simpler. Now,
>   instead of 'array_ptr' to get a sanitized pointer to an array element,
>   just provide an array index sanitization helper 'array_idx' to be called
>   after successfully validating the index is in bounds. I.e. in the
>   exact same location one would otherwise put an lfence, place this
>   sanitizer:
>
>   if (idx < sz) {
>   idx = array_idx(idx, sz);
>   val = array[idx];
>   }
>
>   This lets the implementation include more sanity checking that the
>   compiler can usually compile out. It otherwise appears to produce
>   better assembly. This also cleans up the concern about comparing the
>   value returned from array_ptr to create another speculation point.
>   (Russell, Linus, Cyril)
>
> * Drop the syscall_64_fastpath.  This is the straightforward patch from
>   Linus that might also be in flight from Andy, but I went ahead and
>   included it since I did not see it on LKML yet.
>
> * Kill the MASK_NOSPEC macro and just open code it. (Andy)
>
> * Add system-call-number sanitization to the slow path syscall table
>   lookups.
>
> * Redo the array_ptr conversions with array_idx.
>
> * Update /sys/devices/system/cpu/vulnerabilities/spectre_v1 to indicate
>   the new protections. It now reports "Vulnerable: Minimal user pointer
>   sanitization". (Jiri)
>
> ---
>
> Dan Williams (11):
>   array_idx: sanitize speculative array de-references
>   x86: implement array_idx_mask
>   x86: introduce __uaccess_begin_nospec and ifence
>   x86, __get_user: use __uaccess_begin_nospec
>   x86, get_user: use pointer masking to limit speculation
>   x86: remove the syscall_64 fast-path
>   x86: sanitize sycall table de-references under speculation
>   vfs, fdtable: prevent bounds-check bypass via speculative execution
>   kvm, x86: update spectre-v1 mitigation
>   nl80211: sanitize array index in parse_txq_params
>   x86/spectre: report get_user mitigation for spectre_v1
>
> Mark Rutland (1):
>   Documentation: document array_idx
>
>
>  Documentation/speculation.txt |   87 
>  arch/x86/entry/common.c   |3 +
>  arch/x86/entry/entry_64.S |  116 
> -
>  arch/x86/entry/syscall_64.c   |7 +-
>  arch/x86/include/asm/barrier.h|   26 
>  arch/x86/include/asm/msr.h|3 -
>  arch/x86/include/asm/uaccess.h|   15 -
>  arch/x86/include/asm/uaccess_32.h |6 +-
>  arch/x86/include/asm/uaccess_64.h |   12 ++--
>  arch/x86/kernel/cpu/bugs.c|2 -
>  arch/x86/kvm/vmx.c|   14 +++-
>  arch/x86/lib/getuser.S|   10 +++
>  arch/x86/lib/usercopy_32.c|8 +--
>  include/linux/fdtable.h   |5 +-
>  include/linux/nospec.h|   64 
>  net/wireless/nl80211.c|9 ++-
>  16 files changed, 239 insertions(+), 148 deletions(-)
>  create mode 100644 Documentation/speculation.txt
>  create mode 100644 include/linux/nospec.h

[PATCH v5 11/12] nl80211: sanitize array index in parse_txq_params

[Dan Williams]

Wireless drivers rely on parse_txq_params to validate that
txq_params->ac is less than NL80211_NUM_ACS by the time the low-level
driver's ->conf_tx() handler is called. Use a new helper, 'array_idx',
to sanitize txq_params->ac with respect to speculation. I.e. ensure that
any speculation into ->conf_tx() handlers is done with a value of
txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS).

Reported-by: Christian Lamparter <chunk...@gmail.com>
Reported-by: Elena Reshetova <elena.reshet...@intel.com>
Acked-by: Johannes Berg <johan...@sipsolutions.net>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
---
 net/wireless/nl80211.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d396cb61a280..1479a1c7819c 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2056,20 +2057,22 @@ static const struct nla_policy 
txq_params_policy[NL80211_TXQ_ATTR_MAX + 1] = {
 static int parse_txq_params(struct nlattr *tb[],
struct ieee80211_txq_params *txq_params)
 {
+   u8 ac;
+
if (!tb[NL80211_TXQ_ATTR_AC] || !tb[NL80211_TXQ_ATTR_TXOP] ||
!tb[NL80211_TXQ_ATTR_CWMIN] || !tb[NL80211_TXQ_ATTR_CWMAX] ||
!tb[NL80211_TXQ_ATTR_AIFS])
return -EINVAL;
 
-   txq_params->ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
+   ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
txq_params->txop = nla_get_u16(tb[NL80211_TXQ_ATTR_TXOP]);
txq_params->cwmin = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMIN]);
txq_params->cwmax = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMAX]);
txq_params->aifs = nla_get_u8(tb[NL80211_TXQ_ATTR_AIFS]);
 
-   if (txq_params->ac >= NL80211_NUM_ACS)
+   if (ac >= NL80211_NUM_ACS)
return -EINVAL;
-
+   txq_params->ac = array_idx(ac, NL80211_NUM_ACS);
return 0;
 }
 

[PATCH v5 00/12] spectre variant1 mitigations for tip/x86/pti

[Dan Williams]

Hi Thomas,

Here's another spin of the spectre-v1 mitigations for 4.16.

Changes since v4.1: [1]
* Tweak the sanitization scheme yet again to make it even simpler. Now,
  instead of 'array_ptr' to get a sanitized pointer to an array element,
  just provide an array index sanitization helper 'array_idx' to be called
  after successfully validating the index is in bounds. I.e. in the
  exact same location one would otherwise put an lfence, place this
  sanitizer:

  if (idx < sz) {
  idx = array_idx(idx, sz);
  val = array[idx];
  }

  This lets the implementation include more sanity checking that the
  compiler can usually compile out. It otherwise appears to produce
  better assembly. This also cleans up the concern about comparing the
  value returned from array_ptr to create another speculation point.
  (Russell, Linus, Cyril)

* Drop the syscall_64_fastpath.  This is the straightforward patch from
  Linus that might also be in flight from Andy, but I went ahead and
  included it since I did not see it on LKML yet.

* Kill the MASK_NOSPEC macro and just open code it. (Andy)

* Add system-call-number sanitization to the slow path syscall table
  lookups.

* Redo the array_ptr conversions with array_idx.

* Update /sys/devices/system/cpu/vulnerabilities/spectre_v1 to indicate
  the new protections. It now reports "Vulnerable: Minimal user pointer
  sanitization". (Jiri)

---

Dan Williams (11):
  array_idx: sanitize speculative array de-references
  x86: implement array_idx_mask
  x86: introduce __uaccess_begin_nospec and ifence
  x86, __get_user: use __uaccess_begin_nospec
  x86, get_user: use pointer masking to limit speculation
  x86: remove the syscall_64 fast-path
  x86: sanitize sycall table de-references under speculation
  vfs, fdtable: prevent bounds-check bypass via speculative execution
  kvm, x86: update spectre-v1 mitigation
  nl80211: sanitize array index in parse_txq_params
  x86/spectre: report get_user mitigation for spectre_v1

Mark Rutland (1):
  Documentation: document array_idx


 Documentation/speculation.txt |   87 
 arch/x86/entry/common.c   |3 +
 arch/x86/entry/entry_64.S |  116 -
 arch/x86/entry/syscall_64.c   |7 +-
 arch/x86/include/asm/barrier.h|   26 
 arch/x86/include/asm/msr.h|3 -
 arch/x86/include/asm/uaccess.h|   15 -
 arch/x86/include/asm/uaccess_32.h |6 +-
 arch/x86/include/asm/uaccess_64.h |   12 ++--
 arch/x86/kernel/cpu/bugs.c|2 -
 arch/x86/kvm/vmx.c|   14 +++-
 arch/x86/lib/getuser.S|   10 +++
 arch/x86/lib/usercopy_32.c|8 +--
 include/linux/fdtable.h   |5 +-
 include/linux/nospec.h|   64 
 net/wireless/nl80211.c|9 ++-
 16 files changed, 239 insertions(+), 148 deletions(-)
 create mode 100644 Documentation/speculation.txt
 create mode 100644 include/linux/nospec.h

[PATCH v4.1 10/10] nl80211: sanitize array index in parse_txq_params

[Dan Williams]

Wireless drivers rely on parse_txq_params to validate that
txq_params->ac is less than NL80211_NUM_ACS by the time the low-level
driver's ->conf_tx() handler is called. Use a new helper, 'array_idx',
to sanitize txq_params->ac with respect to speculation. I.e. ensure that
any speculation into ->conf_tx() handlers is done with a value of
txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS).

Reported-by: Christian Lamparter <chunk...@gmail.com>
Reported-by: Elena Reshetova <elena.reshet...@intel.com>
Cc: Johannes Berg <johan...@sipsolutions.net>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
---
 include/linux/nospec.h |   21 +
 net/wireless/nl80211.c |   10 +++---
 2 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/include/linux/nospec.h b/include/linux/nospec.h
index dd3aa05fab87..b8a9222e34d1 100644
--- a/include/linux/nospec.h
+++ b/include/linux/nospec.h
@@ -41,4 +41,25 @@ static inline unsigned long array_ptr_mask(unsigned long 
idx, unsigned long sz)
__u._bit &= _mask;  \
__u._ptr;   \
 })
+
+/**
+ * array_idx - Generate a pointer to an array index, ensuring the
+ * pointer is bounded under speculation to NULL.
+ *
+ * @idx: the index of the element, must be less than LONG_MAX
+ * @sz: the number of elements in the array, must be less than LONG_MAX
+ *
+ * If @idx falls in the interval [0, @sz), returns &@idx otherwise
+ * returns NULL.
+ */
+#define array_idx(idx, sz) \
+({ \
+   union { typeof((idx)) *_ptr; unsigned long _bit; } __u; \
+   typeof(idx) *_i = &(idx);   \
+   unsigned long _mask = array_ptr_mask(*_i, (sz));\
+   \
+   __u._ptr = _i;  \
+   __u._bit &= _mask;  \
+   __u._ptr;   \
+})
 #endif /* __NOSPEC_H__ */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d396cb61a280..e3b3527c16d4 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2056,20 +2057,23 @@ static const struct nla_policy 
txq_params_policy[NL80211_TXQ_ATTR_MAX + 1] = {
 static int parse_txq_params(struct nlattr *tb[],
struct ieee80211_txq_params *txq_params)
 {
+   u8 ac, *idx;
+
if (!tb[NL80211_TXQ_ATTR_AC] || !tb[NL80211_TXQ_ATTR_TXOP] ||
!tb[NL80211_TXQ_ATTR_CWMIN] || !tb[NL80211_TXQ_ATTR_CWMAX] ||
!tb[NL80211_TXQ_ATTR_AIFS])
return -EINVAL;
 
-   txq_params->ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
+   ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
txq_params->txop = nla_get_u16(tb[NL80211_TXQ_ATTR_TXOP]);
txq_params->cwmin = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMIN]);
txq_params->cwmax = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMAX]);
txq_params->aifs = nla_get_u8(tb[NL80211_TXQ_ATTR_AIFS]);
 
-   if (txq_params->ac >= NL80211_NUM_ACS)
+   idx = array_idx(ac, NL80211_NUM_ACS);
+   if (!idx)
return -EINVAL;
-
+   txq_params->ac = *idx;
return 0;
 }
 

[PATCH v4.1 00/10] spectre variant1 mitigations for tip/x86/pti

[Dan Williams]

Hi Thomas,

Please consider taking this collection of spectre-v1 mitigations through
the tip/x86/pti branch for 4.16 inclusion. The review feedback has
dropped off considerably, so I believe these patches are ready for -tip
inclusion. However, "nl80211: sanitize array index in parse_txq_params"
stands out as a patch that should get an ack from net/wireless folks
before moving forward.

Also a heads up that x86/pti is missing commit 75f139aaf896 "KVM: x86:
Add memory barrier on vmcs field lookup", so you will hit a trivial
conflict merging "kvm, x86: update spectre-v1 mitigation" from this set
against latest mainline.

The infrastructure includes:

* __uaccess_begin_nospec: similar to __uaccess_begin this invokes
'stac', but it also includes an 'ifence'. After an 'access_ok' check
has speculatively succeeded that result needs to be retired before the
user pointer is de-referenced. '__get_user' can't use the pointer
sanitization approach without redoing the 'access_ok' check, so per
Linus [1] just use 'ifence'.

* MASK_NOSPEC: an assembler macro for x86 'get_user' and syscall entry
that sanitizes a user controlled pointer or array index to zero after a
'cmp %limit %val' instruction sets the CF flag.

* array_ptr: When dereferencing a kernel pointer with a user controlled
index, sanitize the pointer to either NULL or valid addresses under
speculation to eliminate a precondition for Spectre variant1 attacks.
It uses a mask generation technique that does not involve speculative
control flows on either x86 or ARM64 [2].

* x86 array_ptr_mask: Achieve the same effect as the default
'array_ptr_mask' in fewer instructions. This approach does not have the
same "array index and limit must be less than LONG_MAX" constraint as
the default mask.

* array_idx: Similar to 'array_ptr', use a mask to return a valid
pointer or NULL to an array index variable. An example where we need
this is the wireless driver stack where the core sanitizes user input
and the actual usage of the array index is in a different compilation
unit in the low-level driver.

[1]: https://lkml.org/lkml/2018/1/17/929
[2]: https://www.spinics.net/lists/netdev/msg477542.html

---

Dan Williams (9):
  asm/nospec, array_ptr: sanitize speculative array de-references
  x86: implement array_ptr_mask()
  x86: introduce __uaccess_begin_nospec and ifence
  x86, __get_user: use __uaccess_begin_nospec
  x86, get_user: use pointer masking to limit speculation
  x86: narrow out of bounds syscalls to sys_read under speculation
  vfs, fdtable: prevent bounds-check bypass via speculative execution
  kvm, x86: update spectre-v1 mitigation
  nl80211: sanitize array index in parse_txq_params

Mark Rutland (1):
  Documentation: document array_ptr


 Documentation/speculation.txt |  143 +
 arch/x86/entry/entry_64.S |2 +
 arch/x86/include/asm/barrier.h|   28 +++
 arch/x86/include/asm/msr.h|3 -
 arch/x86/include/asm/smap.h   |   24 ++
 arch/x86/include/asm/uaccess.h|   15 +++-
 arch/x86/include/asm/uaccess_32.h |6 +-
 arch/x86/include/asm/uaccess_64.h |   12 ++-
 arch/x86/kvm/vmx.c|   11 ++-
 arch/x86/lib/getuser.S|5 +
 arch/x86/lib/usercopy_32.c|8 +-
 include/linux/fdtable.h   |7 +-
 include/linux/nospec.h|   65 +
 net/wireless/nl80211.c|   10 ++-
 14 files changed, 312 insertions(+), 27 deletions(-)
 create mode 100644 Documentation/speculation.txt
 create mode 100644 include/linux/nospec.h

Re: [PATCH v4 00/10] prevent bounds-check bypass via speculative execution

[Dan Williams]

On Thu, Jan 18, 2018 at 4:01 PM, Dan Williams <dan.j.willi...@intel.com> wrote:
> Changes since v3 [1]
> * Drop 'ifence_array_ptr' and associated compile-time + run-time
>   switching and just use the masking approach all the time.
>
> * Convert 'get_user' to use pointer sanitization via masking rather than
>   lfence. '__get_user' and associated paths still rely on
>   lfence. (Linus)
>
>   "Basically, the rule is trivial: find all 'stac' users, and use
>address masking if those users already integrate the limit
>check, and lfence they don't."
>
> * At syscall entry sanitize the syscall number under speculation
>   to remove a user controlled pointer de-reference in kernel
>   space.  (Linus)
>
> * Fix a raw lfence in the kvm code (added for v4.15-rc8) to use
>   'array_ptr'.
>
> * Propose 'array_idx' as a way to sanitize user input that is
>   later used as an array index, but where the validation is
>   happening in a different code block than the array reference.
>   (Christian).
>
> * Fix grammar in speculation.txt (Kees)
>
> ---
>
> Quoting Mark's original RFC:
>
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed under speculation, providing an
> arbitrary read gadget. Further details can be found on the GPZ blog [2]
> and the Documentation patch in this series."
>
> A precondition of using this attack on the kernel is to get a user
> controlled pointer de-referenced (under speculation) in privileged code.
> The primary source of user controlled pointers in the kernel is the
> arguments passed to 'get_user' and '__get_user'. An example of other
> user controlled pointers are user-controlled array / pointer offsets.
>
> Better tooling is needed to find more arrays / pointers with user
> controlled indices / offsets that can be converted to use 'array_ptr' or
> 'array_idx'. A few are included in this set, and these are not expected
> to be complete. That said, the 'get_user' protections raise the bar on
> finding a vulnerable gadget in the kernel.
>
> These patches are also available via the 'nospec-v4' git branch here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v4

I've pushed out a nospec-v4.1 with the below minor cleanup, a fixup of
the changelog for "kvm, x86: fix spectre-v1 mitigation", and added
Paolo's ack.

 git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v4.1

diff --git a/include/linux/nospec.h b/include/linux/nospec.h
index 8af35be1869e..b8a9222e34d1 100644
--- a/include/linux/nospec.h
+++ b/include/linux/nospec.h
@@ -37,7 +37,7 @@ static inline unsigned long array_ptr_mask(unsigned
long idx, unsigned long sz)
unsigned long _i = (idx);   \
unsigned long _mask = array_ptr_mask(_i, (sz)); \
\
-   __u._ptr = _arr + (_i & _mask); \
+   __u._ptr = _arr + _i;   \
__u._bit &= _mask;  \
__u._ptr;   \
 })

[PATCH v4 10/10] nl80211: sanitize array index in parse_txq_params

[Dan Williams]

Wireless drivers rely on parse_txq_params to validate that
txq_params->ac is less than NL80211_NUM_ACS by the time the low-level
driver's ->conf_tx() handler is called. Use a new helper, 'array_idx',
to sanitize txq_params->ac with respect to speculation. I.e. ensure that
any speculation into ->conf_tx() handlers is done with a value of
txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS).

Reported-by: Christian Lamparter <chunk...@gmail.com>
Reported-by: Elena Reshetova <elena.reshet...@intel.com>
Cc: Johannes Berg <johan...@sipsolutions.net>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
---
 include/linux/nospec.h |   21 +
 net/wireless/nl80211.c |   10 +++---
 2 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/include/linux/nospec.h b/include/linux/nospec.h
index f841c11f3f1f..8af35be1869e 100644
--- a/include/linux/nospec.h
+++ b/include/linux/nospec.h
@@ -41,4 +41,25 @@ static inline unsigned long array_ptr_mask(unsigned long 
idx, unsigned long sz)
__u._bit &= _mask;  \
__u._ptr;   \
 })
+
+/**
+ * array_idx - Generate a pointer to an array index, ensuring the
+ * pointer is bounded under speculation to NULL.
+ *
+ * @idx: the index of the element, must be less than LONG_MAX
+ * @sz: the number of elements in the array, must be less than LONG_MAX
+ *
+ * If @idx falls in the interval [0, @sz), returns &@idx otherwise
+ * returns NULL.
+ */
+#define array_idx(idx, sz) \
+({ \
+   union { typeof((idx)) *_ptr; unsigned long _bit; } __u; \
+   typeof(idx) *_i = &(idx);   \
+   unsigned long _mask = array_ptr_mask(*_i, (sz));\
+   \
+   __u._ptr = _i;  \
+   __u._bit &= _mask;  \
+   __u._ptr;   \
+})
 #endif /* __NOSPEC_H__ */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 2b3dbcd40e46..202cb1dc03ee 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2056,20 +2057,23 @@ static const struct nla_policy 
txq_params_policy[NL80211_TXQ_ATTR_MAX + 1] = {
 static int parse_txq_params(struct nlattr *tb[],
struct ieee80211_txq_params *txq_params)
 {
+   u8 ac, *idx;
+
if (!tb[NL80211_TXQ_ATTR_AC] || !tb[NL80211_TXQ_ATTR_TXOP] ||
!tb[NL80211_TXQ_ATTR_CWMIN] || !tb[NL80211_TXQ_ATTR_CWMAX] ||
!tb[NL80211_TXQ_ATTR_AIFS])
return -EINVAL;
 
-   txq_params->ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
+   ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
txq_params->txop = nla_get_u16(tb[NL80211_TXQ_ATTR_TXOP]);
txq_params->cwmin = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMIN]);
txq_params->cwmax = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMAX]);
txq_params->aifs = nla_get_u8(tb[NL80211_TXQ_ATTR_AIFS]);
 
-   if (txq_params->ac >= NL80211_NUM_ACS)
+   idx = array_idx(ac, NL80211_NUM_ACS);
+   if (!idx)
return -EINVAL;
-
+   txq_params->ac = *idx;
return 0;
 }
 

[PATCH v4 00/10] prevent bounds-check bypass via speculative execution

[Dan Williams]

Changes since v3 [1]
* Drop 'ifence_array_ptr' and associated compile-time + run-time
  switching and just use the masking approach all the time.

* Convert 'get_user' to use pointer sanitization via masking rather than
  lfence. '__get_user' and associated paths still rely on
  lfence. (Linus)

  "Basically, the rule is trivial: find all 'stac' users, and use
   address masking if those users already integrate the limit
   check, and lfence they don't."

* At syscall entry sanitize the syscall number under speculation
  to remove a user controlled pointer de-reference in kernel
  space.  (Linus)

* Fix a raw lfence in the kvm code (added for v4.15-rc8) to use
  'array_ptr'.

* Propose 'array_idx' as a way to sanitize user input that is
  later used as an array index, but where the validation is
  happening in a different code block than the array reference.
  (Christian).

* Fix grammar in speculation.txt (Kees)

---

Quoting Mark's original RFC:

"Recently, Google Project Zero discovered several classes of attack
against speculative execution. One of these, known as variant-1, allows
explicit bounds checks to be bypassed under speculation, providing an
arbitrary read gadget. Further details can be found on the GPZ blog [2]
and the Documentation patch in this series."

A precondition of using this attack on the kernel is to get a user
controlled pointer de-referenced (under speculation) in privileged code.
The primary source of user controlled pointers in the kernel is the
arguments passed to 'get_user' and '__get_user'. An example of other
user controlled pointers are user-controlled array / pointer offsets.

Better tooling is needed to find more arrays / pointers with user
controlled indices / offsets that can be converted to use 'array_ptr' or
'array_idx'. A few are included in this set, and these are not expected
to be complete. That said, the 'get_user' protections raise the bar on
finding a vulnerable gadget in the kernel.

These patches are also available via the 'nospec-v4' git branch here:

git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v4

Note that the BPF fix for Spectre variant1 is merged for 4.15-rc8.

[2]: 
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

---

Dan Williams (9):
  asm/nospec, array_ptr: sanitize speculative array de-references
  x86: implement array_ptr_mask()
  x86: introduce __uaccess_begin_nospec and ifence
  x86, __get_user: use __uaccess_begin_nospec
  x86, get_user: use pointer masking to limit speculation
  x86: narrow out of bounds syscalls to sys_read under speculation
  vfs, fdtable: prevent bounds-check bypass via speculative execution
  kvm, x86: fix spectre-v1 mitigation
  nl80211: sanitize array index in parse_txq_params

Mark Rutland (1):
  Documentation: document array_ptr


 Documentation/speculation.txt |  143 +
 arch/x86/entry/entry_64.S |2 +
 arch/x86/include/asm/barrier.h|   28 +++
 arch/x86/include/asm/msr.h|3 -
 arch/x86/include/asm/smap.h   |   24 ++
 arch/x86/include/asm/uaccess.h|   15 +++-
 arch/x86/include/asm/uaccess_32.h |6 +-
 arch/x86/include/asm/uaccess_64.h |   12 ++-
 arch/x86/kvm/vmx.c|   19 ++---
 arch/x86/lib/getuser.S|5 +
 arch/x86/lib/usercopy_32.c|8 +-
 include/linux/fdtable.h   |7 +-
 include/linux/nospec.h|   65 +
 net/wireless/nl80211.c|   10 ++-
 14 files changed, 312 insertions(+), 35 deletions(-)
 create mode 100644 Documentation/speculation.txt
 create mode 100644 include/linux/nospec.h

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

[Dan Williams]

On Thu, Jan 18, 2018 at 5:18 AM, Will Deacon <will.dea...@arm.com> wrote:
> Hi Dan, Linus,
>
> On Thu, Jan 11, 2018 at 05:41:08PM -0800, Dan Williams wrote:
>> On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds
>> <torva...@linux-foundation.org> wrote:
>> > On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams <dan.j.willi...@intel.com> 
>> > wrote:
>> >>
>> >> This series incorporates Mark Rutland's latest ARM changes and adds
>> >> the x86 specific implementation of 'ifence_array_ptr'. That ifence
>> >> based approach is provided as an opt-in fallback, but the default
>> >> mitigation, '__array_ptr', uses a 'mask' approach that removes
>> >> conditional branches instructions, and otherwise aims to redirect
>> >> speculation to use a NULL pointer rather than a user controlled value.
>> >
>> > Do you have any performance numbers and perhaps example code
>> > generation? Is this noticeable? Are there any microbenchmarks showing
>> > the difference between lfence use and the masking model?
>>
>> I don't have performance numbers, but here's a sample code generation
>> from __fcheck_files, where the 'and; lea; and' sequence is portion of
>> array_ptr() after the mask generation with 'sbb'.
>>
>> fdp = array_ptr(fdt->fd, fd, fdt->max_fds);
>>  8e7:   8b 02   mov(%rdx),%eax
>>  8e9:   48 39 c7cmp%rax,%rdi
>>  8ec:   48 19 c9sbb%rcx,%rcx
>>  8ef:   48 8b 42 08 mov0x8(%rdx),%rax
>>  8f3:   48 89 femov%rdi,%rsi
>>  8f6:   48 21 ceand%rcx,%rsi
>>  8f9:   48 8d 04 f0 lea(%rax,%rsi,8),%rax
>>  8fd:   48 21 c8and%rcx,%rax
>>
>>
>> > Having both seems good for testing, but wouldn't we want to pick one in 
>> > the end?
>>
>> I was thinking we'd keep it as a 'just in case' sort of thing, at
>> least until the 'probably safe' assumption of the 'mask' approach has
>> more time to settle out.
>
> From the arm64 side, the only concern I have (and this actually applies to
> our CSDB sequence as well) is the calculation of the array size by the
> caller. As Linus mentioned at the end of [1], if the determination of the
> size argument is based on a conditional branch, then masking doesn't help
> because you bound within the wrong range under speculation.
>
> We ran into this when trying to use masking to protect our uaccess routines
> where the conditional bound is either KERNEL_DS or USER_DS. It's possible
> that a prior conditional set_fs(KERNEL_DS) could defeat the masking and so
> we'd need to throw some heavy barriers in set_fs to make it robust.

At least in the conditional mask case near set_fs() usage the approach
we are taking is to use a barrier. I.e. the following guidance from
Linus:

"Basically, the rule is trivial: find all 'stac' users, and use address
masking if those users already integrate the limit check, and lfence
they don't."

...which translates to narrow the pointer for get_user() and use a
barrier  for __get_user().

Re: [PATCH v2 15/19] carl9170: prevent bounds-check bypass via speculative execution

[Dan Williams]

On Fri, Jan 12, 2018 at 12:01 PM, Christian Lamparter
<chunk...@gmail.com> wrote:
> On Friday, January 12, 2018 7:39:50 PM CET Dan Williams wrote:
>> On Fri, Jan 12, 2018 at 6:42 AM, Christian Lamparter <chunk...@gmail.com> 
>> wrote:
>> > On Friday, January 12, 2018 1:47:46 AM CET Dan Williams wrote:
>> >> Static analysis reports that 'queue' may be a user controlled value that
>> >> is used as a data dependency to read from the 'ar9170_qmap' array. In
>> >> order to avoid potential leaks of kernel memory values, block
>> >> speculative execution of the instruction stream that could issue reads
>> >> based on an invalid result of 'ar9170_qmap[queue]'. In this case the
>> >> value of 'ar9170_qmap[queue]' is immediately reused as an index to the
>> >> 'ar->edcf' array.
>> >>
>> >> Based on an original patch by Elena Reshetova.
>> >>
>> >> Cc: Christian Lamparter <chunk...@googlemail.com>
>> >> Cc: Kalle Valo <kv...@codeaurora.org>
>> >> Cc: linux-wireless@vger.kernel.org
>> >> Cc: net...@vger.kernel.org
>> >> Signed-off-by: Elena Reshetova <elena.reshet...@intel.com>
>> >> Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
>> >> ---
>> > This patch (and p54, cw1200) look like the same patch?!
>> > Can you tell me what happend to:
>> >
>> > On Saturday, January 6, 2018 5:34:03 PM CET Dan Williams wrote:
>> >> On Sat, Jan 6, 2018 at 6:23 AM, Christian Lamparter <chunk...@gmail.com> 
>> >> wrote:
>> >> > And Furthermore a invalid queue (param->ac) would cause a crash in
>> >> > this line in mac80211 before it even reaches the driver [1]:
>> >> > |   sdata->tx_conf[params->ac] = p;
>> >> > |   
>> >> > |   if (drv_conf_tx(local, sdata, >>>> params->ac <<<<, )) {
>> >> > |^^ (this is a wrapper for the *_op_conf_tx)
>> >> >
>> >> > I don't think these chin-up exercises are needed.
>> >>
>> >> Quite the contrary, you've identified a better place in the call stack
>> >> to sanitize the input and disable speculation. Then we can kill the
>> >> whole class of the wireless driver reports at once it seems.
>> > <https://www.spinics.net/lists/netdev/msg476353.html>
>>
>> I didn't see where ac is being validated against the driver specific
>> 'queues' value in that earlier patch.
> The link to the check is right there in the earlier post. It's in
> parse_txq_params():
> <https://github.com/torvalds/linux/blob/master/net/wireless/nl80211.c#L2070>
> |   if (txq_params->ac >= NL80211_NUM_ACS)
> |   return -EINVAL;
>
> NL80211_NUM_ACS is 4
> <http://elixir.free-electrons.com/linux/v4.15-rc7/source/include/uapi/linux/nl80211.h#L3748>
>
> This check was added ever since mac80211's ieee80211_set_txq_params():
> | sdata->tx_conf[params->ac] = p;
>
> For cw1200: the driver just sets the dev->queue to 4.
> In carl9170 dev->queues is set to __AR9170_NUM_TXQ and
> p54 uses P54_QUEUE_AC_NUM.
>
> Both __AR9170_NUM_TXQ and P54_QUEUE_AC_NUM are 4.
> And this is not going to change since all drivers
> have to follow mac80211's queue API:
> <https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/queues>
>
> Some background:
> In the old days (linux 2.6 and early 3.x), the parse_txq_params() function did
> not verify the "queue" value. That's why these drivers had to do it.
>
> Here's the relevant code from 2.6.39:
> <http://elixir.free-electrons.com/linux/v2.6.39/source/net/wireless/nl80211.c#L879>
> You'll notice that the check is missing there.
> Here's mac80211's ieee80211_set_txq_params for reference:
> <http://elixir.free-electrons.com/linux/v2.6.39/source/net/mac80211/cfg.c#L1197>
>
> However over time, the check in the driver has become redundant.
>

Excellent, thank you for pointing that out and the background so clearly.

What this tells me though is that we want to inject an ifence() at
this input validation point, i.e.:

if (txq_params->ac >= NL80211_NUM_ACS) {
ifence();
return -EINVAL;
}

...but the kernel, in these patches, only has ifence() defined for
x86. The only way we can sanitize the 'txq_params->ac' value without
ifence() is to do it at array access time, but then we're stuck
touching all drivers when standard kernel development practice says
'refactor common code out of drivers'.

Ugh, the bigger concern is that this driver is being flagged and not
that initial bounds check. Imagine if cw1200 and p54 had already been
converted to assume that they can just trust 'queue'. It would never
have been flagged.

I think we should focus on the get_user path and  __fcheck_files for v3.

Re: [PATCH v2 15/19] carl9170: prevent bounds-check bypass via speculative execution

[Dan Williams]

On Fri, Jan 12, 2018 at 6:42 AM, Christian Lamparter <chunk...@gmail.com> wrote:
> On Friday, January 12, 2018 1:47:46 AM CET Dan Williams wrote:
>> Static analysis reports that 'queue' may be a user controlled value that
>> is used as a data dependency to read from the 'ar9170_qmap' array. In
>> order to avoid potential leaks of kernel memory values, block
>> speculative execution of the instruction stream that could issue reads
>> based on an invalid result of 'ar9170_qmap[queue]'. In this case the
>> value of 'ar9170_qmap[queue]' is immediately reused as an index to the
>> 'ar->edcf' array.
>>
>> Based on an original patch by Elena Reshetova.
>>
>> Cc: Christian Lamparter <chunk...@googlemail.com>
>> Cc: Kalle Valo <kv...@codeaurora.org>
>> Cc: linux-wireless@vger.kernel.org
>> Cc: net...@vger.kernel.org
>> Signed-off-by: Elena Reshetova <elena.reshet...@intel.com>
>> Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
>> ---
> This patch (and p54, cw1200) look like the same patch?!
> Can you tell me what happend to:
>
> On Saturday, January 6, 2018 5:34:03 PM CET Dan Williams wrote:
>> On Sat, Jan 6, 2018 at 6:23 AM, Christian Lamparter <chunk...@gmail.com> 
>> wrote:
>> > And Furthermore a invalid queue (param->ac) would cause a crash in
>> > this line in mac80211 before it even reaches the driver [1]:
>> > |   sdata->tx_conf[params->ac] = p;
>> > |   
>> > |   if (drv_conf_tx(local, sdata, >>>> params->ac <<<<, )) {
>> > |^^ (this is a wrapper for the *_op_conf_tx)
>> >
>> > I don't think these chin-up exercises are needed.
>>
>> Quite the contrary, you've identified a better place in the call stack
>> to sanitize the input and disable speculation. Then we can kill the
>> whole class of the wireless driver reports at once it seems.
> <https://www.spinics.net/lists/netdev/msg476353.html>

I didn't see where ac is being validated against the driver specific
'queues' value in that earlier patch.

>
> Anyway, I think there's an easy way to solve this: remove the
> "if (queue < ar->hw->queues)" check altogether. It's no longer needed
> anymore as the "queue" value is validated long before the driver code
> gets called.

Can you point me to where that validation happens?

> And from my understanding, this will fix the "In this case
> the value of 'ar9170_qmap[queue]' is immediately reused as an index to
> the 'ar->edcf' array." gripe your tool complains about.
>
> This is here's a quick test-case for carl9170.:
> ---
> diff --git a/drivers/net/wireless/ath/carl9170/main.c 
> b/drivers/net/wireless/ath/carl9170/main.c
> index 988c8857d78c..2d3afb15bb62 100644
> --- a/drivers/net/wireless/ath/carl9170/main.c
> +++ b/drivers/net/wireless/ath/carl9170/main.c
> @@ -1387,13 +1387,8 @@ static int carl9170_op_conf_tx(struct ieee80211_hw *hw,
> int ret;
>
> mutex_lock(>mutex);
> -   if (queue < ar->hw->queues) {
> -   memcpy(>edcf[ar9170_qmap[queue]], param, sizeof(*param));
> -   ret = carl9170_set_qos(ar);
> -   } else {
> -   ret = -EINVAL;
> -   }
> -
> +   memcpy(>edcf[ar9170_qmap[queue]], param, sizeof(*param));
> +   ret = carl9170_set_qos(ar);
> mutex_unlock(>mutex);
> return ret;
>  }
> ---
> What does your tool say about this?

If you take away the 'if' then I don't the tool will report on this.

> (If necessary, the "queue" value could be even sanitized with a
> queue %= ARRAY_SIZE(ar9170_qmap); before the mutex_lock.)

That is what array_ptr() is doing in a more sophisticated way.

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

[Dan Williams]

On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams <dan.j.willi...@intel.com> 
> wrote:
>>
>> This series incorporates Mark Rutland's latest ARM changes and adds
>> the x86 specific implementation of 'ifence_array_ptr'. That ifence
>> based approach is provided as an opt-in fallback, but the default
>> mitigation, '__array_ptr', uses a 'mask' approach that removes
>> conditional branches instructions, and otherwise aims to redirect
>> speculation to use a NULL pointer rather than a user controlled value.
>
> Do you have any performance numbers and perhaps example code
> generation? Is this noticeable? Are there any microbenchmarks showing
> the difference between lfence use and the masking model?

I don't have performance numbers, but here's a sample code generation
from __fcheck_files, where the 'and; lea; and' sequence is portion of
array_ptr() after the mask generation with 'sbb'.

fdp = array_ptr(fdt->fd, fd, fdt->max_fds);
 8e7:   8b 02   mov(%rdx),%eax
 8e9:   48 39 c7cmp%rax,%rdi
 8ec:   48 19 c9sbb%rcx,%rcx
 8ef:   48 8b 42 08 mov0x8(%rdx),%rax
 8f3:   48 89 femov%rdi,%rsi
 8f6:   48 21 ceand%rcx,%rsi
 8f9:   48 8d 04 f0 lea(%rax,%rsi,8),%rax
 8fd:   48 21 c8and%rcx,%rax


> Having both seems good for testing, but wouldn't we want to pick one in the 
> end?

I was thinking we'd keep it as a 'just in case' sort of thing, at
least until the 'probably safe' assumption of the 'mask' approach has
more time to settle out.

>
> Also, I do think that there is one particular array load that would
> seem to be pretty obvious: the system call function pointer array.
>
> Yes, yes, the actual call is now behind a retpoline, but that protects
> against a speculative BTB access, it's not obvious that it  protects
> against the mispredict of the __NR_syscall_max comparison in
> arch/x86/entry/entry_64.S.
>
> The act of fetching code is a kind of read too. And retpoline protects
> against BTB stuffing etc, but what if the _actual_ system call
> function address is wrong (due to mis-prediction of the system call
> index check)?
>
> Should the array access in entry_SYSCALL_64_fastpath be made to use
> the masking approach?

I'll take a look. I'm firmly in the 'patch first / worry later' stance
on these investigations.

[PATCH v2 00/19] prevent bounds-check bypass via speculative execution

[Dan Williams]

Changes since v1 [1]:
* fixup the ifence definition to use alternative_2 per recent AMD
  changes in tip/x86/pti (Tom)

* drop 'nospec_ptr' (Linus, Mark)

* rename 'nospec_array_ptr' to 'array_ptr' (Alexei)

* rename 'nospec_barrier' to 'ifence' (Peter, Ingo)

* clean up occasions of 'variable assignment in if()' (Sergei, Stephen)

* make 'array_ptr' use a mask instead of an architectural ifence by
  default (Linus, Alexei)

* provide a command line and compile-time opt-in to the ifence
  mechanism, if an architecture provides 'ifence_array_ptr'.

* provide an optimized mask generation helper, 'array_ptr_mask', for
  x86 (Linus)

* move 'get_user' hardening from '__range_not_ok' to '__uaccess_begin'
  (Linus)

* drop "Thermal/int340x: prevent bounds-check..." since userspace does
  not have arbitrary control over the 'trip' index (Srinivas)

* update the changelog of "net: mpls: prevent bounds-check..." and keep
  it in the series to continue the debate about Spectre hygiene patches.
  (Eric).

* record a reviewed-by from Laurent on "[media] uvcvideo: prevent
  bounds-check..."

* update the cover letter

[1]: https://lwn.net/Articles/743376/

---

Quoting Mark's original RFC:

"Recently, Google Project Zero discovered several classes of attack
against speculative execution. One of these, known as variant-1, allows
explicit bounds checks to be bypassed under speculation, providing an
arbitrary read gadget. Further details can be found on the GPZ blog [2]
and the Documentation patch in this series."

This series incorporates Mark Rutland's latest ARM changes and adds
the x86 specific implementation of 'ifence_array_ptr'. That ifence
based approach is provided as an opt-in fallback, but the default
mitigation, '__array_ptr', uses a 'mask' approach that removes
conditional branches instructions, and otherwise aims to redirect
speculation to use a NULL pointer rather than a user controlled value.

The mask is generated by the following from Alexei, and Linus:

mask = ~(long)(_i | (_s - 1 - _i)) >> (BITS_PER_LONG - 1);

...and Linus provided an optimized mask generation helper for x86:

asm ("cmpq %1,%2; sbbq %0,%0;"
:"=r" (mask)
:"r"(sz),"r" (idx)
:"cc");

The 'array_ptr' mechanism can be switched between 'mask' and 'ifence'
via the spectre_v1={mask,ifence} command line option, and the
compile-time default is set by selecting either CONFIG_SPECTRE1_MASK or
CONFIG_SPECTRE1_IFENCE.

The 'array_ptr' infrastructure is the primary focus this patch set. The
individual patches that perform 'array_ptr' conversions are a point in
time (i.e. earlier kernel, early analysis tooling, x86 only etc...)
start at finding some of these gadgets.

Another consideration for reviewing these patches is the 'hygiene'
argument. When a patch refers to hygiene it is concerned with stopping
speculation on an unconstrained or insufficiently constrained pointer
value under userspace control. That by itself is not sufficient for
attack (per current understanding) [3], but it is a necessary
pre-condition.  So 'hygiene' refers to cleaning up those suspect
pointers regardless of whether they are usable as a gadget.

These patches are also be available via the 'nospec-v2' git branch
here:

git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v2

Note that the BPF fix for Spectre variant1 is merged in the bpf.git
tree [4], and is not included in this branch.

[2]: 
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
[3]: https://spectreattack.com/spectre.pdf
[4]: 
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=b2157399cc98

---

Dan Williams (16):
  x86: implement ifence()
  x86: implement ifence_array_ptr() and array_ptr_mask()
  asm-generic/barrier: mask speculative execution flows
  x86: introduce __uaccess_begin_nospec and ASM_IFENCE
  x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths
  ipv6: prevent bounds-check bypass via speculative execution
  ipv4: prevent bounds-check bypass via speculative execution
  vfs, fdtable: prevent bounds-check bypass via speculative execution
  userns: prevent bounds-check bypass via speculative execution
  udf: prevent bounds-check bypass via speculative execution
  [media] uvcvideo: prevent bounds-check bypass via speculative execution
  carl9170: prevent bounds-check bypass via speculative execution
  p54: prevent bounds-check bypass via speculative execution
  qla2xxx: prevent bounds-check bypass via speculative execution
  cw1200: prevent bounds-check bypass via speculative execution
  net: mpls: prevent bounds-check bypass via speculative execution

Mark Rutland (3):
  Documentation: document array_ptr
  arm64: implement ifence_array_ptr()
  arm: implement ifence_array_ptr()

 

[PATCH v2 16/19] p54: prevent bounds-check bypass via speculative execution

[Dan Williams]

Static analysis reports that 'queue' may be a user controlled value that
is used as a data dependency to read from the 'priv->qos_params' array.
In order to avoid potential leaks of kernel memory values, block
speculative execution of the instruction stream that could issue reads
based on an invalid result of 'priv->qos_params[queue]'.

Based on an original patch by Elena Reshetova.

Cc: Christian Lamparter <chunk...@googlemail.com>
Cc: Kalle Valo <kv...@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Elena Reshetova <elena.reshet...@intel.com>
Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
---
 drivers/net/wireless/intersil/p54/main.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intersil/p54/main.c 
b/drivers/net/wireless/intersil/p54/main.c
index ab6d39e12069..5ce693ff547e 100644
--- a/drivers/net/wireless/intersil/p54/main.c
+++ b/drivers/net/wireless/intersil/p54/main.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -411,12 +412,14 @@ static int p54_conf_tx(struct ieee80211_hw *dev,
   const struct ieee80211_tx_queue_params *params)
 {
struct p54_common *priv = dev->priv;
+   struct p54_edcf_queue_param *p54_q;
int ret;
 
mutex_lock(>conf_mutex);
-   if (queue < dev->queues) {
-   P54_SET_QUEUE(priv->qos_params[queue], params->aifs,
-   params->cw_min, params->cw_max, params->txop);
+   p54_q = array_ptr(priv->qos_params, queue, dev->queues);
+   if (p54_q) {
+   P54_SET_QUEUE(p54_q[0], params->aifs, params->cw_min,
+   params->cw_max, params->txop);
ret = p54_set_edcf(priv);
} else
ret = -EINVAL;

[PATCH v2 15/19] carl9170: prevent bounds-check bypass via speculative execution

[Dan Williams]

Static analysis reports that 'queue' may be a user controlled value that
is used as a data dependency to read from the 'ar9170_qmap' array. In
order to avoid potential leaks of kernel memory values, block
speculative execution of the instruction stream that could issue reads
based on an invalid result of 'ar9170_qmap[queue]'. In this case the
value of 'ar9170_qmap[queue]' is immediately reused as an index to the
'ar->edcf' array.

Based on an original patch by Elena Reshetova.

Cc: Christian Lamparter <chunk...@googlemail.com>
Cc: Kalle Valo <kv...@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Elena Reshetova <elena.reshet...@intel.com>
Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
---
 drivers/net/wireless/ath/carl9170/main.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/carl9170/main.c 
b/drivers/net/wireless/ath/carl9170/main.c
index 988c8857d78c..0acfa8c22b7d 100644
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "hw.h"
@@ -1384,11 +1385,13 @@ static int carl9170_op_conf_tx(struct ieee80211_hw *hw,
   const struct ieee80211_tx_queue_params *param)
 {
struct ar9170 *ar = hw->priv;
+   const u8 *elem;
int ret;
 
mutex_lock(>mutex);
-   if (queue < ar->hw->queues) {
-   memcpy(>edcf[ar9170_qmap[queue]], param, sizeof(*param));
+   elem = array_ptr(ar9170_qmap, queue, ar->hw->queues);
+   if (elem) {
+   memcpy(>edcf[*elem], param, sizeof(*param));
ret = carl9170_set_qos(ar);
} else {
ret = -EINVAL;

[PATCH v2 18/19] cw1200: prevent bounds-check bypass via speculative execution

[Dan Williams]

Static analysis reports that 'queue' may be a user controlled value that
is used as a data dependency to read 'txq_params' from the
'priv->tx_queue_params.params' array.  In order to avoid potential leaks
of kernel memory values, block speculative execution of the instruction
stream that could issue reads based on an invalid value of 'txq_params'.
In this case 'txq_params' is referenced later in the function.

Based on an original patch by Elena Reshetova.

Cc: Solomon Peachy <pi...@shaftnet.org>
Cc: Kalle Valo <kv...@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Elena Reshetova <elena.reshet...@intel.com>
Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
---
 drivers/net/wireless/st/cw1200/sta.c |   11 +++
 drivers/net/wireless/st/cw1200/wsm.h |4 +---
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/st/cw1200/sta.c 
b/drivers/net/wireless/st/cw1200/sta.c
index 38678e9a0562..7521077e50a4 100644
--- a/drivers/net/wireless/st/cw1200/sta.c
+++ b/drivers/net/wireless/st/cw1200/sta.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cw1200.h"
 #include "sta.h"
@@ -612,18 +613,20 @@ int cw1200_conf_tx(struct ieee80211_hw *dev, struct 
ieee80211_vif *vif,
   u16 queue, const struct ieee80211_tx_queue_params *params)
 {
struct cw1200_common *priv = dev->priv;
+   struct wsm_set_tx_queue_params *txq_params;
int ret = 0;
/* To prevent re-applying PM request OID again and again*/
bool old_uapsd_flags;
 
mutex_lock(>conf_mutex);
 
-   if (queue < dev->queues) {
+   txq_params = array_ptr(priv->tx_queue_params.params, queue,
+   dev->queues);
+   if (txq_params) {
old_uapsd_flags = le16_to_cpu(priv->uapsd_info.uapsd_flags);
 
-   WSM_TX_QUEUE_SET(>tx_queue_params, queue, 0, 0, 0);
-   ret = wsm_set_tx_queue_params(priv,
- 
>tx_queue_params.params[queue], queue);
+   WSM_TX_QUEUE_SET(txq_params, 0, 0, 0);
+   ret = wsm_set_tx_queue_params(priv, txq_params, queue);
if (ret) {
ret = -EINVAL;
goto out;
diff --git a/drivers/net/wireless/st/cw1200/wsm.h 
b/drivers/net/wireless/st/cw1200/wsm.h
index 48086e849515..8c8d9191e233 100644
--- a/drivers/net/wireless/st/cw1200/wsm.h
+++ b/drivers/net/wireless/st/cw1200/wsm.h
@@ -1099,10 +1099,8 @@ struct wsm_tx_queue_params {
 };
 
 
-#define WSM_TX_QUEUE_SET(queue_params, queue, ack_policy, allowed_time,\
-   max_life_time)  \
+#define WSM_TX_QUEUE_SET(p, ack_policy, allowed_time, max_life_time)   \
 do {   \
-   struct wsm_set_tx_queue_params *p = &(queue_params)->params[queue]; \
p->ackPolicy = (ack_policy);\
p->allowedMediumTime = (allowed_time);  \
p->maxTransmitLifetime = (max_life_time);   \

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Dan Williams]

On Thu, Jan 11, 2018 at 1:54 AM, Jiri Kosina <ji...@kernel.org> wrote:
> On Tue, 9 Jan 2018, Josh Poimboeuf wrote:
>
>> On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote:
>> > On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina <ji...@kernel.org> wrote:
>> > > On Fri, 5 Jan 2018, Dan Williams wrote:
>> > >
>> > > [ ... snip ... ]
>> > >> Andi Kleen (1):
>> > >>   x86, barrier: stop speculation for failed access_ok
>> > >>
>> > >> Dan Williams (13):
>> > >>   x86: implement nospec_barrier()
>> > >>   [media] uvcvideo: prevent bounds-check bypass via speculative 
>> > >> execution
>> > >>   carl9170: prevent bounds-check bypass via speculative execution
>> > >>   p54: prevent bounds-check bypass via speculative execution
>> > >>   qla2xxx: prevent bounds-check bypass via speculative execution
>> > >>   cw1200: prevent bounds-check bypass via speculative execution
>> > >>   Thermal/int340x: prevent bounds-check bypass via speculative 
>> > >> execution
>> > >>   ipv6: prevent bounds-check bypass via speculative execution
>> > >>   ipv4: prevent bounds-check bypass via speculative execution
>> > >>   vfs, fdtable: prevent bounds-check bypass via speculative 
>> > >> execution
>> > >>   net: mpls: prevent bounds-check bypass via speculative execution
>> > >>   udf: prevent bounds-check bypass via speculative execution
>> > >>   userns: prevent bounds-check bypass via speculative execution
>> > >>
>> > >> Mark Rutland (4):
>> > >>   asm-generic/barrier: add generic nospec helpers
>> > >>   Documentation: document nospec helpers
>> > >>   arm64: implement nospec_ptr()
>> > >>   arm: implement nospec_ptr()
>> > >
>> > > So considering the recent publication of [1], how come we all of a sudden
>> > > don't need the barriers in ___bpf_prog_run(), namely for LD_IMM_DW and
>> > > LDX_MEM_##SIZEOP, and something comparable for eBPF JIT?
>> > >
>> > > Is this going to be handled in eBPF in some other way?
>> > >
>> > > Without that in place, and considering Jann Horn's paper, it would seem
>> > > like PTI doesn't really lock it down fully, right?
>> >
>> > Here is the latest (v3) bpf fix:
>> >
>> > https://patchwork.ozlabs.org/patch/856645/
>> >
>> > I currently have v2 on my 'nospec' branch and will move that to v3 for
>> > the next update, unless it goes upstream before then.
>
> Daniel, I guess you're planning to send this still for 4.15?

It's pending in the bpf.git tree:


https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=b2157399cc9

>> That patch seems specific to CONFIG_BPF_SYSCALL.  Is the bpf() syscall
>> the only attack vector?  Or are there other ways to run bpf programs
>> that we should be worried about?
>
> Seems like Alexei is probably the only person in the whole universe who
> isn't CCed here ... let's fix that.

He will be cc'd on v2 of this series which will be available later today.

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Dan Williams]

On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina <ji...@kernel.org> wrote:
> On Fri, 5 Jan 2018, Dan Williams wrote:
>
> [ ... snip ... ]
>> Andi Kleen (1):
>>   x86, barrier: stop speculation for failed access_ok
>>
>> Dan Williams (13):
>>   x86: implement nospec_barrier()
>>   [media] uvcvideo: prevent bounds-check bypass via speculative execution
>>   carl9170: prevent bounds-check bypass via speculative execution
>>   p54: prevent bounds-check bypass via speculative execution
>>   qla2xxx: prevent bounds-check bypass via speculative execution
>>   cw1200: prevent bounds-check bypass via speculative execution
>>   Thermal/int340x: prevent bounds-check bypass via speculative execution
>>   ipv6: prevent bounds-check bypass via speculative execution
>>   ipv4: prevent bounds-check bypass via speculative execution
>>   vfs, fdtable: prevent bounds-check bypass via speculative execution
>>   net: mpls: prevent bounds-check bypass via speculative execution
>>   udf: prevent bounds-check bypass via speculative execution
>>   userns: prevent bounds-check bypass via speculative execution
>>
>> Mark Rutland (4):
>>   asm-generic/barrier: add generic nospec helpers
>>   Documentation: document nospec helpers
>>   arm64: implement nospec_ptr()
>>   arm: implement nospec_ptr()
>
> So considering the recent publication of [1], how come we all of a sudden
> don't need the barriers in ___bpf_prog_run(), namely for LD_IMM_DW and
> LDX_MEM_##SIZEOP, and something comparable for eBPF JIT?
>
> Is this going to be handled in eBPF in some other way?
>
> Without that in place, and considering Jann Horn's paper, it would seem
> like PTI doesn't really lock it down fully, right?

Here is the latest (v3) bpf fix:

https://patchwork.ozlabs.org/patch/856645/

I currently have v2 on my 'nospec' branch and will move that to v3 for
the next update, unless it goes upstream before then.

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Dan Williams]

On Sat, Jan 6, 2018 at 11:37 AM, Dan Williams <dan.j.willi...@intel.com> wrote:
> On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams <dan.j.willi...@intel.com> wrote:
>> Quoting Mark's original RFC:
>>
>> "Recently, Google Project Zero discovered several classes of attack
>> against speculative execution. One of these, known as variant-1, allows
>> explicit bounds checks to be bypassed under speculation, providing an
>> arbitrary read gadget. Further details can be found on the GPZ blog [1]
>> and the Documentation patch in this series."
>>
>> This series incorporates Mark Rutland's latest api and adds the x86
>> specific implementation of nospec_barrier. The
>> nospec_{array_ptr,ptr,barrier} helpers are then combined with a kernel
>> wide analysis performed by Elena Reshetova to address static analysis
>> reports where speculative execution on a userspace controlled value
>> could bypass a bounds check. The patches address a precondition for the
>> attack discussed in the Spectre paper [2].
>>
>> A consideration worth noting for reviewing these patches is to weigh the
>> dramatic cost of being wrong about whether a given report is exploitable
>> vs the overhead nospec_{array_ptr,ptr} may introduce. In other words,
>> lets make the bar for applying these patches be "can you prove that the
>> bounds check bypass is *not* exploitable". Consider that the Spectre
>> paper reports one example of a speculation window being ~180 cycles.
>>
>> Note that there is also a proposal from Linus, array_access [3], that
>> attempts to quash speculative execution past a bounds check without
>> introducing an lfence instruction. That may be a future optimization
>> possibility that is compatible with this api, but it would appear to
>> need guarantees from the compiler that it is not clear the kernel can
>> rely on at this point. It is also not clear that it would be a
>> significant performance win vs lfence.
>>
>> These patches also will also be available via the 'nospec' git branch
>> here:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec
>
> It appears that git.kernel.org has not mirrored out the new branch. In
> the meantime here's an alternative location:
>
> https://github.com/djbw/linux.git nospec
>
> If there are updates to these patches they will appear in nospec-v2,
> nospec-v3, etc... branches.

For completeness I appended the bpf fix [1] to the git branch.

https://lwn.net/Articles/743288/

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Dan Williams]

On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams <dan.j.willi...@intel.com> wrote:
> Quoting Mark's original RFC:
>
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed under speculation, providing an
> arbitrary read gadget. Further details can be found on the GPZ blog [1]
> and the Documentation patch in this series."
>
> This series incorporates Mark Rutland's latest api and adds the x86
> specific implementation of nospec_barrier. The
> nospec_{array_ptr,ptr,barrier} helpers are then combined with a kernel
> wide analysis performed by Elena Reshetova to address static analysis
> reports where speculative execution on a userspace controlled value
> could bypass a bounds check. The patches address a precondition for the
> attack discussed in the Spectre paper [2].
>
> A consideration worth noting for reviewing these patches is to weigh the
> dramatic cost of being wrong about whether a given report is exploitable
> vs the overhead nospec_{array_ptr,ptr} may introduce. In other words,
> lets make the bar for applying these patches be "can you prove that the
> bounds check bypass is *not* exploitable". Consider that the Spectre
> paper reports one example of a speculation window being ~180 cycles.
>
> Note that there is also a proposal from Linus, array_access [3], that
> attempts to quash speculative execution past a bounds check without
> introducing an lfence instruction. That may be a future optimization
> possibility that is compatible with this api, but it would appear to
> need guarantees from the compiler that it is not clear the kernel can
> rely on at this point. It is also not clear that it would be a
> significant performance win vs lfence.
>
> These patches also will also be available via the 'nospec' git branch
> here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec

It appears that git.kernel.org has not mirrored out the new branch. In
the meantime here's an alternative location:

https://github.com/djbw/linux.git nospec

If there are updates to these patches they will appear in nospec-v2,
nospec-v3, etc... branches.

Re: [PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

[Dan Williams]

On Sat, Jan 6, 2018 at 6:23 AM, Christian Lamparter <chunk...@gmail.com> wrote:
> On Saturday, January 6, 2018 2:10:37 AM CET Dan Williams wrote:
>> Static analysis reports that 'queue' may be a user controlled value that
>> is used as a data dependency to read from the 'ar9170_qmap' array. In
>> order to avoid potential leaks of kernel memory values, block
>> speculative execution of the instruction stream that could issue reads
>> based on an invalid result of 'ar9170_qmap[queue]'. In this case the
>> value of 'ar9170_qmap[queue]' is immediately reused as an index to the
>> 'ar->edcf' array.
>>
>> Based on an original patch by Elena Reshetova.
>>
>> Cc: Christian Lamparter <chunk...@googlemail.com>
>> Cc: Kalle Valo <kv...@codeaurora.org>
>> Cc: linux-wireless@vger.kernel.org
>> Cc: net...@vger.kernel.org
>> Signed-off-by: Elena Reshetova <elena.reshet...@intel.com>
>> Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
>> ---
>>  drivers/net/wireless/ath/carl9170/main.c |6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/carl9170/main.c 
>> b/drivers/net/wireless/ath/carl9170/main.c
>> index 988c8857d78c..0ff34cbe2b62 100644
>> --- a/drivers/net/wireless/ath/carl9170/main.c
>> +++ b/drivers/net/wireless/ath/carl9170/main.c
>> @@ -41,6 +41,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include "hw.h"
>> @@ -1384,11 +1385,12 @@ static int carl9170_op_conf_tx(struct ieee80211_hw 
>> *hw,
>>  const struct ieee80211_tx_queue_params *param)
>>  {
>>   struct ar9170 *ar = hw->priv;
>> + const u8 *elem;
>>   int ret;
>>
>>   mutex_lock(>mutex);
>> - if (queue < ar->hw->queues) {
>> - memcpy(>edcf[ar9170_qmap[queue]], param, sizeof(*param));
>> + if ((elem = nospec_array_ptr(ar9170_qmap, queue, ar->hw->queues))) {
>> + memcpy(>edcf[*elem], param, sizeof(*param));
>>   ret = carl9170_set_qos(ar);
>>   } else {
>>   ret = -EINVAL;
>>
>>
> About the "queue" in carl9170_op_conf_tx, p54_conf_tx and cw1200_conf_tx:
>
> The only way a user can set this in any meaningful way would be via
> a NL80211_CMD_SET_WIPHY netlink message. However, the value will get
> vetted there by cfg80211's parse_txq_params [0]. This is long before
> it reaches any of the *_op_conf_tx functions.
>
> And Furthermore a invalid queue (param->ac) would cause a crash in
> this line in mac80211 before it even reaches the driver [1]:
> |   sdata->tx_conf[params->ac] = p;
> |   
> |   if (drv_conf_tx(local, sdata, >>>> params->ac <<<<, )) {
> |^^ (this is a wrapper for the *_op_conf_tx)
>
> I don't think these chin-up exercises are needed.

Quite the contrary, you've identified a better place in the call stack
to sanitize the input and disable speculation. Then we can kill the
whole class of the wireless driver reports at once it seems.

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Dan Williams]

On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman <ebied...@xmission.com> wrote:
> Dan Williams <dan.j.willi...@intel.com> writes:
>
>> Quoting Mark's original RFC:
>>
>> "Recently, Google Project Zero discovered several classes of attack
>> against speculative execution. One of these, known as variant-1, allows
>> explicit bounds checks to be bypassed under speculation, providing an
>> arbitrary read gadget. Further details can be found on the GPZ blog [1]
>> and the Documentation patch in this series."
>>
>> This series incorporates Mark Rutland's latest api and adds the x86
>> specific implementation of nospec_barrier. The
>> nospec_{array_ptr,ptr,barrier} helpers are then combined with a kernel
>> wide analysis performed by Elena Reshetova to address static analysis
>> reports where speculative execution on a userspace controlled value
>> could bypass a bounds check. The patches address a precondition for the
>> attack discussed in the Spectre paper [2].
>
> Please expand this.
>
> It is not clear what the static analysis is looking for.  Have a clear
> description of what is being fixed is crucial for allowing any of these
> changes.
>
> For the details given in the change description what I read is magic
> changes because a magic process says this code is vunlerable.

Yes, that was my first reaction to the patches as well, I try below to
add some more background and guidance, but in the end these are static
analysis reports across a wide swath of sub-systems. It's going to
take some iteration with domain experts to improve the patch
descriptions, and that's the point of this series, to get the better
trained eyes from the actual sub-system owners to take a look at these
reports.

For example, I'm looking for feedback like what Srinivas gave where he
identified that the report is bogus, the branch condition can not be
seeded with bad values in that path. Be like Srinivas.

> Given the similarities in the code that is being patched to many other
> places in the kernel it is not at all clear that this small set of
> changes is sufficient for any purpose.

I find this assertion absurd, when in the past have we as kernel
developers ever been handed a static analysis report and then
questioned why the static analysis did not flag other call sites
before first reviewing the ones it did find?

>> A consideration worth noting for reviewing these patches is to weigh the
>> dramatic cost of being wrong about whether a given report is exploitable
>> vs the overhead nospec_{array_ptr,ptr} may introduce. In other words,
>> lets make the bar for applying these patches be "can you prove that the
>> bounds check bypass is *not* exploitable". Consider that the Spectre
>> paper reports one example of a speculation window being ~180 cycles.
>
>
>> Note that there is also a proposal from Linus, array_access [3], that
>> attempts to quash speculative execution past a bounds check without
>> introducing an lfence instruction. That may be a future optimization
>> possibility that is compatible with this api, but it would appear to
>> need guarantees from the compiler that it is not clear the kernel can
>> rely on at this point. It is also not clear that it would be a
>> significant performance win vs lfence.
>
> It is also not clear that these changes fix anything, or are in any
> sense correct for the problem they are trying to fix as the problem
> is not clearly described.

I'll try my best. I don't have first hand knowledge of how the static
analyzer is doing this job, and I don't think it matters for
evaluating these reports. I'll give you my thoughts on how I would
handle one of these reports if it flagged one of the sub-systems I
maintain.

Start with the example from the Spectre paper:

if (x < array1_size)
y = array2[array1[x] * 256];

In all the patches 'x' and 'array1' are called out explicitly. For example:

net: mpls: prevent bounds-check bypass via speculative execution

Static analysis reports that 'index' may be a user controlled value that
is used as a data dependency reading 'rt' from the 'platform_label'
array...

So the first thing to review is whether the analyzer got it wrong and
'x' is not arbitrarily controllable by userspace to cause speculation
outside of the checked bounds. Be like Srinivas. The next step is to
ask whether the code can be refactored so that 'x' is sanitized
earlier in the call stack, especially if the nospec_array_ptr() lands
in a hot path. The next aspect that I expect most would be tempted to
go check is whether 'array2[array1[x]]' occurs later in the code
stream, but with speculation windows being architecture dependent and
potentially large (~180 cycles in one case says the p

[PATCH 00/18] prevent bounds-check bypass via speculative execution

[Dan Williams]

Quoting Mark's original RFC:

"Recently, Google Project Zero discovered several classes of attack
against speculative execution. One of these, known as variant-1, allows
explicit bounds checks to be bypassed under speculation, providing an
arbitrary read gadget. Further details can be found on the GPZ blog [1]
and the Documentation patch in this series."

This series incorporates Mark Rutland's latest api and adds the x86
specific implementation of nospec_barrier. The
nospec_{array_ptr,ptr,barrier} helpers are then combined with a kernel
wide analysis performed by Elena Reshetova to address static analysis
reports where speculative execution on a userspace controlled value
could bypass a bounds check. The patches address a precondition for the
attack discussed in the Spectre paper [2].

A consideration worth noting for reviewing these patches is to weigh the
dramatic cost of being wrong about whether a given report is exploitable
vs the overhead nospec_{array_ptr,ptr} may introduce. In other words,
lets make the bar for applying these patches be "can you prove that the
bounds check bypass is *not* exploitable". Consider that the Spectre
paper reports one example of a speculation window being ~180 cycles.

Note that there is also a proposal from Linus, array_access [3], that
attempts to quash speculative execution past a bounds check without
introducing an lfence instruction. That may be a future optimization
possibility that is compatible with this api, but it would appear to
need guarantees from the compiler that it is not clear the kernel can
rely on at this point. It is also not clear that it would be a
significant performance win vs lfence.

These patches also will also be available via the 'nospec' git branch
here:

git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec

[1]: 
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
[2]: https://spectreattack.com/spectre.pdf
[3]: https://marc.info/?l=linux-kernel=151510446027625=2

---

Andi Kleen (1):
  x86, barrier: stop speculation for failed access_ok

Dan Williams (13):
  x86: implement nospec_barrier()
  [media] uvcvideo: prevent bounds-check bypass via speculative execution
  carl9170: prevent bounds-check bypass via speculative execution
  p54: prevent bounds-check bypass via speculative execution
  qla2xxx: prevent bounds-check bypass via speculative execution
  cw1200: prevent bounds-check bypass via speculative execution
  Thermal/int340x: prevent bounds-check bypass via speculative execution
  ipv6: prevent bounds-check bypass via speculative execution
  ipv4: prevent bounds-check bypass via speculative execution
  vfs, fdtable: prevent bounds-check bypass via speculative execution
  net: mpls: prevent bounds-check bypass via speculative execution
  udf: prevent bounds-check bypass via speculative execution
  userns: prevent bounds-check bypass via speculative execution

Mark Rutland (4):
  asm-generic/barrier: add generic nospec helpers
  Documentation: document nospec helpers
  arm64: implement nospec_ptr()
  arm: implement nospec_ptr()

 Documentation/speculation.txt  |  166 
 arch/arm/include/asm/barrier.h |   75 +
 arch/arm64/include/asm/barrier.h   |   55 +++
 arch/x86/include/asm/barrier.h |6 +
 arch/x86/include/asm/uaccess.h |   17 ++
 drivers/media/usb/uvc/uvc_v4l2.c   |7 +
 drivers/net/wireless/ath/carl9170/main.c   |6 -
 drivers/net/wireless/intersil/p54/main.c   |8 +
 drivers/net/wireless/st/cw1200/sta.c   |   10 +
 drivers/net/wireless/st/cw1200/wsm.h   |4 
 drivers/scsi/qla2xxx/qla_mr.c  |   15 +-
 .../thermal/int340x_thermal/int340x_thermal_zone.c |   14 +-
 fs/udf/misc.c  |   39 +++--
 include/asm-generic/barrier.h  |   68 
 include/linux/fdtable.h|5 -
 kernel/user_namespace.c|   10 -
 net/ipv4/raw.c |9 +
 net/ipv6/raw.c |9 +
 net/mpls/af_mpls.c |   12 +
 19 files changed, 466 insertions(+), 69 deletions(-)
 create mode 100644 Documentation/speculation.txt

[PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

[Dan Williams]

Static analysis reports that 'queue' may be a user controlled value that
is used as a data dependency to read from the 'ar9170_qmap' array. In
order to avoid potential leaks of kernel memory values, block
speculative execution of the instruction stream that could issue reads
based on an invalid result of 'ar9170_qmap[queue]'. In this case the
value of 'ar9170_qmap[queue]' is immediately reused as an index to the
'ar->edcf' array.

Based on an original patch by Elena Reshetova.

Cc: Christian Lamparter <chunk...@googlemail.com>
Cc: Kalle Valo <kv...@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Elena Reshetova <elena.reshet...@intel.com>
Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
---
 drivers/net/wireless/ath/carl9170/main.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/carl9170/main.c 
b/drivers/net/wireless/ath/carl9170/main.c
index 988c8857d78c..0ff34cbe2b62 100644
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "hw.h"
@@ -1384,11 +1385,12 @@ static int carl9170_op_conf_tx(struct ieee80211_hw *hw,
   const struct ieee80211_tx_queue_params *param)
 {
struct ar9170 *ar = hw->priv;
+   const u8 *elem;
int ret;
 
mutex_lock(>mutex);
-   if (queue < ar->hw->queues) {
-   memcpy(>edcf[ar9170_qmap[queue]], param, sizeof(*param));
+   if ((elem = nospec_array_ptr(ar9170_qmap, queue, ar->hw->queues))) {
+   memcpy(>edcf[*elem], param, sizeof(*param));
ret = carl9170_set_qos(ar);
} else {
ret = -EINVAL;

[PATCH 09/18] p54: prevent bounds-check bypass via speculative execution

[Dan Williams]

Static analysis reports that 'queue' may be a user controlled value that
is used as a data dependency to read from the 'priv->qos_params' array.
In order to avoid potential leaks of kernel memory values, block
speculative execution of the instruction stream that could issue reads
based on an invalid result of 'priv->qos_params[queue]'.

Based on an original patch by Elena Reshetova.

Cc: Christian Lamparter <chunk...@googlemail.com>
Cc: Kalle Valo <kv...@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Elena Reshetova <elena.reshet...@intel.com>
Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
---
 drivers/net/wireless/intersil/p54/main.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intersil/p54/main.c 
b/drivers/net/wireless/intersil/p54/main.c
index ab6d39e12069..85c9cbee35fc 100644
--- a/drivers/net/wireless/intersil/p54/main.c
+++ b/drivers/net/wireless/intersil/p54/main.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -411,12 +412,13 @@ static int p54_conf_tx(struct ieee80211_hw *dev,
   const struct ieee80211_tx_queue_params *params)
 {
struct p54_common *priv = dev->priv;
+   struct p54_edcf_queue_param *p54_q;
int ret;
 
mutex_lock(>conf_mutex);
-   if (queue < dev->queues) {
-   P54_SET_QUEUE(priv->qos_params[queue], params->aifs,
-   params->cw_min, params->cw_max, params->txop);
+   if ((p54_q = nospec_array_ptr(priv->qos_params, queue, dev->queues))) {
+   P54_SET_QUEUE(p54_q[0], params->aifs, params->cw_min,
+   params->cw_max, params->txop);
ret = p54_set_edcf(priv);
} else
ret = -EINVAL;

[PATCH 11/18] cw1200: prevent bounds-check bypass via speculative execution

[Dan Williams]

Static analysis reports that 'queue' may be a user controlled value that
is used as a data dependency to read 'txq_params' from the
'priv->tx_queue_params.params' array.  In order to avoid potential leaks
of kernel memory values, block speculative execution of the instruction
stream that could issue reads based on an invalid value of 'txq_params'.
In this case 'txq_params' is referenced later in the function.

Based on an original patch by Elena Reshetova.

Cc: Solomon Peachy <pi...@shaftnet.org>
Cc: Kalle Valo <kv...@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Elena Reshetova <elena.reshet...@intel.com>
Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
---
 drivers/net/wireless/st/cw1200/sta.c |   10 ++
 drivers/net/wireless/st/cw1200/wsm.h |4 +---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/st/cw1200/sta.c 
b/drivers/net/wireless/st/cw1200/sta.c
index 38678e9a0562..886942617f14 100644
--- a/drivers/net/wireless/st/cw1200/sta.c
+++ b/drivers/net/wireless/st/cw1200/sta.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cw1200.h"
 #include "sta.h"
@@ -612,18 +613,19 @@ int cw1200_conf_tx(struct ieee80211_hw *dev, struct 
ieee80211_vif *vif,
   u16 queue, const struct ieee80211_tx_queue_params *params)
 {
struct cw1200_common *priv = dev->priv;
+   struct wsm_set_tx_queue_params *txq_params;
int ret = 0;
/* To prevent re-applying PM request OID again and again*/
bool old_uapsd_flags;
 
mutex_lock(>conf_mutex);
 
-   if (queue < dev->queues) {
+   if ((txq_params = nospec_array_ptr(priv->tx_queue_params.params,
+   queue, dev->queues))) {
old_uapsd_flags = le16_to_cpu(priv->uapsd_info.uapsd_flags);
 
-   WSM_TX_QUEUE_SET(>tx_queue_params, queue, 0, 0, 0);
-   ret = wsm_set_tx_queue_params(priv,
- 
>tx_queue_params.params[queue], queue);
+   WSM_TX_QUEUE_SET(txq_params, 0, 0, 0);
+   ret = wsm_set_tx_queue_params(priv, txq_params, queue);
if (ret) {
ret = -EINVAL;
goto out;
diff --git a/drivers/net/wireless/st/cw1200/wsm.h 
b/drivers/net/wireless/st/cw1200/wsm.h
index 48086e849515..8c8d9191e233 100644
--- a/drivers/net/wireless/st/cw1200/wsm.h
+++ b/drivers/net/wireless/st/cw1200/wsm.h
@@ -1099,10 +1099,8 @@ struct wsm_tx_queue_params {
 };
 
 
-#define WSM_TX_QUEUE_SET(queue_params, queue, ack_policy, allowed_time,\
-   max_life_time)  \
+#define WSM_TX_QUEUE_SET(p, ack_policy, allowed_time, max_life_time)   \
 do {   \
-   struct wsm_set_tx_queue_params *p = &(queue_params)->params[queue]; \
p->ackPolicy = (ack_policy);\
p->allowedMediumTime = (allowed_time);  \
p->maxTransmitLifetime = (max_life_time);   \

Re: [PATCH] nl80211: Introduce scan flags to emphasize requested scan behavior

[Dan Williams]

On Wed, 2017-12-13 at 19:52 +0200, Jouni Malinen wrote:
> From: Sunil Dutt 
> 
> This commit defines new scan flags (LOW_SPAN, LOW_POWER,
> HIGH_LATENCY)
> to emphasize the requested scan behavior for the driver. These flags
> are
> optional and are mutually exclusive. Driver shall resort to default
> behavior if a respective flag is not supported. The implementation of
> the respective functionality can be driver/hardware specific.

Can't we have some kind of capability indication that the driver
supports each of these flags or not?  Otherwise we get into a situation
where you just have to try the flag and hope it works, since it doesn't
look like drivers are required to error out if they don't support the
flag.

Dan

> These flags can be used to control the compromise between how long a
> scan takes, how much power it uses, and high accurate/complete the
> scan
> is in finding the BSSs.
> 
> Signed-off-by: Sunil Dutt 
> Signed-off-by: Jouni Malinen 
> ---
>  include/uapi/linux/nl80211.h | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/nl80211.h
> b/include/uapi/linux/nl80211.h
> index 6dd6939..68fdb95 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -5059,6 +5059,11 @@ enum nl80211_timeout_reason {
>   * of NL80211_CMD_TRIGGER_SCAN and NL80211_CMD_START_SCHED_SCAN
>   * requests.
>   *
> + * NL80211_SCAN_FLAG_LOW_SPAN, NL80211_SCAN_FLAG_LOW_POWER, and
> + * NL80211_SCAN_FLAG_HIGH_ACCURACY flags are exclusive of each
> other, i.e., only
> + * one of them can be used in the request. If the driver does not
> support the
> + * requested behavior, default scan behavior will be used instead.
> + *
>   * @NL80211_SCAN_FLAG_LOW_PRIORITY: scan request has low priority
>   * @NL80211_SCAN_FLAG_FLUSH: flush cache before scanning
>   * @NL80211_SCAN_FLAG_AP: force a scan even if the interface is
> configured
> @@ -5086,7 +5091,20 @@ enum nl80211_timeout_reason {
>   *   and suppression (if it has received a broadcast Probe
> Response frame,
>   *   Beacon frame or FILS Discovery frame from an AP that the
> STA considers
>   *   a suitable candidate for (re-)association - suitable in
> terms of
> - *   SSID and/or RSSI
> + *   SSID and/or RSSI.
> + * @NL80211_SCAN_FLAG_LOW_SPAN: Span corresponds to the total time
> taken to
> + *   accomplish the scan. Thus, this flag intends the driver to
> perform the
> + *   scan request with lesser span/duration. It is specific to
> the driver
> + *   implementations on how this is accomplished. Scan accuracy
> may get
> + *   impacted with this flag. This flag cannot be used with
> + * @NL80211_SCAN_FLAG_LOW_POWER: This flag intends the scan attempts
> to consume
> + *   optimal possible power. Drivers can resort to their
> specific means to
> + *   optimize the power. Scan accuracy may get impacted with
> this flag.
> + * @NL80211_SCAN_FLAG_HIGH_ACCURACY: Accuracy here intends to the
> extent of scan
> + *   results obtained. Thus HIGH_ACCURACY scan flag aims to get
> maximum
> + *   possible scan results. This flag hints the driver to use
> the best
> + *   possible scan configuration to improve the accuracy in
> scanning.
> + *   Latency and power use may get impacted with this flag.
>   */
>  enum nl80211_scan_flags {
>   NL80211_SCAN_FLAG_LOW_PRIORITY  
> = 1<<0,
> @@ -5097,6 +5115,9 @@ enum nl80211_scan_flags {
>   NL80211_SCAN_FLAG_ACCEPT_BCAST_PROBE_RESP   =
> 1<<5,
>   NL80211_SCAN_FLAG_OCE_PROBE_REQ_HIGH_TX_RATE
> = 1<<6,
>   NL80211_SCAN_FLAG_OCE_PROBE_REQ_DEFERRAL_SUPPRESSION
> = 1<<7,
> + NL80211_SCAN_FLAG_LOW_SPAN  =
> 1<<8,
> + NL80211_SCAN_FLAG_LOW_POWER =
> 1<<9,
> + NL80211_SCAN_FLAG_HIGH_ACCURACY 
> = 1<<10,
>  };
>  
>  /**

Re: Regression: Bug 196547 - Since 4.12 - bonding module not working with wireless drivers

[Dan Williams]

On Wed, 2017-08-16 at 19:36 -0700, Ben Greear wrote:
> On 08/16/2017 07:11 PM, Dan Williams wrote:
> > On Wed, 2017-08-16 at 14:31 -0700, David Miller wrote:
> > > From: Dan Williams <d...@redhat.com>
> > > Date: Wed, 16 Aug 2017 16:22:41 -0500
> > > 
> > > > My biggest suggestion is that perhaps bonding should grow
> > > 
> > > hysteresis
> > > > for link speeds. Since WiFi can change speed every packet, you
> > > 
> > > probably
> > > > don't want the bond characteristics changing every couple
> > > > seconds
> > > 
> > > just
> > > > in case your WiFi link is jumping around.  Ethernet won't
> > > > bounce
> > > 
> > > around
> > > > that much, so the hysteresis would have no effect there.  Or,
> > > > if
> > > 
> > > people
> > > > are concerned about response time to speed changes on ethernet
> > > 
> > > (where
> > > > you probably do want an instant switch-over) some new flag to
> > > 
> > > indicate
> > > > that certain devices don't have stable speeds over time.
> > > 
> > > Or just report the average of the range the wireless link can
> > > hit,
> > > and
> > > be done with it.
> > > 
> > > I think you guys are overcomplicating things.
> > 
> > That range can be from 1 to > 800Mb/s.  No, it won't usually be all
> > over that range, but it won't be uncommon to fluctuate by hundreds
> > of
> > Mb/s.  I'm not sure a simple average is really the answer
> > here.  Even
> > doing that would require new knobs to ethtool, since the rate
> > depends
> > heavily on card capabilities and also what AP you're connected to
> > *at
> > that moment*.  If you roam to another AP, then the max speed can
> > certainly change.
> > 
> > You'll probably say "aim for the 75% case" or something like that,
> > which is fine, but then you're depending on your 75% case to be (a)
> > single AP, (b) never move (eg, only bond wifi + ethernet), (c)
> > little
> > radio interference.  I'm not sure I'd buy that.  If I've put words
> > in
> > your mouth, forgive me.
> 
> If you keep ethtool API simple and just return the last (rx-rate +
> tx-rate) / 2, or the rate averaged
> over the last 100 frames or 10 seconds, then the caller can do longer
> term averaging
> as it sees fit.  Probably no need for lots of averaging complexity in
> the kernel.

Yeah, that works too, but I was thinking it was better to present the
actual data through ethtool so that things other than bonding could use
it, and since bonding is the thing that actually cares about the
fluctuation, make it do the more extensive processing.

Dan


> rate-ctrl for wifi basically doesn't happen until you transmit or
> receive a
> fairly steady stream, so it will fluctuate a lot.

Re: Regression: Bug 196547 - Since 4.12 - bonding module not working with wireless drivers

[Dan Williams]

On Wed, 2017-08-16 at 14:31 -0700, David Miller wrote:
> From: Dan Williams <d...@redhat.com>
> Date: Wed, 16 Aug 2017 16:22:41 -0500
> 
> > My biggest suggestion is that perhaps bonding should grow
> hysteresis
> > for link speeds. Since WiFi can change speed every packet, you
> probably
> > don't want the bond characteristics changing every couple seconds
> just
> > in case your WiFi link is jumping around.  Ethernet won't bounce
> around
> > that much, so the hysteresis would have no effect there.  Or, if
> people
> > are concerned about response time to speed changes on ethernet
> (where
> > you probably do want an instant switch-over) some new flag to
> indicate
> > that certain devices don't have stable speeds over time.
> 
> Or just report the average of the range the wireless link can hit,
> and
> be done with it.
> 
> I think you guys are overcomplicating things.

That range can be from 1 to > 800Mb/s.  No, it won't usually be all
over that range, but it won't be uncommon to fluctuate by hundreds of
Mb/s.  I'm not sure a simple average is really the answer here.  Even
doing that would require new knobs to ethtool, since the rate depends
heavily on card capabilities and also what AP you're connected to *at
that moment*.  If you roam to another AP, then the max speed can
certainly change.

You'll probably say "aim for the 75% case" or something like that,
which is fine, but then you're depending on your 75% case to be (a)
single AP, (b) never move (eg, only bond wifi + ethernet), (c) little
radio interference.  I'm not sure I'd buy that.  If I've put words in
your mouth, forgive me.

Dan

Re: Regression: Bug 196547 - Since 4.12 - bonding module not working with wireless drivers

[Dan Williams]

On Wed, 2017-08-16 at 14:44 -0600, James Feeney wrote:
> On 08/13/2017 11:42 AM, Andreas Born wrote:
> > On a side note I would recommend some of my own reading to you
> > about
> > patch submission in general [1] and on netdev specifically [2].
> 
> Mmm - [2] and [3], I suspect.  Thanks Andreas.  I'll be studying
> those.  Yeah,
> I'm still learning what is needed and what works.  Sometimes, just a
> note to the
> author is more than enough to resolve a problem.  Sometimes,
> discussion is
> needed.  And other times... well, certain people are infamous... but
> no problem
> here, thankfully.
> 
> > And, just wondering, who's going to eventually close that
> > bugreport?
> > https://bugzilla.kernel.org/show_bug.cgi?id=196547
> 
> I can close it when the patches actually land in the kernel.  I'm
> glad to see
> that there was an "Ack" from Mahesh.
> 
> On the topic of wireless support for kernel ethtool reporting, I'm
> wondering, is
> there is any consensus about that?
> 
> And, for instance, is there any *other* way for the bonding module to
> make
> "better link" decisions for wireless links?  As "wireless" becomes
> more capable,
> possibly more diverse, and probably more essential for computing,
> this is likely
> to become a bigger issue.
> 
> Ben Greear mentioned that he had added some support to the ath10k
> driver.  Dan
> Williams mentioned the possibility of updating the mac80211 stack for
> support.
> And Arend van Spriel suggested that the issue might best be left for
> the next
> Netconf.
> 
> Immediate problem solved, but maybe a larger issue still needs to be
> addressed?

Again, it's technically possible to add the link settings support to
wireless drivers.  But the issue is around what bonding would do with
that information in its various modes.

My biggest suggestion is that perhaps bonding should grow hysteresis
for link speeds. Since WiFi can change speed every packet, you probably
don't want the bond characteristics changing every couple seconds just
in case your WiFi link is jumping around.  Ethernet won't bounce around
that much, so the hysteresis would have no effect there.  Or, if people
are concerned about response time to speed changes on ethernet (where
you probably do want an instant switch-over) some new flag to indicate
that certain devices don't have stable speeds over time.

Dan

Re: wireless drivers fail to report link speed?

[Dan Williams]

On Wed, 2017-08-09 at 11:01 -0600, James Feeney wrote:
> @ Dan Williams
> 
> > I'm not really arguing against updating mac80211 to report this
> > information if somebody actually wants to do the patch.  I'm only
> > saying that even with the patch, it's not going to do exactly what
> > you
> > want it to do, and even if it works for you 90% of the time, it's
> > not
> > going to work for others that much of the time, and thus it gives a
> > false sense of "correctness" which is just wrong.
> 
> Hey - don't put this on me!  This is not about "what I want it to
> do".  I'm only

I had a whole email written out, but it wasn't very constructive.

To be clear: I am not putting anything on you, or blaming you for
anything :)  Sorry if my tone implied that to you.  I feel like the
tone of this thread is becoming contentious and that's not my desire.

There is clearly a problem.  That problem was exposed by a patch to the
bonding driver that newly requires information that the WiFi drivers
don't provide.

The relevant questions, in my view, are:

1) why does the bonding driver now require this information?

2) is this information reasonable to request from WiFi drivers?

3) how would this information affect the operation of the bonding
driver if it doesn't mean the same thing as it means for wired devices?

My answers are:

1) I have no idea, though to continue being constructive to this
discussion, I should probably go find out.  We should also get the
bonding module patch authors to weigh in.  But the core point is that
it used to work, and now it doesn't work, and the WiFi drivers have not
changed in this area.

2) ethtool's API doesn't say much about semantics.  It is likely
reasonable to request this information from WiFi drivers, but
unfortunately WiFi has some different semantics for the information
than ethernet devices do.

3) The bonding module is interpreting the speed in a certain way that
can hugely affect its operation, and ethernet devices don't change
speed very frequently.  But wifi devices do.  This may well cause
unexpected operation from bonding, and we should be well aware of that
before we do anything to fix this problem.

I'd also like to point out the various virtual devices (veth, virtio,
etc) and how they report speed.  They lock the speed to a certain
value, but that doesn't actually mean anything because they are not
hardware based and their throughput is more a function of current CPU
load rather than actual wire speed.  The 'tun' driver locks the rate to
10Mb/s with no capability to change.  These are another case of
mismatch in expectations between bonding and reported speeds.

Again, there is a problem that should be solved.  I am only advocating
that instead of simply adding ethtool get_settings support to WiFi
drivers and washing our hands of it, which may have unintended
consequences, we gather all the information first, and discuss whether
the bonding driver may need to adjust its expectations before this kind
of change is made.

Dan

> trying to make my wireless bonding work again.  But I also don't want
> to simply
> "slap down" Mahesh, by only reverting his patch, which addressed
> another, real,
> problem.  This needs to be a cooperative effort.  How do *we all*
> address the
> problem that Mahesh was trying to resolve, and, at the same time,
> continue to
> support wireless bonding?  Please, don't just "kick the can down the
> road".  It
> seems to me that Mahesh must have been pretty upset about the
> wireless drivers
> not reporting speed, to have written a patch that just disables the
> wireless
> interface when the reporting fails.  Think about it.
> 
> If there is a long-standing screw-up with the wireless drivers
> failing to
> properly support 'section 11.46 ("Estimated throughput") of
> IEEE802.11-2016',
> then let's start-off by admitting that.  *Then* everyone can argue
> about what to
> do about it.  And, if that's not the underlying problem, let's make
> that
> determination.  I'm just trying to find a way forward.
> 
> > No, it's not a fault of ethtool.  Ethtool only reports something,
> > it's
> > up to the thing that interprets that data (eg, bonding) to do the
> > right
> > thing with it.
> 
> It has not yet been established that there is anything - "Estimated
> throughput"
> - being provided universally by the wireless drivers for the kernel
> ethtool to
> report.  So, you cannot blame this immediately upon "the thing that
> interprets
> the data (eg, bonding)", when there *is no data* to interpret.  That
> was the
> original question and issue.  There first *has* to be some data to
> interpret!
> 
> I will say that it is no more appropriate that the wireless drivers
> gener

Re: wireless drivers fail to report link speed?

[Dan Williams]

On Tue, 2017-08-08 at 18:36 -0600, James Feeney wrote:
> Hey
> 
> On 08/08/2017 04:49 PM, Ben Greear wrote:
> > 
> > Some time back, I added some support to ath10k to report some
> > ethtool info.
> > At least most of this is upstream.  I do report rx and rx link
> > rate, and yes,
> > it changes, but it does contain some useful info, at least when
> > modest amounts
> > of packets are being transmitted and received (so that rate-ctrl
> > logic
> > is working).  I think the stuff not prepended with d_ will show up
> > for any
> > mac80211 driver.  Someone could improve ethtool to report these
> > through more
> > normal API than just getting the stats if they wanted...
> 
> Hmm - would you then lean in the direction of saying that this
> failure to report
> a link speed is a fault in the kernel ethtool?

No, it's not a fault of ethtool.  Ethtool only reports something, it's
up to the thing that interprets that data (eg, bonding) to do the right
thing with it.

> And, if so, would an update be required in just the kernel ethtool,
> or in both
> the kernel ethtool and in every wireless driver?

Likely every wireless driver, except that for mac80211-based drivers it
would only take updating the mac80211 stack.

I'm not really arguing against updating mac80211 to report this
information if somebody actually wants to do the patch.  I'm only
saying that even with the patch, it's not going to do exactly what you
want it to do, and even if it works for you 90% of the time, it's not
going to work for others that much of the time, and thus it gives a
false sense of "correctness" which is just wrong.

> Should the kernel ethtool get_settings() be made to report a proper
> link speed
> and duplex when used with the wireless drivers?
> 
> On 08/08/2017 05:43 PM, Dan Williams wrote:
> > 
> > It's very relevant to the question.  Because if the speed is
> > actually
> > not useful for the requested purpose, there is no real point in
> > having
> > it reported it via ethtool.  Same for duplex.  Wifi is only "half
> > duplex", and so the property is actually meaningless for WiFi.
> 
> That seems a little over-broad, at least certainly with respect to
> "half
> duplex".  If the link is known to be half duplex, then the kernel
> ethtool can
> simply report that the link is "half duplex".  I am not hearing a
> good
> justification, or a necessity, for the kernel ethtool to return an
> error, instead.

> > At
> > worst, your bonding link will flip-flop between slaves every second
> > or
> > two.  At best, bonding won't do anything differently than if the
> > speed
> > was just faked to some fake lowest common denominator number so
> > that
> > your wired link was always faster.
> 
> Well ok, flip-flopping every second would seem a pointless and bad
> effect.  But
> then, for instance, my rtl8192ce driver shows a stable, actual link
> speed:
> 
> $ iwconfig wlp2s0
> ...
> Bit Rate=72.2 Mb/s
> ...

iwconfig cannot report high rates, so try 'iw dev  link' to make
sure.

When I did 'iw dev wlp4s0 link' with a 2.4GHz baby monitor on in the
next room, my device flipped continuously between ~70Mb/s and 130Mb/s
every couple seconds. YMMV.  It's gonna be the same anywhere near a
microwave.

> $ ethtool -S wlp2s0
> ...
>  txrate: 7220
>  rxrate: 100
> ...
> 
> Then, I don't know if this effect is as bad as you suggest.  Is there
> an actual
> "stable" link speed here?  Or is this an "illusion", of bit of
> "fluff" being
> promoted by the user-space iwconfig and ethtool?

There is no "stable" link speed.  The link selects the maximum speed
that produces as few errors as possible, and adjusts that speed
continuously due to the radio environment.  Again, many external
factors that you have no control over affect link speed.

In the span of 5 seconds, 2 feet away from my 11n AP, my link went
through 65Mb, 130Mb, 78Mb, and back to 130Mb.  That's just how this
works.

It's like if your ethernet link dynamically adjusted speed from 2Mb/s
up to 10Gb/s based on how much traffic was going through it at a given
time, or to save power, or something.

> > Sure, somebody could do a patch (like Ben has) that plumbs all this
> > stuff through.  But that's not solving the *actual* problem, which
> > is
> > that this bonding change makes assumptions of slave devices that
> > simply
> > don't match how those devices work.
> 
> I take it that your position would be that the bonding module people,
> and Mahesh
> in particular, are being unreasonable in expecting the kernel ethtool
> to provide
> anything bu

Re: wireless drivers fail to report link speed?

[Dan Williams]

On Tue, 2017-08-08 at 16:25 -0600, James Feeney wrote:
> Hey Dan
> 
> > ...
> > So one second the wifi might be the "best" link and then when
> > somebody
> > turns on a microwave oven or a baby monitor, it may be the "worst"
> > until the microwave's duty cycle completes a few seconds later then
> > it'll become the "best" again for a couple seconds then "worst"
> > again,
> > repeat until your Easy Mac is nice and warm and creamy.
> > 
> > Furthermore, for some drivers IIRC when there isn't any traffic,
> > they
> > might drop the link rate very low because there's no reason keep
> > powering blocks when you're not transmitting/receiving any
> > data.  IIRC
> > the Intel drivers used to do that a couple years ago.
> 
> Yes, thanks, but, while all of that is true, it has nothing to do
> with the
> question asked.

It's very relevant to the question.  Because if the speed is actually
not useful for the requested purpose, there is no real point in having
it reported it via ethtool.  Same for duplex.  Wifi is only "half
duplex", and so the property is actually meaningless for WiFi.

The bonding driver is requiring completely irrelevant information, or
at least information that simply doesn't make sense for some
communication mechanisms.  There's no way the bonding driver can make a
useful decision if the speed *intentionally* changes regularly.  At
worst, your bonding link will flip-flop between slaves every second or
two.  At best, bonding won't do anything differently than if the speed
was just faked to some fake lowest common denominator number so that
your wired link was always faster.

Sure, somebody could do a patch (like Ben has) that plumbs all this
stuff through.  But that's not solving the *actual* problem, which is
that this bonding change makes assumptions of slave devices that simply
don't match how those devices work.

Dan

> The question is, regardless that the wireless speed may be constantly
> changing,
> why is it that the kernel ethtool returns an error on get_settings(),
> instead of
> returning the current wireless speed, whatever that link speed might
> be at the
> moment?
> 
> > Also, "duplex" doesn't mean anything in wireless land.  So no clue
> > what
> > bonding is expecting them to say here.  I would say the
> > modifications
> > to the bonding core made assumptions that simply aren't applicable
> > to
> > mediums other than wired ones.
> 
> Since, as Ben mentions,
> 
> > Well, wifi acts half-duplex in that only one side can transmit at
> > once.
> 
> then the wireless drivers would be expected to simply report "half-
> duplex".
> 
> Again, the issue is not that wireless is half-duplex or full-duplex,
> but rather,
> why does the kernel ethtool return an error on get_settings()?
> 
> And, why is it that it seems get_settings() returns an error with
> multiple
> wireless drivers?  Is there some assumption, or convention, that
> causes the
> kernel ethtool to fail with *all* the wireless drivers?
> 
> I see that, on bugzilla, Florian is suggesting that wireless network
> devices
> *cannot* report a speed/duplex, simply because the wireless speed
> changes on a
> per-packet basis, but that does not seem to me to be a persuasive
> argument.  A
> wireless connection *does* always have a current speed, even if that
> speed
> changes frequently.  The kernel ethtool get_settings() should simply
> report that
> speed, not throw an error, yes?
> 
> 
> Thanks
> James
> 

Re: wireless drivers fail to report link speed?

[Dan Williams]

On Tue, 2017-08-08 at 13:07 -0600, James Feeney wrote:
> Hello All
> 
> Would you please look at kernel bug report "Since 4.12 - bonding
> module not
> working with wireless drivers", and tell me if you know why the
> kernel ethtool
> does not receive a speed report from the wireless drivers?
> 
>  https://bugzilla.kernel.org/show_bug.cgi?id=196547
> 
> It seems that Mahesh Bandewar became annoyed that some network
> drivers do not
> report speed and duplex to the bonding module properly, so that it
> becomes
> impossible to make "best connection" decisions.  A patch was applied
> to the
> bonding module in linux 4.12 which now disables any network interface
> that does
> not successfully report its speed and duplex.  In practice, this
> seems to
> include every wireless network driver I've tried, the ath5k, ath9k,
> the
> rtl8192ce and RTL8188CUS.  Of course, this new behavior breaks
> wireless bonding!
> 
> Do you know if there is some general reason why the wireless drivers
> do not work
> with the kernel ethtool?  Is this something that can be fixed?  Can
> you tell if
> this reporting failure would be the fault of the kernel ethtool?  Or
> the
> wireless driver?  Or the bonding module?

Because the "speed" (whatever that means) can and sometimes does change
with every packet.  The driver dynamically adjusts the link rate based
on all kinds of things.  But mainly the current radio environment; how
many other APs are around, how much interference there is, how many
other clients are trying to talk, that kind of thing.

So one second the wifi might be the "best" link and then when somebody
turns on a microwave oven or a baby monitor, it may be the "worst"
until the microwave's duty cycle completes a few seconds later then
it'll become the "best" again for a couple seconds then "worst" again,
repeat until your Easy Mac is nice and warm and creamy.

Furthermore, for some drivers IIRC when there isn't any traffic, they
might drop the link rate very low because there's no reason keep
powering blocks when you're not transmitting/receiving any data.  IIRC
the Intel drivers used to do that a couple years ago.

Also, "duplex" doesn't mean anything in wireless land.  So no clue what
bonding is expecting them to say here.  I would say the modifications
to the bonding core made assumptions that simply aren't applicable to
mediums other than wired ones.

Dan

Re: brcfmac: add possibility to turn off powersave on wiphy

[Dan Williams]

On Fri, 2017-07-21 at 23:19 +0200, Rafal wrote:
> On Fri, 21 Jul 2017, Dan Williams wrote:
> 
> > On Fri, 2017-07-21 at 16:56 +0200, Rafal wrote:
> > > I have a board with ap6212 chip and I have encountered two
> > > problems
> > > with the brcmfmac driver operating with this device. First
> > > problem I
> > > describe below, second one in separate mail.
> > > 
> > > 
> > > Namely, I have noticed quite poor connection with the device
> > > despite
> > > good signal strength. Ping to the device was very uneven, about
> > > 50 -
> > > 100 ms in average, 10 - 20% of packets loss. After some
> > > investigations I have found that problem is caused by powersave
> > > feature on wiphy (BRCMF_C_SET_PM command). When the value is set
> > > to
> > > PM_OFF, the problem does not appear - ping is quite stable, ~2ms.
> > > When set to PM_FAST, the ping is bad.
> > > 
> > > The brcmfmac driver currently does not have possibility to turn
> > > off
> > > the powersave feature. I have added the possibility on 4.11.6
> > > kernel
> > 
> > I don't think that's true?  The driver implements the nl80211
> > set_power_mgmt hook, which lets you turn off powersave with
> > 'iw'.  That
> > seems like a much better option than a module parameter.  I know
> > other
> > drivers have the module parameter, but I personally consider that
> > legacy/holdover, given that we have runtime toggles for this kind
> > of
> > thing.
> > 
> > brcmf_cfg80211_set_power_mgmt() should do what you need, right?
> 
> Yes, it does.
> 
> In fact, I needed only a parameter in OF database. This is a bug in
> the
> device or firmware and I needed to disable the feature for this chip.
> Many device drivers allow to specify in OF database that driver
> should
> use a quirk. This is similar situation.

Does the power management issue cause problems before any association
happens?  If not, then I'd suggest 'iw' in startup scripts somewhere. 
Or better yet, use the normal quirk method of detecting the hardware
version via IDs or detecting the firmware via version or feature
strings and quirking on that.

Dan

> I have added the kernel parameter as an additional feature. I thought
> that not all platforms are using devicetree database. But maybe it is
> a
> bad idea.
> 
> Rafal
> 
> > 
> > Dan
> > 

Re: brcfmac: add possibility to turn off powersave on wiphy

[Dan Williams]

On Fri, 2017-07-21 at 16:56 +0200, Rafal wrote:
> I have a board with ap6212 chip and I have encountered two problems
> with the brcmfmac driver operating with this device. First problem I
> describe below, second one in separate mail.
> 
> 
> Namely, I have noticed quite poor connection with the device despite
> good signal strength. Ping to the device was very uneven, about 50 -
> 100 ms in average, 10 - 20% of packets loss. After some
> investigations I have found that problem is caused by powersave
> feature on wiphy (BRCMF_C_SET_PM command). When the value is set to
> PM_OFF, the problem does not appear - ping is quite stable, ~2ms.
> When set to PM_FAST, the ping is bad.
> 
> The brcmfmac driver currently does not have possibility to turn off
> the powersave feature. I have added the possibility on 4.11.6 kernel 

I don't think that's true?  The driver implements the nl80211
set_power_mgmt hook, which lets you turn off powersave with 'iw'.  That
seems like a much better option than a module parameter.  I know other
drivers have the module parameter, but I personally consider that
legacy/holdover, given that we have runtime toggles for this kind of
thing.

brcmf_cfg80211_set_power_mgmt() should do what you need, right?

Dan

> in my sandbox, but maybe the change is worth to add in general. I'm
> providing my patch for reference. This change allows to turn off
> powersave in two ways. First one, by specify "brcm,powersave-default-
> off" option in OF devicetree. Second one - as a module parameter. The
> parameter is named powersave_default and is tri-state:
> 
> value >0 enables powersave
> value =0 disables powersave
> value <0 (the default) does not override powersave value, i.e. value
> from devicetree or driver default is in effect.
> 
> Rafal
> 
> 
> diff --git
> a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 944b83c..86cd1f7 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -5702,7 +5702,7 @@ static s32 wl_init_priv(struct
> brcmf_cfg80211_info *cfg)
>   s32 err = 0;
> 
>   cfg->scan_request = NULL;
> - cfg->pwr_save = true;
> + cfg->pwr_save = !cfg->pub->settings->powersave_default_off;
>   cfg->active_scan = true;/* we do active scan per
> default */
>   cfg->dongle_up = false; /* dongle is not up
> yet */
>   err = brcmf_init_priv_mem(cfg);
> @@ -6450,8 +6450,9 @@ static int brcmf_setup_wiphy(struct wiphy
> *wiphy, struct brcmf_if *ifp)
>   BIT(NL80211_BSS_SELECT_ATTR_BAN
> D_PREF) |
>   BIT(NL80211_BSS_SELECT_ATTR_RSS
> I_ADJUST);
> 
> - wiphy->flags |= WIPHY_FLAG_PS_ON_BY_DEFAULT |
> - WIPHY_FLAG_OFFCHAN_TX |
> + if( ! ifp->drvr->settings->powersave_default_off )
> + wiphy->flags |= WIPHY_FLAG_PS_ON_BY_DEFAULT;
> + wiphy->flags |= WIPHY_FLAG_OFFCHAN_TX |
>   WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
>   if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_TDLS))
>   wiphy->flags |= WIPHY_FLAG_SUPPORTS_TDLS;
> diff --git
> a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index 33b133f..191424e 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -80,6 +80,10 @@ module_param_named(ignore_probe_fail,
> brcmf_ignore_probe_fail, int, 0);
>   MODULE_PARM_DESC(ignore_probe_fail, "always succeed probe for
> debugging");
>   #endif
> 
> +static int brcmf_powersave_default = -1;
> +module_param_named(powersave_default, brcmf_powersave_default, int,
> 0);
> +MODULE_PARM_DESC(powersave_default, "Set powersave default on/off on
> wiphy");
> +
>   static struct brcmfmac_platform_data *brcmfmac_pdata;
>   struct brcmf_mp_global_t brcmf_mp_global;
> 
> @@ -319,6 +323,8 @@ struct brcmf_mp_device
> *brcmf_get_module_param(struct device *dev,
>   /* No platform data for this device, try OF (Open
> Firwmare) */
>   brcmf_of_probe(dev, bus_type, settings);
>   }
> + if( brcmf_powersave_default >= 0 )
> + settings->powersave_default_off =
> !brcmf_powersave_default;
>   return settings;
>   }
> 
> diff --git
> a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> index a62f8e7..ab67fcf 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> @@ -59,6 +59,7 @@ struct brcmf_mp_device {
>   int fcmode;
>   boolroamoff;
>   boolignore_probe_fail;
> + boolpowersave_default_off;
>   struct brcmfmac_pd_cc *country_codes;
>   union {
>   

[PATCH] ipw2100: don't return positive values to PCI probe on error

[Dan Williams]

Causes the PCI stack to complain, and then eventually call the
PCI remove function, which ipw2100 is not expecting.  It then
tries to unregister an already-released netdev and other nasty
things, leading to a panic.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1185518

Signed-off-by: Dan Williams <d...@redhat.com>
---
 drivers/net/wireless/intel/ipw2x00/ipw2100.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c 
b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index f922859..7819959 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -1724,7 +1724,7 @@ static const struct libipw_geo ipw_geos[] = {
 static int ipw2100_up(struct ipw2100_priv *priv, int deferred)
 {
unsigned long flags;
-   int rc = 0;
+   int err = 0;
u32 lock;
u32 ord_len = sizeof(lock);
 
@@ -1757,33 +1757,33 @@ static int ipw2100_up(struct ipw2100_priv *priv, int 
deferred)
if (priv->status & STATUS_POWERED ||
(priv->status & STATUS_RESET_PENDING)) {
/* Power cycle the card ... */
-   if (ipw2100_power_cycle_adapter(priv)) {
+   err = ipw2100_power_cycle_adapter(priv);
+   if (err) {
printk(KERN_WARNING DRV_NAME
   ": %s: Could not cycle adapter.\n",
   priv->net_dev->name);
-   rc = 1;
goto exit;
}
} else
priv->status |= STATUS_POWERED;
 
/* Load the firmware, start the clocks, etc. */
-   if (ipw2100_start_adapter(priv)) {
+   err = ipw2100_start_adapter(priv);
+   if (err) {
printk(KERN_ERR DRV_NAME
   ": %s: Failed to start the firmware.\n",
   priv->net_dev->name);
-   rc = 1;
goto exit;
}
 
ipw2100_initialize_ordinals(priv);
 
/* Determine capabilities of this particular HW configuration */
-   if (ipw2100_get_hw_features(priv)) {
+   err = ipw2100_get_hw_features(priv);
+   if (err) {
printk(KERN_ERR DRV_NAME
   ": %s: Failed to determine HW features.\n",
   priv->net_dev->name);
-   rc = 1;
goto exit;
}
 
@@ -1792,11 +1792,11 @@ static int ipw2100_up(struct ipw2100_priv *priv, int 
deferred)
priv->ieee->freq_band = LIBIPW_24GHZ_BAND;
 
lock = LOCK_NONE;
-   if (ipw2100_set_ordinal(priv, IPW_ORD_PERS_DB_LOCK, , _len)) {
+   err = ipw2100_set_ordinal(priv, IPW_ORD_PERS_DB_LOCK, , _len);
+   if (err) {
printk(KERN_ERR DRV_NAME
   ": %s: Failed to clear ordinal lock.\n",
   priv->net_dev->name);
-   rc = 1;
goto exit;
}
 
@@ -1820,21 +1820,21 @@ static int ipw2100_up(struct ipw2100_priv *priv, int 
deferred)
 
/* Send all of the commands that must be sent prior to
 * HOST_COMPLETE */
-   if (ipw2100_adapter_setup(priv)) {
+   err = ipw2100_adapter_setup(priv);
+   if (err) {
printk(KERN_ERR DRV_NAME ": %s: Failed to start the card.\n",
   priv->net_dev->name);
-   rc = 1;
goto exit;
}
 
if (!deferred) {
/* Enable the adapter - sends HOST_COMPLETE */
-   if (ipw2100_enable_adapter(priv)) {
+   err = ipw2100_enable_adapter(priv);
+   if (err) {
printk(KERN_ERR DRV_NAME ": "
   "%s: failed in call to enable adapter.\n",
   priv->net_dev->name);
ipw2100_hw_stop_adapter(priv);
-   rc = 1;
goto exit;
}
 
@@ -1844,7 +1844,7 @@ static int ipw2100_up(struct ipw2100_priv *priv, int 
deferred)
}
 
   exit:
-   return rc;
+   return err;
 }
 
 static void ipw2100_down(struct ipw2100_priv *priv)
-- 
2.9.4

Re: WPA and WPA2

[Dan Williams]

On Thu, 2017-05-25 at 08:40 +1000, Tobin C. Harding wrote:
> On Wed, May 24, 2017 at 08:06:40PM +0200, Johannes Berg wrote:
> > Just a small correction:
> > 
> > On Wed, 2017-05-24 at 11:44 -0500, Dan Williams wrote:
> > > 
> > > For RSN, they are 1 = PMK, 2 = GMK, 3 = GMK2, 4 seems unused.
> > 
> > PTK and GTK, and in theory you could have more than two GTKs but
> > that's
> > not usually done.
> 
> Excuse my ignorance but why do you say PTK and GTK here? Who
> generates
> the transient keys, hardware, firmware or software? Is this device
> specific or is there a *normal* way?
> 
> From the nomenclature in the WEXT driver I thought the driver
> supplied the
> master keys to the firmware and transient keys were generated at the
> firmware layer or lower.

Usually the supplicant supplies only the PTK/GTK to the driver at the
right times (like during the 4-way handshake).  It looks like the
driver only refers to PMK/GMK when using the rx_seq[] bits, while the
actual WPA keys are probably the PTK/GTK.

While it's not the best example, see
drivers/net/wireless/marvell/libertas/cfg.c and lbs_cfg_connect() and
lbs_cfg_add_key().  That should translate fairly well to the ks7010
driver.  The important parts you'll get from nl80211 are
add_key/del_key and set_default_key.  The connect hook gets called
first to tell the driver to start the auth/assoc process to a given AP,
 and that's where you'd set up the general stuff like whether or not
you'll use WEP or WPA, what the SSID/BSSID are, whether PSK or
EAPOL/802.1x, rates, etc.  Then after that you'll get the add_key hook
that actually sends the real keys to the driver when the supplicant has
calculated them.


Dan

Re: WPA and WPA2

[Dan Williams]

On Wed, 2017-05-24 at 17:34 +1000, Tobin C. Harding wrote:
> On Wed, May 24, 2017 at 05:27:50PM +1000, Tobin C. Harding wrote:
> > Hi,
> > 
> > I am attempting to rewrite the ks7010 WEXT driver
> > (drivers/staging/ks7010)
> > to use the CFG80211 API.
> > 
> > I am reading 802.11 Wireless Networks - Matthew S. Gast for
> > reference.
> > 
> > I have some confusion regarding WEP/WPA/WPA2/RSN, ciphers, keys and
> > ie's?
> > 
> > As I understand, first there was WEP. Next we got a marketing term
> > WPA
> > which referred to 802.11i (which specified the protocols TKIP and
> > CCMP, and also RSN).
> > 
> > WEP vs WPA
> > --
> > 
> > To add to my confusion the ks7010 code seemingly mixes up the use
> > of
> > WEP keys and WPA keys, to set both the WEP and the WPA keys the
> > driver
> > uses the same MIB requests? Yet throughout the code WEP keys and
> > WPA
> > keys are stored in separate structures (and treated differently).
> 
> Oh, I just got why there is only one MIB request type - there are
> only
> one set of keys used by the target
> 
>   DOT11_WEP_DEFAULT_KEY_VALUE1= 0x13020101,
>   DOT11_WEP_DEFAULT_KEY_VALUE2= 0x13020102,
>   DOT11_WEP_DEFAULT_KEY_VALUE3= 0x13020103,
>   DOT11_WEP_DEFAULT_KEY_VALUE4= 0x13020104,
> 
> removing 'WEP' from the defines removes the confusion here :)

I could be entirely wrong, but it looks like the driver really just
defines 4 "keys" which can be used for anything.

For WEP, they are the 4 WEP key indexes.

For RSN, they are 1 = PMK, 2 = GMK, 3 = GMK2, 4 seems unused.

Because WEXT is pretty convoluted, I woudn't necessarily try to
translate what eg ks_wlan_set_encode_ext() is doing directly to
cfg80211, but to understand how the firmware interface works and then
just write the cfg80211 code to the firmware interface.

Basically, you have the following modes:

a) open, no encryption
b) WEP encryption (4 possible WEP keys, each either 40 or 104 bits)
c) WPA/RSN (PMK and GMK are computed by wpa_supplicant and supplied to
you, just need to send to firmware)

most of the stuff about IW_ENCODE_ALG_* is useless for cfg80211, you
just take the values that you get from userspace (eg, wpa_supplicant)
for the key and the type of key and just tell the firmware to use
those.

The driver also has odd stuff like SME_WEP_FLAG_REQUEST that really
just maps to DOT11_PRIVACY_INVOKED, so that's going to be a bit
confusing for you too since that's used not just for WEP but also for
WPA/RSN.

So anyway, it's going to be an interesting ride for you, but I think
you'll be pleasantly surprised at how much awful code you can actually
remove.

And to answer Johannes, this firmware looks much more fullmac than
softmac; BSS selection seems left up to the firmware.  You just send it
a "connect with these parameters" command (HIF_INFRA_SET_REQ) including
channels, SSID, BSSID, mode, etc and it does everything.

So Tobin, I think that means this driver should probably implement the
"connect" call like fullmac drivers do.  One existing example of that
is the 'brcmfmac' driver, eg brcmf_cfg80211_connect().

Dan

> > If WPA is enabled are not WEP keys superfluous?
> > 
> > WPA vs WPA2
> > ---
> > 
> > Were WPA version 1 and WPA version 2 marketing terms or do they
> > differ?
> > 
> > ieee80211.h does not seem to mention WPA2 (and cfg80211.h mentions
> > it
> > once only in some comments) however, from cfg80211.h;
> > 
> >  * struct cfg80211_crypto_settings - Crypto settings
> >  * @wpa_versions: indicates which, if any, WPA versions are enabled
> >  *  (from enum nl80211_wpa_versions)
> > 
> > When using the CFG80211 API we do not need to worry about the
> > WPA/WPA2
> > distinction? Can I drop all the WPA version 1 code from the driver?
> > 
> > A little more information:
> > 
> > The WEXT driver defines ciphers, from looking at ieee80211.h it
> > seems
> > that it uses WLAN_CIPHER_SUITE_XXX for WPA2 and for WPA it uses
> > 
> > #define CIPHER_ID_WPA_NONE"\x00\x50\xf2\x00"
> > #define CIPHER_ID_WPA_WEP40   "\x00\x50\xf2\x01"
> > #define CIPHER_ID_WPA_TKIP"\x00\x50\xf2\x02"
> > #define CIPHER_ID_WPA_CCMP"\x00\x50\xf2\x04"
> > #define CIPHER_ID_WPA_WEP104  "\x00\x50\xf2\x05"
> > 
> > FYI ieee80211.h has
> > 
> > #define WLAN_OUI_MICROSOFT     0x0050f2
> > 
> > Thanks for taking the time to read this mail, any suggestions most
> > appreciated.
> > 
> > thanks,
> > Tobin.

Re: [PATCH] cfg80211: Be able to set bss expire time at config stage.

[Dan Williams]

On Mon, 2017-05-22 at 18:09 +0200, Enric Balletbo i Serra wrote:
> The IEEE80211_SCAN_RESULT_EXPIRE value was modified several times in
> the
> past. Initially was set at 10 seconds (2a51931192), then increased at
> 15
> seconds (09f97e0fc4) and finally to 30 seconds (f9616e0f88) to cover
> the
> use case when a station is having heavy uplink traffic. On some
> devices,
> like Chromebooks, this value is decreased to 7 seconds to avoid stall
> results, and other devices prefer set to 15 seconds.

Couldn't userspace just look at NL80211_BSS_SEEN_MS_AGO to filter and
create its own list?  Given that the kernel provides the information
userspace needs to figure out the age of a particular BSS, it doesn't
seem like there needs to be a kernel tunable for this.  Userspace can
already avoid stale results.

Also, different runtime situations might want different result ages,
which wouldn't be possible if the kernel had a hardcoded maximum. 
Furthermore, different userspace apps might be reading the same scan
list, and they might have different ideas about staleness.

Or perhaps I misunderstand the problem, which could well be the case.

Dan

> This simple patch tries to make the selection of this value a bit
> more
> flexible by being able to set the expire time at config stage. Most
> users
> can leave the default value set as 30 seconds, others can modify the
> value
> at config stage if they want lower or bigger values.
> 
> Signed-off-by: Enric Balletbo i Serra 
> ---
>  net/wireless/Kconfig | 11 +++
>  net/wireless/core.c  |  2 ++
>  net/wireless/core.h  |  1 +
>  net/wireless/scan.c  |  6 ++
>  4 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index 6c60612..2a54e28 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -29,6 +29,17 @@ config CFG80211
>  
>     When built as a module it will be called cfg80211.
>  
> +config CFG80211_SCAN_RESULT_EXPIRE
> + int "Scan completion time" if CFG80211
> + default 30
> + ---help---
> +   This value is the time in seconds the mac80211 scan method
> needs
> +   to finish. An expiration time to 30 seconds should be
> sufficient
> +   for most cases but for some other cases we might be
> interested in
> +   tweak this value.
> +
> +   If unsure, leave the default of 30.
> +
>  config NL80211_TESTMODE
>   bool "nl80211 testmode command"
>   depends on CFG80211
> diff --git a/net/wireless/core.c b/net/wireless/core.c
> index 83ea164..2a5742c 100644
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -499,6 +499,8 @@ struct wiphy *wiphy_new_nm(const struct
> cfg80211_ops *ops, int sizeof_priv,
>  
>   init_waitqueue_head(>dev_wait);
>  
> + rdev->scan_result_expire =
> CONFIG_CFG80211_SCAN_RESULT_EXPIRE;
> +
>   /*
>    * Initialize wiphy parameters to IEEE 802.11 MIB default
> values.
>    * Fragmentation and RTS threshold are disabled by default
> with the
> diff --git a/net/wireless/core.h b/net/wireless/core.h
> index 6e809325..6a8a164 100644
> --- a/net/wireless/core.h
> +++ b/net/wireless/core.h
> @@ -72,6 +72,7 @@ struct cfg80211_registered_device {
>   struct rb_root bss_tree;
>   u32 bss_generation;
>   u32 bss_entries;
> + unsigned int scan_result_expire;
>   struct cfg80211_scan_request *scan_req; /* protected by RTNL
> */
>   struct sk_buff *scan_msg;
>   struct list_head sched_scan_req_list;
> diff --git a/net/wireless/scan.c b/net/wireless/scan.c
> index 14d5f0c..f0b55a9 100644
> --- a/net/wireless/scan.c
> +++ b/net/wireless/scan.c
> @@ -70,8 +70,6 @@ module_param(bss_entries_limit, int, 0644);
>  MODULE_PARM_DESC(bss_entries_limit,
>   "limit to number of scan BSS entries (per wiphy,
> default 1000)");
>  
> -#define IEEE80211_SCAN_RESULT_EXPIRE (30 * HZ)
> -
>  static void bss_free(struct cfg80211_internal_bss *bss)
>  {
>   struct cfg80211_bss_ies *ies;
> @@ -476,7 +474,7 @@ void cfg80211_bss_age(struct
> cfg80211_registered_device *rdev,
>  
>  void cfg80211_bss_expire(struct cfg80211_registered_device *rdev)
>  {
> - __cfg80211_bss_expire(rdev, jiffies -
> IEEE80211_SCAN_RESULT_EXPIRE);
> + __cfg80211_bss_expire(rdev, jiffies - rdev-
> >scan_result_expire);
>  }
>  
>  const u8 *cfg80211_find_ie_match(u8 eid, const u8 *ies, int len,
> @@ -737,7 +735,7 @@ struct cfg80211_bss *cfg80211_get_bss(struct
> wiphy *wiphy,
>   if (!is_valid_ether_addr(bss->pub.bssid))
>   continue;
>   /* Don't get expired BSS structs */
> - if (time_after(now, bss->ts +
> IEEE80211_SCAN_RESULT_EXPIRE) &&
> + if (time_after(now, bss->ts + rdev-
> >scan_result_expire) &&
>   !atomic_read(>hold))
>   continue;
>   if (is_bss(>pub, bssid, ssid, ssid_len)) {

Re: mwifiex won't connect to WPA2 anymore

[Dan Williams]

On Sat, 2017-05-06 at 22:22 +0200, Julien Cubizolles wrote:
> Dan Williams <d...@redhat.com> writes:
> 
> 
> > Ok, at this point the only thing I can think of is the MAC
> > randomization that NM has.  Please see:
> > 
> > https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-
> > networkmanager-1-4-0/
> > 
> > and look at the section "Randomization during Wi-Fi scanning" where
> > it
> > says:
> > 
> > 
> > This default behavior can be disabled with a global configuration
> > option in NetworkManager.conf:
> > 
> > [device]
> > wifi.scan-rand-mac-address=no
> > 
> > 
> > if you set that, and restart NetworkManager, does that magically
> > make
> > things work?
> 
> Yes! It's now working fine, thanks a lot. I have my wifi AP set to
> only
> accept a whitelist of MAC addresses so it makes sense that I can't
> connect if the MAC address is random. I'll disable the randomization
> for
> now on.

Well, ideally you wouldn't have to do this, but we haven't quite
figured out whether it's a bug in the way NM does randomization or
whether the drivers that require this switch (there are a few) are just
broken somehow.

Dan

Re: mwifiex won't connect to WPA2 anymore

[Dan Williams]

On Sat, 2017-05-06 at 10:41 +0200, Julien Cubizolles wrote:
> Dan Williams <d...@redhat.com> writes:
> 
> 
> > Just to test, could you add:
> > 
> > auth_alg=OPEN
> > key_mgmt=WPA-PSK
> > scan_ssid=1
> > 
> > to the block and retry with the supplicant?  I don't know why those
> > would make a difference but they might.
> 
> They don't: wpa_supplicant still connects with these settings.

Ok, at this point the only thing I can think of is the MAC
randomization that NM has.  Please see:

https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/

and look at the section "Randomization during Wi-Fi scanning" where it
says:


This default behavior can be disabled with a global configuration
option in NetworkManager.conf:

[device]
wifi.scan-rand-mac-address=no


if you set that, and restart NetworkManager, does that magically make
things work?

Dan

Re: mwifiex won't connect to WPA2 anymore

[Dan Williams]

On Thu, 2017-05-04 at 23:27 +0200, Julien Cubizolles wrote:
> Dan Williams <d...@redhat.com> writes:
> 
> > On Wed, 2017-05-03 at 22:33 +0200, Julien Cubizolles wrote:
> > > It turns out that the problem lies with NetworkManager, I managed
> > > to
> > > get
> > > the wifi working with wpa_supplicant.
> > 
> > That's odd.  Any idea what that was?  MAC randomization?  
> 
> I don't know if MAC randomization is supposed to be happen but
> ifconfig
> always display the same MAC address for the wifi interface. Also the
> same wifi router allows connections without secrets with another
> ssid,
> and I have no problem connecting in this case.
> 
> > NM just uses the supplicant underneath, so there's no particular
> > reason NM wouldn't work but wpa_supplicant itself would.
> 
> I'm using the following /etc/wpa_supplicant.conf file:
> 
> --8<---cut here---start->8---
> ctrl_interface=/var/run/wpa_supplicant
> ap_scan=1
> network={
>   priority=2
> ssid="beguiled"
> psk="*"

Just to test, could you add:

auth_alg=OPEN
key_mgmt=WPA-PSK
scan_ssid=1

to the block and retry with the supplicant?  I don't know why those
would make a difference but they might.

The reason code that is returned for the disconnect is unfortunately
WLAN_REASON_PREV_AUTH_NOT_VALID which doesn't tell us much.

Dan

> }
> 
> --8<---cut here---end--->8---
> 
> For the same ssid: NetworkManager uses the following
> /etc/NetworkManager/system-connections/beguiled
> 
> --8<---cut here---start->8---
> [connection]
> id=beguiled
> uuid=4ecc0776-046d-4f05-a324-19f5a8fe6853
> type=wifi
> permissions=
> secondaries=
> 
> [wifi]
> ssid=beguiled
> 
> [wifi-security]
> psk=**
> 
> [ipv4]
> dns-search=
> method=auto
> 
> [ipv6]
> addr-gen-mode=stable-privacy
> dns-search=
> method=auto
> --8<---cut here---end--->8---
> 
> Here are the logs when NM fails:
> --8<---cut here---start->8---
> 
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8411]
> device (wlx6045bdf646b4): set-hw-addr: set MAC address to
> E2:D4:E4:49:77:59 (scanning)
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8433]
> manager: NetworkManager state is now DISCONNECTED
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8435]
> device (wlx6045bdf646b4): Activation: starting connection 'beguiled'
> (406e52d4-e98b-454b-8d32-ce69fee5e03f)
> May  4 23:06:25 touco kernel: [   58.255775] IPv6:
> ADDRCONF(NETDEV_UP): wlx6045bdf646b4: link is not ready
> May  4 23:06:25 touco whoopsie[818]: [23:06:25] Cannot reach: https:/
> /daisy.ubuntu.com
> May  4 23:06:25 touco nm-dispatcher: req:2 'down' [wlx6045bdf646b4]:
> new request (2 scripts)
> May  4 23:06:25 touco nm-dispatcher: req:2 'down' [wlx6045bdf646b4]:
> start running ordered scripts...
> May  4 23:06:25 touco whoopsie[818]: [23:06:25] Cannot reach: https:/
> /daisy.ubuntu.com
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8711]
> sup-iface[0x5634f93244e0,wlx6045bdf646b4]: connection disconnected
> (reason -3)
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8712]
> device (wlx6045bdf646b4): supplicant interface state: completed ->
> disconnected
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8745]
> device (wlx6045bdf646b4): state change: disconnected -> prepare
> (reason 'none') [30 40 0]
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.8747]
> manager: NetworkManager state is now CONNECTING
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9016]
> device (wlx6045bdf646b4): set-hw-addr: set-cloned MAC address to
> 60:45:BD:F6:46:B4 (permanent)
> May  4 23:06:25 touco kernel: [   58.316182] IPv6:
> ADDRCONF(NETDEV_UP): wlx6045bdf646b4: link is not ready
> May  4 23:06:25 touco gsd-sharing[2450]: Failed to StopUnit service:
> GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit rygel.service
> not loaded.
> May  4 23:06:25 touco gsd-sharing[2450]: Failed to StopUnit service:
> GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit vino-
> server.service not loaded.
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9314]
> device (wlx6045bdf646b4): state change: prepare -> config (reason
> 'none') [40 50 0]
> May  4 23:06:25 touco NetworkManager[833]:   [1493931985.9322]
> device (wlx6045bdf646b4): Activation: (wifi) access point 'beguiled'
> has security, but secrets are required.
> May  4 23:06:25 touco NetworkManager[83

Re: How to use netlink to determine wifi protection WEP

[Dan Williams]

On Thu, 2017-04-06 at 16:27 +0200, Thomas Thielemann wrote:
> Thanks!
> 
> If the sequence is the following:
> 
>  1. Prepare and execute NL80211_CMD_TRIGGER_SCAN
>  2. Prepare and execute NL80211_CMD_GET_SCAN
>  Together with NL80211_CMD_GET_SCAN a callback is registered. 
>  In the callback the raw data are parsed as BSS. The IE's are parsed
> to.
> 
> When do I have to fetch the beacon to get the right beacon but
> without lost of the scan result?
> After I fetched all scan results or immediately after the receive of
> every scan result?

The scan results are essentially the beacons, so you just need to read
the GET_SCAN.  Then when parsing the "bss info" you get from the scan
results handler that you registered, you look for:

NL80211_BSS_CAPABILITY: the Privacy bit is in here
NL80211_BSS_INFORMATION_ELEMENTS: the IEs are obviously in here

Dan

> Regards,
> Thomas
> 
> 
> > Am 05.04.2017 um 19:24 schrieb Dan Williams <d...@redhat.com>:
> > 
> > On Wed, 2017-04-05 at 09:27 +0200, Thomas Thielemann wrote:
> > > Hello!
> > > 
> > > I need a solution to determine whether a WiFi is using WEP. I
> > > know
> > > there is a protection flag within MAC frame but do not know how
> > > to
> > > access.
> > > 
> > > To detect whether a WiFi i protected by WPA2 I found the
> > > following
> > > solution: 
> > > 
> > > Scan with
> > > 
> > > nl_sock* socket = nl_socket_alloc();
> > > genl_connect(socket);
> > > struct nl_msg* msg = nlmsg_alloc();
> > > int driverId = genl_ctrl_resolve(socket, "nl80211"); 
> > > genlmsg_put(msg, 0, 0, driverId, 0, 0, NL80211_CMD_TRIGGER_SCAN,
> > > 0);
> > > 
> > > and fetch with
> > > 
> > > genlmsg_put(msg, 0, 0, driverId, 0, NLM_F_DUMP,
> > > NL80211_CMD_GET_SCAN,
> > > 0);
> > > 
> > > Read the received structure using nl80211_bss::
> > > NL80211_BSS_INFORMATION_ELEMENTS from nl80211.h and
> > > 
> > > examine the field RSN(id=48) (see IEEE802.11-2012.pdf, chapter
> > > 8.4.2
> > > Information elements)
> > > 
> > > Which netlink command gives me the related data? Is it
> > > NL80211_CMD_GET_BEACON?
> > 
> > You want both the beacon (for the Privacy bit) and the information
> > elements.
> > 
> > If the privacy bit is set in beacon and there are no WPA/WPA2/RSN-
> > related information elements, then the AP is using
> > WEP.  Unfortunately
> > you don't know whether it's WEP-40 or WEP-104, but that's another
> > topic.
> > 
> > If the privacy bit is set, and there are WPA/WPA2/RSN information
> > elements, then the AP *might* be using WEP in compatibility
> > mode.  This
> > isn't very common though, so you can probably just ignore this
> > case.
> > 
> > Dan
> > 
> 
> 

Re: How to use netlink to determine wifi protection WEP

[Dan Williams]

On Wed, 2017-04-05 at 09:27 +0200, Thomas Thielemann wrote:
> Hello!
> 
> I need a solution to determine whether a WiFi is using WEP. I know
> there is a protection flag within MAC frame but do not know how to
> access.
> 
> To detect whether a WiFi i protected by WPA2 I found the following
> solution: 
> 
> Scan with
> 
> nl_sock* socket = nl_socket_alloc();
> genl_connect(socket);
> struct nl_msg* msg = nlmsg_alloc();
> int driverId = genl_ctrl_resolve(socket, "nl80211"); 
> genlmsg_put(msg, 0, 0, driverId, 0, 0, NL80211_CMD_TRIGGER_SCAN, 0);
> 
> and fetch with
> 
> genlmsg_put(msg, 0, 0, driverId, 0, NLM_F_DUMP, NL80211_CMD_GET_SCAN,
> 0);
> 
> Read the received structure using nl80211_bss::
> NL80211_BSS_INFORMATION_ELEMENTS from nl80211.h and
> 
> examine the field RSN(id=48) (see IEEE802.11-2012.pdf, chapter 8.4.2
> Information elements)
> 
> Which netlink command gives me the related data? Is it
> NL80211_CMD_GET_BEACON?

You want both the beacon (for the Privacy bit) and the information
elements.

If the privacy bit is set in beacon and there are no WPA/WPA2/RSN-
related information elements, then the AP is using WEP.  Unfortunately
you don't know whether it's WEP-40 or WEP-104, but that's another
topic.

If the privacy bit is set, and there are WPA/WPA2/RSN information
elements, then the AP *might* be using WEP in compatibility mode.  This
isn't very common though, so you can probably just ignore this case.

Dan

Re: Ralink - rt2800usb

[Dan Williams]

On Fri, 2017-03-17 at 13:26 -0700, Nikita N. wrote:
> Hi All,
> I'm addressing to the maintainers of Ralink driver rt2800usb
> (RT2870,RT3070).
> To who can I send my request?

This mailing list (linux-wireless@) is the right place.

Dan

Re: iwl3945 randomly crashes

[Dan Williams]

On Tue, 2016-12-20 at 18:11 +0100, Łukasz Walewski wrote:
> On Tue, 20 Dec 2016 10:49:52 -0600
> Dan Williams <d...@redhat.com> wrote:
> 
> > 
> > On Tue, 2016-12-20 at 17:24 +0100, Łukasz Walewski wrote:
> > > 
> > > Hi,
> > > 
> > > I am using the latest Lubuntu 16.10 with fairly recent kernel
> > > 
> > > ljw@hideo:~$ uname -a
> > > Linux hideo 4.8.0-30-generic #32-Ubuntu SMP Fri Dec 2 03:43:33
> > > UTC
> > > 2016 i686 i686 i686 GNU/Linux
> > > 
> > > on an old Toshiba laptop (Satellite Pro U200) equipped with an
> > > Intel
> > > PRO/Wireless 3945ABG adapter
> > > 
> > > ljw@hideo:~$ lspci | grep ireless
> > > 02:00.0 Network controller: Intel Corporation PRO/Wireless
> > > 3945ABG
> > > [Golan] Network Connection (rev 02)
> > > 
> > > The wireless network crashes once in a while with no apparent
> > > reason
> > > with the following log entries:
> > > 
> > > Dec 18 17:23:42 hideo kernel: [94900.863133] iwl3945
> > > :02:00.0:
> > > loaded firmware version 15.32.2.9
> > > Dec 18 17:23:42 hideo kernel: [94900.913626] iwl3945
> > > :02:00.0:
> > > BSM uCode verification failed at addr 0x3800+0 (of 900), is
> > > 0xa5a5a5a2, s/b 0xf802020
> > > Dec 18 17:23:42 hideo kernel: [94900.913633] iwl3945
> > > :02:00.0:
> > > Unable to set up bootstrap uCode: -5
> > > 
> > > This problem has been reported several times on different mailing
> > > lists and community portals all over the Internet, nevertheless I
> > > was
> > > not able to locate the right fix for it.
> > > 
> > > The workaround suggested elswhere (restarting the network-manager
> > > when the problem occurs) works with my setup.
> > 
> > Instead of restarting NM, you can "pkill -TERM wpa_supplicant" or
> > something, which will do the same thing but just bounce the wifi
> > rather
> > than everything.  Or 'rmmod iwl3945; modprobe iwl3945'.
> 
> Thanks, but that is just another workaround. I am interested in
> fixing the problem, i.e. getting the driver not to crash at all,
> rather than playing around with it crashing every now and then.

Yeah, I know.  Just pointing out that people often use a huge hammer,
when a much smaller hammer will do.

Dan

Re: [PATCH v2] cfg80211: add set/get link loss profile

[Dan Williams]

On Mon, 2016-12-19 at 12:58 +0200, Lazar, Alexei Avshalom wrote:
> From 7e41d45179a8762a7d2e1653db35751c19c8c747 Mon Sep 17 00:00:00
> 2001
> From: Alexei Avshalom Lazar 
> Date: Sun, 18 Dec 2016 15:06:38 +0200
> Subject: [PATCH] cfg80211: add set/get link loss profile
> 
> Introduce NL80211_CMD_SET_LINK_LOSS_PROFILE and
> NL80211_CMD_GET_LINK_LOSS_PROFILE needed by user space to configure
> the
> link loss profile.
> The link loss profile represents the priority of maintaining link up
> (connection to AP) in different link quality environments.
> This is intended for full mac80211 drivers. Typically link loss
> detection
> is offloaded to firmware, since it requires close monitoring of the
> RF.
> The firmware will disconnect when link quality drops.
> There are scenarios that require to lose connection faster once
> reduced
> link quality is detected in order to maintain better user experience.
> This can be used in AP and station mode.
> Example use case is FST (Fast Session Transfer), where we have a fast
> 11ad connection but close-range and a backup 11ac connection which is
> "always on". In such cases if we detect poor link quality in the
> active
> 11ad band we prefer to disconnect and switch to the backup 11ac
> connection
> with the good link quality. This will be reached by setting
> "aggressive"
> profile that will cause more rapid disconnect in such cases.
> Three types of behavior for link loss are defined:
> LINK_LOSS_PROFILE_RELAXED: prefer maintaining link up even in a poor
> link quality environment.
> LINK_LOSS_PROFILE_DEFAULT: The default behavior for maintaining link
> up vs link quality.
> LINK_LOSS_PROFILE_AGGRESSIVE: prefer losing link up in a poor link
> quality environment.
> New cfg80211 API also been added, set/get_link_loss_profile.

Still need to address Kalle's comments requesting more detailed
explanation of these.  What do each of these actually mean?  What does
"poor link quality" mean?  Is it based on dBm, noise floor, SNR, etc?
 Is it a windowed average or something?  There's way too many details
left out here for userspace to reliably use this API, especially with
different drivers.

Also need to address Kalle's comment about what modes these are
relevant in, and what differences there are here between modes.

Dan

> Signed-off-by: Alexei Avshalom Lazar 
> ---
>  drivers/net/wireless/ath/wil6210/cfg80211.c | 18 
>  include/net/cfg80211.h  | 13 ++
>  include/uapi/linux/nl80211.h| 32 +
>  net/wireless/nl80211.c  | 70
> +
>  net/wireless/rdev-ops.h | 28 
>  net/wireless/trace.h| 39 
>  6 files changed, 200 insertions(+)
> 
> diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c
> b/drivers/net/wireless/ath/wil6210/cfg80211.c
> index 6aa3ff4..681b792 100644
> --- a/drivers/net/wireless/ath/wil6210/cfg80211.c
> +++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
> @@ -1499,6 +1499,22 @@ static int wil_cfg80211_set_power_mgmt(struct
> wiphy *wiphy,
>   return rc;
>  }
>  
> +static int
> +wil_cfg80211_set_link_loss_profile(struct wiphy *wiphy,
> +    struct wireless_dev *wdev,
> +    enum nl80211_link_loss_profile
> profile,
> +    const u8 *addr)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static enum nl80211_link_loss_profile
> +wil_cfg80211_get_link_loss_profile(struct wiphy *wiphy,
> +    struct wireless_dev *wdev, const
> u8 *addr)
> +{
> + return -ENOTSUPP;
> +}
> +
>  static struct cfg80211_ops wil_cfg80211_ops = {
>   .add_virtual_intf = wil_cfg80211_add_iface,
>   .del_virtual_intf = wil_cfg80211_del_iface,
> @@ -1528,6 +1544,8 @@ static struct cfg80211_ops wil_cfg80211_ops = {
>   .start_p2p_device = wil_cfg80211_start_p2p_device,
>   .stop_p2p_device = wil_cfg80211_stop_p2p_device,
>   .set_power_mgmt = wil_cfg80211_set_power_mgmt,
> + .set_link_loss_profile = wil_cfg80211_set_link_loss_profile,
> + .get_link_loss_profile = wil_cfg80211_get_link_loss_profile,
>  };
>  
>  static void wil_wiphy_init(struct wiphy *wiphy)
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index ca2ac1c..7c2e420 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2764,6 +2764,10 @@ struct cfg80211_nan_func {
>   *   All other parameters must be ignored.
>   *
>   * @set_multicast_to_unicast: configure multicast to unicast
> conversion for BSS
> + *
> + * @set_link_loss_profile: Set link loss profile for specific
> connection.
> + * @get_link_loss_profile: Get the current link loss profile of
> specific
> + *   connection.
>   */
>  struct cfg80211_ops {
>   int (*suspend)(struct wiphy *wiphy, struct
> cfg80211_wowlan *wow);
> @@ -3048,6 +3052,15 @@ struct cfg80211_ops {

Re: iwl3945 randomly crashes

[Dan Williams]

On Tue, 2016-12-20 at 17:24 +0100, Łukasz Walewski wrote:
> Hi,
> 
> I am using the latest Lubuntu 16.10 with fairly recent kernel
> 
> ljw@hideo:~$ uname -a
> Linux hideo 4.8.0-30-generic #32-Ubuntu SMP Fri Dec 2 03:43:33 UTC
> 2016 i686 i686 i686 GNU/Linux
> 
> on an old Toshiba laptop (Satellite Pro U200) equipped with an Intel
> PRO/Wireless 3945ABG adapter
> 
> ljw@hideo:~$ lspci | grep ireless
> 02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG
> [Golan] Network Connection (rev 02)
> 
> The wireless network crashes once in a while with no apparent reason
> with the following log entries:
> 
> Dec 18 17:23:42 hideo kernel: [94900.863133] iwl3945 :02:00.0:
> loaded firmware version 15.32.2.9
> Dec 18 17:23:42 hideo kernel: [94900.913626] iwl3945 :02:00.0:
> BSM uCode verification failed at addr 0x3800+0 (of 900), is
> 0xa5a5a5a2, s/b 0xf802020
> Dec 18 17:23:42 hideo kernel: [94900.913633] iwl3945 :02:00.0:
> Unable to set up bootstrap uCode: -5
> 
> This problem has been reported several times on different mailing
> lists and community portals all over the Internet, nevertheless I was
> not able to locate the right fix for it.
> 
> The workaround suggested elswhere (restarting the network-manager
> when the problem occurs) works with my setup.

Instead of restarting NM, you can "pkill -TERM wpa_supplicant" or
something, which will do the same thing but just bounce the wifi rather
than everything.  Or 'rmmod iwl3945; modprobe iwl3945'.

Dan

> Could you please suggest the solution to the problem? Alternatively,
> where should I file the bug to get it fixed?
> 
> Thank you very much in advance,
> Lukasz Walewski
> 

Re: [RFC V3 03/11] nl80211: add support for gscan

[Dan Williams]

On Mon, 2016-12-12 at 11:59 +, Arend van Spriel wrote:
> This patch adds support for GScan which is a scan offload feature
> used in Android.
> 
> Reviewed-by: Hante Meuleman 
> Reviewed-by: Pieter-Paul Giesberts  m>
> Reviewed-by: Franky Lin 
> Signed-off-by: Arend van Spriel 
> ---
> Changes:
>  V2
>   - remove pr_err() statement from nl80211.c
>   - get rid of #if 0 code.
>  V3
>   - change and document storage type of gscan attributes.
>   - remove base period attribute from nl80211.
>   - bucket periods are changed to be seconds.
>   - change NO_IR attribute to PASSIVE.
>   - check for NL80211_ATTR_MAC{,_MASK} if random mac support is
> requested.
>   - remove NL80211_SCAN_FLAG_IE_DATA.
> ---
>  include/net/cfg80211.h   |  91 +++
>  include/uapi/linux/nl80211.h | 146 ++
>  net/wireless/core.c  |  31 
>  net/wireless/core.h  |   4 +
>  net/wireless/nl80211.c   | 356
> ++-
>  net/wireless/rdev-ops.h  |  25 +++
>  net/wireless/scan.c  |  28 
>  net/wireless/trace.h |   9 ++
>  8 files changed, 685 insertions(+), 5 deletions(-)
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index b78377f..8bc8842 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2453,6 +2453,92 @@ struct cfg80211_nan_func {
>  };
> 
>  /**
> + * struct cfg80211_gscan_channel - GScan channel parameters.
> + *
> +
> + * @ch: specific channel.
> + * @dwell_time: hint for dwell time in milliseconds.
> + * @passive: indicates passive scan is requested.
> + */
> +struct cfg80211_gscan_channel {
> +struct ieee80211_channel *ch;
> +u8 dwell_time;
> +bool passive;
> +};
> +
> +/**
> + * struct cfg80211_gscan_bucket - GScan bucket parameters.
> + *
> + * @idx: unique bucket index.
> + * @band: bit flags for band(s) to use, see %enum
> nl80211_bucket_band.
> + * @report_events: This is a bit field according %enum
> nl80211_bucket_report_event.
> + * @period: period in which the bucket is scheduled to be scanned.
> If the
> + *   period is too small for driver it should not fail but
> report results
> + *   as fast as it can. For exponential backoff bucket this is
> the minimum
> + *   period.
> + * @max_period: used only for the exponential backoff bucket whose
> scan period
> + *   will grow exponentially to a maximum period of max_period.
> + * @exponent: used only for the exponential backoff bucket.
> + * @step_count: used only for the exponential backoff bucket.
> + * @n_channels: number of channels in @channels array.
> + * @channels: channels to scan which may include DFS channels.
> + */
> +struct cfg80211_gscan_bucket {
> + u32 idx;
> + u16 period;
> + u8 band;
> + u8 report_events;
> + u16 max_period;
> + u8 exponent;
> + u8 step_count;
> + u8 n_channels;
> + struct cfg80211_gscan_channel *channels;
> +};
> +
> +/**
> + * struct cfg80211_gscan_request - GScan request parameters.
> + *
> + * @flags: scan request flags according %enum nl80211_scan_flags.
> + * @base_period: base timer period in milliseconds.
> + * @max_ap_per_scan: number of APs to store in each scan entry in
> the BSSID/RSSI
> + *   history buffer (keep APS with highest RSSI).
> + * @report_threshold_percent: wake up system when scan buffer is
> filled to this
> + *   percentage.
> + * @report_threshold_num_scans: wake up system when this many scans
> are stored
> + *   in scan buffer.
> + * @mac: MAC address used for randomisation.
> + * @mac_mask: MAC address mask. bits that are 0 in the mask should
> be
> + *   randomised, bits that are 1 should be taken as is from
> @mac.
> + * @n_buckets: number of entries in @buckets array.
> + * @buckets: array of GScan buckets.
> + *
> + * @dev: net device for which GScan is requested.
> + * @rcu_head: RCU callback used to free the struct.
> + * @owner_nlportid: netlink port which initiated this request.
> + * @scan_start: start time of this scan in jiffies.
> + */
> +struct cfg80211_gscan_request {
> + u32 flags;
> + u16 base_period;
> + u8 max_ap_per_scan;
> + u8 report_threshold_percent;
> + u8 report_threshold_num_scans;
> + u8 mac[ETH_ALEN];
> + u8 mac_mask[ETH_ALEN];
> +
> + u8 n_buckets;
> +
> + /* internal */
> + struct net_device *dev;
> + struct rcu_head rcu_head;
> + u32 owner_nlportid;
> + unsigned long scan_start;
> +
> + /* keep last */
> + struct cfg80211_gscan_bucket buckets[0];
> +};
> +
> +/**
>   * struct cfg80211_ops - backend description for wireless
> configuration
>   *
>   * This struct is registered by fullmac card drivers and/or wireless
> stacks
> @@ -2764,6 +2850,8 @@ struct cfg80211_nan_func {
>   *   All other parameters must be ignored.
>   *
>   * @set_multicast_to_unicast: configure multicast to unicast
> 

Re: [PATCH 1/5] nl80211: allow reporting RTT information in scan results

[Dan Williams]

On Thu, 2016-11-17 at 11:39 +, Arend van Spriel wrote:
> Add distance and its variance to the BSS structure so drivers
> may provide RTT information for BSS instances found during
> scanning.
> 
> Reviewed-by: Hante Meuleman 
> Reviewed-by: Pieter-Paul Giesberts  m>
> Reviewed-by: Franky Lin 
> Signed-off-by: Arend van Spriel 
> ---
>  include/net/cfg80211.h   | 11 +++
>  include/uapi/linux/nl80211.h |  6 ++
>  net/wireless/nl80211.c   |  8 
>  net/wireless/scan.c  |  2 ++
>  4 files changed, 27 insertions(+)
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 2019310..d1217da 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1675,6 +1675,9 @@ enum cfg80211_signal_type {
>   * @scan_width: scan width that was used
>   * @signal: signal strength value, according to the wiphy's
>   *   signal type
> + * @distance: distance to AP with %parent_bssid in centimeters. Zero
> + *   value indicates this is undetermined.
> + * @var_distance: variance of %distance indicating accurracy.

"accuracy" without the second 'r'.

Also, what unit is the variance in?  Needs more documentation.

Dan

>   * @boottime_ns: timestamp (CLOCK_BOOTTIME) when the information was
>   *   received; should match the time when the frame was
> actually
>   *   received by the device (not just by the host, in case it
> was
> @@ -1691,6 +1694,8 @@ struct cfg80211_inform_bss {
>   struct ieee80211_channel *chan;
>   enum nl80211_bss_scan_width scan_width;
>   s32 signal;
> + u32 distance;
> + u32 var_distance;
>   u64 boottime_ns;
>   u64 parent_tsf;
>   u8 parent_bssid[ETH_ALEN] __aligned(2);
> @@ -1737,6 +1742,9 @@ struct cfg80211_bss_ies {
>   *   that holds the beacon data. @beacon_ies is still valid, of
> course, and
>   *   points to the same data as hidden_beacon_bss->beacon_ies
> in that case.
>   * @signal: signal strength value (type depends on the wiphy's
> signal_type)
> + * @distance: distance to AP with %parent_bssid in centimeters. Zero
> + *   value indicates this is undetermined.
> + * @var_distance: variance of %distance indicating accurracy.
>   * @priv: private area for driver use, has at least wiphy-
> >bss_priv_size bytes
>   */
>  struct cfg80211_bss {
> @@ -1756,6 +1764,9 @@ struct cfg80211_bss {
>  
>   u8 bssid[ETH_ALEN];
>  
> + u32 distance;
> + u32 var_distance;
> +
>   u8 priv[0] __aligned(sizeof(void *));
>  };
>  
> diff --git a/include/uapi/linux/nl80211.h
> b/include/uapi/linux/nl80211.h
> index 259c9c7..7e935f6 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -3651,6 +3651,10 @@ enum nl80211_bss_scan_width {
>   *   @NL80211_BSS_PARENT_BSSID. (u64).
>   * @NL80211_BSS_PARENT_BSSID: the BSS according to which
> @NL80211_BSS_PARENT_TSF
>   *   is set.
> + * @NL80211_BSS_DISTANCE: distance to AP with
> @NL80211_BSS_PARENT_BSSID in
> + *   centimeters (u32).
> + * @NL80211_BSS_VARIANCE_DISTANCE: variance of @NL80211_BSS_DISTANCE
> value (u32).
> + *
>   * @__NL80211_BSS_AFTER_LAST: internal
>   * @NL80211_BSS_MAX: highest BSS attribute
>   */
> @@ -3674,6 +3678,8 @@ enum nl80211_bss {
>   NL80211_BSS_PAD,
>   NL80211_BSS_PARENT_TSF,
>   NL80211_BSS_PARENT_BSSID,
> + NL80211_BSS_DISTANCE,
> + NL80211_BSS_VARIANCE_DISTANCE,
>  
>   /* keep last */
>   __NL80211_BSS_AFTER_LAST,
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 24ab199..ffce566 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -7515,6 +7515,14 @@ static int nl80211_send_bss(struct sk_buff
> *msg, struct netlink_callback *cb,
>     intbss->ts_boottime, NL80211_BSS_PAD))
>   goto nla_put_failure;
>  
> + if (res->distance && nla_put_u32(msg, NL80211_BSS_DISTANCE,
> +  res->distance))
> + goto nla_put_failure;
> +
> + if (res->var_distance && nla_put_u32(msg,
> NL80211_BSS_VARIANCE_DISTANCE,
> +  res->var_distance))
> + goto nla_put_failure;
> +
>   switch (rdev->wiphy.signal_type) {
>   case CFG80211_SIGNAL_TYPE_MBM:
>   if (nla_put_u32(msg, NL80211_BSS_SIGNAL_MBM, res-
> >signal))
> diff --git a/net/wireless/scan.c b/net/wireless/scan.c
> index b5bd58d..afda1f9 100644
> --- a/net/wireless/scan.c
> +++ b/net/wireless/scan.c
> @@ -973,6 +973,8 @@ struct cfg80211_bss *
>   tmp.pub.signal = data->signal;
>   tmp.pub.beacon_interval = beacon_interval;
>   tmp.pub.capability = capability;
> + tmp.pub.distance = data->distance;
> + tmp.pub.var_distance = data->var_distance;
>   tmp.ts_boottime = data->boottime_ns;
>  
>   /*

Re: [PATCH] brcmfmac: implement more accurate skb tracking

[Dan Williams]

On Mon, 2016-09-26 at 14:13 +0200, Rafał Miłecki wrote:
> On 26 September 2016 at 13:46, Arend Van Spriel
>  wrote:
> > 
> > On 26-9-2016 12:23, Rafał Miłecki wrote:
> > > 
> > > From: Rafał Miłecki 
> > > 
> > > We need to track 802.1x packets to know if there are any pending
> > > ones
> > > for transmission. This is required for performing key update in
> > > the
> > > firmware.
> > 
> > The problem we are trying to solve is a pretty old one. The problem
> > is
> > that wpa_supplicant uses two separate code paths: EAPOL messaging
> > through data path and key configuration though nl80211.
> 
> Can I find it described/reported somewhere?

If I understand the issue correctly, you can find all this in the
supplicant code.  Once the supplicant has done whatever it wants to do
with the data frames that just happen to be EAPOL it then sends the
keys down to the driver with nl80211.

But it sounds like, instead of sniffing EAPOL frames in the driver skb
tracking and sniffing ETH_P_PAE, you should probably implement support
for NL80211_CMD_CRIT_PROTOCOL_START/NL80211_CMD_CRIT_PROTOCOL_STOP and
key off the passed-in NL80211_CRIT_PROTO_EAPOL.  At least at the
beginning of connection setup only EAPOL packets will be allowed
anyway.

It doesn't seem like the supplicant uses NL80211_CRIT_PROTO_EAPOL yet,
but that should also be fixed in the supplicant itself.  You should
probably get some comments from Jouni on how he'd like to see all this
work.  But generally the less specific sniffing of frames in drivers,
likely the better.

Dan

> 
> > 
> > > 
> > > Unfortunately our old tracking code wasn't very accurate. It was
> > > treating skb as pending as soon as it was passed by the netif.
> > > Actual
> > > handling packet to the firmware was happening later as brcmfmac
> > > internally queues them and uses its own worker(s).
> > 
> > That does not seem right. As soon as we get a 1x packet we need to
> > wait
> > with key configuration regardless whether it is still in the driver
> > or
> > handed over to firmware already.
> 
> OK, thanks.

Re: brcmfmac MAC address change delay and 500ms down delay

[Dan Williams]

On Fri, 2016-09-16 at 11:58 +0200, Arend Van Spriel wrote:
> On 15-9-2016 16:42, Dan Williams wrote:
> > 
> > Hi,
> > 
> > While refining NetworkManager's MAC address randomization behavior
> > we
> > came across two issues with brcmfmac:
> > 
> > 1) when changing the MAC address, the driver schedules work for the
> > new
> > change and returns success, but doesn't actually change the MAC
> > until
> > the work is scheduled.  Because it returns 0 from the
> > ndo_set_mac_address hook the net core will generate a
> > NETDEV_CHANGEADDR
> > event and rtnetlink will send out an RTM_NEWLINK with the old MAC
> > address.  No event for the new address will be sent.  So it's
> > pretty
> > hard to figure out when the address actually changed, and when its
> > safe
> > to associate, without polling the device's MAC address.  Ugly.
> And apparently unnecessary. I recalled we had this as the
> ndo_set_mac_address callback could be called in atomic context. So we
> are using a worker because we are grabbing a mutex upon sending the
> control info to the device. Looking into the core network code it
> seems
> the callback is not called in atomic context so it seems we can get
> rid
> of the worker here. I made a patch
> 
> > 
> > 2) when closing the device (eg, set !IFF_UP) the driver
> > unconditionally
> > blocks for 500ms in __brcmf_cfg80211_down():
> > 
> > if (check_vif_up(ifp->vif)) {
> > brcmf_link_down(ifp->vif, WLAN_REASON_UNSPECIFIED);
> > 
> > /* Make sure WPA_Supplicant receives all the event
> >    generated due to DISASSOC call to the fw to keep
> >    the state fw and WPA_Supplicant state consistent
> >  */
> > brcmf_delay(500);
> > }
> This is actually a bogus delay as we are under an RTNL lock here so I
> think the events will not go out until after the delay has finished.
> I
> did submit a patch long ago removing this delay, but the change was
> not
> accepted. Let me revisit that.
> 
> > 
> > Should I dump these into kernel bugzilla, or is there some internal
> > bug
> > tracker they could get stuffed into?
> Kernel bugzilla is fine although I check it rather infrequently.

Thanks for taking another look at these.  Should I still file in
bugzilla, or are the patches going through the process already?

Dan

brcmfmac MAC address change delay and 500ms down delay

[Dan Williams]

Hi,

While refining NetworkManager's MAC address randomization behavior we
came across two issues with brcmfmac:

1) when changing the MAC address, the driver schedules work for the new
change and returns success, but doesn't actually change the MAC until
the work is scheduled.  Because it returns 0 from the
ndo_set_mac_address hook the net core will generate a NETDEV_CHANGEADDR
event and rtnetlink will send out an RTM_NEWLINK with the old MAC
address.  No event for the new address will be sent.  So it's pretty
hard to figure out when the address actually changed, and when its safe
to associate, without polling the device's MAC address.  Ugly.

2) when closing the device (eg, set !IFF_UP) the driver unconditionally
blocks for 500ms in __brcmf_cfg80211_down():

if (check_vif_up(ifp->vif)) {
brcmf_link_down(ifp->vif, WLAN_REASON_UNSPECIFIED);

/* Make sure WPA_Supplicant receives all the event
   generated due to DISASSOC call to the fw to keep
   the state fw and WPA_Supplicant state consistent
 */
brcmf_delay(500);
}

Should I dump these into kernel bugzilla, or is there some internal bug
tracker they could get stuffed into?

Thanks!
Dan

Re: [RFC v0 3/8] firmware: Factor out firmware load helpers

[Dan Williams]

On Thu, 2016-07-28 at 09:55 +0200, Daniel Wagner wrote:
> From: Daniel Wagner 
> 
> Factor out the firmware loading synchronization code in order to
> allow
> drivers to reuse it. This also documents more clearly what is
> happening. This is especial useful the drivers which will be
> converted
> afterwards. Not everyone has to come with yet another way to handle
> it.

It's somewhat odd to me that the structure is "firmware_stat" but most
of the functions are "fw_loading_*".  That seems inconsistent for a
structure that is (currently) only used by these functions.

I would personally do either:

a) "struct fw_load_status" and "fw_load_*()"

or

b) "struct firmware_load_stat" and "firmware_load_*()"

I'd also change the function names from "loading" -> "load", similar to
how userland has read(2), not reading(2).

Dan

> We use swait instead completion. complete() would only wake up one
> waiter, so complete_all() is used. complete_all() wakes max
> MAX_UINT/2
> waiters which is plenty in all cases. Though withh swait we just wait
> until the exptected status shows up and wake any waiter.
> 
> Signed-off-by: Daniel Wagner 
> ---
>  drivers/base/firmware_class.c | 112 +++-
> --
>  include/linux/firmware.h  |  71 ++
>  2 files changed, 122 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/base/firmware_class.c
> b/drivers/base/firmware_class.c
> index 773fc30..bf1ca70 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -85,11 +86,36 @@ static inline bool fw_is_builtin_firmware(const
> struct firmware *fw)
>  }
>  #endif
>  
> -enum {
> - FW_STATUS_LOADING,
> - FW_STATUS_DONE,
> - FW_STATUS_ABORT,
> -};
> +
> +#if defined(CONFIG_FW_LOADER) || (defined(CONFIG_FW_LOADER_MODULE)
> && defined(MODULE))
> +
> +static inline bool is_fw_sync_done(unsigned long status)
> +{
> + return status == FW_STATUS_LOADED || status ==
> FW_STATUS_ABORT;
> +}
> +
> +int __firmware_stat_wait(struct firmware_stat *fwst,
> + long timeout)
> +{
> + int err;
> + err = swait_event_interruptible_timeout(fwst->wq,
> + is_fw_sync_done(READ_ONCE(fwst-
> >status)),
> + timeout);
> + if (err == 0 && fwst->status == FW_STATUS_ABORT)
> + return -ENOENT;
> +
> + return err;
> +}
> +EXPORT_SYMBOL(__firmware_stat_wait);
> +
> +void __firmware_stat_set(struct firmware_stat *fwst, unsigned long
> status)
> +{
> + WRITE_ONCE(fwst->status, status);
> + swake_up(>wq);
> +}
> +EXPORT_SYMBOL(__firmware_stat_set);
> +
> +#endif
>  
>  static int loading_timeout = 60; /* In seconds */
>  
> @@ -138,9 +164,8 @@ struct firmware_cache {
>  struct firmware_buf {
>   struct kref ref;
>   struct list_head list;
> - struct completion completion;
> + struct firmware_stat fwst;
>   struct firmware_cache *fwc;
> - unsigned long status;
>   void *data;
>   size_t size;
>  #ifdef CONFIG_FW_LOADER_USER_HELPER
> @@ -194,7 +219,7 @@ static struct firmware_buf
> *__allocate_fw_buf(const char *fw_name,
>  
>   kref_init(>ref);
>   buf->fwc = fwc;
> - init_completion(>completion);
> + firmware_stat_init(>fwst);
>  #ifdef CONFIG_FW_LOADER_USER_HELPER
>   INIT_LIST_HEAD(>pending_list);
>  #endif
> @@ -292,15 +317,6 @@ static const char * const fw_path[] = {
>  module_param_string(path, fw_path_para, sizeof(fw_path_para), 0644);
>  MODULE_PARM_DESC(path, "customized firmware image search path with a
> higher priority than default path");
>  
> -static void fw_finish_direct_load(struct device *device,
> -   struct firmware_buf *buf)
> -{
> - mutex_lock(_lock);
> - set_bit(FW_STATUS_DONE, >status);
> - complete_all(>completion);
> - mutex_unlock(_lock);
> -}
> -
>  static int fw_get_filesystem_firmware(struct device *device,
>      struct firmware_buf *buf)
>  {
> @@ -339,7 +355,7 @@ static int fw_get_filesystem_firmware(struct
> device *device,
>   }
>   dev_dbg(device, "direct-loading %s\n", buf->fw_id);
>   buf->size = size;
> - fw_finish_direct_load(device, buf);
> + fw_loading_done(buf->fwst);
>   break;
>   }
>   __putname(path);
> @@ -457,12 +473,11 @@ static void __fw_load_abort(struct firmware_buf
> *buf)
>    * There is a small window in which user can write to
> 'loading'
>    * between loading done and disappearance of 'loading'
>    */
> - if (test_bit(FW_STATUS_DONE, >status))
> + if (is_fw_loading_done(buf->fwst))
>   return;
>  
>   list_del_init(>pending_list);
> - set_bit(FW_STATUS_ABORT, >status);
> - 

Re: Problem connecting to wifi on libertas_cpio (sd8686)

[Dan Williams]

> > > sometimes reports the following:
> > > > > 
> > > > > country 98: DFS-UNSET
> > > > > (2402 - 2472 @ 40), (N/A, 20), (N/A)
> > > > > (2457 - 2472 @ 15), (N/A, 20), (N/A), NO-IR
> > > > > (5170 - 5250 @ 80), (N/A, 17), (N/A), NO-IR
> > > > > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, NO-IR
> > > > > (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
> > > > > (5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
> > > > > (57240 - 63720 @ 2160), (N/A, 0), (N/A)
> > > > > 
> > > > > At best this is simply an annoyance but at worst I’m thinking
> > > > > this may be responsible for the issues I’m seeing.
> > > > > 
> > > > > Is there anywhere else I can force this to be set to GB?
> > > > > 
> > > > > Christopher Williamson
> > > > > 
> > > > > 
> > > > > On 22 July 2016 at 17:54:40, Christopher Williamson (home@chr
> > > > > isaw.com(mailto:h...@chrisaw.com)) wrote:
> > > > > 
> > > > > > 
> > > > > > Disregard - I have actually managed to get this to connect
> > > > > > to a open network!
> > > > > > 
> > > > > > # iw reg set GB
> > > > > > # iw reg get
> > > > > > country GB: DFS-ETSI
> > > > > > (2402 - 2482 @ 40), (N/A, 20), (N/A)
> > > > > > (5170 - 5250 @ 80), (N/A, 20), (N/A)
> > > > > > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS
> > > > > > (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
> > > > > > (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> > > > > > # iwconfig wlan0 essid "shaunthesheep-guest”
> > > > > > # dhclient wlan0
> > > > > > 
> > > > > > It’s good to have some progress - so it looks like the
> > > > > > issue preventing the previous connection was the iw reg not
> > > > > > being set properly (or possibly just wpa_supplicant borking
> > > > > > the connection in some way. I stopped that this time
> > > > > > around. I’ll try wpa1 now and report back.
> > > > > > 
> > > > > > 
> > > > > > Christopher Williamson
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 22 July 2016 at 17:39:50, Christopher Williamson (home@c
> > > > > > hrisaw.com(mailto:h...@chrisaw.com)) wrote:
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Ok so I created a guest wifi network without any
> > > > > > > encryption enabled at all and the client still refuses to
> > > > > > > connect.
> > > > > > > 
> > > > > > > Again, the connection is made perfectly using the USB
> > > > > > > dongle I have but not the built in libertas sd8686
> > > > > > > chipset.
> > > > > > > 
> > > > > > > I do currently use pfSense as a firewall box behind my
> > > > > > > wireless router (acting as an AP) and can see that no
> > > > > > > DHCP request is making it to the pfSense box. I believe
> > > > > > > you are right in the point about the firmware being the
> > > > > > > problem here.
> > > > > > > 
> > > > > > > I should also confirm - the firmware in use is the latest
> > > > > > > from the linux-firmware Ubuntu 16.04 package. I did read
> > > > > > > around the net about being having various issues with
> > > > > > > various firmware sources and not others but despite
> > > > > > > trying firmware linked directly from Marvell I seem to
> > > > > > > always get one of two issues:
> > > > > > > 
> > > > > > > 1.) I am unable to connect and keep getting asked for
> > > > > > > passphrases, or:
> > > > > > > 2.) The system completely freezes up (with the v8
> > > > > > > firmwares I tried)
> > > > > > > 
> > > > > > > I’m not really sure what else to try at this point.
> > > > > > > Christopher Williamson
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 22 July 2016 at 17:24:52, Christopher Williamson (home
> > > > > > > @chrisaw.com(mailto:h...@chrisaw.com)) wrote:
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hi Dan,
> > > > > > > > 
> > > > > > > > I will check out the WPA2 vs WPA vs open wireless thing
> > > > > > > > in a few mins.
> > > > > > > > 
> > > > > > > > For now though - the iwlist scan results for both a USB
> > > > > > > > device and the
> > > > > > > > libertas device:
> > > > > > > > 
> > > > > > > > USB: http://termbin.com/hdwl
> > > > > > > > Libertas: http://termbin.com/jxh7
> > > > > > > > 
> > > > > > > > Will follow up shortly with WPA and Open network
> > > > > > > > configs.
> > > > > > > > 
> > > > > > > > Christopher Williamson
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 22 July 2016 at 17:16:29, Dan Williams (dcbw@redhat.
> > > > > > > > com(mailto:d...@redhat.com)) wrote:
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Hi Dan,
> > > > > > > > > 
> > > > > > > > > I will check out the WPA2 vs WPA vs open wireless
> > > > > > > > > thing in a few mins.
> > > > > > > > > 
> > > > > > > > > For now though - the iwlist scan results for both a
> > > > > > > > > USB device and the
> > > > > > > > > libertas device:
> > > > > > > > > 
> > > > > > > > > USB: http://termbin.com/hdwl
> > > > > > > > > Libertas: http://termbin.com/jxh7
> > > > > > > > > 
> > > > > > > > > Will follow up shortly with WPA and Open network
> > > > > > > > > configs.
> > > > > > > > > 
> > > > > > > > > *Christopher Williamson*
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem connecting to wifi on libertas_cpio (sd8686)

[Dan Williams]

On Fri, 2016-07-22 at 01:48 -0700, Christopher Williamson wrote:
> Looking through the log lines I see gaps between what WPA is doing
> and what
> dmesg reports and figured this is because of the libertas debugging
> level
> so I’ve set that to 0xfff (for libertas) and created a combined
> log of
> the events from both sources labelled with either [wpa] or [dmesg]
> and
> timestamped which should help to give a much clearer combined
> picture:
> 
> http://termbin.com/sjqn
> 
> I’ll have a look through and see if anything jumps out at me but I
> wanted
> to send it out to get expert eyes on it.

Thanks.

The ASSOC command looks OK, but do you have 'iw scan' output for
shaunthesheep from a different card?  Just to make sure that the
passed-in rates and RSN IE is correct.

The ASSOC command completes .5 seconds after it's sent, and the
firmware returns a result that means "association response timeout".
 According to the API docs it doesn't look like this status code (1)
comes from the AP, but from the firmware.

I'm afraid at this point we'd need a second machine to listen on the
channel and see if we can get the exchange between the marvell device
and the AP.

Can you test the device with a WPA-only AP, ie one that's not WPA2/RSN?
 Does it work with an open AP?

Dan


> As a side note - I really appreciate all of the help on this so far -
> there’s a beer in it for all involved! :P
> 
> Christopher Williamson
> 
> 
> 
> On 22 July 2016 at 09:21:44, Christopher Williamson
> (h...@chrisaw.com(mailto:h...@chrisaw.com)) wrote:
> 
> > 
> > 
> > I was thinking about redirecting the wpa logging to syslog but
> > figured I’d take the lazy way out by abusing curl:
> > 
> > curl -s http://termbin.com/cx0e http://termbin.com/bvdj | sort
> > 
> > Resulting combined log file:
> > http://termbin.com/909y
> > 
> > Christopher Williamson
> > 
> > 
> > On 22 July 2016 at 09:09:59, Arend Van Spriel (arend.vanspriel@broa
> > dcom.com(mailto:arend.vanspr...@broadcom.com)) wrote:
> > 
> > > 
> > > On 22-7-2016 0:00, Christopher Williamson wrote:
> > > > 
> > > > I’ve created cleaner logs (particularly the dmesg one) and have
> > > > added
> > > > timestamps line-by-line to both so it should be easier to track
> > > > between the two log files:
> > > > 
> > > > wpa_supplicant:
> > > > http://termbin.com/cx0e
> > > > 
> > > > dmesg | grep libertas:
> > > > http://termbin.com/bvdj
> > > You can make wpa_supplicant log to syslog. That way you get
> > > kernel and
> > > wpa_supplicant log in one file.
> > > 
> > > Regards,
> > > Arend
> > > 
> > > > 
> > > > Christopher Williamson
> > > > 
> > > > 
> > > > 
> > > > 
> > > > On 21 July 2016 at 22:00:02, Christopher Williamson
> > > > (h...@chrisaw.com(mailto:h...@chrisaw.com)) wrote:
> > > > 
> > > > > 
> > > > > Sure!
> > > > > 
> > > > > wpa_supplicant logs:
> > > > > http://termbin.com/z1hg
> > > > > 
> > > > > dmesg logs (grepped for libertas):
> > > > > http://termbin.com/7rt5
> > > > > 
> > > > > 
> > > > > Christopher Williamson
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > On 21 July 2016 at 21:38:26, Dan Williams (d...@redhat.com(ma
> > > > > ilto:d...@redhat.com)) wrote:
> > > > > 
> > > > > > 
> > > > > > On Thu, 2016-07-21 at 11:55 -0700, Christopher Williamson
> > > > > > wrote:
> > > > > > > 
> > > > > > > Just to confirm - I can connect to the same network using
> > > > > > > the same
> > > > > > > configurations using a USB wifi adapter I tried.
> > > > > > Can you grab simultaneous driver debug logging and
> > > > > > supplicant debug
> > > > > > logging? Unfortunately the 'status 1' is an unspecified
> > > > > > failure, which
> > > > > > could be from the AP or the firmware.
> > > > > > 
> > > > > > Dan
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > Unfortunately it’s not ideal since the point of the

Re: Problem connecting to wifi on libertas_cpio (sd8686)

[Dan Williams]

On Thu, 2016-07-21 at 11:55 -0700, Christopher Williamson wrote:
> Just to confirm - I can connect to the same network using the same
> configurations using a USB wifi adapter I tried.

Can you grab simultaneous driver debug logging and supplicant debug
logging?  Unfortunately the 'status 1' is an unspecified failure, which
could be from the AP or the firmware.

Dan


> Unfortunately it’s not ideal since the point of the Viliv N5 is that
> it’s ultra portable so I would really like to get the inbuilt wifi
> card working.
> 
> It seems odd that wpa_supplicant reports the connection being
> “rejected” as seen below:
> 
> wlan0: CTRL-EVENT-ASSOC-REJECT bssid=a0:63:91:1e:ee:43 status_code=1
> 
> Most of the debug output sadly doesn’t mean a great deal to me - wifi
> isn’t really my area of expertise.
> 
> On 21 July 2016 at 19:10:56, Christopher Williamson
> (h...@chrisaw.com(mailto:h...@chrisaw.com)) wrote:
> 
> > 
> > 
> > Sure, here are the results:
> > 
> > http://termbin.com/e8e2
> > 
> > Christopher Williamson
> > 
> > 
> > On 21 July 2016 at 16:37:24, Dan Williams (d...@redhat.com(mailto:d
> > c...@redhat.com)) wrote:
> > 
> > > 
> > > On Wed, 2016-07-20 at 15:16 -0700, Christopher Williamson wrote:
> > > > 
> > > > I used NetworkManager in the previous test.
> > > > 
> > > > This time around I have used wpa_supplicant directly and get
> > > > the
> > > > following results:
> > > > 
> > > > http://termbin.com/j8ea
> > > > 
> > > > Thought I’d throw them on a pastebin since it’s over 700 lines.
> > > Can you try with "-D nl80211" instead of using the WEXT
> > > supplicant
> > > driver? NM is likely going to use nl80211 since the driver has
> > > some
> > > support for cfg80211/nl80211 and only does WEXT through the glue
> > > layer.
> > > 
> > > Dan
> > > 
> > > > 
> > > > Christopher Williamson
> > > > 
> > > > 
> > > > 
> > > > 
> > > > On 20 July 2016 at 22:50:34, Dan Williams
> > > > (d...@redhat.com(mailto:d...@redhat.com)) wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > Hi Dan,
> > > > > > 
> > > > > > Ah - yeah I hadn’t thought it may be a kernel build option.
> > > > > > I’ve
> > > > > > now
> > > > > > built that and dmesg is a much more lively place!
> > > > > > 
> > > > > > I’ve provided output logs for both when the device is
> > > > > > connected
> > > > > > and
> > > > > > when a connection attempt is made - hopefully this is
> > > > > > useful.
> > > > > 
> > > > > The card is scanning and only finds 'shaunthesheep' 20
> > > > > seconds
> > > > > after
> > > > > you "connect for the first time". The logs stop 3 seconds
> > > > > later.
> > > > > Are
> > > > > you connecting with wicd or something else?
> > > > > 
> > > > > Can you run wpa_supplicant with the "-dddtu" option so we can
> > > > > get
> > > > > debug
> > > > > log output from it?
> > > > > 
> > > > > Dan
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe
> > > > linux-
> > > > wireless" in
> > > > the body of a message to majord...@vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.ht
> > > > ml
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem connecting to wifi on libertas_cpio (sd8686)

[Dan Williams]

On Wed, 2016-07-20 at 15:16 -0700, Christopher Williamson wrote:
> I used NetworkManager in the previous test.
> 
> This time around I have used wpa_supplicant directly and get the
> following results:
> 
> http://termbin.com/j8ea
> 
> Thought I’d throw them on a pastebin since it’s over 700 lines.

Can you try with "-D nl80211" instead of using the WEXT supplicant
driver?  NM is likely going to use nl80211 since the driver has some
 support for cfg80211/nl80211 and only does WEXT through the glue
layer.

Dan

> Christopher Williamson
> 
> 
> 
> 
> On 20 July 2016 at 22:50:34, Dan Williams
> (d...@redhat.com(mailto:d...@redhat.com)) wrote:
> 
> > 
> > On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson wrote:
> > > 
> > > Hi Dan,
> > > 
> > > Ah - yeah I hadn’t thought it may be a kernel build option. I’ve
> > > now
> > > built that and dmesg is a much more lively place!
> > > 
> > > I’ve provided output logs for both when the device is connected
> > > and
> > > when a connection attempt is made - hopefully this is useful.
> > 
> > 
> > The card is scanning and only finds 'shaunthesheep' 20 seconds
> > after
> > you "connect for the first time". The logs stop 3 seconds later.
> > Are
> > you connecting with wicd or something else?
> > 
> > Can you run wpa_supplicant with the "-dddtu" option so we can get
> > debug
> > log output from it?
> > 
> > Dan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem connecting to wifi on libertas_cpio (sd8686)

[Dan Williams]

On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson wrote:
> Hi Dan,
> 
> Ah - yeah I hadn’t thought it may be a kernel build option. I’ve now
> built that and dmesg is a much more lively place!
> 
> I’ve provided output logs for both when the device is connected and
> when a connection attempt is made - hopefully this is useful.



The card is scanning and only finds 'shaunthesheep' 20 seconds after
you "connect for the first time".  The logs stop 3 seconds later.  Are
you connecting with wicd or something else?

Can you run wpa_supplicant with the "-dddtu" option so we can get debug
log output from it?

Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem connecting to wifi on libertas_cpio (sd8686)

[Dan Williams]

On Wed, 2016-07-20 at 02:53 -0700, Christopher Williamson wrote:
> Just following up from my previous email:
> 
> I am actually setting the reg domain using: iw reg set GB
> (copy/pasted
> the IN from elsewhere - oops!)
> 
> As for progress, however, I have tried the following:
> 
> - setting the debug level to 0xfff. This still produces no
> additional output even with 8 set in printk.

Yeah, looks like you'd need to rebuild the libertas driver with
CONFIG_LIBERTAS_DEBUG set.  Or just #define that to 1 in defs.h.  Is
that something you could do?

Dan

> - removing the v9 firmware - same result as before - system fully
> locks up.
> 
> - disabling ipv6 - gets rid of IPv6 interface not up warning but
> that’s not causing any problems and this didn’t make any difference.
> 
> It doesn’t seem to matter what I try at the moment - all attempts to
> connect result in the system crashing which I guess is better than it
> just asking me for a password over and over - it looks like it is
> attempting association at this point which is good but I don’t know
> why the box is crashing out and dmesg -w doesn’t show any additional
> output before the freeze.
> 
> If anyone has any more ideas I would be more than happy to try them!
> Thanks for the help so far Dan!
> 
> Christopher Williamson
> 
> On 19 July 2016 at 18:41:34, Christopher Williamson
> (h...@chrisaw.com(mailto:h...@chrisaw.com)) wrote:
> 
> > 
> > So I’ve now disabled IPv6 and have set the GB (Great Britain)
> > regulation code using:
> > 
> > iw reg set IN
> > 
> > Now when I try to connect to the network using wicd the system
> > seems to crash - I guess at least it’s doing something more than
> > just asking for the password again like it did with NetworkManager
> > but so far no further progress on getting this working properly.
> > 
> > Christopher Williamson
> > 
> > 
> > 
> > On 19 July 2016 at 18:03:16, Christopher Williamson (home@chrisaw.c
> > om(mailto:h...@chrisaw.com)) wrote:
> > 
> > > 
> > > Absolutely!
> > > 
> > > With the debug logging enabled I got the following:
> > > 
> > > Connecting the device initially with debug enabled:
> > > 
> > > [ 205.302685] libertas_sdio: Libertas SDIO driver
> > > [ 205.302698] libertas_sdio: Copyright Pierre Ossman
> > > [ 205.503465] cfg80211: World regulatory domain updated:
> > > [ 205.503478] cfg80211: DFS Master region: unset
> > > [ 205.503483] cfg80211: (start_freq - end_freq @ bandwidth),
> > > (max_antenna_gain, max_eirp), (dfs_cac_time)
> > > [ 205.503492] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz),
> > > (N/A, 2000 mBm), (N/A)
> > > [ 205.503499] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz),
> > > (N/A, 2000 mBm), (N/A)
> > > [ 205.503505] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz),
> > > (N/A, 2000 mBm), (N/A)
> > > [ 205.503513] cfg80211: (517 KHz - 525 KHz @ 8 KHz,
> > > 16 KHz AUTO), (N/A, 2000 mBm), (N/A)
> > > [ 205.503522] cfg80211: (525 KHz - 533 KHz @ 8 KHz,
> > > 16 KHz AUTO), (N/A, 2000 mBm), (0 s)
> > > [ 205.503529] cfg80211: (549 KHz - 573 KHz @ 16 KHz),
> > > (N/A, 2000 mBm), (0 s)
> > > [ 205.503535] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz),
> > > (N/A, 2000 mBm), (N/A)
> > > [ 205.503542] cfg80211: (5724 KHz - 6372 KHz @ 216
> > > KHz), (N/A, 0 mBm), (N/A)
> > > [ 212.249171] gma500 :00:02.0: Backlight lvds set brightness
> > > 7a127a12
> > > [ 212.324898] mmc1: new SDIO card at address 0001
> > > [ 212.921672] libertas_sdio mmc1:0001:1 (unnamed net_device)
> > > (uninitialized): 00:02:78:69:49:94, fw 9.70.20p0, cap 0x0303
> > > [ 212.925774] libertas_sdio mmc1:0001:1 (unnamed net_device)
> > > (uninitialized): PREP_CMD: command 0x00a3 failed: 2
> > > [ 212.936190] libertas_sdio mmc1:0001:1 wlan0: Marvell WLAN
> > > 802.11 adapter
> > > [ 213.053612] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> > > 
> > > 
> > > Strangely when I attempt to connect to the WiFi network I’m using
> > > the only error I get is:
> > > 
> > > [ 338.076632] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> > > 
> > > I was expecting more output and am guessing I’ve missed something
> > > here.
> > > 
> > > Christopher Williamson
> > > 
> > > On 19 July 2016 at 17:38:35, Dan Williams (d...@redhat.com(mailto
> > > :d...@r

Re: Problem connecting to wifi on libertas_cpio (sd8686)

[Dan Williams]

On Tue, 2016-07-19 at 12:06 -0400, Christopher Williamson wrote:
> Hi everyone!
> 
> I’ve just got myself a Viliv N5 and am trying to get the integrated
> Wifi chipset working on it.
> 
> I am able to see networks around me but any attempts to connect them
> appear to time out and fail.
> 
> I have filed a linux kernel bug related to this issue:
> https://bugzilla.kernel.org/show_bug.cgi?id=135421
> 
> I figured here may be a good place to ask about it and hopefully to
> get to the bottom of why it happens and how I can help to fix it.
> 
> Happy to provide any information which may be helpful! :)

Can you reload the driver stack:

rmmod libertas_sdio
rmmod libertas
modprobe libertas libertas_debug=0x251e7ff
modprobe libertas_sdio

and then reproduce the issue?  The debug info should dump to 'dmesg'
and may tell us what's going on.

Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ldv-project] [net] libertas: potential race condition

[Dan Williams]

On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote:
> Hi!
> 
> There is a potential race condition in 
> drivers/net/wireless/libertas/libertas.ko.
> In the function lbs_hard_start_xmit(..), line 159, a socket buffer
> is 
> written to priv->current_skb with a spin_lock protection.
> In the function lbs_mac_event_disconnected(..), lines 50-51, the
> field 
> current_skb is cleaned. There is no protection used. The
> corresponding 
> handlers are activated at the same time in lbs_start_card(..) and
> then 
> may be executed simultaneously. Note, there are two structures 
> lbs_netdev_ops and mesh_netdev_ops, which have the target handler 
> lbs_hard_start_xmit.
> Is it a real race or I have missed something?

Yeah, it looks like it should be grabbing priv->driver_lock before
clearing priv->currenttxskb in lbs_mac_event_disconnected().  Care to
submit a patch after testing?  Do you have any of that hardware?

Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Where to post Wireless Tools Patches

[Dan Williams]

On Wed, 2016-06-01 at 21:42 +0530, Dibyajyoti Ghosh wrote:
> Hi,
> 
> I want to know the mail id list to send a patch on Wireless Tools.
> Kindly reply ASAP.

Assuming you mean the "wireless-tools" package, this list is OK.  But
probably nobody will apply the patches, since wireless-tools and the
WEXT API are long-since deprecated and haven't been updated in probably
6 or 7 years.  The bar to changes is quite high because of this, even
for trivial ones.

Instead, drivers and userspace tools have moved to the nl80211 APIs to
replace WEXT and the 'iw' tool to replace 'iwconfig'.

Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

[Dan Williams]

On Wed, 2016-05-11 at 13:03 +0800, Wei-Ning Huang wrote:
> On Fri, May 6, 2016 at 4:19 PM, Wei-Ning Huang <wnhu...@google.com>
> wrote:
> > 
> > On Fri, May 6, 2016 at 12:07 AM, Dan Williams <d...@redhat.com>
> > wrote:
> > > 
> > > 
> > > On Thu, 2016-05-05 at 14:44 +0800, Wei-Ning Huang wrote:
> > > > 
> > > > Recent new hardware has the ability to switch between tablet
> > > > mode and
> > > > clamshell mode. To optimize WiFi performance, we want to be
> > > > able to
> > > > use
> > > > different power table between modes. This patch adds a new
> > > > netlink
> > > > message type and cfg80211_ops function to allow userspace to
> > > > trigger
> > > > a
> > > > power mode switch for a given wireless interface.
> > > > 
> > > > Signed-off-by: Wei-Ning Huang <wnhu...@chromium.org>
> > > > ---
> > > >  include/net/cfg80211.h   | 11 +++
> > > >  include/uapi/linux/nl80211.h | 21 +
> > > >  net/wireless/nl80211.c   | 16 
> > > >  net/wireless/rdev-ops.h  | 22 ++
> > > >  net/wireless/trace.h | 20 
> > > >  5 files changed, 90 insertions(+)
> > > > 
> > > > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> > > > index 9e1b24c..aa77fa0 100644
> > > > --- a/include/net/cfg80211.h
> > > > +++ b/include/net/cfg80211.h
> > > > @@ -2370,6 +2370,12 @@ struct cfg80211_qos_map {
> > > >   * @get_tx_power: store the current TX power into the dbm
> > > > variable;
> > > >   *   return 0 if successful
> > > >   *
> > > > + * @set_tx_power_mode: set the transmit power mode. Some
> > > > device have
> > > > the ability
> > > > + *   to transform between different mode such as clamshell and
> > > > tablet mode.
> > > > + *   set_tx_power_mode allows setting of different TX power
> > > > mode at runtime.
> > > > + * @get_tx_power_mode: store the current TX power mode into
> > > > the mode
> > > > variable;
> > > > + *   return 0 if successful
> > > > + *
> > > >   * @set_wds_peer: set the WDS peer for a WDS interface
> > > >   *
> > > >   * @rfkill_poll: polls the hw rfkill line, use cfg80211
> > > > reporting
> > > > @@ -2631,6 +2637,11 @@ struct cfg80211_ops {
> > > >   int (*get_tx_power)(struct wiphy *wiphy, struct
> > > > wireless_dev *wdev,
> > > >   int *dbm);
> > > > 
> > > > + int (*set_tx_power_mode)(struct wiphy *wiphy,
> > > > +  enum nl80211_tx_power_mode
> > > > mode);
> > > > + int (*get_tx_power_mode)(struct wiphy *wiphy,
> > > > +  enum nl80211_tx_power_mode
> > > > *mode);
> > > > +
> > > >   int (*set_wds_peer)(struct wiphy *wiphy, struct
> > > > net_device *dev,
> > > >   const u8 *addr);
> > > > 
> > > > diff --git a/include/uapi/linux/nl80211.h
> > > > b/include/uapi/linux/nl80211.h
> > > > index 5a30a75..9b1888a 100644
> > > > --- a/include/uapi/linux/nl80211.h
> > > > +++ b/include/uapi/linux/nl80211.h
> > > > @@ -1796,6 +1796,9 @@ enum nl80211_commands {
> > > >   *   connecting to a PCP, and in %NL80211_CMD_START_AP to
> > > > start
> > > >   *   a PCP instead of AP. Relevant for DMG networks only.
> > > >   *
> > > > + * @NL80211_ATTR_WIPHY_TX_POWER_MODE: Transmit power mode. See
> > > > + *   nl80211_tx_power_mode for possible values.
> > > > + *
> > > >   * @NUM_NL80211_ATTR: total number of nl80211_attrs available
> > > >   * @NL80211_ATTR_MAX: highest attribute number currently
> > > > defined
> > > >   * @__NL80211_ATTR_AFTER_LAST: internal use
> > > > @@ -2172,6 +2175,8 @@ enum nl80211_attrs {
> > > > 
> > > >   NL80211_ATTR_PBSS,
> > > > 
> > > > + NL80211_ATTR_WIPHY_TX_POWER_MODE,
> > > > +
> > > >   /* add attributes here, update the policy in nl80211.c */
> > > > 
> > > >   __NL8021

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

[Dan Williams]

On Thu, 2016-05-05 at 14:44 +0800, Wei-Ning Huang wrote:
> Recent new hardware has the ability to switch between tablet mode and
> clamshell mode. To optimize WiFi performance, we want to be able to
> use
> different power table between modes. This patch adds a new netlink
> message type and cfg80211_ops function to allow userspace to trigger
> a
> power mode switch for a given wireless interface.
> 
> Signed-off-by: Wei-Ning Huang 
> ---
>  include/net/cfg80211.h   | 11 +++
>  include/uapi/linux/nl80211.h | 21 +
>  net/wireless/nl80211.c   | 16 
>  net/wireless/rdev-ops.h  | 22 ++
>  net/wireless/trace.h | 20 
>  5 files changed, 90 insertions(+)
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 9e1b24c..aa77fa0 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2370,6 +2370,12 @@ struct cfg80211_qos_map {
>   * @get_tx_power: store the current TX power into the dbm variable;
>   *   return 0 if successful
>   *
> + * @set_tx_power_mode: set the transmit power mode. Some device have
> the ability
> + *   to transform between different mode such as clamshell and
> tablet mode.
> + *   set_tx_power_mode allows setting of different TX power
> mode at runtime.
> + * @get_tx_power_mode: store the current TX power mode into the mode
> variable;
> + *   return 0 if successful
> + *
>   * @set_wds_peer: set the WDS peer for a WDS interface
>   *
>   * @rfkill_poll: polls the hw rfkill line, use cfg80211 reporting
> @@ -2631,6 +2637,11 @@ struct cfg80211_ops {
>   int (*get_tx_power)(struct wiphy *wiphy, struct
> wireless_dev *wdev,
>   int *dbm);
>  
> + int (*set_tx_power_mode)(struct wiphy *wiphy,
> +  enum nl80211_tx_power_mode
> mode);
> + int (*get_tx_power_mode)(struct wiphy *wiphy,
> +  enum nl80211_tx_power_mode
> *mode);
> +
>   int (*set_wds_peer)(struct wiphy *wiphy, struct
> net_device *dev,
>   const u8 *addr);
>  
> diff --git a/include/uapi/linux/nl80211.h
> b/include/uapi/linux/nl80211.h
> index 5a30a75..9b1888a 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -1796,6 +1796,9 @@ enum nl80211_commands {
>   *   connecting to a PCP, and in %NL80211_CMD_START_AP to start
>   *   a PCP instead of AP. Relevant for DMG networks only.
>   *
> + * @NL80211_ATTR_WIPHY_TX_POWER_MODE: Transmit power mode. See
> + *   nl80211_tx_power_mode for possible values.
> + *
>   * @NUM_NL80211_ATTR: total number of nl80211_attrs available
>   * @NL80211_ATTR_MAX: highest attribute number currently defined
>   * @__NL80211_ATTR_AFTER_LAST: internal use
> @@ -2172,6 +2175,8 @@ enum nl80211_attrs {
>  
>   NL80211_ATTR_PBSS,
>  
> + NL80211_ATTR_WIPHY_TX_POWER_MODE,
> +
>   /* add attributes here, update the policy in nl80211.c */
>  
>   __NL80211_ATTR_AFTER_LAST,
> @@ -3703,6 +3708,22 @@ enum nl80211_tx_power_setting {
>  };
>  
>  /**
> + * enum nl80211_tx_power_mode - TX power mode setting
> + * @NL80211_TX_POWER_LOW: general low TX power mode
> + * @NL80211_TX_POWER_MEDIUM: general medium TX power mode
> + * @NL80211_TX_POWER_HIGH: general high TX power mode
> + * @NL80211_TX_POWER_CLAMSHELL: clamshell mode TX power mode
> + * @NL80211_TX_POWER_TABLET: tablet mode TX power mode
> + */
> +enum nl80211_tx_power_mode {
> + NL80211_TX_POWER_LOW,
> + NL80211_TX_POWER_MEDIUM,
> + NL80211_TX_POWER_HIGH,
> + NL80211_TX_POWER_CLAMSHELL,
> + NL80211_TX_POWER_TABLET,

"clamshell" and "tablet" probably mean many different things to many
different people with respect to whether or not they should do anything
with power saving or wifi.  I feel like a more generic interface is
needed here.

Could this be already done by:
@NL80211_ATTR_WIPHY_TX_POWER_SETTING = NL80211_TX_POWER_LIMITED
@NL80211_ATTR_WIPHY_TX_POWER_LEVEL = 

and then the device would be able to change its TX power as it saw fit
up to that limit set by your application which figures out whether it's
in clamshell or tablet mode?

Dan

> +};
> +
> +/**
>   * enum nl80211_packet_pattern_attr - packet pattern attribute
>   * @__NL80211_PKTPAT_INVALID: invalid number for nested attribute
>   * @NL80211_PKTPAT_PATTERN: the pattern, values where the mask has
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 056a730..61b474d 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -402,6 +402,7 @@ static const struct nla_policy
> nl80211_policy[NUM_NL80211_ATTR] = {
>   [NL80211_ATTR_SCHED_SCAN_DELAY] = { .type = NLA_U32 },
>   [NL80211_ATTR_REG_INDOOR] = { .type = NLA_FLAG },
>   [NL80211_ATTR_PBSS] = { .type = NLA_FLAG },
> + [NL80211_ATTR_WIPHY_TX_POWER_MODE] = { .type = NLA_U32 },
>  };
>  
>  /* policy for the key 

Re: [PATCHv2 00/10] RFKill airplane-mode indicator

[Dan Williams]

On Mon, 2016-02-22 at 11:36 -0500, João Paulo Rechi Vita wrote:
> This series implements an airplane-mode indicator LED trigger, which
> can be
> used by platform drivers. The default policy have have airplane-mode
> set when
> all the radios known by RFKill are OFF, and unset otherwise. This
> policy can be
> overwritten by one single userspace application at a time using the
> operations
> _AIRPLANE_MODE_INDICATOR_ACQUIRE and _AIRPLANE_MODE_INDICATOR_CHANGE.
> 
Double-check your commit messages on some of these patches; they didn't
get updated to add INDICATOR.

Dan

> When the
> airplane-mode indicator state changes, userspace gets notifications
> through the
> RFKill control misc device (/dev/rfkill).
> 
> The series also contains a few general fixes and improvements to the
> subsystem.
> 
> Additionally, I have a couple of patches to have this feature
> supported by the
> userspace tool 'rfkill' [1]. Should I use a different subject prefix
> to help
> separate those from kernel patches in linux-wireless?
> 
> [1] https://wireless.wiki.kernel.org/en/users/documentation/rfkill
> 
> João Paulo Rechi Vita (10):
>   rfkill: Improve documentation language
>   rfkill: Remove extra blank line
>   rfkill: Point to the correct deprecated doc location
>   rfkill: Move "state" sysfs file back to stable
>   rfkill: Factor rfkill_global_states[].cur assignments
>   rfkill: Add documentation about LED triggers
>   rfkill: Create "rfkill-airplane-mode" LED trigger
>   rfkill: Use switch to demux userspace operations
>   rfkill: Userspace control for airplane mode
>   rfkill: Notify userspace of airplane-mode state changes
> 
>  Documentation/ABI/obsolete/sysfs-class-rfkill |  20 
>  Documentation/ABI/stable/sysfs-class-rfkill   |  27 -
>  Documentation/rfkill.txt  |  17 +++
>  include/uapi/linux/rfkill.h   |   6 +
>  net/rfkill/core.c | 162
> --
>  5 files changed, 173 insertions(+), 59 deletions(-)
>  delete mode 100644 Documentation/ABI/obsolete/sysfs-class-rfkill
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

[Dan Williams]

On Wed, 2016-02-10 at 17:07 +0100, Johannes Berg wrote:
> On Mon, 2016-02-08 at 10:11 -0600, Dan Williams wrote:
> > I'd like to clarify a bit, so tell me if I'm correct or not.  Using
> > RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device
> > state. It's just an indicator with no relationship to any of the
> > registered rfkill switches, right?
> 
> Yes. I'm not sure I'm totally happy with this userspace API.
> 
> > I wonder if setting RFKILL_OP_AIRPLANE_MODE_CHANGE(true) shouldn't
> > also
> > softblock all switches, otherwise you can set airplane mode all day
> > long with RFKILL_OP_AIRPLANE_MODE_CHANGE and it doesn't actually
> > enable
> > airplane mode at all?
> 
> No, this is kinda the point that you could implement your policy in
> userspace now.

Yeah, I get that now.  It's just that to me, something called
"AIRPLANE_MODE_CHANGE" seems like it should actually change airplane
mode on/off, which implies killing radios.  I wouldn't have had the
problem if it was named AIRPLANE_MODE_INDICATOR_CHANGE, which makes it
clear this is simply an indicator and has no actual effect on anything
other than a LED.

Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

[Dan Williams]

On Mon, 2016-02-08 at 10:41 -0500, João Paulo Rechi Vita wrote:
> Provide an interface for the airplane-mode indicator be controlled
> from
> userspace. User has to first acquire the control through
> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole
> time
> it wants to be in control of the indicator. Closing the fd or using
> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
> 
> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
> operation is used, passing the value on "struct rfkill_event.soft".
> If
> the caller has not acquired the airplane-mode control beforehand, the
> operation fails.

I'd like to clarify a bit, so tell me if I'm correct or not.  Using
RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device
state. It's just an indicator with no relationship to any of the
registered rfkill switches, right?

I wonder if setting RFKILL_OP_AIRPLANE_MODE_CHANGE(true) shouldn't also
softblock all switches, otherwise you can set airplane mode all day
long with RFKILL_OP_AIRPLANE_MODE_CHANGE and it doesn't actually enable
airplane mode at all?

Dan

> Signed-off-by: João Paulo Rechi Vita 
> ---
>  Documentation/rfkill.txt| 10 ++
>  include/uapi/linux/rfkill.h |  3 +++
>  net/rfkill/core.c   | 47
> ++---
>  3 files changed, 57 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
> index b13025a..aa6e014 100644
> --- a/Documentation/rfkill.txt
> +++ b/Documentation/rfkill.txt
> @@ -87,6 +87,7 @@ RFKill provides per-switch LED triggers, which can
> be used to drive LEDs
>  according to the switch state (LED_FULL when blocked, LED_OFF
> otherwise).
>  An airplane-mode indicator LED trigger is also available, which
> triggers
>  LED_FULL when all radios known by RFKill are blocked, and LED_OFF
> otherwise.
> +The airplane-mode indicator LED trigger policy can be overridden by
> userspace.
>  
>  
>  5. Userspace support
> @@ -123,5 +124,14 @@ RFKILL_TYPE
>  The contents of these variables corresponds to the "name", "state"
> and
>  "type" sysfs files explained above.
>  
> +Userspace can also override the default airplane-mode indicator
> policy through
> +/dev/rfkill. Control of the airplane mode indicator has to be
> acquired first,
> +using RFKILL_OP_AIRPLANE_MODE_ACQUIRE, and is only available for one
> userspace
> +application at a time. Closing the fd or using
> RFKILL_OP_AIRPLANE_MODE_RELEASE
> +reverts the airplane-mode indicator back to the default kernel
> policy and makes
> +it available for other applications to take control. Changes to the
> +airplane-mode indicator state can be made using
> RFKILL_OP_AIRPLANE_MODE_CHANGE,
> +passing the new value in the 'soft' field of 'struct rfkill_event'.
> +
>  
>  For further details consult Documentation/ABI/stable/sysfs-class
> -rfkill.
> diff --git a/include/uapi/linux/rfkill.h
> b/include/uapi/linux/rfkill.h
> index 2e00dce..9cb999b 100644
> --- a/include/uapi/linux/rfkill.h
> +++ b/include/uapi/linux/rfkill.h
> @@ -67,6 +67,9 @@ enum rfkill_operation {
>   RFKILL_OP_DEL,
>   RFKILL_OP_CHANGE,
>   RFKILL_OP_CHANGE_ALL,
> + RFKILL_OP_AIRPLANE_MODE_ACQUIRE,
> + RFKILL_OP_AIRPLANE_MODE_RELEASE,
> + RFKILL_OP_AIRPLANE_MODE_CHANGE,
>  };
>  
>  /**
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index fb11547..8067701 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -89,6 +89,7 @@ struct rfkill_data {
>   struct mutexmtx;
>   wait_queue_head_t   read_wait;
>   boolinput_handler;
> + boolis_apm_owner;
>  };
>  
>  
> @@ -123,7 +124,7 @@ static struct {
>  } rfkill_global_states[NUM_RFKILL_TYPES];
>  
>  static bool rfkill_epo_lock_active;
> -
> +static bool rfkill_apm_owned;
>  
>  #ifdef CONFIG_RFKILL_LEDS
>  static struct led_trigger rfkill_apm_led_trigger;
> @@ -350,7 +351,8 @@ static void rfkill_update_global_state(enum
> rfkill_type type, bool blocked)
>  
>   for (i = 0; i < NUM_RFKILL_TYPES; i++)
>   rfkill_global_states[i].cur = blocked;
> - rfkill_apm_led_trigger_event(blocked);
> + if (!rfkill_apm_owned)
> + rfkill_apm_led_trigger_event(blocked);
>  }
>  
>  #ifdef CONFIG_RFKILL_INPUT
> @@ -1183,6 +1185,7 @@ static ssize_t rfkill_fop_read(struct file
> *file, char __user *buf,
>  static ssize_t rfkill_fop_write(struct file *file, const char __user
> *buf,
>   size_t count, loff_t *pos)
>  {
> + struct rfkill_data *data = file->private_data;
>   struct rfkill *rfkill;
>   struct rfkill_event ev;
>  
> @@ -1199,7 +1202,7 @@ static ssize_t rfkill_fop_write(struct file
> *file, const char __user *buf,
>   if (copy_from_user(, buf, count))
>   return -EFAULT;
>  
> - if (ev.op != RFKILL_OP_CHANGE && ev.op !=
> RFKILL_OP_CHANGE_ALL)
> + if (ev.op < 

Re: power save settings for WiFi

[Dan Williams]

On Sun, 2016-01-03 at 12:17 +0200, Emmanuel Grumbach wrote:
> Hi Dan,
> 
> I wanted to debug something with power save control and saw that NM
> disables power save by default. This was a complete surprise for me.
> This probably is because Ubuntu upgraded my NM version to 1.0.4.

Note that upstream NM 1.0.x does not support powersave, that was
apparently backported from NM 1.2.x by Ubuntu (?).  So anything I'm
talking about here applies to NM 1.2...

> I tried to enabled power save with:
> 
>  nmcli c modify  802-11-wireless.powersave 1
> 
> That command returns 0, but power save is still disabled. Note that

This simply modifies the saved configuration, it doesn't modify the
runtime value.  To change that, the connection must be bounced. 
 Upcoming NM versions will support live changes by reflecting what you
do with nmcli to the runtime state of the device (or IP
addresses/routes/etc).  But not in 1.2 and lower.

So 'nmcli con up ' *should* enable powersave on the device.

> the decision to disable power save by default is a bit surprising.
> I understand that some device may not behave well with power save
> enabled, but then, I'd expect those (bad) devices to disable power
> save in the driver level.

When adding new features to NM (like powersave) we attempt to not
horribly break existing use-cases.  Which, for users of devices where
powersave doesn't work very well, would mean breaking their connection
by enabling it by default.  However, NM could have handled this better
by leaving the driver-default value enabled unless the user explicitly
sets the 'powersave' property.  Which it should really do...

I've filed https://bugzilla.gnome.org/show_bug.cgi?id=760125 for that.

Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/11] brcmfmac: Make 5G join preference configurable.

[Dan Williams]

On Wed, 2015-12-02 at 10:00 -0800, Paul Stewart wrote:
> From my perspective it is useful to have the driver express whether
> or not it supports this parameter.  It may not change how the system
> operates, but it will be useful in testing to determine whether it
> is expected that a (given version of a) driver is expected to act
> with respect to this property so we can flag issues with the
> implementation.

Agreed.

Dan

> On Wed, Dec 2, 2015 at 8:38 AM, Dan Williams <d...@redhat.com> wrote:
> > On Wed, 2015-12-02 at 14:32 +0100, Arend van Spriel wrote:
> > > On 12/01/2015 12:08 PM, Jouni Malinen wrote:
> > > > On Tue, Dec 01, 2015 at 11:48:32AM +0200, Kalle Valo wrote:
> > > > > Arend van Spriel <ar...@broadcom.com> writes:
> > > > > > It solves a problem for us, but admittedly it is not
> > > > > > something
> > > > > > that is
> > > > > > very usable by user-space apps. So I guess what you are
> > > > > > suggesting
> > > > > > here is to come up with a nl80211 api for this. On the
> > > > > > mailing
> > > > > > list
> > > > > > (or hostap list) the topic pops up from time to time so
> > > > > > there
> > > > > > are
> > > > > > people who would like to have such a knob to play with.
> > > > > > Still
> > > > > > would
> > > > > > like to keep the module parameter although its use may
> > > > > > change
> > > > > > when
> > > > > > nl80211 api is added.
> > > > > 
> > > > > I don't know what is the best approach, that's why I would
> > > > > like
> > > > > to hear
> > > > > opinions from others. Personally I don't like the idea of
> > > > > adding
> > > > > 802.11
> > > > > level configuration options to module parameters, but on the
> > > > > other hand
> > > > > I don't have any strong opinions about this.
> > > > 
> > > > I would like to see this as a new attribute to
> > > > NL80211_CMD_CONNECT
> > > > to
> > > > provide parameters for offloaded (driver and/or firmware) BSS
> > > > selection
> > > > and roaming. If there is a driver that uses roaming offload
> > > > with
> > > > NL80211_CMD_ASSOCIATE, the same attribute could be used there
> > > > (but
> > > > I'm
> > > > not sure how exact such offloading would work in practice since
> > > > I'd
> > > > expect both authentication and (re)association to be
> > > > offloaded).
> > > 
> > > Sounds reasonable. Just would like to explore the use-case a bit
> > > more.
> > > Looking at tools like NetworkManager and android network list,
> > > the
> > > user
> > > is always presented with just SSID listed once. For
> > > NetworkManager
> > > 
> > While NM has band locking properties, there is currently no "prefer
> > 5ghz" since as Jouni said, the supplicant should probably just
> > prefer
> > 5ghz right now.  In any case, the best path from an NM perspective
> > would be a supplicant per-network property that would then be sent
> > for
> > CONNECT-capable drivers, or which the supplicant would manually
> > handle
> > for softmac drivers through its existing AP selection code.
> > 
> > Dan
> > 
> > > details can be configured for a connection and the bss selection
> > > parameters could be one of those. What level of detail would be
> > > needed
> > > there. Not saying we can not have more detail in the nl80211 API.
> > > 
> > > > > I guess we have two different designs, one where the roaming
> > > > > logic is in
> > > > > firmware and other where wpasupplicant is responsible for
> > > > > this.
> > > > > (And I
> > > > > assume that brcfmac belongs to the former group.) Ideally it
> > > > > would be
> > > > > nice that we would have a same configuration knob for both
> > > > > but I
> > > > > don't
> > > > > know if that's really feasible.
> > > > 
> > > > Both of these would work as long as wpa_supplicant has means
> > > > for
> > > > providing such configuration to the driver in a generic manner.
> > > > That
> > > > NL80211_CMD_CONNECT extension with a new optional attribute
> > > > would
> > > > be
> > > > such a generic design.
> > > 
> > > So does the driver need to advertise support for bss selection
> > > parameters or can it simply ignore the parameters. Assuming the
> > > latter
> > > for now.
> > > 
> > > Regards,
> > > Arend
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux
> > > -wireless" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at  
> > > http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux
> > -wireless" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex problem: incompatible network settings

[Dan Williams]

On Thu, 2015-10-29 at 12:27 +, Amitkumar Karwar wrote:
> Hi Julien,
> 
> > From: Julien Cubizolles [mailto:j.cubizol...@free.fr]
> > Sent: Thursday, October 29, 2015 3:09 AM
> > To: Dan Williams
> > Cc: Amitkumar Karwar; linux-wireless@vger.kernel.org
> > Subject: Re: mwifiex problem: incompatible network settings
> > 
> > Dan Williams <d...@redhat.com> writes:
> > 
> > > He actually meant the wpa_supplicant configuration file, not the
> > > supplicant's dbus config file.  But when driven by NetworkManager,
> > > there is no supplicant configuration file.
> > 
> > Sorry about that.
> > 
> > > Instead, you can find out what config NM is pushing to the supplicant
> > > by checking the NetworkManager logs, where NM will log lines like:
> > 
> > Here are the relevant entries from the syslog file:
> > 
> > I included the failed attempt to connect to the WPA protected network
> > named "southcentral" and the successful one to a non protected one named
> > "FreeWifi".
> > 
> 
> Thanks for the logs. I compared your network manager log with the one on my 
> setup. Both are same. Basically network manager log doesn't show security 
> info (WPA/WPA2, encryption mode etc). So we can't rely on that.

NetworkManager leaves the 'protos' field empty, which allows the
supplicant to choose the correct WPA/WPA2 mode depending on driver
support.  What you see in the NM logs is exactly what gets pushed to the
supplicant in the network block.  So if you don't see "proto" or
"pairwise" or "group" in the NM logs, then it doesn't get pushed to the
supplicant, and the supplicant uses its default behavior, which should
be:

proto=WPA RSN
pairwise=CCMP TKIP
group=CCMP TKIP WEP104 WEP40

Dan

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex problem: incompatible network settings

[Dan Williams]

On Tue, 2015-10-27 at 22:44 +0100, Julien Cubizolles wrote:
> Amitkumar Karwar  writes:
> 
> > Hi Julien,
> >
> >>Yes, I'm using NetworkManager, version 1.0.4-ubuntu5, and I'm guessing
> >>it's using wpa_supplicant. I deleted the configuration for this network
> >>and created it again. The network is configured for WPA in
> >>NetworkManager but I still get the same error message.
> >
> > Looks like driver has received encryption mode as TKIP, but didn't
> > receive WPA ie. Hence the configuration didn't match with AP. Could
> > you share wpa_supplicant configuration file if possible? 
> 
> Here is /etc/dbus-1/system.d/wpa_supplicant.conf, is this the one you
> need ?

He actually meant the wpa_supplicant configuration file, not the
supplicant's dbus config file.  But when driven by NetworkManager, there
is no supplicant configuration file.

Instead, you can find out what config NM is pushing to the supplicant by
checking the NetworkManager logs, where NM will log lines like:

NetworkManager[1163]:   (wlp4s0): Activation: (wifi) connection
'homewifi' has security, and secrets exist.  No new secrets needed.
NetworkManager[1163]:   Config: added 'ssid' value 'homewifi'
NetworkManager[1163]:   Config: added 'scan_ssid' value '1'
NetworkManager[1163]:   Config: added 'key_mgmt' value 'WPA-PSK'
NetworkManager[1163]:   Config: added 'psk' value ''
NetworkManager[1163]:   Config: added 'proto' value 'WPA RSN'
NetworkManager[1163]:   Config: set interface ap_scan to 1

That is almost exactly what would be in the wpa_supplicant config file.
Can you grab this info from your machine for Julien?

Dan

> --8<---cut here---start->8---
>   "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
>  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  receive_type="signal"/>
> 
> 
> 
> 
> 
> 
> 
>  receive_type="signal"/>
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  receive_type="signal"/>
> 
> 
> 
> --8<---cut here---end--->8---
> 
> > Also, check if "sme->ie" is received in mwifiex_cfg80211_assoc()
> > routine.
> 
> Is that what the following debugging is for ? Or should I do something
> else ?
> 
> > Enable driver debug for the test using "echo 0x >
> > /sys/kernel/debug/mwifiex/mlan0/debug_mask" and share dmesg logs.
> 
> Please find them attached.
> 
> Regards,
> 
> Julien.
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex problem: incompatible network settings

[Dan Williams]

On Mon, 2015-10-26 at 22:50 +0100, Julien Cubizolles wrote:
> Dan Williams <d...@redhat.com> writes:
> 
> > On Mon, 2015-10-26 at 16:51 +0100, Julien Cubizolles wrote:
> >> I can't connect anymore to my home wifi since upgrading my machine from
> >> Ubuntu 15.04 to Ubuntuy 15.10. I was previously running kernel 4.3.0-rc2
> >> from kernel.org without any problem. After the upgrade, and with the
> >> same kernel, I couldn't connect anymore. I built 4.3.0-rc7, and the
> >> problem remains. However, I can connect to the wifi access point from my
> >> Android phone.
> >> 
> >> Here are the relevant lines from syslog. Let me know if you need more
> >> information.
> >
> > The AP uses WPA, but the driver has been told that WPA is disabled.  Are
> > you using wpa_supplicant (or NetworkManager, or something else?) to
> > control the WiFi, and if so what version is it?
> 
> Yes, I'm using NetworkManager, version 1.0.4-ubuntu5, and I'm guessing
> it's using wpa_supplicant. I deleted the configuration for this network
> and created it again. The network is configured for WPA in
> NetworkManager but I still get the same error message.

Ok, I think it's a problem with the driver not correctly handling the
wpa_supplicant configuration requests.  Clearly wpa_supplicant is
sending WPA-enabled configuration, but the driver isn't interpreting it
correctly.  I'll leave it up to the mwifiex maintainers to figure that
out though.

Dan

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex problem: incompatible network settings

[Dan Williams]

On Mon, 2015-10-26 at 16:51 +0100, Julien Cubizolles wrote:
> I can't connect anymore to my home wifi since upgrading my machine from
> Ubuntu 15.04 to Ubuntuy 15.10. I was previously running kernel 4.3.0-rc2
> from kernel.org without any problem. After the upgrade, and with the
> same kernel, I couldn't connect anymore. I built 4.3.0-rc7, and the
> problem remains. However, I can connect to the wifi access point from my
> Android phone.
> 
> Here are the relevant lines from syslog. Let me know if you need more
> information.

The AP uses WPA, but the driver has been told that WPA is disabled.  Are
you using wpa_supplicant (or NetworkManager, or something else?) to
control the WiFi, and if so what version is it?

Dan

> --8<---cut here---start->8---
> Oct 26 16:11:38 touco wpa_supplicant[734]: wlx6045bdf646b4: Trying to 
> associate with f4:ca:e5:ef:be:18 (SSID='southcentral' freq=2462 MHz)
> Oct 26 16:11:38 touco wpa_supplicant[734]: wlx6045bdf646b4: 
> CTRL-EVENT-ASSOC-REJECT status_code=1
> Oct 26 16:11:38 touco kernel: [   66.745281] usb 1-3: info: trying to 
> associate to 'southcentral' bssid f4:ca:e5:ef:be:18
> Oct 26 16:11:38 touco kernel: [   66.745289] usb 1-3: info: 
> mwifiex_is_network_compatible: failed: wpa_ie=0xdd wpa2_ie=0x0 WEP=d  
> WPA=d WPA2=d EncMode=0xfac02 privacy=0x1
> Oct 26 16:11:38 touco kernel: [   66.745291] usb 1-3: Incompatible network 
> settings
> Oct 26 16:11:38 touco kernel: [   66.745294] usb 1-3: info: association to 
> bssid f4:ca:e5:ef:be:18 failed
> --8<---cut here---end--->8---
> 
> 
> The machine is a Microsoft Surface Pro. I've been having a lot of
> problems getting the wifi to work but never this particular one, and
> they were all fixed in 4.3.0-rc2.
> 
> Julien.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/2] airo: fix scan after SIOCSIWAP (airo_set_wap)

[Dan Williams]

On Thu, 2015-10-08 at 20:14 +0200, Ondrej Zary wrote:
> SIOCSIWAP (airo_set_wap) affects scan: only the AP specified by
> SIOCSIWAP is present in scan results.
> 
> This makes NetworkManager work for the first time but then unable to
> find any other APs.
> 
> Clear APList before starting scan and set it back after scan completes
> to work-around the problem.

Sounds plausible.  But does this cause any problems while the device is
associated and a scan is requested?  If not then it seems fine.

Dan

> Signed-off-by: Ondrej Zary 
> ---
>  drivers/net/wireless/airo.c |   13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
> index 4ef2f98..654a172 100644
> --- a/drivers/net/wireless/airo.c
> +++ b/drivers/net/wireless/airo.c
> @@ -3037,6 +3037,11 @@ static void airo_process_scan_results (struct 
> airo_info *ai) {
>   }
>  
>  out:
> + /* write APList back (we cleared it in airo_set_scan) */
> + disable_MAC(ai, 0);
> + writeAPListRid(ai, >APList, 0);
> + enable_MAC(ai, 0);
> +
>   ai->scan_timeout = 0;
>   clear_bit(JOB_SCAN_RESULTS, >jobs);
>   up(>sem);
> @@ -7216,6 +7221,7 @@ static int airo_set_scan(struct net_device *dev,
>   Cmd cmd;
>   Resp rsp;
>   int wake = 0;
> + APListRid APList_rid_empty;
>  
>   /* Note : you may have realised that, as this is a SET operation,
>* this is privileged and therefore a normal user can't
> @@ -7233,6 +7239,13 @@ static int airo_set_scan(struct net_device *dev,
>   if (ai->scan_timeout > 0)
>   goto out;
>  
> + /* Clear APList as it affects scan results */
> + memset(_rid_empty, 0, sizeof(APList_rid_empty));
> + APList_rid_empty.len = cpu_to_le16(sizeof(APList_rid_empty));
> + disable_MAC(ai, 0);
> + writeAPListRid(ai, _rid_empty, 0);
> + enable_MAC(ai, 0);
> +
>   /* Initiate a scan command */
>   ai->scan_timeout = RUN_AT(3*HZ);
>   memset(, 0, sizeof(cmd));


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ipw2200-bss

[Dan Williams]

On Wed, 2015-09-30 at 15:21 +, Aaron Kempf wrote:
> I am a tiny bit confused why this 'centrino' driver isn't in the 650mb
> cd download for Debian 8.2

The driver is included in the kernel, so it should be there already.
What may not be included on the CD is the firmware, which you may have
to install later.  It's supposedly in the "firmware-ipw2x00" package.

See also: https://wiki.debian.org/ipw2200

Dan

> I detest Ubuntu in all flavors.. and if you guys would get this driver
> into the Debian kernel, and on the default CD installer.. it would
> make my life a lot easier.
> 
> I wish I could help to do this.. but I am a lowly DBA tryng to get
> deeper into Linux / Debian / BSD.
> 
> Please call me if you could help me to transfer this from a Xubuntu
> 15.04 usb device onto my 8.2 installed system.  I would really
> appreciate it.
> 
> Aaron Kempf
> Microsoft Certified IT Professional: DBA
> Voice: 415-786-0776
> 
> PS - if you guys know of any DBA jobs in San Francisco.. I know my way
> around SQL to say the least :) http://www.fullstackaaron.com/resume
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] airo: fix IW_AUTH_ALG_OPEN_SYSTEM

[Dan Williams]

On Mon, 2015-09-21 at 15:44 +0200, Ondrej Zary wrote:
> IW_AUTH_ALG_OPEN_SYSTEM is ambiguous in set_auth for WEP as
> wpa_supplicant uses it for both no encryption and WEP open system.
> Cache the last mode set (only of these two) and use it here.
> 
> This allows wpa_supplicant to work with unencrypted APs.

Looks OK to me.

Dan

> Signed-off-by: Ondrej Zary 
> ---
>  drivers/net/wireless/airo.c |   59 
> +--
>  1 file changed, 35 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
> index d0c97c2..67001a8 100644
> --- a/drivers/net/wireless/airo.c
> +++ b/drivers/net/wireless/airo.c
> @@ -1237,6 +1237,7 @@ struct airo_info {
>  
>   int wep_capable;
>   int max_wep_idx;
> + int last_auth;
>  
>   /* WPA-related stuff */
>   unsigned int bssListFirst;
> @@ -3786,6 +3787,16 @@ badrx:
>   }
>  }
>  
> +static inline void set_auth_type(struct airo_info *local, int auth_type)
> +{
> + local->config.authType = auth_type;
> + /* Cache the last auth type used (of AUTH_OPEN and AUTH_ENCRYPT).
> +  * Used by airo_set_auth()
> +  */
> + if (auth_type == AUTH_OPEN || auth_type == AUTH_ENCRYPT)
> + local->last_auth = auth_type;
> +}
> +
>  static u16 setup_card(struct airo_info *ai, u8 *mac, int lock)
>  {
>   Cmd cmd;
> @@ -3862,7 +3873,7 @@ static u16 setup_card(struct airo_info *ai, u8 *mac, 
> int lock)
>   "level scale");
>   }
>   ai->config.opmode = adhoc ? MODE_STA_IBSS : MODE_STA_ESS;
> - ai->config.authType = AUTH_OPEN;
> + set_auth_type(ai, AUTH_OPEN);
>   ai->config.modulation = MOD_CCK;
>  
>   if (le16_to_cpu(cap_rid.len) >= sizeof(cap_rid) &&
> @@ -4880,13 +4891,13 @@ static void proc_config_on_close(struct inode *inode, 
> struct file *file)
>   line += 5;
>   switch( line[0] ) {
>   case 's':
> - ai->config.authType = AUTH_SHAREDKEY;
> + set_auth_type(ai, AUTH_SHAREDKEY);
>   break;
>   case 'e':
> - ai->config.authType = AUTH_ENCRYPT;
> + set_auth_type(ai, AUTH_ENCRYPT);
>   break;
>   default:
> - ai->config.authType = AUTH_OPEN;
> + set_auth_type(ai, AUTH_OPEN);
>   break;
>   }
>   set_bit (FLAG_COMMIT, >flags);
> @@ -6368,9 +6379,8 @@ static int airo_set_encode(struct net_device *dev,
>* should be enabled (user may turn it off later)
>* This is also how "iwconfig ethX key on" works */
>   if((index == current_index) && (key.len > 0) &&
> -(local->config.authType == AUTH_OPEN)) {
> - local->config.authType = AUTH_ENCRYPT;
> - }
> +(local->config.authType == AUTH_OPEN))
> + set_auth_type(local, AUTH_ENCRYPT);
>   } else {
>   /* Do we want to just set the transmit key index ? */
>   int index = (dwrq->flags & IW_ENCODE_INDEX) - 1;
> @@ -6389,12 +6399,12 @@ static int airo_set_encode(struct net_device *dev,
>   }
>   }
>   /* Read the flags */
> - if(dwrq->flags & IW_ENCODE_DISABLED)
> - local->config.authType = AUTH_OPEN; // disable encryption
> + if (dwrq->flags & IW_ENCODE_DISABLED)
> + set_auth_type(local, AUTH_OPEN);/* disable encryption */
>   if(dwrq->flags & IW_ENCODE_RESTRICTED)
> - local->config.authType = AUTH_SHAREDKEY;// Only Both
> - if(dwrq->flags & IW_ENCODE_OPEN)
> - local->config.authType = AUTH_ENCRYPT;  // Only Wep
> + set_auth_type(local, AUTH_SHAREDKEY);   /* Only Both */
> + if (dwrq->flags & IW_ENCODE_OPEN)
> + set_auth_type(local, AUTH_ENCRYPT); /* Only Wep */
>   /* Commit the changes to flags if needed */
>   if (local->config.authType != currentAuthType)
>   set_bit (FLAG_COMMIT, >flags);
> @@ -6549,12 +6559,12 @@ static int airo_set_encodeext(struct net_device *dev,
>   }
>  
>   /* Read the flags */
> - if(encoding->flags & IW_ENCODE_DISABLED)
> - local->config.authType = AUTH_OPEN; // disable encryption
> + if (encoding->flags & IW_ENCODE_DISABLED)
> + set_auth_type(local, AUTH_OPEN);/* disable encryption */
>   if(encoding->flags & IW_ENCODE_RESTRICTED)
> - local->config.authType = AUTH_SHAREDKEY;// Only Both
> - if(encoding->flags & 

Re: NetworkManager crashing

[Dan Williams]

On Thu, 2015-08-27 at 18:44 +0200, Arend van Spriel wrote:
> Hi Dan,
> 
> I ran into issue when NetworkManager keeps crashing/respawning. I have
> no idea what happened. My laptop was rebooted (might been my sons work)
> and this was the situation I stumbled upon. Running 4.1 kernel on Linux
> Mint. NetworkManager version is 0.9.8.8.

Odd, can you get any more log messages out of the machine?  Or perhaps a
backtrace?  Looks like it's happening quite early in boot, before
anything would really get configured...

Dan

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NetworkManager crashing

[Dan Williams]

On Mon, 2015-08-31 at 19:47 +0200, Arend van Spriel wrote:
> 
> On 31-08-15 17:43, Dan Williams wrote:
> > On Thu, 2015-08-27 at 18:44 +0200, Arend van Spriel wrote:
> >> Hi Dan,
> >>
> >> I ran into issue when NetworkManager keeps crashing/respawning. I have
> >> no idea what happened. My laptop was rebooted (might been my sons work)
> >> and this was the situation I stumbled upon. Running 4.1 kernel on Linux
> >> Mint. NetworkManager version is 0.9.8.8.
> > 
> > Odd, can you get any more log messages out of the machine?  Or perhaps a
> > backtrace?  Looks like it's happening quite early in boot, before
> > anything would really get configured...
> 
> Yikes. My mistake. I have two libnl-3 versions installed and
> NetworkManager loaded the wrong one. Doing walk of shame here.

Yeah, that'll do it...  glad to see it got figured out.

Dan

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dual mode operation

[Dan Williams]

On Tue, 2015-06-30 at 16:57 -0700, Stark Pister wrote:
 I am trying to figure out how to use virtual interfaces to run my wifi
 module in both AP mode and station mode simultaneously. From the
 description on this page
 (https://wireless.wiki.kernel.org/en/users/documentation/iw/vif) it
 would seem this is possible on devices using the mac80211 subsystem,
 but from what I have read online it only works with madwifi drivers
 which is outdated and abandoned.

Most of the common mac80211-based devices allow this.  You can see what
modes your driver supports by doing:

$ iw phy phy0 info
...
  software interface modes (can always be added):
 * AP/VLAN
 * monitor
  valid interface combinations:
 * #{ managed } = 1, #{ AP, P2P-client, P2P-GO } = 1,
#{ P2P-device } = 1,
   total = 3, #channels = 2
...

This is for an Intel 7265 card, and you can see that this device
supports simultaneous STA and AP modes, but only one interface of each.

 Are there other drivers that tap into this capability of mac80211 or
 is no one else interested in this? Is the generic nl80211 driver
 capable of using this functionality and if so, how do I go about using
 it (note that the AP and Station sections of the above
 documentation page are blank)? If not, what would I have to change to
 enable the use of this dual mode capability?

Whether your device has this capability highly depends on the hardware,
firmware, and driver.  The 'iw' command I posted above will show what
your combination supports.

Dan


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] Add new mac80211 driver mwlwifi.

[Dan Williams]

On Tue, 2015-06-30 at 10:21 +0200, Johannes Berg wrote:
 On Tue, 2015-06-30 at 01:49 +, David Lin wrote:
  +++ b/drivers/net/wireless/mwlwifi/Kconfig
  @@ -0,0 +1,17 @@
  +config MWLWIFI
  +   tristate Marvell Wireless WiFi driver (mwlwifi)
  +   depends on PCI  MAC80211  MWIFIEX_PCIE=n
 
 I still think you need to get rid of this so we can build-test this
 driver properly.

The OLPC 8388 is another device that has two drivers, libertas and
libertas_tf.  I don't think there's any protection between then, you get
whatever gets loaded first by the kernel.  In that case, I think the
answer was either (a) only put the driver you want onto the system, or
(b) manually manage from userspace.  Given that this Marvell hardware is
likely intended for more customized use-cases (AP, embedded, etc?)
perhaps this would be an acceptable option for now...

I tend to agree with Johannes here; the builder of the kernel can
certainly adjust CONFIG_MWLWIFI and CONFIG_MWIFIEX to fit their
scenario, including leaving both enabled.

Dan

  +   select FW_LOADER
  +   select OF
 
 This looks OK, though I get a very strange dependency loop warning from
 Kconfig here.
 
 Looks like the driver now builds almost cleanly with sparse/smatch on
 64-bit.
 
 Two warnings remain, both are bugs:
 
  writew(0x00, (void __iomem *)priv-pcmd_buf[1]);
 
 cannot be right. This memory isn't __iomem, it's dma_alloc_coherent, so
 a simple write should be done.
 
 in mwl_rx_ring_init:
 
  rx_hndl-psk_buff =
  dev_alloc_skb(desc-rx_buf_size);
  
  if (skb_linearize(rx_hndl-psk_buff)) {
 
 *crash*. You also later check rx_hndl-psk_buff, but well after it
 already crashed.
 
 Also, this code sequence is utterly bogus. Please try to understand why
 and then remove it.
 
 You should also use paged RX since you're allocating *very large* buffe
 rs. We found that even alloc_pages(1) will fail eventually, you're
 doing an order-2 allocation here for every RX skb. At least used paged
 RX to get it down to order-1.
 
 johannes
 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: creating ap interface

[Dan Williams]

On Fri, 2015-06-19 at 09:59 +0200, Arend van Spriel wrote:
 On 06/18/15 16:26, Dan Williams wrote:
  On Wed, 2015-06-17 at 20:38 +0200, Arend van Spriel wrote:
  Hi Dan,
 
  When I create an AP interface using iw, it is followed by a change
  interface back to managed mode. I added a WARN_ON to see where it came
  from and it turns out to be the NetworkManager. However, I had disabled
  wifi as you suggested on the mailing list once. What is your take on
  this: bug or intentional?
 
  Which method was that to disable wifi?  Also, what NM version are you
  running?
 
 I used nmcli, ie. nmcli nm wifi off. Running 4.1-rc6 kernel on Ubuntu 
 14.04. Here nmcli version info:
 
 $ nmcli -v
 nmcli tool, version 0.9.8.8

Yeah, unfortunately that won't work with 0.9.8.8 for AP-mode interfaces.
It appears that NM still re-sets interfaces to STA mode when
cleaning/initializing them, including when moving from UNMANAGED -
UNAVAILABLE states where they stay until 'wifi on' is done.  The only
reason it does this is that some drivers used to be *awful* at scanning
in ad-hoc mode.  But these days NM should really just stop doing this;
so I filed:

https://bugzilla.gnome.org/show_bug.cgi?id=751269

At least with NM 0.9.10 and later you can set the interface to be
unmanaged using interface names, and you can also disable the wifi
plugin entirely as well.

But for the 2013-era 0.9.8, if you're able to control the MAC address of
the new AP interface, you can add that to the 'unmanaged-devices' line
in NetworkManager.conf.

Dan

 Regards,
 Arend
 
  Dan
 
  Regards,
  Arend
 
  [195312.837736] brcmfmac: brcmf_cfg80211_add_iface enter: wl5ap type 3
  [195312.844033] brcmfmac: brcmf_ap_add_vif Adding vif wl5ap
  [195312.849525] brcmfmac: brcmf_alloc_vif allocating virtual interface
  (size=3136)
  [195312.856842] brcmfmac: brcmf_fil_bsscfg_data_set ifidx=0, bssidx=0,
  name=bsscfg:ssid, len=40
  [195312.865276] brcmutil: data
  [195312.868070] : 02 00 00 00 05 00 00 00 73 73 69 64 32 00 00
  00  ssid2...
  [195312.876187] 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00  
  [195312.884301] 0020: 00 00 00 00 00 00 00 00
   
  [195312.891725] brcmfmac: brcmf_sdio_bus_txctl Enter
  [195312.896466] brcmfmac: brcmf_sdio_dpc Enter
  [195312.900663] brcmfmac: brcmf_sdio_kso_control Enter: on=1
  [195312.910548] brcmfmac: brcmf_sdio_isr Enter
  [195312.914877] brcmfmac: brcmf_sdio_tx_ctrlframe Enter
  [195312.919943] brcmfmac: brcmf_sdio_dpc Enter
  [195312.920022] brcmfmac: brcmf_sdio_bus_rxctl Enter
  [195312.928967] brcmfmac: brcmf_sdio_isr Enter
  [195312.933282] brcmfmac: brcmf_sdio_dpc Dongle reports CHIPACTIVE
  [195312.939220] brcmfmac: brcmf_sdio_readframes Enter
  [195312.944099] brcmfmac: brcmf_sdio_read_control Enter
  [195312.949234] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame,
  got 68 expected 68
  [195312.949310] brcmfmac: brcmf_fweh_event_worker event IF (54) ifidx 1
  bsscfg 2 addr 00:90:4c:70:43:54
  [195312.949312] brcmfmac: brcmf_fweh_event_worker   version 2 flags 0
  status 0 reason 0
  [195312.949314] brcmutil: event payload, len=5
  [195312.949316] : 01 01 00 02 01
   .
  [195312.949318] brcmfmac: brcmf_fweh_handle_if_event action: 1 idx: 1
  bsscfg: 2 flags: 0 role: 1
  [195312.949320] brcmfmac: brcmf_fweh_handle_if_event adding wl0.2
  (00:90:4c:70:43:54)
  [195312.949322] brcmfmac: brcmf_add_if Enter, idx=2, ifidx=1
  [195312.949323] brcmfmac: brcmf_add_if allocate netdev interface
  [195312.949333] brcmfmac: brcmf_add_if   pid:135f, if:wl0.2
  (00:90:4c:70:43:54) created ===
  [195312.949336] brcmfmac: brcmf_fws_macdesc_init enter: desc
  8800bb798b00 ea=00:90:4c:70:43:54, ifidx=1
  [195312.949338] brcmfmac: brcmf_fws_add_interface added MACIF:1
  [195312.949341] brcmfmac: brcmf_notify_vif_event Enter: action 1 flags 0
  ifidx 1 bsscfg 2
  [195312.949403] brcmfmac: brcmf_sdio_dpc Enter
  [195312.970325] brcmfmac: brcmf_sdio_kso_control Enter: on=0
  [195313.054361] brcmfmac: brcmf_net_attach Enter, idx=2
  mac=00:90:4c:70:43:54
  [195313.061537] brcmfmac: brcmf_netdev_get_stats Enter, idx=2
  [195313.067170] brcmfmac: brcmf_net_attach wl5ap: Broadcom Dongle Host
  Driver
  [195313.074637] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
  [195313.080149] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
  [195313.085653] brcmfmac: brcmf_netdev_get_stats Enter, idx=2
  [195313.091877] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
  [195313.097400] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
  [195313.102934] brcmfmac: brcmf_netdev_get_stats Enter, idx=2
  [195313.108825] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
  [195313.114322] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
  [195313.119835] brcmfmac: brcmf_netdev_get_stats Enter, idx=2
  [195313.125593] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
  [195313.131117] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
  [195313.136610] brcmfmac: brcmf_netdev_get_stats

Re: creating ap interface

[Dan Williams]

On Wed, 2015-06-17 at 20:38 +0200, Arend van Spriel wrote:
 Hi Dan,
 
 When I create an AP interface using iw, it is followed by a change 
 interface back to managed mode. I added a WARN_ON to see where it came 
 from and it turns out to be the NetworkManager. However, I had disabled 
 wifi as you suggested on the mailing list once. What is your take on 
 this: bug or intentional?

Which method was that to disable wifi?  Also, what NM version are you
running?

Dan

 Regards,
 Arend
 
 [195312.837736] brcmfmac: brcmf_cfg80211_add_iface enter: wl5ap type 3
 [195312.844033] brcmfmac: brcmf_ap_add_vif Adding vif wl5ap
 [195312.849525] brcmfmac: brcmf_alloc_vif allocating virtual interface 
 (size=3136)
 [195312.856842] brcmfmac: brcmf_fil_bsscfg_data_set ifidx=0, bssidx=0, 
 name=bsscfg:ssid, len=40
 [195312.865276] brcmutil: data
 [195312.868070] : 02 00 00 00 05 00 00 00 73 73 69 64 32 00 00 
 00  ssid2...
 [195312.876187] 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00  
 [195312.884301] 0020: 00 00 00 00 00 00 00 00 
 
 [195312.891725] brcmfmac: brcmf_sdio_bus_txctl Enter
 [195312.896466] brcmfmac: brcmf_sdio_dpc Enter
 [195312.900663] brcmfmac: brcmf_sdio_kso_control Enter: on=1
 [195312.910548] brcmfmac: brcmf_sdio_isr Enter
 [195312.914877] brcmfmac: brcmf_sdio_tx_ctrlframe Enter
 [195312.919943] brcmfmac: brcmf_sdio_dpc Enter
 [195312.920022] brcmfmac: brcmf_sdio_bus_rxctl Enter
 [195312.928967] brcmfmac: brcmf_sdio_isr Enter
 [195312.933282] brcmfmac: brcmf_sdio_dpc Dongle reports CHIPACTIVE
 [195312.939220] brcmfmac: brcmf_sdio_readframes Enter
 [195312.944099] brcmfmac: brcmf_sdio_read_control Enter
 [195312.949234] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, 
 got 68 expected 68
 [195312.949310] brcmfmac: brcmf_fweh_event_worker event IF (54) ifidx 1 
 bsscfg 2 addr 00:90:4c:70:43:54
 [195312.949312] brcmfmac: brcmf_fweh_event_worker   version 2 flags 0 
 status 0 reason 0
 [195312.949314] brcmutil: event payload, len=5
 [195312.949316] : 01 01 00 02 01 
 .
 [195312.949318] brcmfmac: brcmf_fweh_handle_if_event action: 1 idx: 1 
 bsscfg: 2 flags: 0 role: 1
 [195312.949320] brcmfmac: brcmf_fweh_handle_if_event adding wl0.2 
 (00:90:4c:70:43:54)
 [195312.949322] brcmfmac: brcmf_add_if Enter, idx=2, ifidx=1
 [195312.949323] brcmfmac: brcmf_add_if allocate netdev interface
 [195312.949333] brcmfmac: brcmf_add_if   pid:135f, if:wl0.2 
 (00:90:4c:70:43:54) created ===
 [195312.949336] brcmfmac: brcmf_fws_macdesc_init enter: desc 
 8800bb798b00 ea=00:90:4c:70:43:54, ifidx=1
 [195312.949338] brcmfmac: brcmf_fws_add_interface added MACIF:1
 [195312.949341] brcmfmac: brcmf_notify_vif_event Enter: action 1 flags 0 
 ifidx 1 bsscfg 2
 [195312.949403] brcmfmac: brcmf_sdio_dpc Enter
 [195312.970325] brcmfmac: brcmf_sdio_kso_control Enter: on=0
 [195313.054361] brcmfmac: brcmf_net_attach Enter, idx=2 
 mac=00:90:4c:70:43:54
 [195313.061537] brcmfmac: brcmf_netdev_get_stats Enter, idx=2
 [195313.067170] brcmfmac: brcmf_net_attach wl5ap: Broadcom Dongle Host 
 Driver
 [195313.074637] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
 [195313.080149] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
 [195313.085653] brcmfmac: brcmf_netdev_get_stats Enter, idx=2
 [195313.091877] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
 [195313.097400] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
 [195313.102934] brcmfmac: brcmf_netdev_get_stats Enter, idx=2
 [195313.108825] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
 [195313.114322] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
 [195313.119835] brcmfmac: brcmf_netdev_get_stats Enter, idx=2
 [195313.125593] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
 [195313.131117] brcmfmac: brcmf_netdev_get_stats Enter, idx=0
 [195313.136610] brcmfmac: brcmf_netdev_get_stats Enter, idx=2
 [195313.142185] brcmfmac: brcmf_cfg80211_change_iface Enter, idx=2, type=2
 [195313.148804] [ cut here ]
 [195313.153520] WARNING: CPU: 1 PID: 1398 at 
 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c:864 
 brcmf_cfg80211_change_iface+0x2a9/0x2d0 [brcmfmac]()
 [195313.166897] Modules linked in: brcmfmac(O) brcmutil(O) sdhci_pci 
 sdhci cfg80211 nfsv3 nfs_acl nf_conntrack_ipv4 nf_defrag_ipv4 
 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 iptable_mangle 
 xt_tcpudp ip6table_filter ip6_tables iptable_filter ip_tables 
 ebtable_nat ebtables x_tables autofs4 nfs bridge stp llc lockd grace 
 sunrpc fscache dell_wmi sparse_keymap snd_hda_codec_hdmi 
 snd_hda_codec_idt snd_hda_codec_generic dell_laptop pl2303 usbserial 
 nouveau dcdbas snd_hda_intel snd_hda_controller i8k snd_hda_codec 
 snd_hwdep snd_hda_core snd_pcm snd_seq_midi snd_seq_midi_event 
 snd_rawmidi snd_seq snd_seq_device coretemp crc32c_intel snd_timer 
 mxm_wmi intel_agp microcode serio_raw ttm drm_kms_helper intel_gtt 
 lpc_ich snd drm i2c_algo_bit intel_ips agpgart soundcore mfd_core video 
 mmc_block e1000e ptp 

Re: [PATCH v2] Add new mac80211 driver mwlwifi.

[Dan Williams]

On Wed, 2015-06-17 at 09:27 +0200, Johannes Berg wrote:
 On Wed, 2015-06-17 at 06:06 +, David Lin wrote:
 
 (not really reading all of this right now, just two small comments)
 
  +struct mwl_tx_desc {
  +   u8 data_rate;
  +   u8 tx_priority;
  +   __le16 qos_ctrl;
  +   __le32 pkt_ptr;
  +   __le16 pkt_len;
  +   u8 dest_addr[ETH_ALEN];
  +   __le32 pphys_next;
  +   __le32 sap_pkt_info;
  +   __le32 rate_info;
  +   u8 type;
  +   u8 xmit_control; /* bit 0: use rateinfo, bit 1: disable ampdu */
  +   __le16 reserved;
  +   __le32 tcpack_sn;
  +   __le32 tcpack_src_dst;
  +   struct sk_buff *psk_buff;
  +   struct mwl_tx_desc *pnext;
  +   u8 reserved1[2];
  +   u8 packet_info;
  +   u8 packet_id;
  +   __le16 packet_len_and_retry;
  +   __le16 packet_rate_info;
  +   u8 *sta_info;
  +   __le32 status;
  +} __packed;
 
 This ... cannot be right. You can't have a pointer in a structure that's
 used by firmware, and the __leXX and __packed indicates that it's used
 by firmware. But pointer size is variable, so *clearly* this cannot be
 correct.

I can't see anywhere that mwl_tx_desc-sta_info actually gets read by
the driver; it only appears to be written by mwl_tx_skb().  So (even if
it was intended to be) it's clearly not a stashed pointer for later.

Like you say it's size also needs to be specified, since won't it be 64
bits or 32 depending on the architecture?  I can't imagine the firmware
would like that much.

At the very least, this member and its usage in mwl_tx_skb() deserves a
code comment about what's going on and why a host pointer is getting
stuffed into a field that the firmware is reading...

Dan

  +struct mwl_rx_desc {
  +   __le16 pkt_len;  /* total length of received data  */
  +   __le16 rate; /* receive rate information   */
  +   __le32 pphys_buff_data;  /* physical address of payload data   */
  +   __le32 pphys_next;   /* physical address of next RX desc   */
  +   __le16 qos_ctrl; /* received QosCtrl field variable*/
  +   __le16 ht_sig2;  /* like name states   */
  +   __le32 hw_rssi_info;
  +   __le32 hw_noise_floor_info;
  +   u8 noise_floor;
  +   u8 reserved[3];
  +   u8 rssi; /* received signal strengt indication */
  +   u8 status;   /* status field containing USED bit   */
  +   u8 channel;  /* channel this pkt was received on   */
  +   u8 rx_control;   /* the control element of the desc*/
  +   /* above are 32bits aligned and is same as FW, RxControl put at end
  +* for sync
  +*/
  +   struct sk_buff *psk_buff;/* associated sk_buff for Linux   */
  +   void *pbuff_data;/* virtual address of payload data*/
  +   struct mwl_rx_desc *pnext;   /* virtual address of next RX desc*/
  +} __packed;
 
 Same here. If you really need to have a firmware and driver struct as
 indicated by the comment, you should probably have
 
 struct mwl_rx_info {
   /* firmware info */
 } __packed;
 
 struct mwl_rx_desc {
   struct mwl_rx_info info;
   /* driver info */
 };
 
 (note the lack of __packed also, __packed often makes accesses far less
 efficient)
 
  +struct mwl_desc_data {
  +   dma_addr_t pphys_tx_ring;  /* ptr to first TX desc (phys.)*/
  +   struct mwl_tx_desc *ptx_ring;  /* ptr to first TX desc (virt.)*/
  +   struct mwl_tx_desc *pnext_tx_desc; /* next TX desc that can be used   */
  +   struct mwl_tx_desc *pstale_tx_desc;/* the staled TX descriptor*/
  +   dma_addr_t pphys_rx_ring;  /* ptr to first RX desc (phys.)*/
  +   struct mwl_rx_desc *prx_ring;  /* ptr to first RX desc (virt.)*/
  +   struct mwl_rx_desc *pnext_rx_desc; /* next RX desc that can be used   */
  +   unsigned int wcb_base; /* FW base offset for registers*/
  +   unsigned int rx_desc_write;/* FW descriptor write position*/
  +   unsigned int rx_desc_read; /* FW descriptor read position */
  +   unsigned int rx_buf_size;  /* length of the RX buffers*/
  +} __packed;
 
 ditto - don't pack driver structs
 
 Also, you probably really should have two header files - one for the
 firmware structs and one for the driver structs - especially since you
 seem to be confusing the two!
 
  +++ b/drivers/net/wireless/mwlwifi/fwcmd.c
 
 There are a lot of struct definitions here that you could move to the
 same header file.
 
  +#if SYSADPT_NUM_OF_DESC_DATA  3
 
 how does that get set?
 
  +/* Description:  This file implements main functions of this module.
  + */
 
 You still have a pretty strange comment style.
 
  +   hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION;
 
 This was really what I was looking for :)
 
 Note that I changed this entirely in the mac80211-next tree. I don't
 know how Kalle wants to handle this, but given that your driver isn't
 going to make the cut for 4.2 anyway, you should probably 

Re: packet loss, disconnects and possible bug in iwlwifi

[Dan Williams]

On Wed, 2015-05-27 at 08:54 -0500, Dan Williams wrote:
 On Wed, 2015-05-27 at 02:44 +0300, Nick Dimov wrote:
  Hello,
  thank you for your response. I attach the full syslog since the last
  boot which contains some disconnects. I enabled debug mode for
  wpa_supplicant with -dd option (let me know if you need anything else).
  
  I also tried connecting directly, i.e. without NetworkManager but
  manually with wpa_supplicant and I still get disconnects, howvever
  wpa_supplicant gives different logs with different drivers. Please, see
  the file wifi.log (you can see there the driver i used in
  wpa_supplicant, that log doesn't have the debug activated but let me
  know if you need that too)
 
 Also, make sure you stop NetworkManager when you're doing the manual
 connection.  With systemd, you need to 'systemctl mask NetworkManager'
 and then 'systemctl stop NetworkManager' to prevent it from being D-Bus
 activated too.

Or, nmcli net off to put NM to sleep temporarily, without messing
around with systemd.

Dan

 The reason I say this is because in your logs there are
 locally-generated disconnections, and that happens when NetworkManager
 is still running and hasn't been told to stop handling WiFi, and then
 somebody runs another wpa_supplicant alongside.
 
 Dan
 
  Thank you again,
  Nick.
  
  On 25.05.2015 14:33, Emmanuel Grumbach wrote:
   On Sat, May 23, 2015 at 1:28 PM, Nick Dimov dimovn...@gmail.com wrote:
   Hello,
   I recently bought the Intel 7260 AC wifi card (below is the PCI info)
   and the card works perfectly in windows with the latest intel driver but
   in linux I get deauthenticating and disconnects (reason -3) every minute
   or so. When these disconnects happen I get packet loss. In the attached
   file iwlwifi_dmesg.txt you can see the log that is produced each time a
   disconnect happens. I also tried connecting on 2.4Ghz but I get the same
   packet loss. I also put the last firmware from
   http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git
   but it did not help.
   Please increase the debug level of the supplicant. And attach the full 
   syslog.
  
   There is also another problem: In windows i can see it connecting on
   860mbps, but on linux it never goes higher than 600mbps (i check this
   with iwconfig) and it stays somewhere on 500mbps.
  
   Can you please help me solve this?
   Thank you.
  
   uname -a
   Linux nick-laptop 3.19.0-18-generic #18-Ubuntu SMP Tue May 19 18:31:35
   UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
  
   lspci info:
   03:00.0 Network controller: Intel Corporation Wireless 7260 (rev bb)
   Subsystem: Intel Corporation Dual Band Wireless-AC 7260
   Flags: bus master, fast devsel, latency 0, IRQ 29
   Memory at f720 (64-bit, non-prefetchable) [size=8K]
   Capabilities: [c8] Power Management version 3
   Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
   Capabilities: [40] Express Endpoint, MSI 00
   Capabilities: [100] Advanced Error Reporting
   Capabilities: [140] Device Serial Number d8-fc-93-ff-ff-e4-70-d7
   Capabilities: [14c] Latency Tolerance Reporting
   Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1
   Len=014 ?
   Kernel driver in use: iwlwifi
  
  
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: packet loss, disconnects and possible bug in iwlwifi

[Dan Williams]

On Wed, 2015-05-27 at 02:44 +0300, Nick Dimov wrote:
 Hello,
 thank you for your response. I attach the full syslog since the last
 boot which contains some disconnects. I enabled debug mode for
 wpa_supplicant with -dd option (let me know if you need anything else).
 
 I also tried connecting directly, i.e. without NetworkManager but
 manually with wpa_supplicant and I still get disconnects, howvever
 wpa_supplicant gives different logs with different drivers. Please, see
 the file wifi.log (you can see there the driver i used in
 wpa_supplicant, that log doesn't have the debug activated but let me
 know if you need that too)

Also, make sure you stop NetworkManager when you're doing the manual
connection.  With systemd, you need to 'systemctl mask NetworkManager'
and then 'systemctl stop NetworkManager' to prevent it from being D-Bus
activated too.

The reason I say this is because in your logs there are
locally-generated disconnections, and that happens when NetworkManager
is still running and hasn't been told to stop handling WiFi, and then
somebody runs another wpa_supplicant alongside.

Dan

 Thank you again,
 Nick.
 
 On 25.05.2015 14:33, Emmanuel Grumbach wrote:
  On Sat, May 23, 2015 at 1:28 PM, Nick Dimov dimovn...@gmail.com wrote:
  Hello,
  I recently bought the Intel 7260 AC wifi card (below is the PCI info)
  and the card works perfectly in windows with the latest intel driver but
  in linux I get deauthenticating and disconnects (reason -3) every minute
  or so. When these disconnects happen I get packet loss. In the attached
  file iwlwifi_dmesg.txt you can see the log that is produced each time a
  disconnect happens. I also tried connecting on 2.4Ghz but I get the same
  packet loss. I also put the last firmware from
  http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git
  but it did not help.
  Please increase the debug level of the supplicant. And attach the full 
  syslog.
 
  There is also another problem: In windows i can see it connecting on
  860mbps, but on linux it never goes higher than 600mbps (i check this
  with iwconfig) and it stays somewhere on 500mbps.
 
  Can you please help me solve this?
  Thank you.
 
  uname -a
  Linux nick-laptop 3.19.0-18-generic #18-Ubuntu SMP Tue May 19 18:31:35
  UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
 
  lspci info:
  03:00.0 Network controller: Intel Corporation Wireless 7260 (rev bb)
  Subsystem: Intel Corporation Dual Band Wireless-AC 7260
  Flags: bus master, fast devsel, latency 0, IRQ 29
  Memory at f720 (64-bit, non-prefetchable) [size=8K]
  Capabilities: [c8] Power Management version 3
  Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
  Capabilities: [40] Express Endpoint, MSI 00
  Capabilities: [100] Advanced Error Reporting
  Capabilities: [140] Device Serial Number d8-fc-93-ff-ff-e4-70-d7
  Capabilities: [14c] Latency Tolerance Reporting
  Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1
  Len=014 ?
  Kernel driver in use: iwlwifi
 
 


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: packet loss, disconnects and possible bug in iwlwifi

[Dan Williams]

On Wed, 2015-05-27 at 02:44 +0300, Nick Dimov wrote:
 Hello,
 thank you for your response. I attach the full syslog since the last
 boot which contains some disconnects. I enabled debug mode for
 wpa_supplicant with -dd option (let me know if you need anything else).
 
 I also tried connecting directly, i.e. without NetworkManager but
 manually with wpa_supplicant and I still get disconnects, howvever
 wpa_supplicant gives different logs with different drivers. Please, see
 the file wifi.log (you can see there the driver i used in
 wpa_supplicant, that log doesn't have the debug activated but let me
 know if you need that too)

So if NM isn't involved in your later runs (and it's not, looking at the
logs), then I'm not sure what the issue could be except something in the
driver.

mai 27 02:31:54 nick-G55VW wpa_supplicant[1565]: nl80211: Event message
available
mai 27 02:31:54 nick-G55VW wpa_supplicant[1565]: nl80211: Drv Event 20
(NL80211_CMD_DEL_STATION) received for wlan5
mai 27 02:31:54 nick-G55VW wpa_supplicant[1565]: nl80211: Delete station
d8:50:e6:da:1d:b4
mai 27 02:31:54 nick-G55VW kernel: wlan5: deauthenticating from
d8:50:e6:da:1d:b4 by local choice (Reason: 3=DEAUTH_LEAVING)

I don't see anything interesting around those lines, so I guess its up
to Emmanuel now...  the tracing he requests would be good to get.

Dan

 Thank you again,
 Nick.
 
 On 25.05.2015 14:33, Emmanuel Grumbach wrote:
  On Sat, May 23, 2015 at 1:28 PM, Nick Dimov dimovn...@gmail.com wrote:
  Hello,
  I recently bought the Intel 7260 AC wifi card (below is the PCI info)
  and the card works perfectly in windows with the latest intel driver but
  in linux I get deauthenticating and disconnects (reason -3) every minute
  or so. When these disconnects happen I get packet loss. In the attached
  file iwlwifi_dmesg.txt you can see the log that is produced each time a
  disconnect happens. I also tried connecting on 2.4Ghz but I get the same
  packet loss. I also put the last firmware from
  http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git
  but it did not help.
  Please increase the debug level of the supplicant. And attach the full 
  syslog.
 
  There is also another problem: In windows i can see it connecting on
  860mbps, but on linux it never goes higher than 600mbps (i check this
  with iwconfig) and it stays somewhere on 500mbps.
 
  Can you please help me solve this?
  Thank you.
 
  uname -a
  Linux nick-laptop 3.19.0-18-generic #18-Ubuntu SMP Tue May 19 18:31:35
  UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
 
  lspci info:
  03:00.0 Network controller: Intel Corporation Wireless 7260 (rev bb)
  Subsystem: Intel Corporation Dual Band Wireless-AC 7260
  Flags: bus master, fast devsel, latency 0, IRQ 29
  Memory at f720 (64-bit, non-prefetchable) [size=8K]
  Capabilities: [c8] Power Management version 3
  Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
  Capabilities: [40] Express Endpoint, MSI 00
  Capabilities: [100] Advanced Error Reporting
  Capabilities: [140] Device Serial Number d8-fc-93-ff-ff-e4-70-d7
  Capabilities: [14c] Latency Tolerance Reporting
  Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1
  Len=014 ?
  Kernel driver in use: iwlwifi
 
 


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cfg80211: properly send NL80211_ATTR_DISCONNECTED_BY_AP in disconnect

[Dan Williams]

On Fri, 2015-05-22 at 16:25 +0200, Johannes Berg wrote:
 From: Johannes Berg johannes.b...@intel.com
 
 When we disconnect from the AP, drivers call cfg80211_disconnect().
 This doesn't know whether the disconnection was initiated locally
 or by the AP though, which can cause problems with the supplicant,
 for example with WPS. This issue obviously doesn't show up with any
 mac80211 based driver since mac80211 doesn't call this function.
 
 Fix this by requiring drivers to indicate whether the disconnect is
 locally generated or not. I've tried to update the drivers, but may
 not have gotten the values correct, and some drivers may currently
 not be able to report correct values. In case of doubt I left it at
 false, which is the current behaviour.
 
 Reported-by: Matthieu Mauger matthieux.mau...@intel.com
 Tested-by: Matthieu Mauger matthieux.mau...@intel.com
 Signed-off-by: Johannes Berg johannes.b...@intel.com
 ---
  drivers/net/wireless/ath/ath6kl/cfg80211.c | 4 ++--
  drivers/net/wireless/ath/wil6210/main.c| 2 +-
  drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 4 ++--
  drivers/net/wireless/libertas/cfg.c| 4 ++--
  drivers/net/wireless/mwifiex/join.c| 2 +-
  drivers/net/wireless/mwifiex/sta_event.c   | 2 +-
  drivers/net/wireless/rndis_wlan.c  | 2 +-
  drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c  | 2 +-
  drivers/staging/wlan-ng/cfg80211.c | 2 +-
  include/net/cfg80211.h | 4 +++-
  net/wireless/core.h| 1 +
  net/wireless/sme.c | 4 +++-
  net/wireless/util.c| 3 ++-
  13 files changed, 21 insertions(+), 15 deletions(-)
 
 diff --git a/drivers/net/wireless/libertas/cfg.c 
 b/drivers/net/wireless/libertas/cfg.c
 index 1a4d558022d8..9e3e3176670b 100644
 --- a/drivers/net/wireless/libertas/cfg.c
 +++ b/drivers/net/wireless/libertas/cfg.c
 @@ -841,7 +841,7 @@ void lbs_send_disconnect_notification(struct lbs_private 
 *priv)
  
   cfg80211_disconnected(priv-dev,
   0,
 - NULL, 0,
 + NULL, 0, false,
   GFP_KERNEL);

lbs_send_disconnect_notification() could use a 'bool locally_generated'
parameter that gets passed directly to cfg80211_disconnected(), which in
turn gets passed through from a new 'bool locally_generated' parameter
for lbs_mac_event_disconnected() (which is the only caller of
lbs_send_disconnect_notification).

The calls to lbs_mac_event_disconnected() would pass these values:

lbs_leave_ibss(): true
lbs_process_event(): MACREG_INT_CODE_DEAUTHENTICATED: false
lbs_process_event(): MACREG_INT_CODE_DISASSOCIATED: false
lbs_process_event(): MACREG_INT_CODE_LINK_LOST_NO_SCAN: true
 
   lbs_deb_leave(LBS_DEB_CFG80211);
 @@ -1458,7 +1458,7 @@ int lbs_disconnect(struct lbs_private *priv, u16 reason)
  
   cfg80211_disconnected(priv-dev,
   reason,
 - NULL, 0,
 + NULL, 0, true,
   GFP_KERNEL);
   priv-connect_status = LBS_DISCONNECTED;

This one is correct.

Dan


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless driver ath9k and module 80211 interaction

[Dan Williams]

On Fri, 2015-04-17 at 18:01 +0200, Roshanak Rasoli wrote:
 Hi experts,
 
 I have a question about the code  that you wrote;
 
 1- How does the ath9k announce itself to the mac80211?

The ath9k driver handles its own hardware detection via normal kernel
probing and matching mechanisms, and you end up in
drivers/net/wireless/ath/ath9k/pci.c::ath_pci_probe() or ath_ahb_probe()
depending on the bus the device uses.  From there ath9k calls
ieee80211_alloc_hw() which is how ath9k announces itself to mac80211.

 2- How can the mac80211 know how to configure the ath9k.

The hardware module (ath9k) sends a set of ops (struct ieee80211_ops)
to mac80211 in the ieee80211_alloc_hw() call that contains callbacks
that mac80211 will run when it needs to configure the device.  See
drivers/net/wireless/ath/ath9k/main.c for the ath9k_ops structure.

Dan

 Could you please point out to the code.
 
 Thanks in advance.
 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7265 wireless performance unstable on Linux = 3.19

[Dan Williams]

On Tue, 2015-03-31 at 13:32 -0700, Ryan Finnie wrote:
 On 03/31/2015 02:15 AM, Emmanuel Grumbach wrote:
  Please open a bug on bugzilla.kernel.org and CC
  i...@linux.intel.com to the bug. Attach your syslog output as
  well.
 
 Done: https://bugzilla.kernel.org/show_bug.cgi?id=95901
 
  It seems that the supplicant is deauthenticating. What is your
  supplicant version?
 
 wpasupplicant 2.1-0ubuntu7 from Ubuntu vivid.  From the syslog output,
 it appears the wpa_supplicant output is reacting to the kernel event,
 with nothing relevant preceding it:
 
 Mar 31 13:15:11 linda systemd[1]: Started Stop ureadahead data collection.
 Mar 31 13:15:20 linda kernel: [   72.442153] wlan0: deauthenticating
 from 38:2c:4a:5c:7f:e4 by local choice (Reason: 3=DEAUTH_LEAVING)
 Mar 31 13:15:20 linda kernel: [   72.457967] cfg80211: Calling CRDA to
 update world regulatory domain
 Mar 31 13:15:20 linda wpa_supplicant[902]: wlan0:
 CTRL-EVENT-DISCONNECTED bssid=38:2c:4a:5c:7f:e4 reason=3
 locally_generated=1
 Mar 31 13:15:20 linda NetworkManager[815]: warn Connection
 disconnected (reason -3)

I've looked through the log for relevant NetworkManager stuff, since
reason=3/locally-generated disconnections are often a result of NM's
association attempt timing out or moving to a new network.  In this
case, I cannot find any evidence of NetworkManager disconnecting
intentionally, it seems to come out of nowhere.

Dan

  One idea came through my mind. Can you try this?
  
  diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c 
  b/drivers/net/wireless/iwlwifi/mvm/mac80211.c index
  302c8cc..7c12c9f 100644 ---
  a/drivers/net/wireless/iwlwifi/mvm/mac80211.c +++
  b/drivers/net/wireless/iwlwifi/mvm/mac80211.c @@ -525,7 +525,7 @@
  int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm) else 
  hw-wiphy-flags = ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
  
  -   if (IWL_UCODE_API(mvm-fw-ucode_ver) = 10) { +   if
  (IWL_UCODE_API(mvm-fw-ucode_ver) = 10  false) { 
  hw-wiphy-flags |= WIPHY_FLAG_SUPPORTS_SCHED_SCAN; 
  hw-wiphy-max_sched_scan_ssids = PROBE_OPTION_MAX; 
  hw-wiphy-max_match_sets = IWL_SCAN_MAX_PROFILES;
 
 Sorry, it didn't appear to have any effect; DEAUTH_LEAVING would still
 occur every ~60 seconds.
 
 RF
 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 14e4:4331 [MacBookPro9,2] b43 802.11 won't connect to Verzion Jetpack MiFi 5510L (no secrets provided)

[Dan Williams]

On Sun, 2015-03-29 at 09:52 -0500, Christopher M. Penalver wrote:
 [1.] One line summary of the problem:
 14e4:4331 [MacBookPro9,2] b43 802.11 won't connect to Verzion Jetpack
 MiFi 5510L (no secrets provided)
 
 [2.] Full description of the problem/report:
 The laptop won't connect to an 802.11 g/n WAP. The same device with
 the proprietary bcmwl drivers works, and other devices (and operating
 systems) works fine with the same WAP. Latest router firmware and
 laptop BIOS already applied.

Mar 29 09:34:08 macbookpro kernel: [ 7347.474993] wlan1:
XX:XX:XX:XX:XX:XX denied association (code=27)

27 = Association denied because the requesting STA does not
support HT features

I'll leave it up to Arend to talk about specifics with Broadcom
hardware...

Dan

 Relevant syslog:
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info Activation
 (wlan1) starting connection 'SSID'
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info Activation
 (wlan1) Stage 1 of 5 (Device Prepare) scheduled...
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info Activation
 (wlan1) Stage 1 of 5 (Device Prepare) started...
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info (wlan1): device
 state change: disconnected - prepare (reason 'none') [30 40 0]
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info Activation
 (wlan1) Stage 2 of 5 (Device Configure) scheduled...
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info Activation
 (wlan1) Stage 1 of 5 (Device Prepare) complete.
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info Activation
 (wlan1) Stage 2 of 5 (Device Configure) starting...
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info (wlan1): device
 state change: prepare - config (reason 'none') [40 50 0]
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info Activation
 (wlan1/wireless): connection 'SSID' has security, and secrets exist.
 No new secrets needed.
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info Config: added
 'ssid' value 'SSID'
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info Config: added
 'scan_ssid' value '1'
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info Config: added
 'key_mgmt' value 'WPA-PSK'
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info Config: added
 'psk' value 'omitted'
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info Activation
 (wlan1) Stage 2 of 5 (Device Configure) complete.
 Mar 29 09:34:07 macbookpro NetworkManager[755]: info (wlan1):
 supplicant interface state: inactive - scanning
 Mar 29 09:34:07 macbookpro wpa_supplicant[838]: message repeated 7
 times: [ wlan1: CTRL-EVENT-SCAN-STARTED]
 Mar 29 09:34:08 macbookpro wpa_supplicant[838]: wlan1: SME: Trying to
 authenticate with XX:XX:XX:XX:XX:XX (SSID='SSID' freq=2427 MHz)
 Mar 29 09:34:08 macbookpro kernel: [ 7347.429080] wlan1: authenticate
 with XX:XX:XX:XX:XX:XX
 Mar 29 09:34:08 macbookpro NetworkManager[755]: info (wlan1):
 supplicant interface state: scanning - authenticating
 Mar 29 09:34:08 macbookpro wpa_supplicant[838]: wlan1: Trying to
 associate with XX:XX:XX:XX:XX:XX (SSID='SSID' freq=2427 MHz)
 Mar 29 09:34:08 macbookpro kernel: [ 7347.468770] wlan1: send auth to
 XX:XX:XX:XX:XX:XX (try 1/3)
 Mar 29 09:34:08 macbookpro kernel: [ 7347.470425] wlan1: authenticated
 Mar 29 09:34:08 macbookpro NetworkManager[755]: info (wlan1):
 supplicant interface state: authenticating - associating
 Mar 29 09:34:08 macbookpro kernel: [ 7347.472671] wlan1: associate
 with XX:XX:XX:XX:XX:XX (try 1/3)
 Mar 29 09:34:08 macbookpro kernel: [ 7347.474991] wlan1: RX AssocResp
 from XX:XX:XX:XX:XX:XX (capab=0x431 status=27 aid=0)
 Mar 29 09:34:08 macbookpro kernel: [ 7347.474993] wlan1:
 XX:XX:XX:XX:XX:XX denied association (code=27)
 Mar 29 09:34:08 macbookpro wpa_supplicant[838]: wlan1:
 CTRL-EVENT-ASSOC-REJECT bssid=XX:XX:XX:XX:XX:XX status_code=27
 Mar 29 09:34:08 macbookpro wpa_supplicant[838]: wlan1: SME: Deauth
 request to the driver failed
 Mar 29 09:34:08 macbookpro wpa_supplicant[838]: wlan1:
 CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid=SSID auth_failures=1
 duration=10
 Mar 29 09:34:08 macbookpro NetworkManager[755]: info (wlan1):
 supplicant interface state: associating - disconnected
 Mar 29 09:34:18 macbookpro wpa_supplicant[838]: wlan1: CTRL-EVENT-SCAN-STARTED
 Mar 29 09:34:18 macbookpro NetworkManager[755]: info (wlan1):
 supplicant interface state: disconnected - scanning
 Mar 29 09:34:19 macbookpro wpa_supplicant[838]: wlan1:
 CTRL-EVENT-SSID-REENABLED id=0 ssid=SSID
 Mar 29 09:34:19 macbookpro wpa_supplicant[838]: wlan1: SME: Trying to
 authenticate with XX:XX:XX:XX:XX:XX (SSID='SSID' freq=2427 MHz)
 Mar 29 09:34:19 macbookpro kernel: [ 7358.762637] wlan1: authenticate
 with XX:XX:XX:XX:XX:XX
 Mar 29 09:34:19 macbookpro NetworkManager[755]: info (wlan1):
 supplicant interface state: scanning - authenticating
 Mar 29 09:34:19 macbookpro wpa_supplicant[838]: wlan1: Trying to
 associate with XX:XX:XX:XX:XX:XX (SSID='SSID' freq=2427 MHz)
 Mar 29 09:34:19 macbookpro kernel: [ 7358.802148] wlan1: send 

Re: Broadcom 43340

[Dan Williams]

On Tue, 2015-03-17 at 21:01 +, Jürgen Bausa wrote:
 Arend van Spriel arend@... writes:
 
  
  On 03/15/15 21:38, Jürgen Bausa wrote:
  
   would be nice, if you could make it clear.
  
  
  Maybe you need to mount it. This is what I found [1]:
  
  $ sudo mount -t efivarfs none /sys/firmware/efi/efivars
  
 
 Thanks, that worked. Now I have firmware and nvram-file and the driver seems
 to load ok. At least I have an interface wlan0.
 
 However, I am not able to connect.Network-manager just says interface is
 being set up ... forever. I have no idea howto debug this. In the other
 post you said that the nl80211 driver should be used instead of wext. I
 found that nl80211 is the default for network-manager. So, whats going wrong
 here?

Could you provide more NetworkManager logs?  They should look like this;
where do your logs stop?

NetworkManager[1949]: info  (wlan0): Activation: starting connection 'my wifi'
NetworkManager[1949]: info  (wlan0): Activation: Stage 1 of 5 (Device 
Prepare) scheduled...
NetworkManager[1949]: info  (wlan0): Activation: Stage 1 of 5 (Device 
Prepare) started...
NetworkManager[1949]: info  (wlan0): device state change: disconnected - 
prepare (reason 'none') [30 40 0]
NetworkManager[1949]: info  (wlan0): Activation: Stage 2 of 5 (Device 
Configure) scheduled...
NetworkManager[1949]: info  (wlan0): Activation: Stage 1 of 5 (Device 
Prepare) complete.
NetworkManager[1949]: info  (wlan0): Activation: Stage 2 of 5 (Device 
Configure) starting...
NetworkManager[1949]: info  (wlan0): device state change: prepare - config 
(reason 'none') [40 50 0]
NetworkManager[1949]: info  (wlan0): Activation: (wifi) connection 'my wifi' 
has security, and secrets exist.  No new secrets needed.
NetworkManager[1949]: info  Config: added 'ssid' value 'my wifi'
NetworkManager[1949]: info  Config: added 'scan_ssid' value '1'
NetworkManager[1949]: info  Config: added 'key_mgmt' value 'WPA-PSK'
NetworkManager[1949]: info  Config: added 'psk' value 'omitted'
NetworkManager[1949]: info  Config: added 'proto' value 'WPA RSN'
NetworkManager[1949]: info  (wlan0): Activation: Stage 2 of 5 (Device 
Configure) complete.
NetworkManager[1949]: info  Config: set interface ap_scan to 1
NetworkManager[1949]: info  (wlan0): supplicant interface state: inactive - 
scanning
NetworkManager[1949]: info  (wlan0): supplicant interface state: scanning - 
authenticating
NetworkManager[1949]: info  (wlan0): supplicant interface state: 
authenticating - associating
NetworkManager[1949]: info  (wlan0): supplicant interface state: associating 
- associated
NetworkManager[1949]: info  (wlan0): supplicant interface state: associated 
- 4-way handshake
NetworkManager[1949]: info  (wlan0): supplicant interface state: 4-way 
handshake - completed

Dan

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ARP dropped during WPA handshake

[Dan Williams]

On Tue, 2015-03-17 at 16:02 +0100, voncken wrote:
 
During the initial WPA handshake the connection is not fully set up,
and so no general traffic can (nor should) pass between the STA and AP.
That includes ARP and any L2/L3+ protocols, except for EAP and wifi
management packets.
   
The interface itself must be IFF_UP before it can pass traffic,
including the WPA handshake traffic.  IFF_UP only means that the
interface can be configured at the L2 level and the hardware is
active, it does *not* mean the interface can pass traffic.
   
Whatever is causing the ARPs shouldn't be doing that yet, and should
be fixed to use the interface's operstate or IFF_LOWER_UP instead
of IFF_UP.  Only when the supplicant changes the interface's
operstate to IF_OPER_UP is the interface *actually* ready to pass
  traffic.  IFF_UP is not sufficient.
   
  
   Thanks for your reply.
  
   It seems wpa_supplicant set the operstate to IF_OPER_DORMANT when he
  received the ASSOCIATED Event from the driver (through netlink). And set the
  operstate to IF_OPER_UP in case of wpa handshake success.
  
   Is it normal the local ip stack send arp when netdev it is on
  IF_OPER_DORMANT state?
  
  I'm not sure the kernel stack cares much as long as the device is up.
  It is requesting the ARP because some application is attempting to
  communicate with that IP address.  That application should probably be
  waiting until the interface is actually ready to communicate, which means
  IF_OPER_UP.
  
  But if this is the first WPA handshake with the AP during the initial
  connection, the wifi device shouldn't even have an IP address yet, so 
  nothing
  should be doing ARP on the interface yet.  Perhaps whatever is assigning the
  IP address to the interface is doing it too early, before the interface is
  IF_OPER_UP?
  
 It is not the initial connection. My sta is connected on AP1 and the 
 communication is established (in my test the communication it is iperf from 
 STA to computer behind the APs). 
 
 I looking for a solution to enable the communication for wpa_supplicant, but 
 block the L3 communication while the WPA handshake is not finished.

Yeah, I saw your mail to netdev.  In my opinion (which may not count for
much) I don't think the kernel should be doing any ARP when the
interface is not IF_OPER_UP.  wpa_supplicant is doing the right thing if
it is setting the interface IF_OPER_DORMANT when doing the rekeying and
then setting the interface to IF_OPER_UP when it has successfully
installed the new keys.

There's only a few places where ARPs get triggered in the kernel, and
perhaps those need to be modified to defer the ARP until IF_OPER_UP or
something like that.  In any case, I think this is best followed up on
netdev since I don't think the supplicant is doing anything wrong here.

Dan

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html