From greearb at candelatech.com  Mon May  2 10:18:11 2016
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 2 May 2016 10:18:11 -0700
Subject: [PATCH v2] supplicant: Allow custom probe and assoc req ie.
In-Reply-To: <20160424083035.GA3283@w1.fi>
References: <20160408152216.GA15835@w1.fi> <5707CF8C.9050502@candelatech.com>
 <20160408170751.GA5415@w1.fi> <5707EA49.6020706@candelatech.com>
 <20160408210109.GA6744@w1.fi> <57081E88.2070207@candelatech.com>
 <20160409080355.GA3051@w1.fi> <570920AC.9010105@candelatech.com>
 <20160417162111.GA32101@w1.fi> <57163B79.90704@candelatech.com>
 <20160424083035.GA3283@w1.fi>
Message-ID: <57278BD3.7060305@candelatech.com>

On 04/24/2016 01:30 AM, Jouni Malinen wrote:
> On Tue, Apr 19, 2016 at 07:06:49AM -0700, Ben Greear wrote:
>> The "vendor_elem" array is in the wpa_s struct, but the config logic
>> deals with "struct wpa_config", which has no way to reference wpa_s as
>> far as I can tell.
>
> Correct.
>
>> Any opinion on moving wpa_s->vendor_elem to the wpa_config struct?
>>
>> Or, maybe add a back-pointer from wpa_config to the wpa_s?
>
> Why would either of those be needed? The new configuration parameters
> would be completely independent of wpa_s->vendor_elem, i.e., they are
> used only as a default value to set wpa_s->vendor_elem when bringing up
> an interface. No further changes to the configuration parameter during
> the lifetime of the interface would change wpa_s->vendor_elem and
> similarly, no VENDOR_ELEM* command would change the value of the
> configuration parameter.

My usage often involves writing out a new config file and then telling
supplicant to (re)load it.  I would want any changes to the custom probe/assoc
ies to take affect at that time.

 From your comment above, it seems you are suggesting a reload would not
effect the vendor elems?

Thanks,
Ben

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



From j at w1.fi  Mon May  2 13:20:45 2016
From: j at w1.fi (Jouni Malinen)
Date: Mon, 2 May 2016 23:20:45 +0300
Subject: psk configuration parameter update allowing arbitrary data to be
 written
Message-ID: <20160502202045.GA5701@w1.fi>

Published: May 2, 2016
Identifier: related to CVE-2016-2447
Latest version available from: http://w1.fi/security/2016-1/


Vulnerability

A vulnerability was found in how hostapd and wpa_supplicant writes the
configuration file update for the WPA/WPA2 passphrase parameter. If this
parameter has been updated to include control characters either through
a WPS operation or through local configuration change over the
wpa_supplicant control interface, the resulting configuration file may
prevent the hostapd and wpa_supplicant from starting when the updated
file is used. In addition for wpa_supplicant, it may be possible to load
a local library file and execute code from there with the same
privileges under which the wpa_supplicant process runs.

The WPS trigger for this requires local user action to authorize the WPS
operation in which a new configuration would be received. The attacker
would also need to be in radio range of the device or have access to the
IP network to act as a WPS External Registrar. Such an attack could
result in denial of service by not allowing hostapd or wpa_supplicant to
start after they have been stopped.

The local configuration update through the control interface SET_NETWORK
command could allow privilege escalation for the local user to run code
from a locally stored library file under the same privileges as the
wpa_supplicant process has. The assumption here is that a not fully
trusted user/application might have access through a connection manager
to set network profile parameters like psk, but would not have access to
set other configuration file parameters. If the connection manager in
such a case does not filter out control characters from the psk value,
it could have been possible to practically update the global parameters
by embedding a newline character within the psk value. In addition, the
untrusted user/application would need to be able to install a library
file somewhere on the device from where the wpa_supplicant process has
privileges to load the library.

Similarly to the SET_NETWORK case, if a connection manager exposes
access to the SET_CRED or SET commands, similar issue with newline
characters can exist as those commands do not filter out control
characters from the value.

It should also be noted that providing unlimited access to the
wpa_supplicant control interface would allow arbitrary SET commands to
be issued. Such unlimited access should not be provided to untrusted
users/applications.


Vulnerable versions/configurations

For the local control interface attack vector:

wpa_supplicant v0.4.0-v2.5 with control interface enabled

update_config=1 must have been enabled in the configuration file.


For the WPS attack vector:

wpa_supplicant v0.6.7-v2.5 with CONFIG_WPS build option enabled
hostapd v0.6.7-v2.5 with CONFIG_WPS build option enabled

WPS needs to be enabled in the runtime operation and the WPS operation
needs to have been authorized by the local user over the control
interface. For wpa_supplicant, update_config=1 must have been enabled in
the configuration file.


Acknowledgments

Thanks to Google for reporting this issue and Imre Rad of SEARCH-LAB
Ltd. discovering it.


Possible mitigation steps

- Merge the following commits to hostapd/wpa_supplicant and rebuild it:

  WPS: Reject a Credential with invalid passphrase
  Reject psk parameter set with invalid passphrase character
  Remove newlines from wpa_supplicant config network output
  Reject SET_CRED commands with newline characters in the string values
  Reject SET commands with newline characters in the string values

  These patches are available from http://w1.fi/security/2016-1/

- Update to wpa_supplicant v2.6 or newer, once available

-- 
Jouni Malinen                                            PGP id EFC895FA


From nickrossi00 at gmail.com  Tue May  3 16:47:42 2016
From: nickrossi00 at gmail.com (Nick Rossi)
Date: Tue, 3 May 2016 16:47:42 -0700
Subject: hostapd + wpa_supplicant + 4addr for client bridge
Message-ID: <CAOuQ7gHcX1tb9rqn0WG4pdHUNhzCMnr+namNhC7=asxbuBiRSQ@mail.gmail.com>

Hello,

Hoping this group can help - I'm trying to bridge two wired networks
into a single VLAN using 4-address mode with wpa_supplicant and
hostapd (both v2.5), following recommendations from an old thread on
this list (below).

One one machine I have a working hostapd AP with "wds_sta=1" and
wlan0/eth0 bridge. On another, wpa_supplicant with 4addr enabled on
wlan0, also bridged to its eth0. Hardware and kernel are identical on
both machines (nl80211 driver).

$ brctl addbr br0
$ brctl addif br0 eth0
$ iw dev wlan0 set 4addr on
$ brctl addif br0 wlan0
$ wpa_supplicant -B -b br0 -dd -i wlan0 -D nl80211 -c <conf> -f <log>

The above script succeeds, wpa_supplicant connects to the AP, and the
client machine can ping the host and IPs bridged behind the host.

However, the client-side bridge doesn't work, because it seems 4addr
isn't actually active; hostapd does not create an additional
"wlan0.sta1" interface, and hostapd debug output shows no recognition
of WDS mode. Also, icmp packets in tcpdump with 4addr enabled look
identical to packets without it enabled (I thought 4addr would
increase the payload size for the additional MAC address).

I have tried all this without the bridges, with the same result.

What could cause 4addr mode to not be active or recognized by hostapd
despite enabling it on the client? Does some wireless hardware not
support it?

Thank you,

Nick


> michaelm michael.melkonian at netcommwireless.com
> Thu Apr 9 05:01:10 EDT 2015
>
> After stuffing around a lot more with 4-address mode, it all appears
> good. Here are some tips (not too obvious in the documentation):
>
> 1) On AP side, when writing hostapd configuration file, make sure to add:
> wds_sta=1
> wds_bridge=br0
>
> When 4-address enabled WDS client connects, an interface appears with a
> name of wlan0.sta1 (I am assuming additional interfaces will appear as
> wlan0.sta2 and so on if more 4-address enabled clients connect).
>
> The wds_bridge line in the hostapd configuration file will automatically
> add the wlan0.sta to your nominated bridge, e.g. br0. Alternatively, you
> can always do brctl addif and so on.
>
> As one would hope, non 4-address clients continue to work as normal and
> co-exist with 4-address clients.
>
> 2) On STA side, as specified in documentation, the interface has to be
> brought up with 4addr on option, e.g.
> iw phy phy0 interface add wlan_sta0 type station 4addr on

> Bridge the 4-addr mode client interface (which is now connected to AP
> side) wlan_sta0 to AP, e.g.
> brctl addif br0 wlan_sta0 wlan0


From davidben at google.com  Thu May  5 10:43:42 2016
From: davidben at google.com (David Benjamin)
Date: Thu, 5 May 2016 13:43:42 -0400
Subject: [PATCH] OpenSSL: BoringSSL has SSL_get_client_random, etc.
Message-ID: <CAF8qwaDAts-FAPJs1ttZ5ac6qQQC2KX=JWAXi5o1ncfMhTGK7w@mail.gmail.com>

Attached since I trust my mail client to completely destroy the whitespace.

Apologies for making your #ifdef soup even messier. The motivation
here is we'd like to opaquify the SSL structs in BoringSSL (which
should, in the long run, make wpa_supplicant less sensitive to changes
on our end). To keep things simple, I'm mirroring OpenSSL 1.1.0's
APIs. But, for the moment, BoringSSL's OPENSSL_VERSION_NUMBER still
claims to be 1.0.2, so this will need some more conditionals.

I'm optimistic that someday we'll mimic enough of 1.1.0 that bumping
OPENSSL_VERSION_NUMBER might make sense and then we won't need this
special-case. For now, it and the ecosystem are enough of a moving
target that I don't think it's feasible just yet.

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-OpenSSL-BoringSSL-has-SSL_get_client_random-etc.patch
Type: text/x-patch
Size: 1941 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160505/7876e2d4/attachment.bin>

From j at w1.fi  Thu May  5 14:16:03 2016
From: j at w1.fi (Jouni Malinen)
Date: Fri, 6 May 2016 00:16:03 +0300
Subject: [PATCH] OpenSSL: BoringSSL has SSL_get_client_random, etc.
In-Reply-To: <CAF8qwaDAts-FAPJs1ttZ5ac6qQQC2KX=JWAXi5o1ncfMhTGK7w@mail.gmail.com>
References: <CAF8qwaDAts-FAPJs1ttZ5ac6qQQC2KX=JWAXi5o1ncfMhTGK7w@mail.gmail.com>
Message-ID: <20160505211603.GD30363@w1.fi>

On Thu, May 05, 2016 at 01:43:42PM -0400, David Benjamin wrote:
> Apologies for making your #ifdef soup even messier. The motivation
> here is we'd like to opaquify the SSL structs in BoringSSL (which
> should, in the long run, make wpa_supplicant less sensitive to changes
> on our end). To keep things simple, I'm mirroring OpenSSL 1.1.0's
> APIs. But, for the moment, BoringSSL's OPENSSL_VERSION_NUMBER still
> claims to be 1.0.2, so this will need some more conditionals.
> 
> I'm optimistic that someday we'll mimic enough of 1.1.0 that bumping
> OPENSSL_VERSION_NUMBER might make sense and then we won't need this
> special-case. For now, it and the ecosystem are enough of a moving
> target that I don't think it's feasible just yet.

This is problematic with existing versions of BoringSSL. As an example,
if I apply this and try to build against my previous BoringSSL build,
the compilation fails with:

  CC  ../src/eap_peer/eap_tls_common.c
../src/crypto/tls_openssl.c: In function ?tls_connection_get_random?:
../src/crypto/tls_openssl.c:3079:2: error: implicit declaration of function ?SSL_get_client_random? [-Werror=implicit-function-declaration]
  keys->client_random_len = SSL_get_client_random(
  ^
../src/crypto/tls_openssl.c:3082:2: error: implicit declaration of function ?SSL_get_server_random? [-Werror=implicit-function-declaration]
  keys->server_random_len = SSL_get_server_random(
  ^
../src/crypto/tls_openssl.c: In function ?openssl_tls_prf?:
../src/crypto/tls_openssl.c:3203:2: error: implicit declaration of function ?SSL_SESSION_get_master_key?
[-Werror=implicit-function-declaration]
  master_key_len = SSL_SESSION_get_master_key(sess, master_key,
  ^


IMHO, it is quite unfortunate that BoringSSL is maintained in a manner
that prevents clean backwards compatibility with at least the versions
used in the recent past. Applying this patch would break various Android
cases where the BoringSSL version in the branch is not sufficiently
recent to have the macro defined.

Would there be any other way of using the pre-processor to automatically
determine whether BoringSSL is recent enough to include the new
commands? The "Add SSL_get_client_random and SSL_get_server_random"
doesn't seem to add anything to the header files to help the
pre-processor for this..

> BoringSSL added 1.1.0's SSL_get_client_random and friends in working towards
> opaquifying the SSL struct. But it, for the moment, still looks more like 1.0.2
> than 1.1.0 and advertises OPENSSL_VERSION_NUMBER as such. This means that there
> is no need to define those in BoringSSL and defining them causes conflicts. (C
> does not like having static and non-static functions with the same name.)

I guess the wrapper functions in src/crypto/tls_openssl.c could be
defined to us an alternative name and then use #define to override the
functions. Not that this is exactly nice, but at least it seems to build
with the current boringssl.git snapshot:

diff --git a/src/crypto/tls_openssl.c b/src/crypto/tls_openssl.c
index ebcc545..0f67290 100644
--- a/src/crypto/tls_openssl.c
+++ b/src/crypto/tls_openssl.c
@@ -57,8 +57,8 @@ typedef int stack_index_t;
  * 1.1.0. Provide compatibility wrappers for older versions.
  */
 
-static size_t SSL_get_client_random(const SSL *ssl, unsigned char *out,
-				    size_t outlen)
+static size_t _SSL_get_client_random(const SSL *ssl, unsigned char *out,
+				     size_t outlen)
 {
 	if (!ssl->s3 || outlen < SSL3_RANDOM_SIZE)
 		return 0;
@@ -66,9 +66,11 @@ static size_t SSL_get_client_random(const SSL *ssl, unsigned char *out,
 	return SSL3_RANDOM_SIZE;
 }
 
+#define SSL_get_client_random _SSL_get_client_random
 
-static size_t SSL_get_server_random(const SSL *ssl, unsigned char *out,
-				    size_t outlen)
+
+static size_t _SSL_get_server_random(const SSL *ssl, unsigned char *out,
+				     size_t outlen)
 {
 	if (!ssl->s3 || outlen < SSL3_RANDOM_SIZE)
 		return 0;
@@ -76,9 +78,10 @@ static size_t SSL_get_server_random(const SSL *ssl, unsigned char *out,
 	return SSL3_RANDOM_SIZE;
 }
 
+#define SSL_get_server_random _SSL_get_server_random
 
-static size_t SSL_SESSION_get_master_key(const SSL_SESSION *session,
-					 unsigned char *out, size_t outlen)
+static size_t _SSL_SESSION_get_master_key(const SSL_SESSION *session,
+					  unsigned char *out, size_t outlen)
 {
 	if (!session || session->master_key_length < 0 ||
 	    (size_t) session->master_key_length > outlen)
@@ -89,6 +92,8 @@ static size_t SSL_SESSION_get_master_key(const SSL_SESSION *session,
 	return outlen;
 }
 
+#define SSL_SESSION_get_master_key _SSL_SESSION_get_master_key
+
 #endif
 
 #ifdef ANDROID

-- 
Jouni Malinen                                            PGP id EFC895FA


From davidben at google.com  Thu May  5 15:41:19 2016
From: davidben at google.com (David Benjamin)
Date: Thu, 5 May 2016 18:41:19 -0400
Subject: [PATCH] OpenSSL: BoringSSL has SSL_get_client_random, etc.
In-Reply-To: <20160505211603.GD30363@w1.fi>
References: <CAF8qwaDAts-FAPJs1ttZ5ac6qQQC2KX=JWAXi5o1ncfMhTGK7w@mail.gmail.com>
 <20160505211603.GD30363@w1.fi>
Message-ID: <CAF8qwaBiEgN=GTG5JoTQWXqdKyfOfE6AOp+ux4_MrWTth2PeAg@mail.gmail.com>

On Thu, May 5, 2016 at 5:16 PM, Jouni Malinen <j at w1.fi> wrote:
> This is problematic with existing versions of BoringSSL. As an example,
> if I apply this and try to build against my previous BoringSSL build,
> the compilation fails with:
>
>   CC  ../src/eap_peer/eap_tls_common.c
> ../src/crypto/tls_openssl.c: In function ?tls_connection_get_random?:
> ../src/crypto/tls_openssl.c:3079:2: error: implicit declaration of function ?SSL_get_client_random? [-Werror=implicit-function-declaration]
>   keys->client_random_len = SSL_get_client_random(
>   ^
> ../src/crypto/tls_openssl.c:3082:2: error: implicit declaration of function ?SSL_get_server_random? [-Werror=implicit-function-declaration]
>   keys->server_random_len = SSL_get_server_random(
>   ^
> ../src/crypto/tls_openssl.c: In function ?openssl_tls_prf?:
> ../src/crypto/tls_openssl.c:3203:2: error: implicit declaration of function ?SSL_SESSION_get_master_key?
> [-Werror=implicit-function-declaration]
>   master_key_len = SSL_SESSION_get_master_key(sess, master_key,
>   ^
>
>
> IMHO, it is quite unfortunate that BoringSSL is maintained in a manner
> that prevents clean backwards compatibility with at least the versions
> used in the recent past. Applying this patch would break various Android
> cases where the BoringSSL version in the branch is not sufficiently
> recent to have the macro defined.
>
> Would there be any other way of using the pre-processor to automatically
> determine whether BoringSSL is recent enough to include the new
> commands? The "Add SSL_get_client_random and SSL_get_server_random"
> doesn't seem to add anything to the header files to help the
> pre-processor for this..

So, previously, our approach was not to try to support old versions of
BoringSSL much. It's annoying having our own code (much less yours!)
saddled with #ifdefs for our past mistakes. (You all have enough of a
mess on your hands with multiple versions of OpenSSL. I don't want to
make things worse!) Instead, we only use it in environments with
controlled versions that move forwards, so we can coordinate caller
and callee updates, sometimes even atomically. If atomic changes
aren't possible, we'd add very temporary scaffolding #defines and
#ifdefs locally, get to the end state (caller and callee both assumed
new enough) as fast as possible, and dismantle it.

Though talking with Dmitry some more, it sounds like it's actually
desirable to be able to build newer wpa_supplicant against a release
or two behind of AOSP? Is that right? This isn't how we had previous
done things on the BoringSSL end, but we can certainly accommodate it.

I can start a BORINGSSL_API_VERSION counter and roll that into AOSP
now. This will be a random meaningless number except we promise it
will only increase and we'll probably increment it at points vaguely
corresponding with additions or changes in the API, wherever it ends
up convenient to do so. :-) Then this patch will be updated to be
defined(BORINGSSL_API_VERSION). In future we'd do
BORINGSSL_API_VERSION > whatever. And then you all can figure out how
far back it should go. (For my part, I want to minimize your burden,
so I would encourage you need to retain support for versions older
than you need, but it sounds like your master branch cares about more
Android releases than I thought.)

Does that sound reasonable?

>> BoringSSL added 1.1.0's SSL_get_client_random and friends in working towards
>> opaquifying the SSL struct. But it, for the moment, still looks more like 1.0.2
>> than 1.1.0 and advertises OPENSSL_VERSION_NUMBER as such. This means that there
>> is no need to define those in BoringSSL and defining them causes conflicts. (C
>> does not like having static and non-static functions with the same name.)
>
> I guess the wrapper functions in src/crypto/tls_openssl.c could be
> defined to us an alternative name and then use #define to override the
> functions. Not that this is exactly nice, but at least it seems to build
> with the current boringssl.git snapshot:
>
> diff --git a/src/crypto/tls_openssl.c b/src/crypto/tls_openssl.c
> index ebcc545..0f67290 100644
> --- a/src/crypto/tls_openssl.c
> +++ b/src/crypto/tls_openssl.c
> [snip]

Yeah, that's horrific. :-) I would definitely prefer changing our
strategy over forcing you to do that!

If we start the BORINGSSL_API_VERSION counter, the only versions
subject to the naming conflict would be those between when I added
SSL_get_client_random and when I add BORINGSSL_API_VERSION. I'll
update AOSP as soon that happens, so no released version of AOSP will
check a BoringSSL revision in that window. That should avoid this.

David


From serega.belarus at gmail.com  Tue May  3 01:36:06 2016
From: serega.belarus at gmail.com (Sergei Sinyak)
Date: Tue, 3 May 2016 11:36:06 +0300
Subject: eduroam disconnects with reason=3 (WPA-EAP, PEAP, MSCHAPv2)
In-Reply-To: <1461161495.30371.5.camel@redhat.com>
References: <CAGdowONbg=pKQChF+tWXz-Kc1Jh-CKegokx41rYjB5k3mR72MA@mail.gmail.com>
 <20160408135149.GB28917@w1.fi>
 <CAGdowOOPgPOykhm+HJyVfuP6-Ytm9oH_KmiuxENQhWS=UTCvGg@mail.gmail.com>
 <CAGdowONDQtCY6BPt8OnyWvTOSwv82h0CVeb0w8t1FnsNOXfHOQ@mail.gmail.com>
 <CAGdowONB7UB4vg1SiCvDEAzmkgsi2-Gmm9V4AC0ZzYt3aKZg7A@mail.gmail.com>
 <20160417185934.GB493@w1.fi>
 <CAGdowOOT2zi9J-AxrKoDK_q4pV0AGpvYMN+=hLtTNUkRHvMdgw@mail.gmail.com>
 <20160419084758.GA3249@w1.fi>
 <CAGdowOOv8Y682jCddEt+hxTiC-OSotcs371KryEJpO-H5+MGkg@mail.gmail.com>
 <CAGdowONsjYf6KAWct6FcHj75yvY9VO_DTevuzNZfYSSmez1NVQ@mail.gmail.com>
 <1461161495.30371.5.camel@redhat.com>
Message-ID: <CAGdowOP-m4ASFBSf-fh=BFDFEQaNjF-CFWjnhM6iEEKcqELWRQ@mail.gmail.com>

Hello.

I tried to configure wpa_supplicant with those keys
"tls_disable_tlsv1_1=1 tls_disable_tlsv1_2=1".

wpa_supplicant sucefully achieves "Authorized state"
https://gist.github.com/anonymous/72f8d94c677d735cdff168bc7c181747#file-wpa_supplicant-log-L857

But it can't complete "4WAY-HANDSHAKE", because of "WPA: Failed to set
GTK to the driver".
https://gist.github.com/anonymous/72f8d94c677d735cdff168bc7c181747#file-wpa_supplicant-log-L870

Here is log from wpa_supplicant
https://gist.github.com/anonymous/72f8d94c677d735cdff168bc7c181747

Here is wpa_supplicant config
https://gist.github.com/anonymous/576c99d71652bc0a3a00744e13034bf3

Please explain a possible reason for such a behaviour.

Sergei Sinyak


From davidben at google.com  Mon May  9 16:58:15 2016
From: davidben at google.com (David Benjamin)
Date: Mon, 9 May 2016 19:58:15 -0400
Subject: [PATCH] OpenSSL: BoringSSL has SSL_get_client_random, etc.
In-Reply-To: <CAF8qwaBiEgN=GTG5JoTQWXqdKyfOfE6AOp+ux4_MrWTth2PeAg@mail.gmail.com>
References: <CAF8qwaDAts-FAPJs1ttZ5ac6qQQC2KX=JWAXi5o1ncfMhTGK7w@mail.gmail.com>
 <20160505211603.GD30363@w1.fi>
 <CAF8qwaBiEgN=GTG5JoTQWXqdKyfOfE6AOp+ux4_MrWTth2PeAg@mail.gmail.com>
Message-ID: <CAF8qwaDbQiooEMNMz9-CXvoqqoauywb2-bsZq_2dhWhnPeAEgw@mail.gmail.com>

On Thu, May 5, 2016 at 6:41 PM David Benjamin <davidben at google.com> wrote:
>
> I can start a BORINGSSL_API_VERSION counter and roll that into AOSP
> now. This will be a random meaningless number except we promise it
> will only increase and we'll probably increment it at points vaguely
> corresponding with additions or changes in the API, wherever it ends
> up convenient to do so. :-) Then this patch will be updated to be
> defined(BORINGSSL_API_VERSION). In future we'd do
> BORINGSSL_API_VERSION > whatever. And then you all can figure out how
> far back it should go. (For my part, I want to minimize your burden,
> so I would encourage you need to retain support for versions older
> than you need, but it sounds like your master branch cares about more
> Android releases than I thought.)
>
> Does that sound reasonable?

BORINGSSL_API_VERSION is now in BoringSSL and AOSP master. I've
attached a revised version of the patch that uses it instead.

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-OpenSSL-BoringSSL-has-SSL_get_client_random-etc.patch
Type: text/x-patch
Size: 2202 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160509/00ef23ef/attachment.bin>

From xue.liu at dks-koeln.de  Tue May 10 00:18:16 2016
From: xue.liu at dks-koeln.de (Xue Liu)
Date: Tue, 10 May 2016 09:18:16 +0200
Subject: wpabuf overflow with WPS
In-Reply-To: <20160428170603.GA8334@w1.fi>
References: <5f7c55d9-f0e8-991e-25ff-74f94643bf24@dks-koeln.de>
 <20160427153227.GA5370@w1.fi>
 <20a3fd4c-c41c-f70a-c02b-c43f904a2fe5@dks-koeln.de>
 <20160428170603.GA8334@w1.fi>
Message-ID: <1aedf756-312c-7221-06a3-cbb0c61e69d1@dks-koeln.de>

Hello


On 28/04/16 19:06, Jouni Malinen wrote:
> On Thu, Apr 28, 2016 at 01:31:05PM +0200, Xue Liu wrote:
>> I have removed the patch and generate a new hostapd program. Then I
>> run the program with -d option, and there is no wpabuf overflow, but
>> my Nexus 9 still can not make a connection with Clearfog board via
>> WPS. Since the debug info is quite a lot. I put them in the
>> attachment. Thank you.
> Thanks. This looks like something completely different. The client
> device does not seem to even try to associate with the AP. It does go
> through Authentication frame exchange, but then nothing.. The debug
> patch should have no impact on this type of functionality, so it is a
> bit difficult to say what caused this.
>
>> root at OpenWrt:~# hostapd -d hostapd.cfg
> Or are you maybe running this over a slow serial port connection? If so,
> there will likely be a significant extra latency on operations and it
> would be better to direct the output to a file with something like
>
> hostapd -dd hostapd.cfg > /tmp/hostapd.log
>
Yes. I am running hostapd over a serial port connection.
I did another test last few days and I found the problem is not in the 
hostapd but in wps_supplicant. During the connection via WPS, the 
wps_supplicant has "Segmentation fault". I run wpa_supplicant with 
"/usr/sbin/wpa_supplicant -dd -P /var/run/wpa_supplicant-wlan0.pid -D 
nl80211 -i wlan0 -c wpa_supplicant-wlan0.conf -C /var/run/wpa_supplicant".

In addition I compile the wpad with TARGET_CFLAGS += -ggdb3. I run "gdb 
/usr/sbin/wpa_supplicant" and then "run -dd -P 
/var/run/wpa_supplicant-wlan0.pid -D nl80211 -i wlan0 -c 
wpa_supplicant-wlan0.conf -C /var/run/wpa_supplicant?. When segmentation 
fault appears after "WPS: Generate new DH keys", I run "bt".

In the attachment you can find the wpa_supplicant_gdb.log file and 
wps_supplicant-wlan0.conf file. It seems that there is no useful 
backtrace info.

I would like also to say that in the OpenWRT I use wpad package to 
replace wpa_supplicant and hostapd. I am a newbie of it, and I don't 
know what is the differences.

Regards,

Xue Liu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wpa_supplicant_gdb.log
Type: text/x-log
Size: 22338 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160510/77682e1e/attachment-0001.bin>
-------------- next part --------------
country=DE

update_config=1

network={
        scan_ssid=1
        ssid="Yun-AP"
        key_mgmt=WPA-PSK
        psk="12345678"
        proto=RSN
        bssid=90:A2:DA:F0:11:7E
}


From chinawrj at gmail.com  Tue May 10 03:52:23 2016
From: chinawrj at gmail.com (Wang Linetkux)
Date: Tue, 10 May 2016 18:52:23 +0800
Subject: wpabuf overflow with WPS
In-Reply-To: <1aedf756-312c-7221-06a3-cbb0c61e69d1@dks-koeln.de>
References: <5f7c55d9-f0e8-991e-25ff-74f94643bf24@dks-koeln.de>
 <20160427153227.GA5370@w1.fi>
 <20a3fd4c-c41c-f70a-c02b-c43f904a2fe5@dks-koeln.de>
 <20160428170603.GA8334@w1.fi>
 <1aedf756-312c-7221-06a3-cbb0c61e69d1@dks-koeln.de>
Message-ID: <CANQnsBo4TAtU6t_5oBbCXNn4kTxE9uAER6RiB_JgWONjNptr-Q@mail.gmail.com>

Hi, guys
   I have figured out what's going a few days a ago on OpenWrt DD.
This issue is caused by the uninitialized ptr of wpa buffer, which is
introduced by the following commit:

2015-11-29 20:53 Jouni Malinen      o Fix memory leak on NFC DH
generation error path
Commit ID: 4104267e81b0a0acdb43f693a67f236b3237a719

In this patch, "wpabuf_free" is called in "dh5_init", which assumes
that ptr of wpa buffer is already set. But actually ptr of wpa buffer
may be still uninitialized.

I have generated the patch for these issue.



2016-05-10 15:18 GMT+08:00 Xue Liu <xue.liu at dks-koeln.de>:
> Hello
>
>
> On 28/04/16 19:06, Jouni Malinen wrote:
>>
>> On Thu, Apr 28, 2016 at 01:31:05PM +0200, Xue Liu wrote:
>>>
>>> I have removed the patch and generate a new hostapd program. Then I
>>> run the program with -d option, and there is no wpabuf overflow, but
>>> my Nexus 9 still can not make a connection with Clearfog board via
>>> WPS. Since the debug info is quite a lot. I put them in the
>>> attachment. Thank you.
>>
>> Thanks. This looks like something completely different. The client
>> device does not seem to even try to associate with the AP. It does go
>> through Authentication frame exchange, but then nothing.. The debug
>> patch should have no impact on this type of functionality, so it is a
>> bit difficult to say what caused this.
>>
>>> root at OpenWrt:~# hostapd -d hostapd.cfg
>>
>> Or are you maybe running this over a slow serial port connection? If so,
>> there will likely be a significant extra latency on operations and it
>> would be better to direct the output to a file with something like
>>
>> hostapd -dd hostapd.cfg > /tmp/hostapd.log
>>
> Yes. I am running hostapd over a serial port connection.
> I did another test last few days and I found the problem is not in the
> hostapd but in wps_supplicant. During the connection via WPS, the
> wps_supplicant has "Segmentation fault". I run wpa_supplicant with
> "/usr/sbin/wpa_supplicant -dd -P /var/run/wpa_supplicant-wlan0.pid -D
> nl80211 -i wlan0 -c wpa_supplicant-wlan0.conf -C /var/run/wpa_supplicant".
>
> In addition I compile the wpad with TARGET_CFLAGS += -ggdb3. I run "gdb
> /usr/sbin/wpa_supplicant" and then "run -dd -P
> /var/run/wpa_supplicant-wlan0.pid -D nl80211 -i wlan0 -c
> wpa_supplicant-wlan0.conf -C /var/run/wpa_supplicant?. When segmentation
> fault appears after "WPS: Generate new DH keys", I run "bt".
>
> In the attachment you can find the wpa_supplicant_gdb.log file and
> wps_supplicant-wlan0.conf file. It seems that there is no useful backtrace
> info.
>
> I would like also to say that in the OpenWRT I use wpad package to replace
> wpa_supplicant and hostapd. I am a newbie of it, and I don't know what is
> the differences.
>
> Regards,
>
> Xue Liu
>
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-un-set-pointer-which-cause-segment-fault.patch
Type: application/octet-stream
Size: 692 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160510/79ad80c0/attachment.obj>

From xue.liu at dks-koeln.de  Tue May 10 04:39:56 2016
From: xue.liu at dks-koeln.de (Xue Liu)
Date: Tue, 10 May 2016 13:39:56 +0200
Subject: wpabuf overflow with WPS
In-Reply-To: <CANQnsBo4TAtU6t_5oBbCXNn4kTxE9uAER6RiB_JgWONjNptr-Q@mail.gmail.com>
References: <5f7c55d9-f0e8-991e-25ff-74f94643bf24@dks-koeln.de>
 <20160427153227.GA5370@w1.fi>
 <20a3fd4c-c41c-f70a-c02b-c43f904a2fe5@dks-koeln.de>
 <20160428170603.GA8334@w1.fi>
 <1aedf756-312c-7221-06a3-cbb0c61e69d1@dks-koeln.de>
 <CANQnsBo4TAtU6t_5oBbCXNn4kTxE9uAER6RiB_JgWONjNptr-Q@mail.gmail.com>
Message-ID: <f6298b48-3e0e-7985-ecbe-457ca42552f5@dks-koeln.de>

Hello Rujun,

Thank you for your help and patch. Now hostapd and wpa_supplicant are 
working  properly with WPS. :-)

Regards,

Xue Liu

On 10/05/16 12:52, Wang Linetkux wrote:
> "wpabuf_free" is called in "dh5_init"



From j at w1.fi  Tue May 10 09:48:40 2016
From: j at w1.fi (Jouni Malinen)
Date: Tue, 10 May 2016 19:48:40 +0300
Subject: [PATCH] OpenSSL: BoringSSL has SSL_get_client_random, etc.
In-Reply-To: <CAF8qwaBiEgN=GTG5JoTQWXqdKyfOfE6AOp+ux4_MrWTth2PeAg@mail.gmail.com>
References: <CAF8qwaDAts-FAPJs1ttZ5ac6qQQC2KX=JWAXi5o1ncfMhTGK7w@mail.gmail.com>
 <20160505211603.GD30363@w1.fi>
 <CAF8qwaBiEgN=GTG5JoTQWXqdKyfOfE6AOp+ux4_MrWTth2PeAg@mail.gmail.com>
Message-ID: <20160510164840.GA7865@w1.fi>

On Thu, May 05, 2016 at 06:41:19PM -0400, David Benjamin wrote:
> So, previously, our approach was not to try to support old versions of
> BoringSSL much. It's annoying having our own code (much less yours!)
> saddled with #ifdefs for our past mistakes. (You all have enough of a
> mess on your hands with multiple versions of OpenSSL. I don't want to
> make things worse!) Instead, we only use it in environments with
> controlled versions that move forwards, so we can coordinate caller
> and callee updates, sometimes even atomically. If atomic changes
> aren't possible, we'd add very temporary scaffolding #defines and
> #ifdefs locally, get to the end state (caller and callee both assumed
> new enough) as fast as possible, and dismantle it.

In theory, that would be nice in case all components using BoringSSL are
only used in the same controlled environment..

> Though talking with Dmitry some more, it sounds like it's actually
> desirable to be able to build newer wpa_supplicant against a release
> or two behind of AOSP? Is that right? This isn't how we had previous
> done things on the BoringSSL end, but we can certainly accommodate it.

Yes, my goal is to be able to take a master branch snapshot from
hostap.git and be able to build wpa_supplicant from that with at least
the latest releases AOSP version or ideally two if the previous one is
still being used in significant new development. Quite a bit of Wi-Fi
related work happens with and on Android versions that are a bit older
than what is in the latest development trees (especially if those trees
are not always publicly available).

If this can be maintained with couple of well placed #ifdefs, then so be
it. I'm willing to take that temporary extra complexity to get the
benefits of having a new version that can be built on top of Android
versions that are used as the baseline for ongoing development and
product releases.

> I can start a BORINGSSL_API_VERSION counter and roll that into AOSP
> now. This will be a random meaningless number except we promise it
> will only increase and we'll probably increment it at points vaguely
> corresponding with additions or changes in the API, wherever it ends
> up convenient to do so. :-) Then this patch will be updated to be
> defined(BORINGSSL_API_VERSION). In future we'd do
> BORINGSSL_API_VERSION > whatever. And then you all can figure out how
> far back it should go. (For my part, I want to minimize your burden,
> so I would encourage you need to retain support for versions older
> than you need, but it sounds like your master branch cares about more
> Android releases than I thought.)
> 
> Does that sound reasonable?

Yes, this would work fine for me and the updated patch you sent looked
good as well.

And as a side note, most of my automated testing is on non-Android
platforms with Linux, so it is a significant benefit to be able to build
the latest wpa_supplicant with number of snapshots of BoringSSL on
x86_64 Linux. This allows both the current master branch of BoringSSL
(i.e., what to expect to see in the products in the future) and various
releases version (e.g., based on Android release tags) being used to run
through the mac80211_hwsim test runs for regression testing and to come
up with new test cases to verify issues that may show up in this area.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Tue May 10 09:53:45 2016
From: j at w1.fi (Jouni Malinen)
Date: Tue, 10 May 2016 19:53:45 +0300
Subject: wpabuf overflow with WPS
In-Reply-To: <CANQnsBo4TAtU6t_5oBbCXNn4kTxE9uAER6RiB_JgWONjNptr-Q@mail.gmail.com>
References: <5f7c55d9-f0e8-991e-25ff-74f94643bf24@dks-koeln.de>
 <20160427153227.GA5370@w1.fi>
 <20a3fd4c-c41c-f70a-c02b-c43f904a2fe5@dks-koeln.de>
 <20160428170603.GA8334@w1.fi>
 <1aedf756-312c-7221-06a3-cbb0c61e69d1@dks-koeln.de>
 <CANQnsBo4TAtU6t_5oBbCXNn4kTxE9uAER6RiB_JgWONjNptr-Q@mail.gmail.com>
Message-ID: <20160510165345.GB7865@w1.fi>

On Tue, May 10, 2016 at 06:52:23PM +0800, Wang Linetkux wrote:
>    I have figured out what's going a few days a ago on OpenWrt DD.
> This issue is caused by the uninitialized ptr of wpa buffer, which is
> introduced by the following commit:
> 
> 2015-11-29 20:53 Jouni Malinen      o Fix memory leak on NFC DH
> generation error path
> Commit ID: 4104267e81b0a0acdb43f693a67f236b3237a719
> 
> In this patch, "wpabuf_free" is called in "dh5_init", which assumes
> that ptr of wpa buffer is already set. But actually ptr of wpa buffer
> may be still uninitialized.
> 
> I have generated the patch for these issue.

Excellent, thank you. Could you please provide a Signed-off-by: line to
be added to the end of the commit message as described in the top level
CONTRIBUTIONS file? I need that for all hostap.git commits.

-- 
Jouni Malinen                                            PGP id EFC895FA


From davidben at google.com  Tue May 10 10:28:22 2016
From: davidben at google.com (David Benjamin)
Date: Tue, 10 May 2016 13:28:22 -0400
Subject: EAP-FAST PRF hooks and BoringSSL
Message-ID: <CAF8qwaCeha_KGz0rt6BJtYpAYt08F=+LL2zLWCjGmwSPQwF=NQ@mail.gmail.com>

Hey folks,

So, you all have this logic to reimplement the TLS PRF and key
derivation in src/crypto/tls_openssl.c in openssl_get_keyblock_size
and openssl_tls_prf. It appears these are used for key derivation in
EAP-TLS, EAP-TTLS, and EAP-FAST. EAP-(T)TLS can just use RFC 5705
exporters by way of SSL_export_keying_material, which you use. But
EAP-FAST is a bit of a nightmare. Among other sins, it hooks into
TLS's internal key derivation, so you all understandably need to do
some invasive wrangling.

We took the EAP-FAST bits out of BoringSSL a long time ago. (The way
it integrated into session resumption was problematic. I know how I'd
redo it if I had to, but there hasn't been a need yet.) But to keep
wpa_supplicant compiling, we have to keep some fields around
(ssl->enc_read_ctx, ssl->read_hash, and
ssl->s3->tmp.new_mac_secret_size) even though we never fill them in.
I'd like to resolve that. I can see a few options, but I don't know
which you'd prefer:

1. I can condition the EAP-FAST-only parts of the key derivation
conditioned on EAP_FAST #defines. With
df5bde83daaf3c820b6ac1f8d383b16a64ebd2db, we're finally no longer
defining those symbols, so this would work. I would probably, to make
this cleaner, split the tls_connection_prf entry-point into two
functions, one for the reasonable RFC 5705 mechanisms and one for
EAP-FAST's crazy thing. (Right now the API supports the RFC 5705
style, but with skip_keyblock set, which is a little odd.)

2. For OpenSSL 1.1.x, you all use SSL_CIPHER_get_cipher_nid and
SSL_CIPHER_get_digest_nid. BoringSSL doesn't have these, but I have no
problems adding them. (I would not have used NIDs for
SSL_CIPHER_get_kx_nid and SSL_CIPHER_get_auth_nid but whatever.) It's
a little odd because the computation is wrong for TLS 1.1+ and we
don't use EVP_CIPHER in our SSL code anymore. But the code will never
run anyway, and if it were to later, I could make it match OpenSSL.

3. For other reasons, we added a pair of functions,
SSL_get_key_block_len and SSL_generate_key_block which are actually
exactly what EAP-FAST wants here. I could make
openssl_get_keyblock_size call SSL_get_key_block_len and even make
openssl_tls_prf use SSL_generate_key_block. (Probably this would come
with a similar tls_connection_prf split as in option #1.) But this
would be BoringSSL-only code to support a feature that doesn't work in
BoringSSL anyway, so this is of questionable use.
https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_get_key_block_len

Do you all have a preference? #2 would be the least invasive option,
but splitting tls_connection_prf in two for #1 might be preferable, at
which point you may as well condition on EAP-FAST. In doing so, we can
probably do away with the fallback from SSL_export_keying_material to
openssl_tls_prf if SSL_export_keying_material fails (looks like that's
a remnant of how the #ifdefs worked out while 1.0.0 was supported) and
not even ship a custom TLS PRF in the no-EAP-FAST config. I'm happy to
do a bit of cleanup for you along the way here.

David


From xue.liu at dks-koeln.de  Tue May 10 00:28:53 2016
From: xue.liu at dks-koeln.de (Xue Liu)
Date: Tue, 10 May 2016 09:28:53 +0200
Subject: wpabuf overflow with WPS
In-Reply-To: <1aedf756-312c-7221-06a3-cbb0c61e69d1@dks-koeln.de>
References: <5f7c55d9-f0e8-991e-25ff-74f94643bf24@dks-koeln.de>
 <20160427153227.GA5370@w1.fi>
 <20a3fd4c-c41c-f70a-c02b-c43f904a2fe5@dks-koeln.de>
 <20160428170603.GA8334@w1.fi>
 <1aedf756-312c-7221-06a3-cbb0c61e69d1@dks-koeln.de>
Message-ID: <5e45d96b-756c-22cb-6f4e-5412b04737eb@dks-koeln.de>

Sorry I think I upload a wrong log file. The right one is in the attachment.


On 10/05/16 09:18, Xue Liu wrote:
> Hello
>
>
> On 28/04/16 19:06, Jouni Malinen wrote:
>> On Thu, Apr 28, 2016 at 01:31:05PM +0200, Xue Liu wrote:
>>> I have removed the patch and generate a new hostapd program. Then I
>>> run the program with -d option, and there is no wpabuf overflow, but
>>> my Nexus 9 still can not make a connection with Clearfog board via
>>> WPS. Since the debug info is quite a lot. I put them in the
>>> attachment. Thank you.
>> Thanks. This looks like something completely different. The client
>> device does not seem to even try to associate with the AP. It does go
>> through Authentication frame exchange, but then nothing.. The debug
>> patch should have no impact on this type of functionality, so it is a
>> bit difficult to say what caused this.
>>
>>> root at OpenWrt:~# hostapd -d hostapd.cfg
>> Or are you maybe running this over a slow serial port connection? If so,
>> there will likely be a significant extra latency on operations and it
>> would be better to direct the output to a file with something like
>>
>> hostapd -dd hostapd.cfg > /tmp/hostapd.log
>>
> Yes. I am running hostapd over a serial port connection.
> I did another test last few days and I found the problem is not in the 
> hostapd but in wps_supplicant. During the connection via WPS, the 
> wps_supplicant has "Segmentation fault". I run wpa_supplicant with 
> "/usr/sbin/wpa_supplicant -dd -P /var/run/wpa_supplicant-wlan0.pid -D 
> nl80211 -i wlan0 -c wpa_supplicant-wlan0.conf -C 
> /var/run/wpa_supplicant".
>
> In addition I compile the wpad with TARGET_CFLAGS += -ggdb3. I run 
> "gdb /usr/sbin/wpa_supplicant" and then "run -dd -P 
> /var/run/wpa_supplicant-wlan0.pid -D nl80211 -i wlan0 -c 
> wpa_supplicant-wlan0.conf -C /var/run/wpa_supplicant?. When 
> segmentation fault appears after "WPS: Generate new DH keys", I run "bt".
>
> In the attachment you can find the wpa_supplicant_gdb.log file and 
> wps_supplicant-wlan0.conf file. It seems that there is no useful 
> backtrace info.
>
> I would like also to say that in the OpenWRT I use wpad package to 
> replace wpa_supplicant and hostapd. I am a newbie of it, and I don't 
> know what is the differences.
>
> Regards,
>
> Xue Liu
>
>
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wps_supplicant.log
Type: text/x-log
Size: 39327 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160510/a8d3f043/attachment-0001.bin>

From chinawrj at gmail.com  Tue May 10 17:40:44 2016
From: chinawrj at gmail.com (Wang Linetkux)
Date: Wed, 11 May 2016 08:40:44 +0800
Subject: wpabuf overflow with WPS
In-Reply-To: <20160510165345.GB7865@w1.fi>
References: <5f7c55d9-f0e8-991e-25ff-74f94643bf24@dks-koeln.de>
 <20160427153227.GA5370@w1.fi>
 <20a3fd4c-c41c-f70a-c02b-c43f904a2fe5@dks-koeln.de>
 <20160428170603.GA8334@w1.fi>
 <1aedf756-312c-7221-06a3-cbb0c61e69d1@dks-koeln.de>
 <CANQnsBo4TAtU6t_5oBbCXNn4kTxE9uAER6RiB_JgWONjNptr-Q@mail.gmail.com>
 <20160510165345.GB7865@w1.fi>
Message-ID: <CANQnsBo09+GBzX2C-ySoRiMj8NiRoVRJ3XUiC+bKfqzcmhaZ8g@mail.gmail.com>

Hi, Jouni
  Added now. It's the first time that I contribute to open-source
community in such way. I hope the format of patch is well.

Rujun

2016-05-11 0:53 GMT+08:00 Jouni Malinen <j at w1.fi>:
> On Tue, May 10, 2016 at 06:52:23PM +0800, Wang Linetkux wrote:
>>    I have figured out what's going a few days a ago on OpenWrt DD.
>> This issue is caused by the uninitialized ptr of wpa buffer, which is
>> introduced by the following commit:
>>
>> 2015-11-29 20:53 Jouni Malinen      o Fix memory leak on NFC DH
>> generation error path
>> Commit ID: 4104267e81b0a0acdb43f693a67f236b3237a719
>>
>> In this patch, "wpabuf_free" is called in "dh5_init", which assumes
>> that ptr of wpa buffer is already set. But actually ptr of wpa buffer
>> may be still uninitialized.
>>
>> I have generated the patch for these issue.
>
> Excellent, thank you. Could you please provide a Signed-off-by: line to
> be added to the end of the commit message as described in the top level
> CONTRIBUTIONS file? I need that for all hostap.git commits.
>
> --
> Jouni Malinen                                            PGP id EFC895FA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-un-set-pointer-which-cause-segment-fault.patch
Type: application/octet-stream
Size: 739 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160511/0f402bf2/attachment.obj>

From saurav.babu at samsung.com  Tue May 10 22:37:23 2016
From: saurav.babu at samsung.com (Saurav Babu)
Date: Wed, 11 May 2016 11:07:23 +0530
Subject: [PATCH] D-Bus: Check Driver capability for IBSS in Modes property of
 Capabilities
Message-ID: <1462945043-30272-1-git-send-email-saurav.babu@samsung.com>

Signed-off-by: Saurav Babu <saurav.babu at samsung.com>
---
 wpa_supplicant/dbus/dbus_new_handlers.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
index da90ea1..c6c3a0d 100644
--- a/wpa_supplicant/dbus/dbus_new_handlers.c
+++ b/wpa_supplicant/dbus/dbus_new_handlers.c
@@ -2639,8 +2639,9 @@ dbus_bool_t wpas_dbus_getter_capabilities(
 					      &iter_array) ||
 	    !wpa_dbus_dict_string_array_add_element(
 		    &iter_array, "infrastructure") ||
-	    !wpa_dbus_dict_string_array_add_element(
-		    &iter_array, "ad-hoc") ||
+	    (res >= 0 && (capa.flags & WPA_DRIVER_FLAGS_IBSS) &&
+		 !wpa_dbus_dict_string_array_add_element(
+		    &iter_array, "ad-hoc")) ||
 	    (res >= 0 && (capa.flags & WPA_DRIVER_FLAGS_AP) &&
 	     !wpa_dbus_dict_string_array_add_element(
 		     &iter_array, "ap")) ||
-- 
1.9.1



From Guenther.Kelleter at devolo.de  Wed May 11 07:25:21 2016
From: Guenther.Kelleter at devolo.de (Guenther Kelleter)
Date: Wed, 11 May 2016 14:25:21 +0000
Subject: dynamic vlan with ath10k not working - regression
Message-ID: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>

Hi

Since commit 7cebc8e2100626dc6981a3f53301058452953b9b, "Fix init of group state machine for static VLANs" dynamic VLAN isn't working with atk10k radio anymore. Parent commit works as expected.
Symptom is that neither wlanX-Y.<VLAN-ID> nor the corresponding vlan-bridge is created. Association fails.

I tried the same with ath9k radio: works as expected with both versions.

This is the relevant debug log of hostapd:

wlan0-2: STA 78:7e:61:61:15:a3 RADIUS: VLAN ID 20
VLAN: vlan_add_dynamic(vlan_id=20 ifname=wlan0-2.#)
nl80211: Create interface iftype 4 (AP_VLAN)
nl80211: Ignored event (cmd=7) for foreign interface (ifindex 60 wdev 0x0)
nl80211: New interface wlan0-2.20 created: ifindex=60
nl80211: Add own interface ifindex 60
nl80211: if_indices[16]: 5 34 58 59 60
nl80211: Add own interface ifindex 60
nl80211: ifindex 60 already in the list
VLAN: Set interface wlan0-2.20 up
WPA: Add group state machine for VLAN-ID 20
GMK - hexdump(len=32): [REMOVED]
Key Counter - hexdump(len=32): [REMOVED]
WPA: group state machine entering state GTK_INIT (VLAN-ID 20)
GTK - hexdump(len=16): [REMOVED]
IGTK - hexdump(len=16): [REMOVED]
WPA: group state machine entering state SETKEYSDONE (VLAN-ID 20)
wpa_driver_nl80211_set_key: ifindex=60 (wlan0-2.20) alg=3 addr=0x496be4 key_idx=1 set_tx=1 seq_len=0 key_len=16
nl80211: KEY_DATA - hexdump(len=16): [REMOVED]
   broadcast key
nl80211: set_key failed; err=-22 Invalid argument)
WPA: group state machine entering state FATAL_FAILURE
WPA: Ensure group state machine running for VLAN ID 20
WPA initialization for VLAN 20 failed (-1)
WPA: Try stopping group state machine for VLAN ID 20
WPA: Remove group state machine for VLAN-ID 20
WPA deinit of wlan0-2.20 failed
nl80211: wpa_driver_nl80211_if_remove(type=1 ifname=wlan0-2.20) ifindex=60 added_if=1
nl80211: Remove interface ifindex=60
nl80211: if_indices[16]: 5 34 58 59


Regards,
G?nther



From davidben at google.com  Wed May 11 14:08:56 2016
From: davidben at google.com (David Benjamin)
Date: Wed, 11 May 2016 17:08:56 -0400
Subject: [PATCH] OpenSSL: BoringSSL has SSL_get_client_random, etc.
In-Reply-To: <20160510164840.GA7865@w1.fi>
References: <CAF8qwaDAts-FAPJs1ttZ5ac6qQQC2KX=JWAXi5o1ncfMhTGK7w@mail.gmail.com>
 <20160505211603.GD30363@w1.fi>
 <CAF8qwaBiEgN=GTG5JoTQWXqdKyfOfE6AOp+ux4_MrWTth2PeAg@mail.gmail.com>
 <20160510164840.GA7865@w1.fi>
Message-ID: <CAF8qwaCbGZRk3hqH7JsHqsibyfDSO1z9GKKCNeNj16t9qNu6Ew@mail.gmail.com>

On Tue, May 10, 2016 at 12:48 PM, Jouni Malinen <j at w1.fi> wrote:
>> I can start a BORINGSSL_API_VERSION counter and roll that into AOSP
>> now. This will be a random meaningless number except we promise it
>> will only increase and we'll probably increment it at points vaguely
>> corresponding with additions or changes in the API, wherever it ends
>> up convenient to do so. :-) Then this patch will be updated to be
>> defined(BORINGSSL_API_VERSION). In future we'd do
>> BORINGSSL_API_VERSION > whatever. And then you all can figure out how
>> far back it should go. (For my part, I want to minimize your burden,
>> so I would encourage you need to retain support for versions older
>> than you need, but it sounds like your master branch cares about more
>> Android releases than I thought.)
>>
>> Does that sound reasonable?
>
> Yes, this would work fine for me and the updated patch you sent looked
> good as well.
>
> And as a side note, most of my automated testing is on non-Android
> platforms with Linux, so it is a significant benefit to be able to build
> the latest wpa_supplicant with number of snapshots of BoringSSL on
> x86_64 Linux. This allows both the current master branch of BoringSSL
> (i.e., what to expect to see in the products in the future) and various
> releases version (e.g., based on Android release tags) being used to run
> through the mac80211_hwsim test runs for regression testing and to come
> up with new test cases to verify issues that may show up in this area.

Sounds good. I'll bump BORINGSSL_API_VERSION where relevant for you
all in future then. I'll leave cleaning up any old codepaths to you,
since I don't know how far back you want to go.

Is there anything else you need from me w.r.t. the updated patch, or
is it good to go? external/boringssl on AOSP master is now updated
past the point where BORINGSSL_API_VERSION is defined, so that should
be all good.

David


From michael-dev at fami-braun.de  Wed May 11 18:02:44 2016
From: michael-dev at fami-braun.de (michael-dev)
Date: Thu, 12 May 2016 03:02:44 +0200
Subject: dynamic vlan with ath10k not working - regression
In-Reply-To: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
References: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
Message-ID: <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>

Hi,

Am 11.05.2016 16:25, schrieb Guenther Kelleter:
> Since commit 7cebc8e2100626dc6981a3f53301058452953b9b, "Fix init of
> group state machine for static VLANs" dynamic VLAN isn't working with
> atk10k radio anymore. Parent commit works as expected.

basically this fix added wpa group key initialization during ap_vlan 
interface creation, that is before any station is assigned to the 
driver.
This is required for static VLANs with WPA where AP_VLAN interfaces are 
created possibly long before any station connects.

> Symptom is that neither wlanX-Y.<VLAN-ID> nor the corresponding
> vlan-bridge is created. Association fails.

The driver refuses to accept the key. Therefore that per VLAN wpa_group 
enters state FATAL_FAILURE, thus stations cannot complete group keying.

Solutions
a) make ath10k accept group keys without any station connected
b) let hostapd skip set_key without any stations connected if this is a 
dynamic vlan. This means static VLANs will continue to not work with 
ath10k.

I unsure which would be best?

> I tried the same with ath9k radio: works as expected with both 
> versions.
> 
> This is the relevant debug log of hostapd:
> 
> wlan0-2: STA 78:7e:61:61:15:a3 RADIUS: VLAN ID 20

so we add the new ap_vlan interface due to a station needing it.

> nl80211: New interface wlan0-2.20 created: ifindex=60

that interface has ifindex=60 assigned

> VLAN: Set interface wlan0-2.20 up

and is configured ifconfig_up

> WPA: Add group state machine for VLAN-ID 20

now wpa group keying starts before the station was assigned to the 
driver

> wpa_driver_nl80211_set_key: ifindex=60 (wlan0-2.20) alg=3
> addr=0x496be4 key_idx=1 set_tx=1 seq_len=0 key_len=16

a wpa group key shall be configured to the wireless driver

> nl80211: set_key failed; err=-22 Invalid argument)

but the driver does not like it. I don't know why. It should not.

> WPA: group state machine entering state FATAL_FAILURE

so the group state machine blocks and

> WPA initialization for VLAN 20 failed (-1)

interface initialization is declared failing

Regards,
M. Braun


From johannes at sipsolutions.net  Thu May 12 00:26:10 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Thu, 12 May 2016 09:26:10 +0200
Subject: [PATCH] drivers.mak: add NEED_RADIOTAP
Message-ID: <1463037970-16342-1-git-send-email-johannes@sipsolutions.net>

If there's ever a driver that, like nl80211, requires radiotap,
we need to have a NEED_RADIOTAP variable to avoid trying to link
the radiotap helpers twice. Introduce that.

Signed-off-by: Johannes Berg <johannes at sipsolutions.net>
---
 src/drivers/drivers.mak | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/drivers/drivers.mak b/src/drivers/drivers.mak
index 247e3259bfd7..064f7b4b8b68 100644
--- a/src/drivers/drivers.mak
+++ b/src/drivers/drivers.mak
@@ -29,7 +29,6 @@ DRV_OBJS += ../src/drivers/driver_nl80211_capa.o
 DRV_OBJS += ../src/drivers/driver_nl80211_event.o
 DRV_OBJS += ../src/drivers/driver_nl80211_monitor.o
 DRV_OBJS += ../src/drivers/driver_nl80211_scan.o
-DRV_OBJS += ../src/utils/radiotap.o
 ifdef CONFIG_DRIVER_NL80211_QCA
 DRV_CFLAGS += -DCONFIG_DRIVER_NL80211_QCA
 endif
@@ -38,6 +37,7 @@ NEED_AP_MLME=y
 NEED_NETLINK=y
 NEED_LINUX_IOCTL=y
 NEED_RFKILL=y
+NEED_RADIOTAP=y
 
 ifdef CONFIG_LIBNL32
   DRV_LIBS += -lnl-3
@@ -207,6 +207,10 @@ ifdef NEED_RFKILL
 DRV_OBJS += ../src/drivers/rfkill.o
 endif
 
+ifdef NEED_RADIOTAP
+DRV_OBJS += ../src/utils/radiotap.o
+endif
+
 ifdef CONFIG_VLAN_NETLINK
 ifdef CONFIG_FULL_DYNAMIC_VLAN
 ifdef CONFIG_LIBNL32
-- 
2.8.0.rc3



From Guenther.Kelleter at devolo.de  Thu May 12 03:25:14 2016
From: Guenther.Kelleter at devolo.de (Guenther Kelleter)
Date: Thu, 12 May 2016 10:25:14 +0000
Subject: dynamic vlan with ath10k not working - regression
In-Reply-To: <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>
References: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
 <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>
Message-ID: <EF6DF72779EE294A8A2425E8DA3BC0CC54351A8F@Pallas.devolo.intern>

Hi 

At first please excuse my ignorance but I'm new to WiFi and hostapd and don't know yet how all this is working.

> -----Original Message-----
> From: michael-dev [mailto:michael-dev at fami-braun.de]
> Sent: Thursday, May 12, 2016 3:03 AM
> To: Guenther Kelleter
> Cc: hostap at lists.infradead.org
> Subject: Re: dynamic vlan with ath10k not working - regression
> 
> Hi,
> 
> Am 11.05.2016 16:25, schrieb Guenther Kelleter:
> > Since commit 7cebc8e2100626dc6981a3f53301058452953b9b, "Fix init of
> > group state machine for static VLANs" dynamic VLAN isn't working with
> > atk10k radio anymore. Parent commit works as expected.
> 
> basically this fix added wpa group key initialization during ap_vlan
> interface creation, that is before any station is assigned to the
> driver.
> This is required for static VLANs with WPA where AP_VLAN interfaces are
> created possibly long before any station connects.

What exactly is not working in the static VLAN case?
I can configure an SSID to be part of a non-dynamic vlan in OpenWrt, i.e. that all stations are put in the configured vlan-bridge. This doesn't create a wlan0.<VLAN-ID> interface but uses the plain wlan0. I can't see anything not working in this case before this fix was added.
Maybe you're talking about a different thing?

> 
> > Symptom is that neither wlanX-Y.<VLAN-ID> nor the corresponding
> > vlan-bridge is created. Association fails.
> 
> The driver refuses to accept the key. Therefore that per VLAN wpa_group
> enters state FATAL_FAILURE, thus stations cannot complete group keying.
> 
> Solutions
> a) make ath10k accept group keys without any station connected

I understand even less of the driver than of hostapd :-) It's a pitch black box...

> b) let hostapd skip set_key without any stations connected if this is a
> dynamic vlan. This means static VLANs will continue to not work with
> ath10k.

Hmmm... looking at the code I'm not sure how to do that
Prevent calling wpa_group_setkeysdone? 

> 
> I unsure which would be best?
> 
> > I tried the same with ath9k radio: works as expected with both
> > versions.
> >
> > This is the relevant debug log of hostapd:
> >
> > wlan0-2: STA 78:7e:61:61:15:a3 RADIUS: VLAN ID 20
> 
> so we add the new ap_vlan interface due to a station needing it.
> 
> > nl80211: New interface wlan0-2.20 created: ifindex=60
> 
> that interface has ifindex=60 assigned
> 
> > VLAN: Set interface wlan0-2.20 up
> 
> and is configured ifconfig_up
> 
> > WPA: Add group state machine for VLAN-ID 20
> 
> now wpa group keying starts before the station was assigned to the
> driver
> 
> > wpa_driver_nl80211_set_key: ifindex=60 (wlan0-2.20) alg=3
> > addr=0x496be4 key_idx=1 set_tx=1 seq_len=0 key_len=16
> 
> a wpa group key shall be configured to the wireless driver
> 
> > nl80211: set_key failed; err=-22 Invalid argument)
> 
> but the driver does not like it. I don't know why. It should not.
> 
> > WPA: group state machine entering state FATAL_FAILURE
> 
> so the group state machine blocks and
> 
> > WPA initialization for VLAN 20 failed (-1)
> 
> interface initialization is declared failing
> 
> Regards,
> M. Braun


G?nther


From Guenther.Kelleter at devolo.de  Thu May 12 08:28:11 2016
From: Guenther.Kelleter at devolo.de (Guenther Kelleter)
Date: Thu, 12 May 2016 15:28:11 +0000
Subject: dynamic vlan with ath10k not working - regression
In-Reply-To: <EF6DF72779EE294A8A2425E8DA3BC0CC54351A8F@Pallas.devolo.intern>
References: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
 <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351A8F@Pallas.devolo.intern>
Message-ID: <EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern>

Replying to my own message:

> -----Original Message-----
> From: Hostap [mailto:hostap-bounces at lists.infradead.org] On Behalf Of Guenther
> Kelleter
> Sent: Thursday, May 12, 2016 12:25 PM
> To: hostap at lists.infradead.org
> Subject: RE: dynamic vlan with ath10k not working - regression
> 
> Hi
> 
> At first please excuse my ignorance but I'm new to WiFi and hostapd and don't
> know yet how all this is working.
> 
> > -----Original Message-----
> > From: michael-dev [mailto:michael-dev at fami-braun.de]
> > Sent: Thursday, May 12, 2016 3:03 AM
> > To: Guenther Kelleter
> > Cc: hostap at lists.infradead.org
> > Subject: Re: dynamic vlan with ath10k not working - regression
> >
> > Hi,
> >
> > Am 11.05.2016 16:25, schrieb Guenther Kelleter:
> > > Since commit 7cebc8e2100626dc6981a3f53301058452953b9b, "Fix init of
> > > group state machine for static VLANs" dynamic VLAN isn't working with
> > > atk10k radio anymore. Parent commit works as expected.
> >
> > basically this fix added wpa group key initialization during ap_vlan
> > interface creation, that is before any station is assigned to the
> > driver.
> > This is required for static VLANs with WPA where AP_VLAN interfaces are
> > created possibly long before any station connects.
> 
> What exactly is not working in the static VLAN case?
> I can configure an SSID to be part of a non-dynamic vlan in OpenWrt, i.e. that
> all stations are put in the configured vlan-bridge. This doesn't create a
> wlan0.<VLAN-ID> interface but uses the plain wlan0. I can't see anything not
> working in this case before this fix was added.
> Maybe you're talking about a different thing?
> 
> >
> > > Symptom is that neither wlanX-Y.<VLAN-ID> nor the corresponding
> > > vlan-bridge is created. Association fails.
> >
> > The driver refuses to accept the key. Therefore that per VLAN wpa_group
> > enters state FATAL_FAILURE, thus stations cannot complete group keying.
> >
> > Solutions
> > a) make ath10k accept group keys without any station connected
> 
> I understand even less of the driver than of hostapd :-) It's a pitch black
> box...
> 
> > b) let hostapd skip set_key without any stations connected if this is a
> > dynamic vlan. This means static VLANs will continue to not work with
> > ath10k.
> 
> Hmmm... looking at the code I'm not sure how to do that
> Prevent calling wpa_group_setkeysdone?

Adding this patch the station can associate again and the tagged wlan interface is created and put into the vlan-bridge. But I don't know what negative consequences it could cause:

diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c
index 9c136ef..bca8573 100644
--- a/src/ap/wpa_auth.c
+++ b/src/ap/wpa_auth.c
@@ -361,7 +361,7 @@ static struct wpa_group * wpa_group_init(struct wpa_authenticator *wpa_auth,
 	if (group == NULL)
 		return NULL;
 
-	group->GTKAuthenticator = TRUE;
+	group->GTKAuthenticator = FALSE;
 	group->vlan_id = vlan_id;
 	group->GTK_len = wpa_cipher_key_len(wpa_auth->conf.wpa_group);
 


> 
> >
> > I unsure which would be best?
> >
> > > I tried the same with ath9k radio: works as expected with both
> > > versions.
> > >
> > > This is the relevant debug log of hostapd:
> > >
> > > wlan0-2: STA 78:7e:61:61:15:a3 RADIUS: VLAN ID 20
> >
> > so we add the new ap_vlan interface due to a station needing it.
> >
> > > nl80211: New interface wlan0-2.20 created: ifindex=60
> >
> > that interface has ifindex=60 assigned
> >
> > > VLAN: Set interface wlan0-2.20 up
> >
> > and is configured ifconfig_up
> >
> > > WPA: Add group state machine for VLAN-ID 20
> >
> > now wpa group keying starts before the station was assigned to the
> > driver
> >
> > > wpa_driver_nl80211_set_key: ifindex=60 (wlan0-2.20) alg=3
> > > addr=0x496be4 key_idx=1 set_tx=1 seq_len=0 key_len=16
> >
> > a wpa group key shall be configured to the wireless driver
> >
> > > nl80211: set_key failed; err=-22 Invalid argument)
> >
> > but the driver does not like it. I don't know why. It should not.
> >
> > > WPA: group state machine entering state FATAL_FAILURE
> >
> > so the group state machine blocks and
> >
> > > WPA initialization for VLAN 20 failed (-1)
> >
> > interface initialization is declared failing
> >
> > Regards,
> > M. Braun
> 
> 
> G?nther
> 
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap


From johannes at sipsolutions.net  Thu May 12 15:26:59 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Fri, 13 May 2016 00:26:59 +0200
Subject: [PATCH] wpa_supplicant: fix build without CTRL_IFACE
Message-ID: <1463092019-10462-1-git-send-email-johannes@sipsolutions.net>

wpas_ap_pmksa_cache_list() and wpas_ap_pmksa_cache_flush() should be
under the #ifdef since they're only called for the control iface and
use functionality that otherwise isn't available.

Signed-off-by: Johannes Berg <johannes at sipsolutions.net>
---
 wpa_supplicant/ap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c
index 4f895f34c0ad..49fbc1bc41e3 100644
--- a/wpa_supplicant/ap.c
+++ b/wpa_supplicant/ap.c
@@ -1368,7 +1368,6 @@ int wpas_ap_stop_ap(struct wpa_supplicant *wpa_s)
 	hapd = wpa_s->ap_iface->bss[0];
 	return hostapd_ctrl_iface_stop_ap(hapd);
 }
-#endif /* CONFIG_CTRL_IFACE */
 
 
 int wpas_ap_pmksa_cache_list(struct wpa_supplicant *wpa_s, char *buf,
@@ -1421,6 +1420,7 @@ void wpas_ap_pmksa_cache_flush(struct wpa_supplicant *wpa_s)
 	if (wpa_s->ifmsh)
 		hostapd_ctrl_iface_pmksa_flush(wpa_s->ifmsh->bss[0]);
 }
+#endif /* CONFIG_CTRL_IFACE */
 
 
 #ifdef NEED_AP_MLME
-- 
2.8.0.rc3



From kkangshawn at gmail.com  Thu May 12 19:18:14 2016
From: kkangshawn at gmail.com (SiWon Kang)
Date: Fri, 13 May 2016 11:18:14 +0900
Subject: [PATCH] wpa_cli: Add backspace key process for some terminal
Message-ID: <CAAYDh_hvk1gAu3jXTSiM1CxToFCU_Ydhae+Wimri2-p=4rP2WQ@mail.gmail.com>

In some terminal, verified with gtkterm and teraterm, backspace key is
not properly processed. For instance, type 'abc', 3 times of backspace
key press then '123' shows the result of 'abc123' instead of '123'. To
fix this, I add a routine to process '\b' character input.

Signed-off-by: Siwon Kang <kkangshawn at gmail.com>
---
 src/utils/edit_simple.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/src/utils/edit_simple.c b/src/utils/edit_simple.c
index 13173cb..9ac3f99 100644
--- a/src/utils/edit_simple.c
+++ b/src/utils/edit_simple.c
@@ -46,6 +46,12 @@ static void edit_read_char(int sock, void
*eloop_ctx, void *sock_ctx)
                fflush(stdout);
                return;
        }
+
+       if (c == '\b') {
+               if (cmdbuf_pos > 0) {
+                       cmdbuf[cmdbuf_pos--] = c;
+               }
+       }

        if (c >= 32 && c <= 255) {
                if (cmdbuf_pos < (int) sizeof(cmdbuf) - 1) {
-- 
1.9.1


From michael-dev at fami-braun.de  Fri May 13 00:18:39 2016
From: michael-dev at fami-braun.de (M. Braun)
Date: Fri, 13 May 2016 09:18:39 +0200
Subject: dynamic vlan with ath10k not working - regression
In-Reply-To: <EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern>
References: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
 <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351A8F@Pallas.devolo.intern>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern>
Message-ID: <57357FCF.4090006@fami-braun.de>

Hi,

Am 12.05.2016 um 17:28 schrieb Guenther Kelleter:
>> What exactly is not working in the static VLAN case?
>> I can configure an SSID to be part of a non-dynamic vlan in OpenWrt,
>> i.e. that all stations are put in the configured vlan-bridge. This
>> doesn't create a wlan0.<VLAN-ID> interface but uses the plain wlan0.
>> I can't see anything not working in this case before this fix was
>> added.
>> Maybe you're talking about a different thing?

When configuring non-wildcard vlans with config option vlan_file ,
hostapd will create the AP_VLAN (= wlan0.xyz) interfaces during process
startup and possibly add them to a bridge. This is what I call
"static" VLANs, as their AP_VLAN interfaces are present all the time
while hostapd runs.
That way the (static) AP_VLAN interfaces might already transmit
broadcast or multicast frames even when there is no station associated
in this VLAN.
If hostapd does not configure any WPA group key to the AP_VLAN
interface, it will transmit unencrypted.

> Adding this patch the station can associate again and the tagged wlan interface is created and put into the vlan-bridge. But I don't know what negative consequences it could cause:

I guess it basically makes hostapd believe it already configured a group
key to the AP_VLAN interface and thus nullifies the fix. I might as well
also break other things.

Regards,
M. Braun


From Guenther.Kelleter at devolo.de  Fri May 13 04:46:21 2016
From: Guenther.Kelleter at devolo.de (Guenther Kelleter)
Date: Fri, 13 May 2016 11:46:21 +0000
Subject: dynamic vlan with ath10k not working - regression
In-Reply-To: <57357FCF.4090006@fami-braun.de>
References: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
 <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351A8F@Pallas.devolo.intern>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern>
 <57357FCF.4090006@fami-braun.de>
Message-ID: <EF6DF72779EE294A8A2425E8DA3BC0CC54351F8C@Pallas.devolo.intern>

Hi


> -----Original Message-----
> From: Hostap [mailto:hostap-bounces at lists.infradead.org] On Behalf Of M. Braun
> Sent: Friday, May 13, 2016 9:19 AM
> To: hostap at lists.infradead.org
> Subject: Re: dynamic vlan with ath10k not working - regression
> 
> Hi,
> 
> Am 12.05.2016 um 17:28 schrieb Guenther Kelleter:
> >> What exactly is not working in the static VLAN case?
> >> I can configure an SSID to be part of a non-dynamic vlan in OpenWrt,
> >> i.e. that all stations are put in the configured vlan-bridge. This
> >> doesn't create a wlan0.<VLAN-ID> interface but uses the plain wlan0.
> >> I can't see anything not working in this case before this fix was
> >> added.
> >> Maybe you're talking about a different thing?
> 
> When configuring non-wildcard vlans with config option vlan_file ,
> hostapd will create the AP_VLAN (= wlan0.xyz) interfaces during process
> startup and possibly add them to a bridge. This is what I call
> "static" VLANs, as their AP_VLAN interfaces are present all the time
> while hostapd runs.
> That way the (static) AP_VLAN interfaces might already transmit
> broadcast or multicast frames even when there is no station associated
> in this VLAN.
> If hostapd does not configure any WPA group key to the AP_VLAN
> interface, it will transmit unencrypted.
> 
> > Adding this patch the station can associate again and the tagged wlan
> interface is created and put into the vlan-bridge. But I don't know what
> negative consequences it could cause:
> 
> I guess it basically makes hostapd believe it already configured a group
> key to the AP_VLAN interface and thus nullifies the fix. I might as well
> also break other things.
> 
> Regards,
> M. Braun
> 



Let me sum up what I did understand so far:
An AP_VLAN interface is created with every VLAN on a specific SSID. There is always an AP_VLAN with ID 0 created for the base interface of an SSID. When more VLANs are configured, either by static configuration in a vlan_file or by dynamic assignment through 802.1X RADIUS, an extra AP_VLAN interface is created per configured VLAN.
All AP_VLANs of an SSID must use their own group keys, to separate broadcast and multicast traffic. If they had no group key set broadcasts from lets say VLAN-1 would be transmitted unencrypted and then could be received by all the stations which are associated to the same SSID but assigned to another VLAN.

Is this correct?
How can I check if an AP_VLAN has a group key? I want to make sure that the dynamic VLANs are properly encrypted when I'm patching this to work on ath10k.
How to check if a GTK-rekey is executed for all AP_VLANs? (In debug log I only see " daemon.debug hostapd: wlan0: WPA rekeying GTK" but not e.g. " daemon.debug hostapd: wlan0.20: WPA rekeying GTK" for the tagged wlan interface.

Finally, is there any useful doc about those complex internals of hostapd? It's really difficult to know this by only looking at the code. And 802.11 doesn't mention how VLANs fit into it at all.


Thanks,
G?nther


From j at w1.fi  Fri May 13 11:26:29 2016
From: j at w1.fi (Jouni Malinen)
Date: Fri, 13 May 2016 21:26:29 +0300
Subject: [PATCH] OpenSSL: BoringSSL has SSL_get_client_random, etc.
In-Reply-To: <CAF8qwaDbQiooEMNMz9-CXvoqqoauywb2-bsZq_2dhWhnPeAEgw@mail.gmail.com>
References: <CAF8qwaDAts-FAPJs1ttZ5ac6qQQC2KX=JWAXi5o1ncfMhTGK7w@mail.gmail.com>
 <20160505211603.GD30363@w1.fi>
 <CAF8qwaBiEgN=GTG5JoTQWXqdKyfOfE6AOp+ux4_MrWTth2PeAg@mail.gmail.com>
 <CAF8qwaDbQiooEMNMz9-CXvoqqoauywb2-bsZq_2dhWhnPeAEgw@mail.gmail.com>
Message-ID: <20160513182629.GA5778@w1.fi>

On Mon, May 09, 2016 at 07:58:15PM -0400, David Benjamin wrote:
> BORINGSSL_API_VERSION is now in BoringSSL and AOSP master. I've
> attached a revised version of the patch that uses it instead.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri May 13 11:26:52 2016
From: j at w1.fi (Jouni Malinen)
Date: Fri, 13 May 2016 21:26:52 +0300
Subject: wpabuf overflow with WPS
In-Reply-To: <CANQnsBo09+GBzX2C-ySoRiMj8NiRoVRJ3XUiC+bKfqzcmhaZ8g@mail.gmail.com>
References: <5f7c55d9-f0e8-991e-25ff-74f94643bf24@dks-koeln.de>
 <20160427153227.GA5370@w1.fi>
 <20a3fd4c-c41c-f70a-c02b-c43f904a2fe5@dks-koeln.de>
 <20160428170603.GA8334@w1.fi>
 <1aedf756-312c-7221-06a3-cbb0c61e69d1@dks-koeln.de>
 <CANQnsBo4TAtU6t_5oBbCXNn4kTxE9uAER6RiB_JgWONjNptr-Q@mail.gmail.com>
 <20160510165345.GB7865@w1.fi>
 <CANQnsBo09+GBzX2C-ySoRiMj8NiRoVRJ3XUiC+bKfqzcmhaZ8g@mail.gmail.com>
Message-ID: <20160513182652.GB5778@w1.fi>

On Wed, May 11, 2016 at 08:40:44AM +0800, Wang Linetkux wrote:
>   Added now. It's the first time that I contribute to open-source
> community in such way. I hope the format of patch is well.

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri May 13 11:27:08 2016
From: j at w1.fi (Jouni Malinen)
Date: Fri, 13 May 2016 21:27:08 +0300
Subject: [PATCH] D-Bus: Check Driver capability for IBSS in Modes
 property of Capabilities
In-Reply-To: <1462945043-30272-1-git-send-email-saurav.babu@samsung.com>
References: <1462945043-30272-1-git-send-email-saurav.babu@samsung.com>
Message-ID: <20160513182708.GC5778@w1.fi>

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri May 13 11:27:23 2016
From: j at w1.fi (Jouni Malinen)
Date: Fri, 13 May 2016 21:27:23 +0300
Subject: [PATCH] drivers.mak: add NEED_RADIOTAP
In-Reply-To: <1463037970-16342-1-git-send-email-johannes@sipsolutions.net>
References: <1463037970-16342-1-git-send-email-johannes@sipsolutions.net>
Message-ID: <20160513182723.GD5778@w1.fi>

On Thu, May 12, 2016 at 09:26:10AM +0200, Johannes Berg wrote:
> If there's ever a driver that, like nl80211, requires radiotap,
> we need to have a NEED_RADIOTAP variable to avoid trying to link
> the radiotap helpers twice. Introduce that.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri May 13 11:27:36 2016
From: j at w1.fi (Jouni Malinen)
Date: Fri, 13 May 2016 21:27:36 +0300
Subject: [PATCH] wpa_supplicant: fix build without CTRL_IFACE
In-Reply-To: <1463092019-10462-1-git-send-email-johannes@sipsolutions.net>
References: <1463092019-10462-1-git-send-email-johannes@sipsolutions.net>
Message-ID: <20160513182736.GE5778@w1.fi>

On Fri, May 13, 2016 at 12:26:59AM +0200, Johannes Berg wrote:
> wpas_ap_pmksa_cache_list() and wpas_ap_pmksa_cache_flush() should be
> under the #ifdef since they're only called for the control iface and
> use functionality that otherwise isn't available.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri May 13 11:27:52 2016
From: j at w1.fi (Jouni Malinen)
Date: Fri, 13 May 2016 21:27:52 +0300
Subject: [PATCH] wpa_cli: Add backspace key process for some terminal
In-Reply-To: <CAAYDh_hvk1gAu3jXTSiM1CxToFCU_Ydhae+Wimri2-p=4rP2WQ@mail.gmail.com>
References: <CAAYDh_hvk1gAu3jXTSiM1CxToFCU_Ydhae+Wimri2-p=4rP2WQ@mail.gmail.com>
Message-ID: <20160513182752.GF5778@w1.fi>

On Fri, May 13, 2016 at 11:18:14AM +0900, SiWon Kang wrote:
> In some terminal, verified with gtkterm and teraterm, backspace key is
> not properly processed. For instance, type 'abc', 3 times of backspace
> key press then '123' shows the result of 'abc123' instead of '123'. To
> fix this, I add a routine to process '\b' character input.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From serega.belarus at gmail.com  Fri May 13 09:36:51 2016
From: serega.belarus at gmail.com (Sergei Sinyak)
Date: Fri, 13 May 2016 19:36:51 +0300
Subject: eduroam disconnects with reason=3 (WPA-EAP, PEAP, MSCHAPv2)
In-Reply-To: <CAGdowOP-m4ASFBSf-fh=BFDFEQaNjF-CFWjnhM6iEEKcqELWRQ@mail.gmail.com>
References: <CAGdowONbg=pKQChF+tWXz-Kc1Jh-CKegokx41rYjB5k3mR72MA@mail.gmail.com>
 <20160408135149.GB28917@w1.fi>
 <CAGdowOOPgPOykhm+HJyVfuP6-Ytm9oH_KmiuxENQhWS=UTCvGg@mail.gmail.com>
 <CAGdowONDQtCY6BPt8OnyWvTOSwv82h0CVeb0w8t1FnsNOXfHOQ@mail.gmail.com>
 <CAGdowONB7UB4vg1SiCvDEAzmkgsi2-Gmm9V4AC0ZzYt3aKZg7A@mail.gmail.com>
 <20160417185934.GB493@w1.fi>
 <CAGdowOOT2zi9J-AxrKoDK_q4pV0AGpvYMN+=hLtTNUkRHvMdgw@mail.gmail.com>
 <20160419084758.GA3249@w1.fi>
 <CAGdowOOv8Y682jCddEt+hxTiC-OSotcs371KryEJpO-H5+MGkg@mail.gmail.com>
 <CAGdowONsjYf6KAWct6FcHj75yvY9VO_DTevuzNZfYSSmez1NVQ@mail.gmail.com>
 <1461161495.30371.5.camel@redhat.com>
 <CAGdowOP-m4ASFBSf-fh=BFDFEQaNjF-CFWjnhM6iEEKcqELWRQ@mail.gmail.com>
Message-ID: <CAGdowOOHaqsHrHZrbE2Ow4Nf0-oJP9MoFw36FbC3Yme7j2_zkw@mail.gmail.com>

Hello, developers.

I confirm that this options solve issue in general. Connection establishes
via wpa_supplicant and dhcpcd retrieves ip configuration.

here is config:

% cat eduroam.conf
ctrl_interface=/run/wpa_supplicant
network={
  ssid="eduroam"
  key_mgmt=WPA-EAP
  eap=PEAP
  identity="fpm.SinyakSA"
  password="USER_PASSWORD_OMITTED"
  phase1="tls_disable_tlsv1_1=1 tls_disable_tlsv1_2=1"
  phase2="auth=MSCHAPV2"
}
% wpa_supplicant -i wlp1s0b1 -c eduroam.conf
% dhcpcd wlp1s0b1

It works well! Thanks for your time.

best regards,
Sergei Sinyak

P.S.
It works for a few laptops of my friends.
But on my machine it results in a error on a further stage.
Particularly, here it is:
nl80211: set_key failed; err=-22 Invalid argument)

More info can be found on archforum thread
https://bbs.archlinux.org/viewtopic.php?id=211842


From greearb at candelatech.com  Sat May 14 06:38:23 2016
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 14 May 2016 06:38:23 -0700
Subject: RFC:  patch to support 5Mhz and 10Mhz widths.
Message-ID: <57372A4F.9080205@candelatech.com>

This patch does not compile....looks like I have to pass chwidth into a lot
more places.  But, I'm curious if anyone has any opinions on whether this is
even remotely the right way to go about doing this?

Or, is it better to just hack the driver directly like openwrt does?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hostap_5mhz.patch
Type: text/x-patch
Size: 24027 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160514/0bfec4aa/attachment.bin>

From j at w1.fi  Sat May 14 07:13:29 2016
From: j at w1.fi (Jouni Malinen)
Date: Sat, 14 May 2016 17:13:29 +0300
Subject: RFC:  patch to support 5Mhz and 10Mhz widths.
In-Reply-To: <57372A4F.9080205@candelatech.com>
References: <57372A4F.9080205@candelatech.com>
Message-ID: <20160514141329.GA18000@w1.fi>

On Sat, May 14, 2016 at 06:38:23AM -0700, Ben Greear wrote:
> This patch does not compile....looks like I have to pass chwidth into a lot
> more places.  But, I'm curious if anyone has any opinions on whether this is
> even remotely the right way to go about doing this?

What is your use case for this? 5 and 10 MHz channel widths are not
really used very commonly today and only in quite special use cases..
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From greearb at candelatech.com  Sat May 14 09:18:15 2016
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 14 May 2016 09:18:15 -0700
Subject: RFC:  patch to support 5Mhz and 10Mhz widths.
In-Reply-To: <20160514141329.GA18000@w1.fi>
References: <57372A4F.9080205@candelatech.com> <20160514141329.GA18000@w1.fi>
Message-ID: <57374FC7.5080006@candelatech.com>



On 05/14/2016 07:13 AM, Jouni Malinen wrote:
> On Sat, May 14, 2016 at 06:38:23AM -0700, Ben Greear wrote:
>> This patch does not compile....looks like I have to pass chwidth into a lot
>> more places.  But, I'm curious if anyone has any opinions on whether this is
>> even remotely the right way to go about doing this?
>
> What is your use case for this? 5 and 10 MHz channel widths are not
> really used very commonly today and only in quite special use cases..

Seems they are used in the 4.9Ghz band, at least.  That is what my user
is interested in...

Thanks,
Ben

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


From j at w1.fi  Sat May 14 10:08:28 2016
From: j at w1.fi (Jouni Malinen)
Date: Sat, 14 May 2016 20:08:28 +0300
Subject: [PATCH] wpa_supplicant: send event to all interfaces
In-Reply-To: <CB3B3D4774441E42AA3EA0E1BA8230A0613FFCEC@HASMSX110.ger.corp.intel.com>
References: <1459450394-19120-1-git-send-email-janusz.dziedzic@tieto.com>
 <20160402103010.GB20860@w1.fi>
 <CAFED-jkbw62bRE36TsnNCw5oRppskqprXocjgJm3trGbPu01zA@mail.gmail.com>
 <CAFED-jkMKsLY6ECMdr-8zqxgrL8QcquBny26jOsQCh5tXek23A@mail.gmail.com>
 <20160424084238.GC3283@w1.fi>
 <CALhHN=oB-VN0t2o54FFzrEtgjG2AZ0VhRGn1m9cvxuQUcvrhJw@mail.gmail.com>
 <CB3B3D4774441E42AA3EA0E1BA8230A0613FFCEC@HASMSX110.ger.corp.intel.com>
Message-ID: <20160514170828.GA29772@w1.fi>

On Mon, Apr 25, 2016 at 06:35:05AM +0000, Peer, Ilan wrote:
> I think that is the same issue that was addressed in http://lists.shmoo.com/pipermail/hostap/2015-June/033085.html
> 
> The attached patch also handles this issue. 

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat May 14 10:09:11 2016
From: j at w1.fi (Jouni Malinen)
Date: Sat, 14 May 2016 20:09:11 +0300
Subject: [PATCH v3 1/6] tests: remotehost.py use join
In-Reply-To: <1461906457-18455-1-git-send-email-janusz.dziedzic@tieto.com>
References: <1461906457-18455-1-git-send-email-janusz.dziedzic@tieto.com>
Message-ID: <20160514170911.GB29772@w1.fi>

Thanks, all six patches applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From janusz.dziedzic at tieto.com  Sat May 14 11:27:58 2016
From: janusz.dziedzic at tieto.com (Janusz Dziedzic)
Date: Sat, 14 May 2016 20:27:58 +0200
Subject: [PATCH v3 1/6] tests: remotehost.py use join
In-Reply-To: <20160514170911.GB29772@w1.fi>
References: <1461906457-18455-1-git-send-email-janusz.dziedzic@tieto.com>
 <20160514170911.GB29772@w1.fi>
Message-ID: <CALhHN=qHKYX77mW0oa1qc1O0TgCgiypcCv-bLszV4AADgs5pYw@mail.gmail.com>

On 14 May 2016 at 19:09, Jouni Malinen <j at w1.fi> wrote:
> Thanks, all six patches applied.
>
Thanks!!!

BR
Janusz

> --
> Jouni Malinen                                            PGP id EFC895FA


From greearb at candelatech.com  Sat May 14 14:08:34 2016
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 14 May 2016 14:08:34 -0700
Subject: RFC: patch to support 5Mhz and 10Mhz widths.
In-Reply-To: <57374FC7.5080006@candelatech.com>
References: <57372A4F.9080205@candelatech.com> <20160514141329.GA18000@w1.fi>
 <57374FC7.5080006@candelatech.com>
Message-ID: <573793D2.1060408@candelatech.com>

I'm giving up on this for now, but the patches I was trying
are attached in case someone else wants to try it someday.

It compiles now, but AP won't start...I have no idea why.

Thanks,
Ben

On 05/14/2016 09:18 AM, Ben Greear wrote:
>
>
> On 05/14/2016 07:13 AM, Jouni Malinen wrote:
>> On Sat, May 14, 2016 at 06:38:23AM -0700, Ben Greear wrote:
>>> This patch does not compile....looks like I have to pass chwidth into a lot
>>> more places.  But, I'm curious if anyone has any opinions on whether this is
>>> even remotely the right way to go about doing this?
>>
>> What is your use case for this? 5 and 10 MHz channel widths are not
>> really used very commonly today and only in quite special use cases..
>
> Seems they are used in the 4.9Ghz band, at least.  That is what my user
> is interested in...
>
> Thanks,
> Ben
>


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hostap_5mhz.patch
Type: text/x-patch
Size: 29120 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160514/3addd165/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nl80211_5mhz.patch
Type: text/x-patch
Size: 1117 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160514/3addd165/attachment-0003.bin>

From michael-dev at fami-braun.de  Sun May 15 07:44:57 2016
From: michael-dev at fami-braun.de (M. Braun)
Date: Sun, 15 May 2016 16:44:57 +0200
Subject: dynamic vlan with ath10k not working - regression
In-Reply-To: <EF6DF72779EE294A8A2425E8DA3BC0CC54351F8C@Pallas.devolo.intern>
References: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
 <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351A8F@Pallas.devolo.intern>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern>
 <57357FCF.4090006@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351F8C@Pallas.devolo.intern>
Message-ID: <57388B69.50900@fami-braun.de>

Am 13.05.2016 um 13:46 schrieb Guenther Kelleter:
> Let me sum up what I did understand so far:
> ...
> Is this correct?

Yes.

To be more precise, that "base" interface is per BSS and has type "AP",
but that does not really make a difference here.

Please also note that also with dynamic vlans, there might be some
time (and protocol steps) between hostapd creating the new AP_VLAN
interface but not yet binding the station there.

> then could be received by all the stations which are associated to
> the same SSID but assigned to another VLAN.

The stations should not accept those packets because they should expect
all frames to be encrypted. But those packets could be sniffed by any
possibly unconnected station and thus leak data.

> How can I check if an AP_VLAN has a group key? I want to make sure
> that the dynamic VLANs are properly encrypted when I'm patching this
> to work on ath10k.

You can hook into the set_key function and debug print it.
Or you generate some packets on that interface (e.g. with some
distinguishing source mac address ) and then sniff it. As the mac
address is not encrypted, you can easily filter for these packets and
inspect them for encryption.

Properly encrypted would also require the keys used to be sufficiently
random, thought that cannot be verified that easily.

> How to check if a GTK-rekey is executed for all AP_VLANs? (In debug
> log I only see " daemon.debug hostapd: wlan0: WPA rekeying GTK" but
> not e.g. " daemon.debug hostapd: wlan0.20: WPA rekeying GTK" for the
> tagged wlan interface.

see src/ap/wpa_auth.c function wpa_rekey_gtk which creates that debug
print. It iterates over all struct wpa_group ( aka VLAN ) of that BSS
and triggers rekeying. So the main point for making sure WPA rekeying
happens for all VLANs is by ensuring that for each AP_VLAN interface,
there is a corresponding struct wpa_group entry.
This is also how 7cebc8e2 fixed its issue.
Of course you can just add debug statements into that loop.

> Finally, is there any useful doc about those complex internals of
> hostapd? It's really difficult to know this by only looking at the
> code. And 802.11 doesn't mention how VLANs fit into it at all.

Hostapd has doxygen docs [1]. Apart of that, I have been reading the
source of hostapd and mac80211 for some years now.

Regards,
 M. Braun

[1] http://w1.fi/wpa_supplicant/devel/



From davidben at google.com  Wed May 18 10:10:07 2016
From: davidben at google.com (David Benjamin)
Date: Wed, 18 May 2016 13:10:07 -0400
Subject: [PATCH] OpenSSL: Remove two more accesses of ssl_ctx->cert_store.
Message-ID: <CAF8qwaBLk5-2Ra1jwewsuPGYEDzyBrUpUcPSzaJWbXU-o-4XtQ@mail.gmail.com>

Patch attached.

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-OpenSSL-Remove-two-more-accesses-of-ssl_ctx-cert_sto.patch
Type: text/x-patch
Size: 1953 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160518/143c92ba/attachment.bin>

From davidben at google.com  Wed May 18 10:27:17 2016
From: davidben at google.com (David Benjamin)
Date: Wed, 18 May 2016 13:27:17 -0400
Subject: EAP-FAST PRF hooks and BoringSSL
In-Reply-To: <CAF8qwaCeha_KGz0rt6BJtYpAYt08F=+LL2zLWCjGmwSPQwF=NQ@mail.gmail.com>
References: <CAF8qwaCeha_KGz0rt6BJtYpAYt08F=+LL2zLWCjGmwSPQwF=NQ@mail.gmail.com>
Message-ID: <CAF8qwaBwg-vC3KMEuyXMP2q4++zsbcrzoPWjQEoo2P4hhO6v4A@mail.gmail.com>

On Tue, May 10, 2016 at 1:28 PM, David Benjamin <davidben at google.com> wrote:
> 1. I can condition the EAP-FAST-only parts of the key derivation
> conditioned on EAP_FAST #defines. With
> df5bde83daaf3c820b6ac1f8d383b16a64ebd2db, we're finally no longer
> defining those symbols, so this would work. I would probably, to make
> this cleaner, split the tls_connection_prf entry-point into two
> functions, one for the reasonable RFC 5705 mechanisms and one for
> EAP-FAST's crazy thing. (Right now the API supports the RFC 5705
> style, but with skip_keyblock set, which is a little odd.)

I've attached the cleanup and #ifdefs I was thinking for this option.
Note: I've only compile-tested this against Android thus far. It's
mostly to clarify what I mean, and I'm sure I messed up somewhere.

I think the first of these two patches is worthwhile in itself. The
EAP-FAST key derivation is very different compared to how new
protocols are supposed to do it (RFC 5705). The split is also more
conducive to, say, OpenSSL maybe providing an API for extracting
EAP-FAST style keys, either by adding BoringSSL's
SSL_generate_key_block API to OpenSSL or perhaps they add an
EAP-FAST-specific key derivation function. I don't think it makes
sense that hostap needs to reimplement the TLS PRF.

You can also see awkwardness in the merged tls_connection_prf; the
skip_keyblock parameter makes no sense unless server_random_first and
label align with the native TLS key derivation. Whereas when
skip_keyblock and server_random_first is 0, this is just a call to
SSL_export_keying_material in OpenSSL. This suggests they should be
two distinct operations.

The second one I don't have strong opinions on. For my purposes, I
would be happy with it, with making BoringSSL use the OpenSSL 1.1.x
path (I'd add the missing functions), or with using the
BoringSSL-specific functions. I'm happy to put together whichever
version you all prefer.

Thoughts?

> 2. For OpenSSL 1.1.x, you all use SSL_CIPHER_get_cipher_nid and
> SSL_CIPHER_get_digest_nid. BoringSSL doesn't have these, but I have no
> problems adding them. (I would not have used NIDs for
> SSL_CIPHER_get_kx_nid and SSL_CIPHER_get_auth_nid but whatever.) It's
> a little odd because the computation is wrong for TLS 1.1+ and we
> don't use EVP_CIPHER in our SSL code anymore. But the code will never
> run anyway, and if it were to later, I could make it match OpenSSL.
>
> 3. For other reasons, we added a pair of functions,
> SSL_get_key_block_len and SSL_generate_key_block which are actually
> exactly what EAP-FAST wants here. I could make
> openssl_get_keyblock_size call SSL_get_key_block_len and even make
> openssl_tls_prf use SSL_generate_key_block. (Probably this would come
> with a similar tls_connection_prf split as in option #1.) But this
> would be BoringSSL-only code to support a feature that doesn't work in
> BoringSSL anyway, so this is of questionable use.
> https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_get_key_block_len
>
> Do you all have a preference? #2 would be the least invasive option,
> but splitting tls_connection_prf in two for #1 might be preferable, at
> which point you may as well condition on EAP-FAST. In doing so, we can
> probably do away with the fallback from SSL_export_keying_material to
> openssl_tls_prf if SSL_export_keying_material fails (looks like that's
> a remnant of how the #ifdefs worked out while 1.0.0 was supported) and
> not even ship a custom TLS PRF in the no-EAP-FAST config. I'm happy to
> do a bit of cleanup for you along the way here.
>
> David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-TLS-Split-tls_connection_prf-into-two-functions.patch
Type: text/x-patch
Size: 15563 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160518/d10c4957/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-OpenSSL-Don-t-implement-tls_connection_get_eap_fast_.patch
Type: text/x-patch
Size: 2265 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160518/d10c4957/attachment-0003.bin>

From annlo.tech at gmail.com  Wed May 18 11:07:30 2016
From: annlo.tech at gmail.com (Ann Lo)
Date: Wed, 18 May 2016 11:07:30 -0700
Subject: Question on Multiple BSSID support
Message-ID: <CABy9W5nn8w1C-EUgva4sOQGOv46qQ0BFVpXfrbtSPar+Vz06Tg@mail.gmail.com>

The hostapd configuration allows for multiple BSSID support, with the
following comment:

#bss=wlan0_0
#ssid=test2
# most of the above items can be used here (apart from radio interface specific
# items, like channel)

Would you advise whether it is OK to define the following
configurations differently for each BSSID? We are using ath10k driver.
1) WMM parameters
2) Station inactivity limit
3) max_num_sta
4) WPA/IEEE 802.11i configuration

Thanks,
Ann


From Guenther.Kelleter at devolo.de  Thu May 19 04:45:58 2016
From: Guenther.Kelleter at devolo.de (Guenther Kelleter)
Date: Thu, 19 May 2016 11:45:58 +0000
Subject: dynamic vlan with ath10k not working - regression
In-Reply-To: <57388B69.50900@fami-braun.de>
References: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
 <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351A8F@Pallas.devolo.intern>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern>
 <57357FCF.4090006@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351F8C@Pallas.devolo.intern>
 <57388B69.50900@fami-braun.de>
Message-ID: <EF6DF72779EE294A8A2425E8DA3BC0CC54352FCF@Pallas.devolo.intern>

Hi


> -----Original Message-----
> From: Hostap [mailto:hostap-bounces at lists.infradead.org] On Behalf Of M. Braun
> Sent: Sunday, May 15, 2016 4:45 PM
> To: hostap at lists.infradead.org
> Subject: Re: dynamic vlan with ath10k not working - regression
> 
> Am 13.05.2016 um 13:46 schrieb Guenther Kelleter:
> > Let me sum up what I did understand so far:
> > ...
> > Is this correct?
> 
> Yes.
> 
> To be more precise, that "base" interface is per BSS and has type "AP",
> but that does not really make a difference here.

Ah, but isn't this exactly the difference that matters here?
According to a comment in mac80211 an AP_VLAN interface is not represented by a vdev of the driver. And a key cannot be installed for a VLAN. Does AP_VLAN encryption have to be handled in software? But the SW_CRYPTO_CONTROL flag somehow prevents SW-crypto for ath10k.
How is this VLAN encryption gonna work at all when for an AP_VLAN neither HW nor SW- crypto are supported?
I don't get it. 

from net/mac80211/key.c:ieee80211_key_enable_hw_accel() of mac-80211
Thats why set_key() fails:

static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
{
[...]
        if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
                /*
                 * The driver doesn't know anything about VLAN interfaces.
                 * Hence, don't send GTKs for VLAN interfaces to the driver.
                 */
                if (!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE))         // ! This condition is true
                        goto out_unsupported;
        }
[...]
out_unsupported:
        switch (key->conf.cipher) {
        case WLAN_CIPHER_SUITE_WEP40:
        case WLAN_CIPHER_SUITE_WEP104:
        case WLAN_CIPHER_SUITE_TKIP:
        case WLAN_CIPHER_SUITE_CCMP:
        case WLAN_CIPHER_SUITE_CCMP_256:
        case WLAN_CIPHER_SUITE_AES_CMAC:
        case WLAN_CIPHER_SUITE_BIP_CMAC_256:
        case WLAN_CIPHER_SUITE_BIP_GMAC_128:
        case WLAN_CIPHER_SUITE_BIP_GMAC_256:
        case WLAN_CIPHER_SUITE_GCMP:
        case WLAN_CIPHER_SUITE_GCMP_256:
                /* all of these we can do in software - if driver can */
                if (ret == 1)
                        return 0;
                if (ieee80211_hw_check(&key->local->hw, SW_CRYPTO_CONTROL))    // ! this condition also true 
-------->               return -EINVAL;
                return 0;
        default:
                return -EINVAL;
        }
}



G?nther


> 
> Please also note that also with dynamic vlans, there might be some
> time (and protocol steps) between hostapd creating the new AP_VLAN
> interface but not yet binding the station there.
> 
> > then could be received by all the stations which are associated to
> > the same SSID but assigned to another VLAN.
> 
> The stations should not accept those packets because they should expect
> all frames to be encrypted. But those packets could be sniffed by any
> possibly unconnected station and thus leak data.
> 
> > How can I check if an AP_VLAN has a group key? I want to make sure
> > that the dynamic VLANs are properly encrypted when I'm patching this
> > to work on ath10k.
> 
> You can hook into the set_key function and debug print it.
> Or you generate some packets on that interface (e.g. with some
> distinguishing source mac address ) and then sniff it. As the mac
> address is not encrypted, you can easily filter for these packets and
> inspect them for encryption.
> 
> Properly encrypted would also require the keys used to be sufficiently
> random, thought that cannot be verified that easily.
> 
> > How to check if a GTK-rekey is executed for all AP_VLANs? (In debug
> > log I only see " daemon.debug hostapd: wlan0: WPA rekeying GTK" but
> > not e.g. " daemon.debug hostapd: wlan0.20: WPA rekeying GTK" for the
> > tagged wlan interface.
> 
> see src/ap/wpa_auth.c function wpa_rekey_gtk which creates that debug
> print. It iterates over all struct wpa_group ( aka VLAN ) of that BSS
> and triggers rekeying. So the main point for making sure WPA rekeying
> happens for all VLANs is by ensuring that for each AP_VLAN interface,
> there is a corresponding struct wpa_group entry.
> This is also how 7cebc8e2 fixed its issue.
> Of course you can just add debug statements into that loop.
> 
> > Finally, is there any useful doc about those complex internals of
> > hostapd? It's really difficult to know this by only looking at the
> > code. And 802.11 doesn't mention how VLANs fit into it at all.
> 
> Hostapd has doxygen docs [1]. Apart of that, I have been reading the
> source of hostapd and mac80211 for some years now.
> 
> Regards,
>  M. Braun
> 
> [1] http://w1.fi/wpa_supplicant/devel/
> 
> 
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap


From jonathan at wizery.com  Thu May 19 06:06:42 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Thu, 19 May 2016 16:06:42 +0300
Subject: [PATCH 1/9] tests: Support p2p group interfaces in hwsim remote tests
Message-ID: <1463663210-15610-1-git-send-email-jonathan@wizery.com>

Start using the wpa_supplicant remote udp interface for the
control and monitor sockets for p2p group interfaces so
that p2p tests would work on real hardware.
Also have the group requests and events show in the test log
with the hostname and the interface name of the group interface.

Signed-off-by: Jonathan Afek <jonathanx.afek at intel.com>
---
 tests/hwsim/wpasupplicant.py | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/tests/hwsim/wpasupplicant.py b/tests/hwsim/wpasupplicant.py
index f26124d..bee447a 100644
--- a/tests/hwsim/wpasupplicant.py
+++ b/tests/hwsim/wpasupplicant.py
@@ -158,8 +158,12 @@ class WpaSupplicant:
 
     def group_request(self, cmd):
         if self.group_ifname and self.group_ifname != self.ifname:
-            logger.debug(self.group_ifname + ": CTRL: " + cmd)
-            gctrl = wpaspy.Ctrl(os.path.join(wpas_ctrl, self.group_ifname))
+            if self.hostname is None:
+                gctrl = wpaspy.Ctrl(os.path.join(wpas_ctrl, self.group_ifname))
+            else:
+                port = self.get_ctrl_iface_port(self.group_ifname)
+                gctrl = wpaspy.Ctrl(self.hostname, port)
+            logger.debug(self.group_dbg + ": CTRL(group): " + cmd)
             return gctrl.request(cmd)
         return self.request(cmd)
 
@@ -574,7 +578,13 @@ class WpaSupplicant:
         res['ifname'] = s[2]
         self.group_ifname = s[2]
         try:
-            self.gctrl_mon = wpaspy.Ctrl(os.path.join(wpas_ctrl, self.group_ifname))
+            if self.hostname is None:
+                self.gctrl_mon = wpaspy.Ctrl(os.path.join(wpas_ctrl, self.group_ifname))
+                self.group_dbg = self.group_ifname
+            else:
+                port = self.get_ctrl_iface_port(self.group_ifname)
+                self.gctrl_mon = wpaspy.Ctrl(self.hostname, port)
+                self.group_dbg = self.hostname + "/" + self.group_ifname
             self.gctrl_mon.attach()
         except:
             logger.debug("Could not open monitor socket for group interface")
@@ -755,7 +765,7 @@ class WpaSupplicant:
             while True:
                 while self.gctrl_mon.pending():
                     ev = self.gctrl_mon.recv()
-                    logger.debug(self.group_ifname + ": " + ev)
+                    logger.debug(self.group_dbg + "(group): " + ev)
                     for event in events:
                         if event in ev:
                             return ev
-- 
1.9.1



From jonathan at wizery.com  Thu May 19 06:06:43 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Thu, 19 May 2016 16:06:43 +0300
Subject: [PATCH 2/9] tests: Remote hwsim tests skip broadcast connectivity test
In-Reply-To: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
Message-ID: <1463663210-15610-2-git-send-email-jonathan@wizery.com>

The regular hwsim tests use both unicast and broadcast frames to test
the connectivity between 2 interfaces.
For real hardware (remote hwsim tests) the broadcast frames will
sometimes not be seen by all connected stations since they can be in
low power mode during DTIM or because broadcast frames are not
acked.
This commit makes the connectivity test for real hardware use
only unicast frames instead of both unicast and broadcast.

Signed-off-by: Jonathan Afek <jonathanx.afek at intel.com>
---
 tests/hwsim/hwsim_utils.py | 54 ++++++++++++++++++++++++----------------------
 1 file changed, 28 insertions(+), 26 deletions(-)

diff --git a/tests/hwsim/hwsim_utils.py b/tests/hwsim/hwsim_utils.py
index 85f54a2..9438372 100644
--- a/tests/hwsim/hwsim_utils.py
+++ b/tests/hwsim/hwsim_utils.py
@@ -61,19 +61,20 @@ def run_connectivity_test(dev1, dev2, tos, dev1group=False, dev2group=False,
         if "DATA-TEST-RX {} {}".format(addr2, addr1) not in ev:
             raise Exception("Unexpected dev1->dev2 unicast data result")
 
-        cmd = "DATA_TEST_TX ff:ff:ff:ff:ff:ff {} {}".format(addr1, tos)
-        if dev1group:
-            dev1.group_request(cmd)
-        else:
-            dev1.request(cmd)
-        if dev2group:
-            ev = dev2.wait_group_event(["DATA-TEST-RX"], timeout=timeout)
-        else:
-            ev = dev2.wait_event(["DATA-TEST-RX"], timeout=timeout)
-        if ev is None:
-            raise Exception("dev1->dev2 broadcast data delivery failed")
-        if "DATA-TEST-RX ff:ff:ff:ff:ff:ff {}".format(addr1) not in ev:
-            raise Exception("Unexpected dev1->dev2 broadcast data result")
+        if dev1.hostname is None and dev2.hostname is None:
+            cmd = "DATA_TEST_TX ff:ff:ff:ff:ff:ff {} {}".format(addr1, tos)
+            if dev1group:
+                dev1.group_request(cmd)
+            else:
+                dev1.request(cmd)
+            if dev2group:
+                ev = dev2.wait_group_event(["DATA-TEST-RX"], timeout=timeout)
+            else:
+                ev = dev2.wait_event(["DATA-TEST-RX"], timeout=timeout)
+            if ev is None:
+                raise Exception("dev1->dev2 broadcast data delivery failed")
+            if "DATA-TEST-RX ff:ff:ff:ff:ff:ff {}".format(addr1) not in ev:
+                raise Exception("Unexpected dev1->dev2 broadcast data result")
 
         cmd = "DATA_TEST_TX {} {} {}".format(addr1, addr2, tos)
         if dev2group:
@@ -89,19 +90,20 @@ def run_connectivity_test(dev1, dev2, tos, dev1group=False, dev2group=False,
         if "DATA-TEST-RX {} {}".format(addr1, addr2) not in ev:
             raise Exception("Unexpected dev2->dev1 unicast data result")
 
-        cmd = "DATA_TEST_TX ff:ff:ff:ff:ff:ff {} {}".format(addr2, tos)
-        if dev2group:
-            dev2.group_request(cmd)
-        else:
-            dev2.request(cmd)
-        if dev1group:
-            ev = dev1.wait_group_event(["DATA-TEST-RX"], timeout=timeout)
-        else:
-            ev = dev1.wait_event(["DATA-TEST-RX"], timeout=timeout)
-        if ev is None:
-            raise Exception("dev2->dev1 broadcast data delivery failed")
-        if "DATA-TEST-RX ff:ff:ff:ff:ff:ff {}".format(addr2) not in ev:
-            raise Exception("Unexpected dev2->dev1 broadcast data result")
+        if dev1.hostname is None and dev2.hostname is None:
+            cmd = "DATA_TEST_TX ff:ff:ff:ff:ff:ff {} {}".format(addr2, tos)
+            if dev2group:
+                dev2.group_request(cmd)
+            else:
+                dev2.request(cmd)
+            if dev1group:
+                ev = dev1.wait_group_event(["DATA-TEST-RX"], timeout=timeout)
+            else:
+                ev = dev1.wait_event(["DATA-TEST-RX"], timeout=timeout)
+            if ev is None:
+                raise Exception("dev2->dev1 broadcast data delivery failed")
+            if "DATA-TEST-RX ff:ff:ff:ff:ff:ff {}".format(addr2) not in ev:
+                raise Exception("Unexpected dev2->dev1 broadcast data result")
     finally:
         if config:
             if dev1group:
-- 
1.9.1



From jonathan at wizery.com  Thu May 19 06:06:45 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Thu, 19 May 2016 16:06:45 +0300
Subject: [PATCH 4/9] tests: Add support for get_monitor_params() for p2p ifaces
In-Reply-To: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
Message-ID: <1463663210-15610-4-git-send-email-jonathan@wizery.com>

This function is used for tests when a monitor interface is wanted on the
channel on which the softap operates.
This change enables us to also query p2p interfaces for the channel
information to use for monitor interfaces.

Signed-off-by: Jonathan Afek <jonathanx.afek at intel.com>
---
 tests/remote/monitor.py | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/tests/remote/monitor.py b/tests/remote/monitor.py
index fe67592..a88eecc 100644
--- a/tests/remote/monitor.py
+++ b/tests/remote/monitor.py
@@ -139,16 +139,21 @@ def remove(host):
 
 
 # get monitor params from hostapd
-def get_monitor_params(hapd):
-    freq = hapd.get_status_field("freq")
+def get_monitor_params(wpa, is_p2p=False):
+    get_status_field_f = None
+    if is_p2p:
+        get_status_field_f = wpa.get_group_status_field
+    else:
+        get_status_field_f = wpa.get_status_field
+    freq = get_status_field_f("freq")
     bw = "20"
     center_freq1=""
     center_freq2=""
 
-    vht_oper_chwidth = hapd.get_status_field("vht_oper_chwidth")
-    secondary_channel = hapd.get_status_field("secondary_channel")
-    vht_oper_centr_freq_seg0_idx = hapd.get_status_field("vht_oper_centr_freq_seg0_idx")
-    vht_oper_centr_freq_seg1_idx = hapd.get_status_field("vht_oper_centr_freq_seg1_idx")
+    vht_oper_chwidth = get_status_field_f("vht_oper_chwidth")
+    secondary_channel = get_status_field_f("secondary_channel")
+    vht_oper_centr_freq_seg0_idx = get_status_field_f("vht_oper_centr_freq_seg0_idx")
+    vht_oper_centr_freq_seg1_idx = get_status_field_f("vht_oper_centr_freq_seg1_idx")
     if vht_oper_chwidth == "0" or vht_oper_chwidth is None:
         if secondary_channel == "1":
             bw = "40"
-- 
1.9.1



From jonathan at wizery.com  Thu May 19 06:06:44 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Thu, 19 May 2016 16:06:44 +0300
Subject: [PATCH 3/9] tests: Use a function to add a log file to a remote host
In-Reply-To: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
Message-ID: <1463663210-15610-3-git-send-email-jonathan@wizery.com>

Instead of accessing the logs list member of the remote host directly,
use a function to add logs to the remote host to be collected after the
test. This enables us to later have different implementation of remote hosts
or logs collection without requiring to have this list as the implementation.

Signed-off-by: Jonathan Afek <jonathanx.afek at intel.com>
---
 tests/hwsim/remotehost.py    | 3 +++
 tests/remote/monitor.py      | 2 +-
 tests/remote/rutils.py       | 8 ++++----
 tests/remote/test_example.py | 4 ++--
 4 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/tests/hwsim/remotehost.py b/tests/hwsim/remotehost.py
index 5021b92..39d7253 100644
--- a/tests/hwsim/remotehost.py
+++ b/tests/hwsim/remotehost.py
@@ -93,6 +93,9 @@ class Host():
         if t.isAlive():
             t.join(wait)
 
+    def add_log(self, log_file):
+        self.logs.append(log_file)
+
     def get_logs(self, local_log_dir=None):
         for log in self.logs:
             if local_log_dir:
diff --git a/tests/remote/monitor.py b/tests/remote/monitor.py
index fb621ad..fe67592 100644
--- a/tests/remote/monitor.py
+++ b/tests/remote/monitor.py
@@ -95,7 +95,7 @@ def run(host, setup_params):
         log_monitor = log_monitor + "_" + monitor
 
     log = log_dir + tc_name + "_" + host.name + log_monitor + ".pcap"
-    host.logs.append(log)
+    host.add_log(log)
     thread = host.execute_run([tshark, "-w", log], monitor_res)
     host.thread = thread
 
diff --git a/tests/remote/rutils.py b/tests/remote/rutils.py
index 588566a..fd6127b 100644
--- a/tests/remote/rutils.py
+++ b/tests/remote/rutils.py
@@ -63,7 +63,7 @@ def trace_start_stop(host, setup_params, start):
         else:
             cmd = stop_trace
         trace_dir = setup_params['log_dir'] + host.ifname + "/remote_traces"
-        host.logs.append(trace_dir + "/*")
+        host.add_log(trace_dir + "/*")
         host.execute([cmd, "-I", host.ifname, "-D", trace_dir])
     except:
         pass
@@ -88,7 +88,7 @@ def perf_start_stop(host, setup_params, start):
         else:
             cmd = perf_stop
         perf_dir = setup_params['log_dir'] + host.ifname + "/remote_perf"
-        host.logs.append(perf_dir + "/*")
+        host.add_log(perf_dir + "/*")
         host.execute([cmd, "-I", host.ifname, "-D", perf_dir])
     except:
         pass
@@ -106,7 +106,7 @@ def run_hostapd(host, setup_params):
         log = ""
 
     if log_file:
-        host.logs.append(log_file)
+        host.add_log(log_file)
     status, buf = host.execute([setup_params['hostapd'], "-B", "-ddt", "-g", "udp:" + host.port, log])
     if status != 0:
         raise Exception("Could not run hostapd: " + buf)
@@ -123,7 +123,7 @@ def run_wpasupplicant(host, setup_params):
         log = ""
 
     if log_file:
-        host.logs.append(log_file)
+        host.add_log(log_file)
     status, buf = host.execute([setup_params['wpa_supplicant'], "-B", "-ddt", "-g", "udp:" + host.port, log])
     if status != 0:
         raise Exception("Could not run wpa_supplicant: " + buf)
diff --git a/tests/remote/test_example.py b/tests/remote/test_example.py
index f834c0a..09c7e77 100644
--- a/tests/remote/test_example.py
+++ b/tests/remote/test_example.py
@@ -128,14 +128,14 @@ def test_example(devices, setup_params, refs, duts, monitors):
             monitor.remove(sta)
             dmesg = setup_params['log_dir'] + setup_params['tc_name'] + "_" + sta.name + "_" + sta.ifname + ".dmesg"
             sta.execute(["dmesg", "-c", ">", dmesg])
-            sta.logs.append(dmesg)
+            sta.add_log(dmesg)
             sta.get_logs(local_log_dir)
             sta.execute(["ifconfig", sta.ifname, "down"])
         if ap:
             monitor.remove(ap)
             dmesg = setup_params['log_dir'] + setup_params['tc_name'] + "_" + ap.name + "_" + ap.ifname + ".dmesg"
             ap.execute(["dmesg", "-c", ">", dmesg])
-            ap.logs.append(dmesg)
+            ap.add_log(dmesg)
             ap.get_logs(local_log_dir)
             ap.execute(["ifconfig", ap.ifname, " down"])
         raise
-- 
1.9.1



From jonathan at wizery.com  Thu May 19 06:06:46 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Thu, 19 May 2016 16:06:46 +0300
Subject: [PATCH 5/9] tests: Fix style and typos in remote tests code
In-Reply-To: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
Message-ID: <1463663210-15610-5-git-send-email-jonathan@wizery.com>

Signed-off-by: Jonathan Afek <jonathanx.afek at intel.com>
---
 tests/remote/hwsim_wrapper.py | 3 ++-
 tests/remote/monitor.py       | 2 +-
 tests/remote/test_devices.py  | 4 ++--
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tests/remote/hwsim_wrapper.py b/tests/remote/hwsim_wrapper.py
index 8c21a86..d70fe85 100644
--- a/tests/remote/hwsim_wrapper.py
+++ b/tests/remote/hwsim_wrapper.py
@@ -48,7 +48,8 @@ def run_hwsim_test(devices, setup_params, refs, duts, monitors, hwsim_test):
         # run hostapd/wpa_supplicant
         for ref_host in ref_hosts:
             rutils.run_wpasupplicant(ref_host, setup_params)
-            wpas = WpaSupplicant(hostname = ref_host.host, global_iface="udp", global_port = ref_host.port)
+            wpas = WpaSupplicant(hostname=ref_host.host, global_iface="udp",
+                                 global_port=ref_host.port)
             wpas.interface_add(ref_host.ifname)
             dev.append(wpas)
         for dut_host in dut_hosts:
diff --git a/tests/remote/monitor.py b/tests/remote/monitor.py
index a88eecc..e002c8d 100644
--- a/tests/remote/monitor.py
+++ b/tests/remote/monitor.py
@@ -15,7 +15,7 @@ import hostapd
 
 # standalone monitor with multi iface support
 def create(devices, setup_params, refs, duts, monitors):
-    mons= []
+    mons = []
     mhosts = []
     hosts = duts + refs
 
diff --git a/tests/remote/test_devices.py b/tests/remote/test_devices.py
index 4c89c13..97484f5 100644
--- a/tests/remote/test_devices.py
+++ b/tests/remote/test_devices.py
@@ -121,11 +121,11 @@ def check_device(devices, setup_params, dev_name, monitor=False):
 
     status, buf = host.execute(["which", setup_params['iperf']])
     if status != 0:
-        raise Exception(dev_name + " - hostapd: " + buf)
+        raise Exception(dev_name + " - iperf: " + buf)
 
     status, buf = host.execute(["which", "tshark"])
     if status != 0:
-        logger.debug(dev_name + " - hostapd: " + buf)
+        logger.debug(dev_name + " - tshark: " + buf)
 
 def check_devices(devices, setup_params, refs, duts, monitors):
     """Check duts/refs/monitors devices"""
-- 
1.9.1



From jonathan at wizery.com  Thu May 19 06:06:48 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Thu, 19 May 2016 16:06:48 +0300
Subject: [PATCH 7/9] tests: Fix usage of a non existing variable
In-Reply-To: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
Message-ID: <1463663210-15610-7-git-send-email-jonathan@wizery.com>

In monitor.py in the remote tests code there is fucntion create()
that creates standalone monitor interfaces. In this function
there is an iteration of the ifaces of the host by using the ifaces
variable but this variable is non-existing.
This patch creates this variable before its usage.

Signed-off-by: Jonathan Afek <jonathanx.afek at intel.com>
---
 tests/remote/monitor.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/remote/monitor.py b/tests/remote/monitor.py
index e002c8d..fefc97f 100644
--- a/tests/remote/monitor.py
+++ b/tests/remote/monitor.py
@@ -37,6 +37,7 @@ def create(devices, setup_params, refs, duts, monitors):
         try:
             host.execute(["iw", "reg", "set", setup_params['country']])
             setup_hw = setup_params['setup_hw']
+            ifaces = re.split('; | |, ', host.ifname)
             for iface in ifaces:
                 host.execute(setup_hw + " -I " + iface + " -R 1")
         except:
-- 
1.9.1



From jonathan at wizery.com  Thu May 19 06:06:47 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Thu, 19 May 2016 16:06:47 +0300
Subject: [PATCH 6/9] tests: Fix potentially referencing non existing attribute
In-Reply-To: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
Message-ID: <1463663210-15610-6-git-send-email-jonathan@wizery.com>

In wpaspy.py in the Ctrl object constructor there is a try/except.
In the except part the code references the s attribute of the
object. This attribute is only created later in the try part.
If an exception occurs before the attribute creation then
the except part references a non existing attribute.
Fix that by assigning None to the s attribute at the beginning
of the try part.

Signed-off-by: Jonathan Afek <jonathanx.afek at intel.com>
---
 wpaspy/wpaspy.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/wpaspy/wpaspy.py b/wpaspy/wpaspy.py
index 809b4ce..c2aace0 100644
--- a/wpaspy/wpaspy.py
+++ b/wpaspy/wpaspy.py
@@ -44,6 +44,7 @@ class Ctrl:
                 raise
         else:
             try:
+                self.s = None
                 ai_list = socket.getaddrinfo(path, port, socket.AF_INET,
                                              socket.SOCK_DGRAM)
                 for af, socktype, proto, cn, sockaddr in ai_list:
-- 
1.9.1



From jonathan at wizery.com  Thu May 19 06:06:50 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Thu, 19 May 2016 16:06:50 +0300
Subject: [PATCH 9/9] tests: Fix execution of setup_hw for remote tests
In-Reply-To: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
Message-ID: <1463663210-15610-9-git-send-email-jonathan@wizery.com>

The code contained some places that used an additional
argument for setup_hw after -R and also contained places
where setup_hw cmdline was passed as a string isntead of an
argument list. It also contained places where the ifname was only
treated as a single interface and disregarded the possiblity of
multiple interfaces.
This patch fixes these issues and executes setup_hw from a signle
function for all cases.

Signed-off-by: Jonathan Afek <jonathanx.afek at intel.com>
---
 tests/remote/monitor.py      |  6 ++----
 tests/remote/rutils.py       | 24 +++++++++++++++++-------
 tests/remote/test_devices.py | 41 +++++++++++++----------------------------
 3 files changed, 32 insertions(+), 39 deletions(-)

diff --git a/tests/remote/monitor.py b/tests/remote/monitor.py
index fefc97f..bfb6599 100644
--- a/tests/remote/monitor.py
+++ b/tests/remote/monitor.py
@@ -7,6 +7,7 @@
 import time
 from remotehost import Host
 import config
+import rutils
 import re
 import traceback
 import logging
@@ -36,10 +37,7 @@ def create(devices, setup_params, refs, duts, monitors):
 
         try:
             host.execute(["iw", "reg", "set", setup_params['country']])
-            setup_hw = setup_params['setup_hw']
-            ifaces = re.split('; | |, ', host.ifname)
-            for iface in ifaces:
-                host.execute(setup_hw + " -I " + iface + " -R 1")
+            rutils.setup_hw_host(host, setup_params, True)
         except:
             pass
         mhosts.append(host)
diff --git a/tests/remote/rutils.py b/tests/remote/rutils.py
index fd6127b..7836be7 100644
--- a/tests/remote/rutils.py
+++ b/tests/remote/rutils.py
@@ -4,6 +4,7 @@
 # This software may be distributed under the terms of the BSD license.
 # See README for more details.
 
+import re
 import time
 from remotehost import Host
 import hostapd
@@ -26,23 +27,32 @@ def get_host(devices, dev_name):
     return host
 
 # run setup_hw - hw specyfic
-def setup_hw(hosts, setup_params):
-    for host in hosts:
-        setup_hw_host(host, setup_params)
-
-def setup_hw_host(host, setup_params):
+def setup_hw_host_iface(host, iface, setup_params, force_restart=False):
     try:
         setup_hw = setup_params['setup_hw']
         restart = ""
         try:
             if setup_params['restart_device'] == True:
-                restart = " -R "
+                restart = "-R"
         except:
             pass
-        host.execute([setup_hw, "-I", host.ifname, restart])
+
+        if force_restart:
+            restart = "-R"
+
+        host.execute([setup_hw, "-I", iface, restart])
     except:
         pass
 
+def setup_hw_host(host, setup_params, force_restart=False):
+    ifaces = re.split('; | |, ', host.ifname)
+    for iface in ifaces:
+        setup_hw_host_iface(host, iface, setup_params, force_restart)
+
+def setup_hw(hosts, setup_params, force_restart=False):
+    for host in hosts:
+        setup_hw_host(host, setup_params, force_restart)
+
 # get traces - hw specific
 def trace_start(hosts, setup_params):
     for host in hosts:
diff --git a/tests/remote/test_devices.py b/tests/remote/test_devices.py
index 97484f5..6d84d11 100644
--- a/tests/remote/test_devices.py
+++ b/tests/remote/test_devices.py
@@ -35,26 +35,21 @@ def show_devices(devices, setup_params):
         else:
             print "[" + host.name + "] - ssh communication: OK"
         # check setup_hw works correctly
-        try:
-            setup_hw = setup_params['setup_hw']
-            try:
-                restart_device = setup_params['restart_device']
-            except:
-                restart_device = "0"
-            host.execute([setup_hw, "-I", host.ifname, "-R", restart_device])
-        except:
-            pass
+        rutils.setup_hw_host(host, setup_params)
+
         # show uname
         status, buf = host.execute(["uname", "-s", "-n", "-r", "-m", "-o"])
         print "\t" + buf
         # show ifconfig
-        status, buf = host.execute(["ifconfig", host.ifname])
-        if status != 0:
-            print "\t" + host.ifname + " failed\n"
-            continue
-        lines = buf.splitlines()
-        for line in lines:
-            print "\t" + line
+        ifaces = re.split('; | |, ', host.ifname)
+        for iface in ifaces:
+            status, buf = host.execute(["ifconfig", iface])
+            if status != 0:
+                print "\t" + iface + " failed\n"
+                continue
+            lines = buf.splitlines()
+            for line in lines:
+                print "\t" + line
         # check hostapd, wpa_supplicant, iperf exist
         status, buf = host.execute([setup_params['wpa_supplicant'], "-v"])
         if status != 0:
@@ -88,19 +83,9 @@ def check_device(devices, setup_params, dev_name, monitor=False):
     if status != 0:
         raise Exception(dev_name + " - ssh communication FAILED: " + buf)
 
-    ifaces = re.split('; | |, ', host.ifname)
-    # try to setup host/ifaces
-    for iface in ifaces:
-        try:
-            setup_hw = setup_params['setup_hw']
-            try:
-                restart_device = setup_params['restart_device']
-            except:
-                restart_device = "0"
-            host.execute(setup_hw + " -I " + iface + " -R " + restart_device)
-        except:
-            pass
+    rutils.setup_hw_host(host, setup_params)
 
+    ifaces = re.split('; | |, ', host.ifname)
     # check interfaces (multi for monitor)
     for iface in ifaces:
         status, buf = host.execute(["ifconfig", iface])
-- 
1.9.1



From jonathan at wizery.com  Thu May 19 06:06:49 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Thu, 19 May 2016 16:06:49 +0300
Subject: [PATCH 8/9] tests: Add support for wlantest for remote hwsim tests
In-Reply-To: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
Message-ID: <1463663210-15610-8-git-send-email-jonathan@wizery.com>

Use a monitor interface given in the commandline that is
not also a station or a softap as a monitor running wlantest
on the channel used by the test.
This makes all the tests that use wlantest available for execution
on real hardware on remote hosts.

Signed-off-by: Jonathan Afek <jonathanx.afek at intel.com>
---
 tests/hwsim/run-tests.py       |   3 +
 tests/hwsim/test_ap_ciphers.py |  10 +--
 tests/hwsim/test_ap_hs20.py    |   3 +-
 tests/hwsim/test_ap_pmf.py     |  70 ++++++++++++---------
 tests/hwsim/test_ap_qosmap.py  |   1 +
 tests/hwsim/test_ap_tdls.py    |  49 +++++++--------
 tests/hwsim/test_p2p_autogo.py |   3 +-
 tests/hwsim/test_peerkey.py    |  10 +--
 tests/hwsim/test_wnm.py        |   8 ++-
 tests/hwsim/wlantest.py        | 135 +++++++++++++++++++++++++++++++++--------
 tests/remote/config.py         |   2 +
 tests/remote/hwsim_wrapper.py  |  14 +++++
 12 files changed, 217 insertions(+), 91 deletions(-)

diff --git a/tests/hwsim/run-tests.py b/tests/hwsim/run-tests.py
index fd81b02..0a5489f 100755
--- a/tests/hwsim/run-tests.py
+++ b/tests/hwsim/run-tests.py
@@ -503,6 +503,9 @@ def main():
                 del hapd
                 hapd = None
 
+            #use None here since this instance of Wlantest() will never be
+            #used for remote host hwsim tests on real hw.
+            Wlantest.setup(None)
             wt = Wlantest()
             rename_log(args.logdir, 'hwsim0.pcapng', name, wt)
             rename_log(args.logdir, 'hwsim0', name, wt)
diff --git a/tests/hwsim/test_ap_ciphers.py b/tests/hwsim/test_ap_ciphers.py
index 6cde14a..bff8906 100644
--- a/tests/hwsim/test_ap_ciphers.py
+++ b/tests/hwsim/test_ap_ciphers.py
@@ -28,10 +28,6 @@ def check_cipher(dev, ap, cipher):
     hwsim_utils.test_connectivity(dev, hapd)
 
 def check_group_mgmt_cipher(dev, ap, cipher):
-    wt = Wlantest()
-    wt.flush()
-    wt.add_passphrase("12345678")
-
     if cipher not in dev.get_capability("group_mgmt"):
         raise HwsimSkip("Cipher %s not supported" % cipher)
     params = { "ssid": "test-wpa2-psk-pmf",
@@ -42,6 +38,12 @@ def check_group_mgmt_cipher(dev, ap, cipher):
                "rsn_pairwise": "CCMP",
                "group_mgmt_cipher": cipher }
     hapd = hostapd.add_ap(ap, params)
+
+    Wlantest.setup(hapd)
+    wt = Wlantest()
+    wt.flush()
+    wt.add_passphrase("12345678")
+
     dev.connect("test-wpa2-psk-pmf", psk="12345678", ieee80211w="2",
                 key_mgmt="WPA-PSK-SHA256",
                 pairwise="CCMP", group="CCMP", scan_freq="2412")
diff --git a/tests/hwsim/test_ap_hs20.py b/tests/hwsim/test_ap_hs20.py
index a3b61b2..3a93544 100644
--- a/tests/hwsim/test_ap_hs20.py
+++ b/tests/hwsim/test_ap_hs20.py
@@ -298,7 +298,7 @@ def _test_ap_interworking_scan_filtering(dev, apdev):
     ssid = "test-hs20-ap1"
     params['ssid'] = ssid
     params['hessid'] = bssid
-    hostapd.add_ap(apdev[0], params)
+    hapd0 = hostapd.add_ap(apdev[0], params)
 
     bssid2 = apdev[1]['bssid']
     params = hs20_ap_params()
@@ -312,6 +312,7 @@ def _test_ap_interworking_scan_filtering(dev, apdev):
 
     dev[0].hs20_enable()
 
+    Wlantest.setup(hapd0)
     wt = Wlantest()
     wt.flush()
 
diff --git a/tests/hwsim/test_ap_pmf.py b/tests/hwsim/test_ap_pmf.py
index f7c5f29..c9d7403 100644
--- a/tests/hwsim/test_ap_pmf.py
+++ b/tests/hwsim/test_ap_pmf.py
@@ -17,13 +17,14 @@ from wpasupplicant import WpaSupplicant
 def test_ap_pmf_required(dev, apdev):
     """WPA2-PSK AP with PMF required"""
     ssid = "test-pmf-required"
-    wt = Wlantest()
-    wt.flush()
-    wt.add_passphrase("12345678")
     params = hostapd.wpa2_params(ssid=ssid, passphrase="12345678")
     params["wpa_key_mgmt"] = "WPA-PSK-SHA256";
     params["ieee80211w"] = "2";
     hapd = hostapd.add_ap(apdev[0], params)
+    Wlantest.setup(hapd)
+    wt = Wlantest()
+    wt.flush()
+    wt.add_passphrase("12345678")
     key_mgmt = hapd.get_config()['key_mgmt']
     if key_mgmt.split(' ')[0] != "WPA-PSK-SHA256":
         raise Exception("Unexpected GET_CONFIG(key_mgmt): " + key_mgmt)
@@ -53,13 +54,14 @@ def test_ap_pmf_required(dev, apdev):
 def test_ap_pmf_optional(dev, apdev):
     """WPA2-PSK AP with PMF optional"""
     ssid = "test-pmf-optional"
-    wt = Wlantest()
-    wt.flush()
-    wt.add_passphrase("12345678")
     params = hostapd.wpa2_params(ssid=ssid, passphrase="12345678")
     params["wpa_key_mgmt"] = "WPA-PSK";
     params["ieee80211w"] = "1";
     hapd = hostapd.add_ap(apdev[0], params)
+    Wlantest.setup(hapd)
+    wt = Wlantest()
+    wt.flush()
+    wt.add_passphrase("12345678")
     dev[0].connect(ssid, psk="12345678", ieee80211w="1",
                    key_mgmt="WPA-PSK WPA-PSK-SHA256", proto="WPA2",
                    scan_freq="2412")
@@ -75,13 +77,14 @@ def test_ap_pmf_optional(dev, apdev):
 def test_ap_pmf_optional_2akm(dev, apdev):
     """WPA2-PSK AP with PMF optional (2 AKMs)"""
     ssid = "test-pmf-optional-2akm"
-    wt = Wlantest()
-    wt.flush()
-    wt.add_passphrase("12345678")
     params = hostapd.wpa2_params(ssid=ssid, passphrase="12345678")
     params["wpa_key_mgmt"] = "WPA-PSK WPA-PSK-SHA256";
     params["ieee80211w"] = "1";
     hapd = hostapd.add_ap(apdev[0], params)
+    Wlantest.setup(hapd)
+    wt = Wlantest()
+    wt.flush()
+    wt.add_passphrase("12345678")
     dev[0].connect(ssid, psk="12345678", ieee80211w="1",
                    key_mgmt="WPA-PSK WPA-PSK-SHA256", proto="WPA2",
                    scan_freq="2412")
@@ -101,11 +104,12 @@ def test_ap_pmf_optional_2akm(dev, apdev):
 def test_ap_pmf_negative(dev, apdev):
     """WPA2-PSK AP without PMF (negative test)"""
     ssid = "test-pmf-negative"
+    params = hostapd.wpa2_params(ssid=ssid, passphrase="12345678")
+    hapd = hostapd.add_ap(apdev[0], params)
+    Wlantest.setup(hapd)
     wt = Wlantest()
     wt.flush()
     wt.add_passphrase("12345678")
-    params = hostapd.wpa2_params(ssid=ssid, passphrase="12345678")
-    hapd = hostapd.add_ap(apdev[0], params)
     dev[0].connect(ssid, psk="12345678", ieee80211w="1",
                    key_mgmt="WPA-PSK WPA-PSK-SHA256", proto="WPA2",
                    scan_freq="2412")
@@ -123,13 +127,14 @@ def test_ap_pmf_negative(dev, apdev):
 def test_ap_pmf_assoc_comeback(dev, apdev):
     """WPA2-PSK AP with PMF association comeback"""
     ssid = "assoc-comeback"
-    wt = Wlantest()
-    wt.flush()
-    wt.add_passphrase("12345678")
     params = hostapd.wpa2_params(ssid=ssid, passphrase="12345678")
     params["wpa_key_mgmt"] = "WPA-PSK-SHA256";
     params["ieee80211w"] = "2";
     hapd = hostapd.add_ap(apdev[0], params)
+    Wlantest.setup(hapd)
+    wt = Wlantest()
+    wt.flush()
+    wt.add_passphrase("12345678")
     dev[0].connect(ssid, psk="12345678", ieee80211w="1",
                    key_mgmt="WPA-PSK WPA-PSK-SHA256", proto="WPA2",
                    scan_freq="2412")
@@ -146,13 +151,14 @@ def test_ap_pmf_assoc_comeback(dev, apdev):
 def test_ap_pmf_assoc_comeback2(dev, apdev):
     """WPA2-PSK AP with PMF association comeback (using DROP_SA)"""
     ssid = "assoc-comeback"
-    wt = Wlantest()
-    wt.flush()
-    wt.add_passphrase("12345678")
     params = hostapd.wpa2_params(ssid=ssid, passphrase="12345678")
     params["wpa_key_mgmt"] = "WPA-PSK";
     params["ieee80211w"] = "1";
     hapd = hostapd.add_ap(apdev[0], params)
+    Wlantest.setup(hapd)
+    wt = Wlantest()
+    wt.flush()
+    wt.add_passphrase("12345678")
     dev[0].connect(ssid, psk="12345678", ieee80211w="2",
                    key_mgmt="WPA-PSK", proto="WPA2", scan_freq="2412")
     if "OK" not in dev[0].request("DROP_SA"):
@@ -167,9 +173,6 @@ def test_ap_pmf_sta_sa_query(dev, apdev):
     """WPA2-PSK AP with station using SA Query"""
     ssid = "assoc-comeback"
     addr = dev[0].own_addr()
-    wt = Wlantest()
-    wt.flush()
-    wt.add_passphrase("12345678")
 
     wpas = WpaSupplicant(global_iface='/tmp/wpas-wlan5')
     wpas.interface_add("wlan5", drv_params="use_monitor=1")
@@ -187,6 +190,11 @@ def test_ap_pmf_sta_sa_query(dev, apdev):
     bssid = wpas.own_addr()
     wpas.dump_monitor()
 
+    Wlantest.setup(wpas)
+    wt = Wlantest()
+    wt.flush()
+    wt.add_passphrase("12345678")
+
     dev[0].connect(ssid, psk="12345678", ieee80211w="1",
                    key_mgmt="WPA-PSK WPA-PSK-SHA256", proto="WPA2",
                    scan_freq="2412")
@@ -260,9 +268,6 @@ def test_ap_pmf_sta_unprot_deauth_burst(dev, apdev):
     """WPA2-PSK AP with station receiving burst of unprotected Deauthentication frames"""
     ssid = "deauth-attack"
     addr = dev[0].own_addr()
-    wt = Wlantest()
-    wt.flush()
-    wt.add_passphrase("12345678")
 
     wpas = WpaSupplicant(global_iface='/tmp/wpas-wlan5')
     wpas.interface_add("wlan5", drv_params="use_monitor=1")
@@ -279,6 +284,11 @@ def test_ap_pmf_sta_unprot_deauth_burst(dev, apdev):
     wpas.connect_network(id)
     bssid = wpas.own_addr()
 
+    Wlantest.setup(wpas)
+    wt = Wlantest()
+    wt.flush()
+    wt.add_passphrase("12345678")
+
     dev[0].connect(ssid, psk="12345678", ieee80211w="1",
                    key_mgmt="WPA-PSK WPA-PSK-SHA256", proto="WPA2",
                    scan_freq="2412")
@@ -348,13 +358,14 @@ def test_ap_pmf_optional_eap(dev, apdev):
 def test_ap_pmf_required_sha1(dev, apdev):
     """WPA2-PSK AP with PMF required with SHA1 AKM"""
     ssid = "test-pmf-required-sha1"
-    wt = Wlantest()
-    wt.flush()
-    wt.add_passphrase("12345678")
     params = hostapd.wpa2_params(ssid=ssid, passphrase="12345678")
     params["wpa_key_mgmt"] = "WPA-PSK";
     params["ieee80211w"] = "2";
     hapd = hostapd.add_ap(apdev[0], params)
+    Wlantest.setup(hapd)
+    wt = Wlantest()
+    wt.flush()
+    wt.add_passphrase("12345678")
     key_mgmt = hapd.get_config()['key_mgmt']
     if key_mgmt.split(' ')[0] != "WPA-PSK":
         raise Exception("Unexpected GET_CONFIG(key_mgmt): " + key_mgmt)
@@ -373,15 +384,16 @@ def test_ap_pmf_toggle(dev, apdev):
 
 def _test_ap_pmf_toggle(dev, apdev):
     ssid = "test-pmf-optional"
-    wt = Wlantest()
-    wt.flush()
-    wt.add_passphrase("12345678")
     params = hostapd.wpa2_params(ssid=ssid, passphrase="12345678")
     params["wpa_key_mgmt"] = "WPA-PSK";
     params["ieee80211w"] = "1";
     params["assoc_sa_query_max_timeout"] = "1"
     params["assoc_sa_query_retry_timeout"] = "1"
     hapd = hostapd.add_ap(apdev[0], params)
+    Wlantest.setup(hapd)
+    wt = Wlantest()
+    wt.flush()
+    wt.add_passphrase("12345678")
     bssid = apdev[0]['bssid']
     addr = dev[0].own_addr()
     dev[0].request("SET reassoc_same_bss_optim 1")
diff --git a/tests/hwsim/test_ap_qosmap.py b/tests/hwsim/test_ap_qosmap.py
index 0dd0cba..6084521 100644
--- a/tests/hwsim/test_ap_qosmap.py
+++ b/tests/hwsim/test_ap_qosmap.py
@@ -18,6 +18,7 @@ def check_qos_map(ap, hapd, dev, sta, dscp, tid, ap_tid=None):
     if not ap_tid:
         ap_tid = tid
     bssid = ap['bssid']
+    Wlantest.setup(hapd)
     wt = Wlantest()
     wt.clear_sta_counters(bssid, sta)
     hwsim_utils.test_connectivity(dev, hapd, dscp=dscp, config=False)
diff --git a/tests/hwsim/test_ap_tdls.py b/tests/hwsim/test_ap_tdls.py
index 297a928..138f21c 100644
--- a/tests/hwsim/test_ap_tdls.py
+++ b/tests/hwsim/test_ap_tdls.py
@@ -56,7 +56,8 @@ def connect_2sta_open(dev, hapd, scan_freq="2412"):
     dev[1].connect("test-open", key_mgmt="NONE", scan_freq=scan_freq)
     connectivity(dev, hapd)
 
-def wlantest_setup():
+def wlantest_setup(hapd):
+    Wlantest.setup(hapd)
     wt = Wlantest()
     wt.flush()
     wt.add_passphrase("12345678")
@@ -165,7 +166,7 @@ def check_tdls_link(sta0, sta1, connected=True):
 def test_ap_tdls_discovery(dev, apdev):
     """WPA2-PSK AP and two stations using TDLS discovery"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     dev[0].request("TDLS_DISCOVER " + dev[1].p2p_interface_addr())
     time.sleep(0.2)
@@ -173,7 +174,7 @@ def test_ap_tdls_discovery(dev, apdev):
 def test_ap_wpa2_tdls(dev, apdev):
     """WPA2-PSK AP and two stations using TDLS"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     setup_tdls(dev[0], dev[1], hapd)
     teardown_tdls(dev[0], dev[1], hapd)
@@ -183,7 +184,7 @@ def test_ap_wpa2_tdls(dev, apdev):
 def test_ap_wpa2_tdls_concurrent_init(dev, apdev):
     """Concurrent TDLS setup initiation"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     dev[0].request("SET tdls_testing 0x80")
     setup_tdls(dev[1], dev[0], hapd, reverse=True)
@@ -191,7 +192,7 @@ def test_ap_wpa2_tdls_concurrent_init(dev, apdev):
 def test_ap_wpa2_tdls_concurrent_init2(dev, apdev):
     """Concurrent TDLS setup initiation (reverse)"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     dev[1].request("SET tdls_testing 0x80")
     setup_tdls(dev[0], dev[1], hapd)
@@ -199,7 +200,7 @@ def test_ap_wpa2_tdls_concurrent_init2(dev, apdev):
 def test_ap_wpa2_tdls_decline_resp(dev, apdev):
     """Decline TDLS Setup Response"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     dev[1].request("SET tdls_testing 0x200")
     setup_tdls(dev[1], dev[0], hapd, expect_fail=True)
@@ -207,7 +208,7 @@ def test_ap_wpa2_tdls_decline_resp(dev, apdev):
 def test_ap_wpa2_tdls_long_lifetime(dev, apdev):
     """TDLS with long TPK lifetime"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     dev[1].request("SET tdls_testing 0x40")
     setup_tdls(dev[1], dev[0], hapd)
@@ -215,7 +216,7 @@ def test_ap_wpa2_tdls_long_lifetime(dev, apdev):
 def test_ap_wpa2_tdls_long_frame(dev, apdev):
     """TDLS with long setup/teardown frames"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     dev[0].request("SET tdls_testing 0x1")
     dev[1].request("SET tdls_testing 0x1")
@@ -226,7 +227,7 @@ def test_ap_wpa2_tdls_long_frame(dev, apdev):
 def test_ap_wpa2_tdls_reneg(dev, apdev):
     """Renegotiate TDLS link"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     setup_tdls(dev[1], dev[0], hapd)
     setup_tdls(dev[0], dev[1], hapd)
@@ -234,7 +235,7 @@ def test_ap_wpa2_tdls_reneg(dev, apdev):
 def test_ap_wpa2_tdls_wrong_lifetime_resp(dev, apdev):
     """Incorrect TPK lifetime in TDLS Setup Response"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     dev[1].request("SET tdls_testing 0x10")
     setup_tdls(dev[0], dev[1], hapd, expect_fail=True)
@@ -242,7 +243,7 @@ def test_ap_wpa2_tdls_wrong_lifetime_resp(dev, apdev):
 def test_ap_wpa2_tdls_diff_rsnie(dev, apdev):
     """TDLS with different RSN IEs"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     dev[1].request("SET tdls_testing 0x2")
     setup_tdls(dev[1], dev[0], hapd)
@@ -251,7 +252,7 @@ def test_ap_wpa2_tdls_diff_rsnie(dev, apdev):
 def test_ap_wpa2_tdls_wrong_tpk_m2_mic(dev, apdev):
     """Incorrect MIC in TDLS Setup Response"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     dev[0].request("SET tdls_testing 0x800")
     addr0 = dev[0].p2p_interface_addr()
@@ -261,7 +262,7 @@ def test_ap_wpa2_tdls_wrong_tpk_m2_mic(dev, apdev):
 def test_ap_wpa2_tdls_wrong_tpk_m3_mic(dev, apdev):
     """Incorrect MIC in TDLS Setup Confirm"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     dev[1].request("SET tdls_testing 0x800")
     addr0 = dev[0].p2p_interface_addr()
@@ -274,7 +275,7 @@ def test_ap_wpa_tdls(dev, apdev):
     hapd = hostapd.add_ap(apdev[0],
                           hostapd.wpa_params(ssid="test-wpa-psk",
                                              passphrase="12345678"))
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa_psk(dev, hapd)
     setup_tdls(dev[0], dev[1], hapd)
     teardown_tdls(dev[0], dev[1], hapd)
@@ -286,7 +287,7 @@ def test_ap_wpa_mixed_tdls(dev, apdev):
     hapd = hostapd.add_ap(apdev[0],
                           hostapd.wpa_mixed_params(ssid="test-wpa-mixed-psk",
                                                    passphrase="12345678"))
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa_psk_mixed(dev, hapd)
     setup_tdls(dev[0], dev[1], hapd)
     teardown_tdls(dev[0], dev[1], hapd)
@@ -296,7 +297,7 @@ def test_ap_wep_tdls(dev, apdev):
     """WEP AP and two stations using TDLS"""
     hapd = hostapd.add_ap(apdev[0],
                           { "ssid": "test-wep", "wep_key0": '"hello"' })
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wep(dev, hapd)
     setup_tdls(dev[0], dev[1], hapd)
     teardown_tdls(dev[0], dev[1], hapd)
@@ -305,7 +306,7 @@ def test_ap_wep_tdls(dev, apdev):
 def test_ap_open_tdls(dev, apdev):
     """Open AP and two stations using TDLS"""
     hapd = hostapd.add_ap(apdev[0], { "ssid": "test-open" })
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_open(dev, hapd)
     setup_tdls(dev[0], dev[1], hapd)
     teardown_tdls(dev[0], dev[1], hapd)
@@ -321,7 +322,7 @@ def test_ap_wpa2_tdls_bssid_mismatch(dev, apdev):
         params['bridge'] = 'ap-br0'
         hapd = hostapd.add_ap(apdev[0], params)
         hostapd.add_ap(apdev[1], params)
-        wlantest_setup()
+        wlantest_setup(hapd)
         subprocess.call(['brctl', 'setfd', 'ap-br0', '0'])
         subprocess.call(['ip', 'link', 'set', 'dev', 'ap-br0', 'up'])
         dev[0].connect(ssid, psk=passphrase, scan_freq="2412",
@@ -343,7 +344,7 @@ def test_ap_wpa2_tdls_bssid_mismatch(dev, apdev):
 def test_ap_wpa2_tdls_responder_teardown(dev, apdev):
     """TDLS teardown from responder with WPA2-PSK AP"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     setup_tdls(dev[0], dev[1], hapd)
     teardown_tdls(dev[0], dev[1], hapd, responder=True)
@@ -362,7 +363,7 @@ def test_ap_open_tdls_vht(dev, apdev):
                "vht_oper_centr_freq_seg0_idx": "0" }
     try:
         hapd = hostapd.add_ap(apdev[0], params)
-        wlantest_setup()
+        wlantest_setup(hapd)
         connect_2sta_open(dev, hapd, scan_freq="5180")
         setup_tdls(dev[0], dev[1], hapd)
         teardown_tdls(dev[0], dev[1], hapd)
@@ -392,7 +393,7 @@ def test_ap_open_tdls_vht80(dev, apdev):
     try:
         hapd = None
         hapd = hostapd.add_ap(apdev[0], params)
-        wlantest_setup()
+        wlantest_setup(hapd)
         connect_2sta_open(dev, hapd, scan_freq="5180")
         sig = dev[0].request("SIGNAL_POLL").splitlines()
         if "WIDTH=80 MHz" not in sig:
@@ -436,7 +437,7 @@ def test_ap_open_tdls_vht80plus80(dev, apdev):
     try:
         hapd = None
         hapd = hostapd.add_ap(apdev[0], params)
-        wlantest_setup()
+        wlantest_setup(hapd)
         connect_2sta_open(dev, hapd, scan_freq="5180")
         sig = dev[0].request("SIGNAL_POLL").splitlines()
         if "FREQUENCY=5180" not in sig:
@@ -492,7 +493,7 @@ def test_ap_open_tdls_vht160(dev, apdev):
                 if "5490" in r and "DFS" in r:
                     raise HwsimSkip("ZA regulatory rule did not have DFS requirement removed")
             raise Exception("AP setup timed out")
-        wlantest_setup()
+        wlantest_setup(hapd)
         connect_2sta_open(dev, hapd, scan_freq="5520")
         sig = dev[0].request("SIGNAL_POLL").splitlines()
         if "WIDTH=160 MHz" not in sig:
@@ -539,7 +540,7 @@ def test_tdls_chan_switch(dev, apdev):
 def test_ap_tdls_link_status(dev, apdev):
     """Check TDLS link status between two stations"""
     hapd = start_ap_wpa2_psk(apdev[0])
-    wlantest_setup()
+    wlantest_setup(hapd)
     connect_2sta_wpa2_psk(dev, hapd)
     check_tdls_link(dev[0], dev[1], connected=False)
     setup_tdls(dev[0], dev[1], hapd)
diff --git a/tests/hwsim/test_p2p_autogo.py b/tests/hwsim/test_p2p_autogo.py
index 3875343..55c4c0f 100644
--- a/tests/hwsim/test_p2p_autogo.py
+++ b/tests/hwsim/test_p2p_autogo.py
@@ -231,7 +231,6 @@ def test_autogo_pbc(dev):
 
 def test_autogo_tdls(dev):
     """P2P autonomous GO and two clients using TDLS"""
-    wt = Wlantest()
     go = dev[0]
     logger.info("Start autonomous GO with fixed parameters " + go.ifname)
     id = go.add_network()
@@ -241,6 +240,8 @@ def test_autogo_tdls(dev):
     go.set_network(id, "disabled", "2")
     res = go.p2p_start_go(persistent=id, freq="2462")
     logger.debug("res: " + str(res))
+    Wlantest.setup(go, True)
+    wt = Wlantest()
     wt.flush()
     wt.add_passphrase("12345678")
     connect_cli(go, dev[1], social=True, freq=2462)
diff --git a/tests/hwsim/test_peerkey.py b/tests/hwsim/test_peerkey.py
index b1e7b1f..30d9b60 100644
--- a/tests/hwsim/test_peerkey.py
+++ b/tests/hwsim/test_peerkey.py
@@ -50,15 +50,17 @@ def test_peerkey_unknown_peer(dev, apdev):
 def test_peerkey_pairwise_mismatch(dev, apdev):
     """RSN TKIP+CCMP AP and PeerKey between two STAs using different ciphers"""
     skip_with_fips(dev[0])
-    wt = Wlantest()
-    wt.flush()
-    wt.add_passphrase("12345678")
     ssid = "test-peerkey"
     passphrase = "12345678"
     params = hostapd.wpa2_params(ssid=ssid, passphrase=passphrase)
     params['peerkey'] = "1"
     params['rsn_pairwise'] = "TKIP CCMP"
-    hostapd.add_ap(apdev[0], params)
+    hapd = hostapd.add_ap(apdev[0], params)
+
+    Wlantest.setup(hapd)
+    wt = Wlantest()
+    wt.flush()
+    wt.add_passphrase("12345678")
 
     dev[0].connect(ssid, psk=passphrase, scan_freq="2412", peerkey=True,
                    pairwise="CCMP")
diff --git a/tests/hwsim/test_wnm.py b/tests/hwsim/test_wnm.py
index 8048113..3788ed2 100644
--- a/tests/hwsim/test_wnm.py
+++ b/tests/hwsim/test_wnm.py
@@ -185,9 +185,6 @@ def test_wnm_sleep_mode_ap_oom(dev, apdev):
 
 def test_wnm_sleep_mode_rsn_pmf(dev, apdev):
     """WNM Sleep Mode - RSN with PMF"""
-    wt = Wlantest()
-    wt.flush()
-    wt.add_passphrase("12345678")
     params = hostapd.wpa2_params("test-wnm-rsn", "12345678")
     params["wpa_key_mgmt"] = "WPA-PSK-SHA256";
     params["ieee80211w"] = "2";
@@ -197,6 +194,11 @@ def test_wnm_sleep_mode_rsn_pmf(dev, apdev):
     params["bss_transition"] = "1"
     hapd = hostapd.add_ap(apdev[0], params)
 
+    Wlantest.setup(hapd)
+    wt = Wlantest()
+    wt.flush()
+    wt.add_passphrase("12345678")
+
     dev[0].connect("test-wnm-rsn", psk="12345678", ieee80211w="2",
                    key_mgmt="WPA-PSK-SHA256", proto="WPA2", scan_freq="2412")
     ev = hapd.wait_event([ "AP-STA-CONNECTED" ], timeout=5)
diff --git a/tests/hwsim/wlantest.py b/tests/hwsim/wlantest.py
index 5f6b4ac..ea450af 100644
--- a/tests/hwsim/wlantest.py
+++ b/tests/hwsim/wlantest.py
@@ -4,7 +4,9 @@
 # This software may be distributed under the terms of the BSD license.
 # See README for more details.
 
+import re
 import os
+import posixpath
 import time
 import subprocess
 import logging
@@ -13,44 +15,135 @@ import wpaspy
 logger = logging.getLogger()
 
 class Wlantest:
+
+    remote_host = None
+    setup_params = None
+    exe_thread = None
+    exe_res = []
+    monitor_mod = None
+    setup_done = False
+
+    @classmethod
+    def stop_remote_wlantest(cls):
+        if cls.exe_thread is None:
+            #non remote flow
+            return
+
+        cls.remote_host.execute(["killall", "-9", "wlantest"])
+        cls.remote_host.wait_execute_complete(cls.exe_thread, 5)
+        cls.exe_thread = None
+        cls.exe_res = []
+
+    @classmethod
+    def reset_remote_wlantest(cls):
+        cls.stop_remote_wlantest()
+        cls.remote_host = None
+        cls.setup_params = None
+        cls.exe_thread = None
+        cls.exe_res = []
+        cls.monitor_mod = None
+        cls.setup_done = False
+
+    @classmethod
+    def start_remote_wlantest(cls):
+        if cls.remote_host is None:
+            #non remote flow
+            return
+        if cls.exe_thread is not None:
+            raise Exception("can't start wlantest twice")
+
+        log_dir = cls.setup_params['log_dir']
+        ifaces = re.split('; | |, ', cls.remote_host.ifname)
+        ifname = ifaces[0]
+        exe = cls.setup_params["wlantest"]
+        tc_name = cls.setup_params["tc_name"]
+        base_log_name = tc_name + "_wlantest_" + \
+                        cls.remote_host.name + "_" + ifname
+        log_file = posixpath.join(log_dir, base_log_name + ".log")
+        pcap_file = posixpath.join(log_dir, base_log_name + ".pcapng")
+        cmd = "{} -i {} -n {} -c -dtN -L {}".format(exe, ifname,
+                                                    pcap_file, log_file)
+        cls.remote_host.add_log(log_file)
+        cls.remote_host.add_log(pcap_file)
+        cls.exe_thread = cls.remote_host.execute_run(cmd.split(), cls.exe_res)
+        #give wlantest a chance to start working
+        time.sleep(1)
+
+
+    @classmethod
+    def register_remote_wlantest(cls, host, setup_params, monitor_mod):
+        if cls.remote_host is not None:
+            raise Exception("can't register remote wlantest twice")
+        cls.remote_host = host
+        cls.setup_params = setup_params
+        cls.monitor_mod = monitor_mod
+        status, buf = host.execute(["which", setup_params['wlantest']])
+        if status != 0:
+            raise Exception(host.name + " - wlantest: " + buf)
+        status, buf = host.execute(["which", setup_params['wlantest_cli']])
+        if status != 0:
+            raise Exception(host.name + " - wlantest_cli: " + buf)
+
+    @classmethod
+    def chan_from_wpa(cls, wpa, is_p2p=False):
+        if cls.monitor_mod is None:
+            return
+        m = cls.monitor_mod
+        return m.setup(cls.remote_host, [m.get_monitor_params(wpa, is_p2p)])
+
+    @classmethod
+    def setup(cls, wpa, is_p2p=False):
+        cls.chan_from_wpa(wpa, is_p2p)
+        cls.start_remote_wlantest()
+        cls.setup_done = True
+
     def __init__(self):
+        if not self.setup_done:
+            raise Exception("can't create Wlantest inst before setup()")
         if os.path.isfile('../../wlantest/wlantest_cli'):
             self.wlantest_cli = '../../wlantest/wlantest_cli'
         else:
             self.wlantest_cli = 'wlantest_cli'
 
+    def cli_cmd(self, params):
+        if self.remote_host is not None:
+            exe = self.setup_params["wlantest_cli"]
+            ret = self.remote_host.execute([exe] + params)
+            if 0 != ret[0]:
+                raise Exception("wlantest_cli failed")
+            return ret[1]
+        else:
+            return subprocess.check_output([self.wlantest_cli] + params)
+
     def flush(self):
-        res = subprocess.check_output([self.wlantest_cli, "flush"])
+        res = self.cli_cmd(["flush"])
         if "FAIL" in res:
             raise Exception("wlantest_cli flush failed")
 
     def relog(self):
-        res = subprocess.check_output([self.wlantest_cli, "relog"])
+        res = self.cli_cmd(["relog"])
         if "FAIL" in res:
             raise Exception("wlantest_cli relog failed")
 
     def add_passphrase(self, passphrase):
-        res = subprocess.check_output([self.wlantest_cli, "add_passphrase",
-                                       passphrase])
+        res = self.cli_cmd(["add_passphrase", passphrase])
         if "FAIL" in res:
             raise Exception("wlantest_cli add_passphrase failed")
 
     def add_wepkey(self, key):
-        res = subprocess.check_output([self.wlantest_cli, "add_wepkey", key])
+        res = self.cli_cmd(["add_wepkey", key])
         if "FAIL" in res:
             raise Exception("wlantest_cli add_key failed")
 
     def info_bss(self, field, bssid):
-        res = subprocess.check_output([self.wlantest_cli, "info_bss",
-                                       field, bssid])
+        res = self.cli_cmd(["info_bss", field, bssid])
         if "FAIL" in res:
             raise Exception("Could not get BSS info from wlantest for " + bssid)
         return res
 
     def get_bss_counter(self, field, bssid):
         try:
-            res = subprocess.check_output([self.wlantest_cli, "get_bss_counter",
-                                           field, bssid]);
+            res = self.cli_cmd(["get_bss_counter", field, bssid])
         except Exception, e:
             return 0
         if "FAIL" in res:
@@ -58,36 +151,30 @@ class Wlantest:
         return int(res)
 
     def clear_bss_counters(self, bssid):
-        subprocess.call([self.wlantest_cli, "clear_bss_counters", bssid],
-                        stdout=open('/dev/null', 'w'));
+        self.cli_cmd(["clear_bss_counters", bssid])
 
     def info_sta(self, field, bssid, addr):
-        res = subprocess.check_output([self.wlantest_cli, "info_sta",
-                                       field, bssid, addr])
+        res = self.cli_cmd(["info_sta", field, bssid, addr])
         if "FAIL" in res:
             raise Exception("Could not get STA info from wlantest for " + addr)
         return res
 
     def get_sta_counter(self, field, bssid, addr):
-        res = subprocess.check_output([self.wlantest_cli, "get_sta_counter",
-                                       field, bssid, addr]);
+        res = self.cli_cmd(["get_sta_counter", field, bssid, addr])
         if "FAIL" in res:
             raise Exception("wlantest_cli command failed")
         return int(res)
 
     def clear_sta_counters(self, bssid, addr):
-        res = subprocess.check_output([self.wlantest_cli, "clear_sta_counters",
-                                       bssid, addr]);
+        res = self.cli_cmd(["clear_sta_counters", bssid, addr])
         if "FAIL" in res:
             raise Exception("wlantest_cli command failed")
 
     def tdls_clear(self, bssid, addr1, addr2):
-        res = subprocess.check_output([self.wlantest_cli, "clear_tdls_counters",
-                                       bssid, addr1, addr2]);
+        self.cli_cmd(["clear_tdls_counters", bssid, addr1, addr2])
 
     def get_tdls_counter(self, field, bssid, addr1, addr2):
-        res = subprocess.check_output([self.wlantest_cli, "get_tdls_counter",
-                                       field, bssid, addr1, addr2]);
+        res = self.cli_cmd(["get_tdls_counter", field, bssid, addr1, addr2])
         if "FAIL" in res:
             raise Exception("wlantest_cli command failed")
         return int(res)
@@ -139,15 +226,13 @@ class Wlantest:
             raise Exception("Unexpected STA key_mgmt")
 
     def get_tx_tid(self, bssid, addr, tid):
-        res = subprocess.check_output([self.wlantest_cli, "get_tx_tid",
-                                       bssid, addr, str(tid)]);
+        res = self.cli_cmd(["get_tx_tid", bssid, addr, str(tid)])
         if "FAIL" in res:
             raise Exception("wlantest_cli command failed")
         return int(res)
 
     def get_rx_tid(self, bssid, addr, tid):
-        res = subprocess.check_output([self.wlantest_cli, "get_rx_tid",
-                                       bssid, addr, str(tid)]);
+        res = self.cli_cmd(["get_rx_tid", bssid, addr, str(tid)])
         if "FAIL" in res:
             raise Exception("wlantest_cli command failed")
         return int(res)
diff --git a/tests/remote/config.py b/tests/remote/config.py
index 0826ea0..cf3b77f 100644
--- a/tests/remote/config.py
+++ b/tests/remote/config.py
@@ -20,6 +20,8 @@ setup_params = { "setup_hw" : "./tests/setup_hw.sh",
                  "hostapd" : "./tests/hostapd",
                  "wpa_supplicant" : "./tests/wpa_supplicant",
                  "iperf" : "iperf",
+                 "wlantest" : "./tests/wlantest",
+                 "wlantest_cli" : "./tests/wlantest_cli",
                  "country" : "US",
                  "log_dir" : "/tmp/",
                  "ipv4_test_net" : "192.168.12.0",
diff --git a/tests/remote/hwsim_wrapper.py b/tests/remote/hwsim_wrapper.py
index d70fe85..3b4c0cc 100644
--- a/tests/remote/hwsim_wrapper.py
+++ b/tests/remote/hwsim_wrapper.py
@@ -11,6 +11,7 @@ import config
 import rutils
 import monitor
 import traceback
+import wlantest
 
 import logging
 logger = logging.getLogger()
@@ -45,6 +46,13 @@ def run_hwsim_test(devices, setup_params, refs, duts, monitors, hwsim_test):
             monitor.add(dut_host, monitors)
             monitor.run(dut_host, setup_params)
 
+        monitor_hosts = monitor.create(devices, setup_params, refs, duts, monitors)
+        mon = None
+        if len(monitor_hosts) > 0:
+            mon = monitor_hosts[0]
+            wlantest.Wlantest.reset_remote_wlantest()
+            wlantest.Wlantest.register_remote_wlantest(mon, setup_params, monitor)
+
         # run hostapd/wpa_supplicant
         for ref_host in ref_hosts:
             rutils.run_wpasupplicant(ref_host, setup_params)
@@ -83,6 +91,9 @@ def run_hwsim_test(devices, setup_params, refs, duts, monitors, hwsim_test):
         for dut_host in dut_hosts:
             dut_host.execute(["killall", "hostapd"])
             dut_host.get_logs(local_log_dir)
+        if mon is not None:
+            wlantest.Wlantest.reset_remote_wlantest()
+            mon.get_logs(local_log_dir)
 
         return ""
     except:
@@ -105,4 +116,7 @@ def run_hwsim_test(devices, setup_params, refs, duts, monitors, hwsim_test):
         for dut_host in dut_hosts:
             dut_host.execute(["killall", "hostapd"])
             dut_host.get_logs(local_log_dir)
+        if mon is not None:
+            wlantest.Wlantest.reset_remote_wlantest()
+            mon.get_logs(local_log_dir)
         raise
-- 
1.9.1



From james at nurealm.net  Thu May 19 14:11:16 2016
From: james at nurealm.net (James Feeney)
Date: Thu, 19 May 2016 15:11:16 -0600
Subject: "kernel: BUG: scheduling while atomic:" errors with linux kernel 4.6
Message-ID: <e2d89c7d-7567-c3ac-505e-7a9aa887c158@nurealm.net>

Arch linux 4.6-1
wpa_supplicant 1:2.5-3
Toshiba Satellite, circa 2011, with a Pentium Dual-Core Mobile
Error is not seen on other machines.

kernel: BUG: scheduling while atomic: wpa_supplicant/375/0x00000002
...
kernel: BUG: scheduling while atomic: wpa_supplicant/375/0x00000000
...
kernel: BUG: scheduling while atomic: wpa_supplicant/627/0x00000002
...
kernel: BUG: scheduling while atomic: wpa_supplicant/627/0x00000000
...
systemd-coredump[630]: Process 627 (wpa_supplicant) of user 0 dumped core.

See attached.
-------------- next part --------------
May 19 10:26:07 lapis kernel: BUG: scheduling while atomic: wpa_supplicant/627/0x00000002
May 19 10:26:07 lapis kernel: Modules linked in: nf_log_ipv6 nf_log_ipv4 nf_log_common nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nft_log nft_limit nft_meta nft_ct nf_conntrack nft_hash nft_rbtree nf_tables_inet nf_tables_ipv6 nf_tables_ipv4 nf_tables nfnetlink bonding uvcvideo videobuf2_vmalloc videobuf2_memops arc4 rtl8192ce videobuf2_v4l2 joydev mousedev rtl_pci videobuf2_core rtl8192c_common rtlwifi ums_realtek uas videodev mac80211 usb_storage media cfg80211 iTCO_wdt iTCO_vendor_support toshiba_acpi pcspkr input_leds intel_powerclamp sparse_keymap coretemp atl1c toshiba_bluetooth led_class serio_raw rfkill psmouse i2c_i801 snd_hda_codec_conexant snd_hda_codec_generic wmi snd_hda_intel intel_ips snd_hda_codec snd_hda_core ac snd_hwdep snd_pcm snd_timer snd evdev fjes shpchp mac_hid battery
May 19 10:26:07 lapis kernel:  lpc_ich soundcore mei_me mei acpi_cpufreq tpm_tis tpm processor sch_fq_codel sg ip_tables x_tables ext4 crc16 jbd2 mbcache sr_mod cdrom sd_mod atkbd libps2 ahci libahci libata scsi_mod i8042 serio ehci_pci ehci_hcd usbcore usb_common i915 video button i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_agp intel_gtt
May 19 10:26:07 lapis kernel: CPU: 0 PID: 627 Comm: wpa_supplicant Tainted: G        W       4.6.0-1-ARCH #1
May 19 10:26:07 lapis kernel: Hardware name: TOSHIBA Satellite L655/Base Board Product Name, BIOS 2.80 07/03/2012
May 19 10:26:07 lapis kernel:  0000000000000286 00000000766b165b ffff8800b1ac76a8 ffffffff812e5362
May 19 10:26:07 lapis kernel:  ffff880137c15940 0000000000000001 ffff8800b1ac76b8 ffffffff810a10eb
May 19 10:26:07 lapis kernel:  ffff8800b1ac7708 ffffffff815c2b39 000000000000ec40 0000000000000040
May 19 10:26:07 lapis kernel: Call Trace:
May 19 10:26:07 lapis kernel:  [<ffffffff812e5362>] dump_stack+0x63/0x81
May 19 10:26:07 lapis kernel:  [<ffffffff810a10eb>] __schedule_bug+0x4b/0x60
May 19 10:26:07 lapis kernel:  [<ffffffff815c2b39>] __schedule+0x899/0xad0
May 19 10:26:07 lapis kernel:  [<ffffffff815c2dac>] schedule+0x3c/0x90
May 19 10:26:07 lapis kernel:  [<ffffffff815c5bb2>] schedule_hrtimeout_range_clock+0xa2/0x120
May 19 10:26:07 lapis kernel:  [<ffffffff810e8b80>] ? hrtimer_init+0x120/0x120
May 19 10:26:07 lapis kernel:  [<ffffffff815c5ba6>] ? schedule_hrtimeout_range_clock+0x96/0x120
May 19 10:26:07 lapis kernel:  [<ffffffff815c5c43>] schedule_hrtimeout_range+0x13/0x20
May 19 10:26:07 lapis kernel:  [<ffffffff815c568f>] usleep_range+0x4f/0x70
May 19 10:26:07 lapis kernel:  [<ffffffffa0667218>] rtl_rfreg_delay+0x38/0x50 [rtlwifi]
May 19 10:26:07 lapis kernel:  [<ffffffffa06dd0e7>] rtl92c_phy_config_rf_with_headerfile+0xc7/0xe0 [rtl8192ce]
May 19 10:26:07 lapis kernel:  [<ffffffffa06de61c>] rtl92ce_phy_rf6052_config+0x19c/0x2c0 [rtl8192ce]
May 19 10:26:07 lapis kernel:  [<ffffffffa067ed2e>] rtl92c_phy_rf_config+0x1e/0x20 [rtl8192c_common]
May 19 10:26:07 lapis kernel:  [<ffffffffa06db826>] rtl92ce_hw_init+0x7e6/0x1870 [rtl8192ce]
May 19 10:26:07 lapis kernel:  [<ffffffffa066998e>] rtl_ps_enable_nic+0x2e/0x70 [rtlwifi]
May 19 10:26:07 lapis kernel:  [<ffffffffa06ddadc>] rtl92c_phy_set_rf_power_state+0x3bc/0x470 [rtl8192ce]
May 19 10:26:07 lapis kernel:  [<ffffffffa0669b17>] rtl_ps_set_rf_state+0xe7/0x1b0 [rtlwifi]
May 19 10:26:07 lapis kernel:  [<ffffffffa0669c1d>] _rtl_ps_inactive_ps+0x3d/0xc0 [rtlwifi]
May 19 10:26:07 lapis kernel:  [<ffffffffa0669d20>] rtl_ips_nic_on+0x80/0xb0 [rtlwifi]
May 19 10:26:07 lapis kernel:  [<ffffffffa0666c28>] rtl_op_config+0x1d8/0x3f0 [rtlwifi]
May 19 10:26:07 lapis kernel:  [<ffffffff8120b4a8>] ? do_select+0x778/0x820
May 19 10:26:07 lapis kernel:  [<ffffffffa05c2a33>] ieee80211_hw_config+0x63/0x3a0 [mac80211]
May 19 10:26:07 lapis kernel:  [<ffffffffa05d92a2>] ieee80211_recalc_idle+0x22/0x30 [mac80211]
May 19 10:26:07 lapis kernel:  [<ffffffffa05cd693>] __ieee80211_start_scan+0x203/0x750 [mac80211]
May 19 10:26:07 lapis kernel:  [<ffffffffa05ce7f0>] ieee80211_request_scan+0x30/0x50 [mac80211]
May 19 10:26:07 lapis kernel:  [<ffffffffa05e0a65>] ieee80211_scan+0x65/0xb0 [mac80211]
May 19 10:26:07 lapis kernel:  [<ffffffffa055673f>] nl80211_trigger_scan+0x49f/0x740 [cfg80211]
May 19 10:26:07 lapis kernel:  [<ffffffff814f190f>] genl_family_rcv_msg+0x1df/0x3d0
May 19 10:26:07 lapis kernel:  [<ffffffff8120ab10>] ? poll_select_copy_remaining+0x140/0x140
May 19 10:26:07 lapis kernel:  [<ffffffff814f1b00>] ? genl_family_rcv_msg+0x3d0/0x3d0
May 19 10:26:07 lapis kernel:  [<ffffffff814f1b87>] genl_rcv_msg+0x87/0xc0
May 19 10:26:07 lapis kernel:  [<ffffffff814f0b84>] netlink_rcv_skb+0xa4/0xc0
May 19 10:26:07 lapis kernel:  [<ffffffff814f1718>] genl_rcv+0x28/0x40
May 19 10:26:07 lapis kernel:  [<ffffffff814f0481>] netlink_unicast+0x181/0x230
May 19 10:26:07 lapis kernel:  [<ffffffff814f0948>] netlink_sendmsg+0x348/0x3b0
May 19 10:26:07 lapis kernel:  [<ffffffff8149eaa7>] sock_sendmsg+0x17/0x30
May 19 10:26:07 lapis kernel:  [<ffffffff8149f1c5>] ___sys_sendmsg+0x295/0x2b0
May 19 10:26:07 lapis kernel:  [<ffffffff8149eaa7>] ? sock_sendmsg+0x17/0x30
May 19 10:26:07 lapis kernel:  [<ffffffff8149fea0>] ? SyS_sendto+0x140/0x190
May 19 10:26:07 lapis kernel:  [<ffffffff810eebff>] ? ktime_get_ts64+0x4f/0x100
May 19 10:26:07 lapis kernel:  [<ffffffff814a0324>] __sys_sendmsg+0x54/0x90
May 19 10:26:07 lapis kernel:  [<ffffffff814a0372>] SyS_sendmsg+0x12/0x20
May 19 10:26:07 lapis kernel:  [<ffffffff815c6832>] entry_SYSCALL_64_fastpath+0x1a/0xa4
May 19 10:26:08 lapis kernel: ------------[ cut here ]------------
May 19 10:26:08 lapis kernel: WARNING: CPU: 0 PID: 627 at net/core/skbuff.c:653 skb_release_head_state+0xa0/0xb0
May 19 10:26:08 lapis kernel: Modules linked in: nf_log_ipv6 nf_log_ipv4 nf_log_common nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nft_log nft_limit nft_meta nft_ct nf_conntrack nft_hash nft_rbtree nf_tables_inet nf_tables_ipv6 nf_tables_ipv4 nf_tables nfnetlink bonding uvcvideo videobuf2_vmalloc videobuf2_memops arc4 rtl8192ce videobuf2_v4l2 joydev mousedev rtl_pci videobuf2_core rtl8192c_common rtlwifi ums_realtek uas videodev mac80211 usb_storage media cfg80211 iTCO_wdt iTCO_vendor_support toshiba_acpi pcspkr input_leds intel_powerclamp sparse_keymap coretemp atl1c toshiba_bluetooth led_class serio_raw rfkill psmouse i2c_i801 snd_hda_codec_conexant snd_hda_codec_generic wmi snd_hda_intel intel_ips snd_hda_codec snd_hda_core ac snd_hwdep snd_pcm snd_timer snd evdev fjes shpchp mac_hid battery
May 19 10:26:08 lapis kernel:  lpc_ich soundcore mei_me mei acpi_cpufreq tpm_tis tpm processor sch_fq_codel sg ip_tables x_tables ext4 crc16 jbd2 mbcache sr_mod cdrom sd_mod atkbd libps2 ahci libahci libata scsi_mod i8042 serio ehci_pci ehci_hcd usbcore usb_common i915 video button i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_agp intel_gtt
May 19 10:26:08 lapis kernel: CPU: 0 PID: 627 Comm: wpa_supplicant Tainted: G        W       4.6.0-1-ARCH #1
May 19 10:26:08 lapis kernel: Hardware name: TOSHIBA Satellite L655/Base Board Product Name, BIOS 2.80 07/03/2012
May 19 10:26:08 lapis kernel:  0000000000000286 00000000766b165b ffff8800b1ac7bb8 ffffffff812e5362
May 19 10:26:08 lapis kernel:  0000000000000000 0000000000000000 ffff8800b1ac7bf8 ffffffff8107a68b
May 19 10:26:08 lapis kernel:  0000028d00000014 ffff8800b199ac00 ffff8800b199ac00 ffff8800b199ac00
May 19 10:26:08 lapis kernel: Call Trace:
May 19 10:26:08 lapis kernel:  [<ffffffff812e5362>] dump_stack+0x63/0x81
May 19 10:26:08 lapis kernel:  [<ffffffff8107a68b>] __warn+0xcb/0xf0
May 19 10:26:08 lapis kernel:  [<ffffffff8107a7bd>] warn_slowpath_null+0x1d/0x20
May 19 10:26:08 lapis kernel:  [<ffffffff814a6090>] skb_release_head_state+0xa0/0xb0
May 19 10:26:08 lapis kernel:  [<ffffffff814a9412>] skb_release_all+0x12/0x30
May 19 10:26:08 lapis kernel:  [<ffffffff814a9c6c>] consume_skb+0x2c/0xa0
May 19 10:26:08 lapis kernel:  [<ffffffff814f0489>] netlink_unicast+0x189/0x230
May 19 10:26:08 lapis kernel:  [<ffffffff814f0948>] netlink_sendmsg+0x348/0x3b0
May 19 10:26:08 lapis kernel:  [<ffffffff8149eaa7>] sock_sendmsg+0x17/0x30
May 19 10:26:08 lapis kernel:  [<ffffffff8149f1c5>] ___sys_sendmsg+0x295/0x2b0
May 19 10:26:08 lapis kernel:  [<ffffffff8149eaa7>] ? sock_sendmsg+0x17/0x30
May 19 10:26:08 lapis kernel:  [<ffffffff8149fea0>] ? SyS_sendto+0x140/0x190
May 19 10:26:08 lapis kernel:  [<ffffffff810eebff>] ? ktime_get_ts64+0x4f/0x100
May 19 10:26:08 lapis kernel:  [<ffffffff814a0324>] __sys_sendmsg+0x54/0x90
May 19 10:26:08 lapis kernel:  [<ffffffff814a0372>] SyS_sendmsg+0x12/0x20
May 19 10:26:08 lapis kernel:  [<ffffffff815c6832>] entry_SYSCALL_64_fastpath+0x1a/0xa4
May 19 10:26:08 lapis kernel: ---[ end trace 83fcfcdab9871116 ]---
May 19 10:26:08 lapis kernel: wpa_supplicant[627]: segfault at 20e81a8 ip 00007fc8de7b6b39 sp 00007ffe16711230 error 6
May 19 10:26:08 lapis kernel: BUG: scheduling while atomic: wpa_supplicant/627/0x00000000
May 19 10:26:08 lapis kernel: Modules linked in: nf_log_ipv6 nf_log_ipv4 nf_log_common nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nft_log nft_limit nft_meta nft_ct nf_conntrack nft_hash nft_rbtree nf_tables_inet nf_tables_ipv6 nf_tables_ipv4 nf_tables nfnetlink bonding uvcvideo videobuf2_vmalloc videobuf2_memops arc4 rtl8192ce videobuf2_v4l2 joydev mousedev rtl_pci videobuf2_core rtl8192c_common rtlwifi ums_realtek uas videodev mac80211 usb_storage media cfg80211 iTCO_wdt iTCO_vendor_support toshiba_acpi pcspkr input_leds intel_powerclamp sparse_keymap coretemp atl1c toshiba_bluetooth led_class serio_raw rfkill psmouse i2c_i801 snd_hda_codec_conexant snd_hda_codec_generic wmi snd_hda_intel intel_ips snd_hda_codec snd_hda_core ac snd_hwdep snd_pcm snd_timer snd evdev fjes shpchp mac_hid battery
May 19 10:26:08 lapis kernel:  lpc_ich soundcore mei_me mei acpi_cpufreq tpm_tis tpm processor sch_fq_codel sg ip_tables x_tables ext4 crc16 jbd2 mbcache sr_mod cdrom sd_mod atkbd libps2 ahci libahci libata scsi_mod i8042 serio ehci_pci ehci_hcd usbcore usb_common i915 video button i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_agp intel_gtt
May 19 10:26:08 lapis kernel: CPU: 0 PID: 627 Comm: wpa_supplicant Tainted: G        W       4.6.0-1-ARCH #1
May 19 10:26:08 lapis kernel: Hardware name: TOSHIBA Satellite L655/Base Board Product Name, BIOS 2.80 07/03/2012
May 19 10:26:08 lapis kernel:  0000000000000286 00000000766b165b ffff8800b1ac7a28 ffffffff812e5362
May 19 10:26:08 lapis kernel:  ffff880137c15940 ffff8800b1ac7bf0 ffff8800b1ac7a38 ffffffff810a10eb
May 19 10:26:08 lapis kernel:  ffff8800b1ac7a88 ffffffff815c2b39 00ff880137c55940 ffffffff810aa489
May 19 10:26:08 lapis kernel: Call Trace:
May 19 10:26:08 lapis kernel:  [<ffffffff812e5362>] dump_stack+0x63/0x81
May 19 10:26:08 lapis kernel:  [<ffffffff810a10eb>] __schedule_bug+0x4b/0x60
May 19 10:26:08 lapis kernel:  [<ffffffff815c2b39>] __schedule+0x899/0xad0
May 19 10:26:08 lapis kernel:  [<ffffffff810aa489>] ? sched_clock_cpu+0xa9/0xd0
May 19 10:26:08 lapis kernel:  [<ffffffff815c2dac>] schedule+0x3c/0x90
May 19 10:26:08 lapis kernel:  [<ffffffff815c5883>] schedule_timeout+0x1d3/0x260
May 19 10:26:08 lapis kernel:  [<ffffffff810a3bed>] ? ttwu_do_activate.constprop.40+0x5d/0x70
May 19 10:26:08 lapis kernel:  [<ffffffff810a47a3>] ? try_to_wake_up+0x183/0x3d0
May 19 10:26:08 lapis kernel:  [<ffffffff815c3931>] wait_for_common+0xc1/0x180
May 19 10:26:08 lapis kernel:  [<ffffffff810a4a80>] ? wake_up_q+0x70/0x70
May 19 10:26:08 lapis kernel:  [<ffffffff815c3a0d>] wait_for_completion+0x1d/0x20
May 19 10:26:08 lapis kernel:  [<ffffffff8108f480>] call_usermodehelper_exec+0xf0/0x170
May 19 10:26:08 lapis kernel:  [<ffffffff812576d7>] do_coredump+0x4c7/0xe10
May 19 10:26:08 lapis kernel:  [<ffffffff810876fa>] ? signal_wake_up_state+0x2a/0x30
May 19 10:26:08 lapis kernel:  [<ffffffff81087c2b>] ? complete_signal+0xdb/0x210
May 19 10:26:08 lapis kernel:  [<ffffffff81089bb8>] get_signal+0x348/0x650
May 19 10:26:08 lapis kernel:  [<ffffffff8102e147>] do_signal+0x37/0x6f0
May 19 10:26:08 lapis kernel:  [<ffffffff810d422f>] ? vprintk_default+0x1f/0x30
May 19 10:26:08 lapis kernel:  [<ffffffff8116da29>] ? printk+0x57/0x73
May 19 10:26:08 lapis kernel:  [<ffffffff812eb462>] ? ___ratelimit+0xb2/0x100
May 19 10:26:08 lapis kernel:  [<ffffffff810d422f>] ? vprintk_default+0x1f/0x30
May 19 10:26:08 lapis kernel:  [<ffffffff81067144>] ? bad_area_nosemaphore+0x14/0x20
May 19 10:26:08 lapis kernel:  [<ffffffff81003691>] exit_to_usermode_loop+0xa1/0xc0
May 19 10:26:08 lapis kernel:  [<ffffffff81003b86>] prepare_exit_to_usermode+0x26/0x30
May 19 10:26:08 lapis kernel:  [<ffffffff815c71a5>] retint_user+0x8/0x10
May 19 10:26:08 lapis systemd-coredump[630]: Process 627 (wpa_supplicant) of user 0 dumped core.

                                             Stack trace of thread 627:
                                             #0  0x00007fc8de7b6b39 _int_malloc (libc.so.6)
                                             #1  0x00007fc8de7b81d4 malloc (libc.so.6)
                                             #2  0x00007fc8df631a99 nl_recv (libnl-3.so.200)
                                             #3  0x00007fc8df6323e5 nl_recvmsgs_report (libnl-3.so.200)
                                             #4  0x00007fc8df6326d9 nl_recvmsgs (libnl-3.so.200)
                                             #5  0x0000000000501573 n/a (wpa_supplicant)
                                             #6  0x0000000000514c27 n/a (wpa_supplicant)
                                             #7  0x00000000004fb463 n/a (wpa_supplicant)
                                             #8  0x00000000004e9600 n/a (wpa_supplicant)
                                             #9  0x0000000000422276 n/a (wpa_supplicant)
                                             #10 0x00000000004ed697 n/a (wpa_supplicant)
                                             #11 0x0000000000412f05 n/a (wpa_supplicant)
                                             #12 0x00007fc8de760741 __libc_start_main (libc.so.6)
                                             #13 0x0000000000412f99 n/a (wpa_supplicant)


From me at bobcopeland.com  Thu May 19 15:56:12 2016
From: me at bobcopeland.com (Bob Copeland)
Date: Thu, 19 May 2016 18:56:12 -0400
Subject: "kernel: BUG: scheduling while atomic:" errors with linux kernel
 4.6
In-Reply-To: <e2d89c7d-7567-c3ac-505e-7a9aa887c158@nurealm.net>
References: <e2d89c7d-7567-c3ac-505e-7a9aa887c158@nurealm.net>
Message-ID: <20160519225612.GB12028@localhost>

+linux-wireless

On Thu, May 19, 2016 at 03:11:16PM -0600, James Feeney wrote:
> Arch linux 4.6-1
> wpa_supplicant 1:2.5-3
> Toshiba Satellite, circa 2011, with a Pentium Dual-Core Mobile
> Error is not seen on other machines.
> 
> kernel: BUG: scheduling while atomic: wpa_supplicant/375/0x00000002

This is a kernel bug, not a wpa_supplicant bug.  The linux-wireless mailing
list would be a more appropriate venue for this bug report.


> May 19 10:26:07 lapis kernel: BUG: scheduling while atomic: wpa_supplicant/627/0x00000002
[...]
> May 19 10:26:07 lapis kernel:  [<ffffffff815c2b39>] __schedule+0x899/0xad0
> May 19 10:26:07 lapis kernel:  [<ffffffff815c2dac>] schedule+0x3c/0x90
> May 19 10:26:07 lapis kernel:  [<ffffffff815c5bb2>] schedule_hrtimeout_range_clock+0xa2/0x120
> May 19 10:26:07 lapis kernel:  [<ffffffff810e8b80>] ? hrtimer_init+0x120/0x120
> May 19 10:26:07 lapis kernel:  [<ffffffff815c5ba6>] ? schedule_hrtimeout_range_clock+0x96/0x120
> May 19 10:26:07 lapis kernel:  [<ffffffff815c5c43>] schedule_hrtimeout_range+0x13/0x20
> May 19 10:26:07 lapis kernel:  [<ffffffff815c568f>] usleep_range+0x4f/0x70
> May 19 10:26:07 lapis kernel:  [<ffffffffa0667218>] rtl_rfreg_delay+0x38/0x50 [rtlwifi]
> May 19 10:26:07 lapis kernel:  [<ffffffffa06dd0e7>] rtl92c_phy_config_rf_with_headerfile+0xc7/0xe0 [rtl8192ce]

[Probably due to this kernel change:

commit 49f86ec21c01b654f6ec47f2f4567f4f9ebaa26b
Author: Larry Finger <Larry.Finger at lwfinger.net>
Date:   Mon Feb 15 16:12:07 2016 -0600

    rtlwifi: Change long delays to sleeps


...apparently this function isn't in sleepable context after all.]

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


From michal.kazior at tieto.com  Thu May 19 23:26:32 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Fri, 20 May 2016 08:26:32 +0200
Subject: dynamic vlan with ath10k not working - regression
In-Reply-To: <EF6DF72779EE294A8A2425E8DA3BC0CC54352FCF@Pallas.devolo.intern>
References: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
 <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351A8F@Pallas.devolo.intern>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern>
 <57357FCF.4090006@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351F8C@Pallas.devolo.intern>
 <57388B69.50900@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54352FCF@Pallas.devolo.intern>
Message-ID: <CA+BoTQkgA+UbdKL_ER0r3-eaNqurxUhj8k0Tn4Vkkho_h25cRQ@mail.gmail.com>

On 19 May 2016 at 13:45, Guenther Kelleter <Guenther.Kelleter at devolo.de> wrote:
> Hi
>
>
>> -----Original Message-----
>> From: Hostap [mailto:hostap-bounces at lists.infradead.org] On Behalf Of M. Braun
>> Sent: Sunday, May 15, 2016 4:45 PM
>> To: hostap at lists.infradead.org
>> Subject: Re: dynamic vlan with ath10k not working - regression
>>
>> Am 13.05.2016 um 13:46 schrieb Guenther Kelleter:
>> > Let me sum up what I did understand so far:
>> > ...
>> > Is this correct?
>>
>> Yes.
>>
>> To be more precise, that "base" interface is per BSS and has type "AP",
>> but that does not really make a difference here.
>
> Ah, but isn't this exactly the difference that matters here?
> According to a comment in mac80211 an AP_VLAN interface is not represented by a vdev of the driver. And a key cannot be installed for a VLAN. Does AP_VLAN encryption have to be handled in software? But the SW_CRYPTO_CONTROL flag somehow prevents SW-crypto for ath10k.
> How is this VLAN encryption gonna work at all when for an AP_VLAN neither HW nor SW- crypto are supported?
> I don't get it.

Some drivers (i.e. ath10k in this case) don't use real 802.11 frames
when talking to device firmware hence it is impossible to pass through
things like IV and MIC unless both FW and HW fully support given
crypto mode.

See: https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?id=fa7e1fbcb52cc9efab394526a566d80fb31529bb

What you can do is to try using raw mode in ath10k (I think recent
10.2.4.x should do fine) by playing around with "cryptmode" and
"rawmode" ath10k_core module parameters.

Be vary that this will impact performance (both airtime efficiency and
CPU consumption for various reasons).


Micha?


From Guenther.Kelleter at devolo.de  Fri May 20 06:16:31 2016
From: Guenther.Kelleter at devolo.de (Guenther Kelleter)
Date: Fri, 20 May 2016 13:16:31 +0000
Subject: dynamic vlan with ath10k not working - regression
In-Reply-To: <CA+BoTQkgA+UbdKL_ER0r3-eaNqurxUhj8k0Tn4Vkkho_h25cRQ@mail.gmail.com>
References: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
 <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351A8F@Pallas.devolo.intern>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern>
 <57357FCF.4090006@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351F8C@Pallas.devolo.intern>
 <57388B69.50900@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54352FCF@Pallas.devolo.intern>
 <CA+BoTQkgA+UbdKL_ER0r3-eaNqurxUhj8k0Tn4Vkkho_h25cRQ@mail.gmail.com>
Message-ID: <EF6DF72779EE294A8A2425E8DA3BC0CC543532E9@Pallas.devolo.intern>


> -----Original Message-----
> From: Michal Kazior [mailto:michal.kazior at tieto.com]
> Sent: Friday, May 20, 2016 8:27 AM
> To: Guenther Kelleter
> Cc: hostap at lists.infradead.org
> Subject: Re: dynamic vlan with ath10k not working - regression
> 
> On 19 May 2016 at 13:45, Guenther Kelleter <Guenther.Kelleter at devolo.de>
> wrote:
> > Hi
> >
> >
> >> -----Original Message-----
> >> From: Hostap [mailto:hostap-bounces at lists.infradead.org] On Behalf Of M.
> Braun
> >> Sent: Sunday, May 15, 2016 4:45 PM
> >> To: hostap at lists.infradead.org
> >> Subject: Re: dynamic vlan with ath10k not working - regression
> >>
> >> Am 13.05.2016 um 13:46 schrieb Guenther Kelleter:
> >> > Let me sum up what I did understand so far:
> >> > ...
> >> > Is this correct?
> >>
> >> Yes.
> >>
> >> To be more precise, that "base" interface is per BSS and has type "AP",
> >> but that does not really make a difference here.
> >
> > Ah, but isn't this exactly the difference that matters here?
> > According to a comment in mac80211 an AP_VLAN interface is not represented
> by a vdev of the driver. And a key cannot be installed for a VLAN. Does
> AP_VLAN encryption have to be handled in software? But the SW_CRYPTO_CONTROL
> flag somehow prevents SW-crypto for ath10k.
> > How is this VLAN encryption gonna work at all when for an AP_VLAN neither HW
> nor SW- crypto are supported?
> > I don't get it.
> 
> Some drivers (i.e. ath10k in this case) don't use real 802.11 frames
> when talking to device firmware hence it is impossible to pass through
> things like IV and MIC unless both FW and HW fully support given
> crypto mode.
> 
> See:
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?id=fa7e1fbc
> b52cc9efab394526a566d80fb31529bb
> 
> What you can do is to try using raw mode in ath10k (I think recent
> 10.2.4.x should do fine) by playing around with "cryptmode" and
> "rawmode" ath10k_core module parameters.


I tried that already, but neither 10.2.4.70.xx nor 10.2.4.97 support raw mode which the driver requires for cryptmode=1.

[   13.570000] ath10k_pci 0000:00:00.0: firmware ver 10.2.4.70.42-2 api 5 features no-p2p,raw-mode,mfp crc32 44f66eae
[   13.620000] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[   13.630000] ath10k_pci 0000:00:00.0: Falling back to user helper
[   13.700000] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
[   13.720000] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[   14.860000] ath10k_pci 0000:00:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1


[   14.366027] ath10k_pci 0000:00:00.0: firmware ver 10.2.4.97 api 5 features no-p2p crc32 f91e34f2
[   14.415333] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[   14.425989] ath10k_pci 0000:00:00.0: Falling back to user helper
[   14.703039] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
[   14.732334] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[   14.739841] ath10k_pci 0000:00:00.0: cryptmode > 0 requires raw mode support from firmware
[   14.748279] ath10k_pci 0000:00:00.0: fatal problem with firmware features: -22
[   14.755852] ath10k_pci 0000:00:00.0: could not probe fw (-22)


However, I might be wrong, but I think that trying to set a HW-crypt key for an AP_VLAN vif the driver doesn't know about is wrong in the first place. The AP_VLAN's (I)GTK should be passed via the corresponding AP vif to ieee80211_key_enable_hw_accel() instead(?)

Because
static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
[...]
        if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
                /*
                 * The driver doesn't know anything about VLAN interfaces.
                 * Hence, don't send GTKs for VLAN interfaces to the driver.
                 */
                if (!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE))
                        goto out_unsupported;
        }
it's an error to do this. Or is it only an ath10k defect and other drivers use SW-crypto on AP_VLAN? Can't we pass already encrypted frames to ath10k?

Is the PTK for station on an AP_VLAN set on the corresponding AP vif resp. passed to AP's driver vdev? Or is AP_VLAN crypto not hw-accelerated?


> 
> Be vary that this will impact performance (both airtime efficiency and
> CPU consumption for various reasons).
> 
> 
> Micha?

G?nther

From Larry.Finger at lwfinger.net  Fri May 20 08:39:31 2016
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Fri, 20 May 2016 10:39:31 -0500
Subject: "kernel: BUG: scheduling while atomic:" errors with linux kernel
 4.6
In-Reply-To: <20160519225612.GB12028@localhost>
References: <e2d89c7d-7567-c3ac-505e-7a9aa887c158@nurealm.net>
 <20160519225612.GB12028@localhost>
Message-ID: <573F2FB3.6090206@lwfinger.net>

On 05/19/2016 05:56 PM, Bob Copeland wrote:
> +linux-wireless
>
> On Thu, May 19, 2016 at 03:11:16PM -0600, James Feeney wrote:
>> Arch linux 4.6-1
>> wpa_supplicant 1:2.5-3
>> Toshiba Satellite, circa 2011, with a Pentium Dual-Core Mobile
>> Error is not seen on other machines.
>>
>> kernel: BUG: scheduling while atomic: wpa_supplicant/375/0x00000002
>
> This is a kernel bug, not a wpa_supplicant bug.  The linux-wireless mailing
> list would be a more appropriate venue for this bug report.
>
>
>> May 19 10:26:07 lapis kernel: BUG: scheduling while atomic: wpa_supplicant/627/0x00000002
> [...]
>> May 19 10:26:07 lapis kernel:  [<ffffffff815c2b39>] __schedule+0x899/0xad0
>> May 19 10:26:07 lapis kernel:  [<ffffffff815c2dac>] schedule+0x3c/0x90
>> May 19 10:26:07 lapis kernel:  [<ffffffff815c5bb2>] schedule_hrtimeout_range_clock+0xa2/0x120
>> May 19 10:26:07 lapis kernel:  [<ffffffff810e8b80>] ? hrtimer_init+0x120/0x120
>> May 19 10:26:07 lapis kernel:  [<ffffffff815c5ba6>] ? schedule_hrtimeout_range_clock+0x96/0x120
>> May 19 10:26:07 lapis kernel:  [<ffffffff815c5c43>] schedule_hrtimeout_range+0x13/0x20
>> May 19 10:26:07 lapis kernel:  [<ffffffff815c568f>] usleep_range+0x4f/0x70
>> May 19 10:26:07 lapis kernel:  [<ffffffffa0667218>] rtl_rfreg_delay+0x38/0x50 [rtlwifi]
>> May 19 10:26:07 lapis kernel:  [<ffffffffa06dd0e7>] rtl92c_phy_config_rf_with_headerfile+0xc7/0xe0 [rtl8192ce]
>
> [Probably due to this kernel change:
>
> commit 49f86ec21c01b654f6ec47f2f4567f4f9ebaa26b
> Author: Larry Finger <Larry.Finger at lwfinger.net>
> Date:   Mon Feb 15 16:12:07 2016 -0600
>
>      rtlwifi: Change long delays to sleeps
>
>
> ...apparently this function isn't in sleepable context after all.]
>

@James: Please run the command "dmesg | grep rtl_rfreg_delay". Do any of the 
resulting lines show a value other than "+0x38" for the offset? If that is the 
only one, the attached patch should fix the problem.

Thanks,

Larry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_schedule_while_atomic.patch
Type: text/x-patch
Size: 740 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160520/0971b752/attachment.bin>

From j at w1.fi  Fri May 20 14:37:42 2016
From: j at w1.fi (Jouni Malinen)
Date: Sat, 21 May 2016 00:37:42 +0300
Subject: Question on Multiple BSSID support
In-Reply-To: <CABy9W5nn8w1C-EUgva4sOQGOv46qQ0BFVpXfrbtSPar+Vz06Tg@mail.gmail.com>
References: <CABy9W5nn8w1C-EUgva4sOQGOv46qQ0BFVpXfrbtSPar+Vz06Tg@mail.gmail.com>
Message-ID: <20160520213742.GA22197@w1.fi>

On Wed, May 18, 2016 at 11:07:30AM -0700, Ann Lo wrote:
> The hostapd configuration allows for multiple BSSID support, with the
> following comment:
> 
> #bss=wlan0_0
> #ssid=test2
> # most of the above items can be used here (apart from radio interface specific
> # items, like channel)
> 
> Would you advise whether it is OK to define the following
> configurations differently for each BSSID? We are using ath10k driver.
> 1) WMM parameters
> 2) Station inactivity limit
> 3) max_num_sta
> 4) WPA/IEEE 802.11i configuration

As far as hostapd is concerned, most of the WMM parameters are shared
between all virtual BSSes that use the same radio, i.e., tx_queue_* and
wmm_ac_* parameters are global for each radio. I'd expect most drivers
to have similar restriction at least for tx_queue_*. In theory, wmm_ac_*
could likely be made to use different values for each BSS with a hostapd
change since these only impact what is being advertised in various
management frames. tx_queue_* would likely be more difficult due to
driver/hardware restrictions.

The other items on the list are per-BSS in hostapd and will likely work
with most drivers as per-BSS parameters as well, so different values can
be used for each BSS.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Fri May 20 14:39:55 2016
From: j at w1.fi (Jouni Malinen)
Date: Sat, 21 May 2016 00:39:55 +0300
Subject: [PATCH 2/9] tests: Remote hwsim tests skip broadcast
 connectivity test
In-Reply-To: <1463663210-15610-2-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
 <1463663210-15610-2-git-send-email-jonathan@wizery.com>
Message-ID: <20160520213955.GB22197@w1.fi>

On Thu, May 19, 2016 at 04:06:43PM +0300, Jonathan Afek wrote:
> The regular hwsim tests use both unicast and broadcast frames to test
> the connectivity between 2 interfaces.
> For real hardware (remote hwsim tests) the broadcast frames will
> sometimes not be seen by all connected stations since they can be in
> low power mode during DTIM or because broadcast frames are not
> acked.
> This commit makes the connectivity test for real hardware use
> only unicast frames instead of both unicast and broadcast.

I don't think this is a good idea. Verifying that broadcast delivery
works is an important part of connectivity testing especially with all
test cases using encrypted connection.

-- 
Jouni Malinen                                            PGP id EFC895FA


From annlo.tech at gmail.com  Fri May 20 21:38:07 2016
From: annlo.tech at gmail.com (Ann Lo)
Date: Fri, 20 May 2016 21:38:07 -0700
Subject: Question on Multiple BSSID support
In-Reply-To: <20160520213742.GA22197@w1.fi>
References: <CABy9W5nn8w1C-EUgva4sOQGOv46qQ0BFVpXfrbtSPar+Vz06Tg@mail.gmail.com>
 <20160520213742.GA22197@w1.fi>
Message-ID: <CABy9W5kB7sdM7U2ECU3Uv-xU5zdjKBN=5rQ-XqSoR3ZbouRwHQ@mail.gmail.com>

This is good information to know.

Thanks,
Ann

On Fri, May 20, 2016 at 2:37 PM, Jouni Malinen <j at w1.fi> wrote:
> On Wed, May 18, 2016 at 11:07:30AM -0700, Ann Lo wrote:
>> The hostapd configuration allows for multiple BSSID support, with the
>> following comment:
>>
>> #bss=wlan0_0
>> #ssid=test2
>> # most of the above items can be used here (apart from radio interface specific
>> # items, like channel)
>>
>> Would you advise whether it is OK to define the following
>> configurations differently for each BSSID? We are using ath10k driver.
>> 1) WMM parameters
>> 2) Station inactivity limit
>> 3) max_num_sta
>> 4) WPA/IEEE 802.11i configuration
>
> As far as hostapd is concerned, most of the WMM parameters are shared
> between all virtual BSSes that use the same radio, i.e., tx_queue_* and
> wmm_ac_* parameters are global for each radio. I'd expect most drivers
> to have similar restriction at least for tx_queue_*. In theory, wmm_ac_*
> could likely be made to use different values for each BSS with a hostapd
> change since these only impact what is being advertised in various
> management frames. tx_queue_* would likely be more difficult due to
> driver/hardware restrictions.
>
> The other items on the list are per-BSS in hostapd and will likely work
> with most drivers as per-BSS parameters as well, so different values can
> be used for each BSS.
>
> --
> Jouni Malinen                                            PGP id EFC895FA


From michael-dev at fami-braun.de  Sun May 22 05:25:54 2016
From: michael-dev at fami-braun.de (M. Braun)
Date: Sun, 22 May 2016 14:25:54 +0200
Subject: dynamic vlan with ath10k not working - regression
In-Reply-To: <EF6DF72779EE294A8A2425E8DA3BC0CC543532E9@Pallas.devolo.intern>
References: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
 <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351A8F@Pallas.devolo.intern>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern>
 <57357FCF.4090006@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351F8C@Pallas.devolo.intern>
 <57388B69.50900@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54352FCF@Pallas.devolo.intern>
 <CA+BoTQkgA+UbdKL_ER0r3-eaNqurxUhj8k0Tn4Vkkho_h25cRQ@mail.gmail.com>
 <EF6DF72779EE294A8A2425E8DA3BC0CC543532E9@Pallas.devolo.intern>
Message-ID: <5741A552.7040004@fami-braun.de>

Am 20.05.2016 um 15:16 schrieb Guenther Kelleter:
> However, I might be wrong, but I think that trying to set a HW-crypt
> key for an AP_VLAN vif the driver doesn't know about is wrong in the
> first place. The AP_VLAN's (I)GTK should be passed via the
> corresponding AP vif to ieee80211_key_enable_hw_accel() instead(?)

We need different GTK per AP/AP_VLAN netdev in order to achieve per-VLAN
isolation. So the correct correct GTK when encrypting the
broadcast/multicast frame must be choosen.

As AP_VLAN is within a single BSS, BSSID cannot be used to select here.
As GTK is for broadcast/multicast frames, destination mac address cannot
be used as well.
So there is nothing except the AP_VLAN ifindex here to make the driver
or firmware choose the correct GTK.

Passing all GTK to the AP interface will essentially not allow for
multiple (per VLAN) GTK to be stored/used. Instead, the GTK for one VLAN
would override the one for another VLAN.

> Is the PTK for station on an AP_VLAN set on the corresponding AP vif
> resp. passed to AP's driver vdev? Or is AP_VLAN crypto not
> hw-accelerated?

As PTK is used for unicast traffic, the correct key can be selected
using the destination mac address (station). Thus AP_VLAN does not
matter with PTK.

Regards,
M. Braun


From jonathan at wizery.com  Sun May 22 06:27:45 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Sun, 22 May 2016 16:27:45 +0300
Subject: [PATCH 2/9] tests: Remote hwsim tests skip broadcast connectivity
 test
In-Reply-To: <20160520213955.GB22197@w1.fi>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
 <1463663210-15610-2-git-send-email-jonathan@wizery.com>
 <20160520213955.GB22197@w1.fi>
Message-ID: <CAD8d0+0BBKqvbD0H2PQrOhgzsTEzgnLAMrRMcxnuNOBNjt9yBw@mail.gmail.com>

On Sat, May 21, 2016 at 12:39 AM, Jouni Malinen <j at w1.fi> wrote:
> I don't think this is a good idea. Verifying that broadcast delivery
> works is an important part of connectivity testing especially with all
> test cases using encrypted connection.
You are right. What about doing 10 retries for real hardware and
passing the broadcast connectivity test if one of them is received?


From michal.kazior at tieto.com  Sun May 22 22:30:31 2016
From: michal.kazior at tieto.com (Michal Kazior)
Date: Mon, 23 May 2016 07:30:31 +0200
Subject: dynamic vlan with ath10k not working - regression
In-Reply-To: <EF6DF72779EE294A8A2425E8DA3BC0CC543532E9@Pallas.devolo.intern>
References: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
 <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351A8F@Pallas.devolo.intern>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern>
 <57357FCF.4090006@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351F8C@Pallas.devolo.intern>
 <57388B69.50900@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54352FCF@Pallas.devolo.intern>
 <CA+BoTQkgA+UbdKL_ER0r3-eaNqurxUhj8k0Tn4Vkkho_h25cRQ@mail.gmail.com>
 <EF6DF72779EE294A8A2425E8DA3BC0CC543532E9@Pallas.devolo.intern>
Message-ID: <CA+BoTQ=gFjKOdVCYKVRLuqQo4DOTMtxPOcJ_okh1+d4E5v33dg@mail.gmail.com>

On 20 May 2016 at 15:16, Guenther Kelleter <Guenther.Kelleter at devolo.de> wrote:
>
>> -----Original Message-----
>> From: Michal Kazior [mailto:michal.kazior at tieto.com]
>> Sent: Friday, May 20, 2016 8:27 AM
>> To: Guenther Kelleter
>> Cc: hostap at lists.infradead.org
>> Subject: Re: dynamic vlan with ath10k not working - regression
>>
>> On 19 May 2016 at 13:45, Guenther Kelleter <Guenther.Kelleter at devolo.de>
>> wrote:
>> > Hi
>> >
>> >
>> >> -----Original Message-----
>> >> From: Hostap [mailto:hostap-bounces at lists.infradead.org] On Behalf Of M.
>> Braun
>> >> Sent: Sunday, May 15, 2016 4:45 PM
>> >> To: hostap at lists.infradead.org
>> >> Subject: Re: dynamic vlan with ath10k not working - regression
>> >>
>> >> Am 13.05.2016 um 13:46 schrieb Guenther Kelleter:
>> >> > Let me sum up what I did understand so far:
>> >> > ...
>> >> > Is this correct?
>> >>
>> >> Yes.
>> >>
>> >> To be more precise, that "base" interface is per BSS and has type "AP",
>> >> but that does not really make a difference here.
>> >
>> > Ah, but isn't this exactly the difference that matters here?
>> > According to a comment in mac80211 an AP_VLAN interface is not represented
>> by a vdev of the driver. And a key cannot be installed for a VLAN. Does
>> AP_VLAN encryption have to be handled in software? But the SW_CRYPTO_CONTROL
>> flag somehow prevents SW-crypto for ath10k.
>> > How is this VLAN encryption gonna work at all when for an AP_VLAN neither HW
>> nor SW- crypto are supported?
>> > I don't get it.
>>
>> Some drivers (i.e. ath10k in this case) don't use real 802.11 frames
>> when talking to device firmware hence it is impossible to pass through
>> things like IV and MIC unless both FW and HW fully support given
>> crypto mode.
>>
>> See:
>> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?id=fa7e1fbc
>> b52cc9efab394526a566d80fb31529bb
>>
>> What you can do is to try using raw mode in ath10k (I think recent
>> 10.2.4.x should do fine) by playing around with "cryptmode" and
>> "rawmode" ath10k_core module parameters.
>
>
> I tried that already, but neither 10.2.4.70.xx nor 10.2.4.97 support raw mode which the driver requires for cryptmode=1.
>
> [   13.570000] ath10k_pci 0000:00:00.0: firmware ver 10.2.4.70.42-2 api 5 features no-p2p,raw-mode,mfp crc32 44f66eae

10.2.4.70.42-2 does advertise raw-mode.


> [   13.620000] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> [   13.630000] ath10k_pci 0000:00:00.0: Falling back to user helper
> [   13.700000] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
> [   13.720000] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
> [   14.860000] ath10k_pci 0000:00:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1

But you didn't enable sw crypto in this case (see "raw 0 hwcrypto 1").


>
>
> [   14.366027] ath10k_pci 0000:00:00.0: firmware ver 10.2.4.97 api 5 features no-p2p crc32 f91e34f2

10.2.4.97 does not support raw-mode.

> [   14.415333] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> [   14.425989] ath10k_pci 0000:00:00.0: Falling back to user helper
> [   14.703039] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
> [   14.732334] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
> [   14.739841] ath10k_pci 0000:00:00.0: cryptmode > 0 requires raw mode support from firmware
> [   14.748279] ath10k_pci 0000:00:00.0: fatal problem with firmware features: -22
> [   14.755852] ath10k_pci 0000:00:00.0: could not probe fw (-22)

And you can see driver telling you it doesn't support sw crypto
without raw mode support.


Micha?


From blanquicet at gmail.com  Mon May 23 02:12:54 2016
From: blanquicet at gmail.com (Jose Blanquicet)
Date: Mon, 23 May 2016 11:12:54 +0200
Subject: P2P-GO remains in an autonomous group after last P2P-CLI disconnection
Message-ID: <CAFC8iJJZvFQeHnk0F8_8QLUMMAb0xcjZ5ecM6phrgV4zhz7Zfg@mail.gmail.com>

Hello,

We have found that when our system is the P2P-GO and the last P2P-CLI
in the P2P-Group gets disconnected, the wpa_supplicant does not delete
the P2P-Group and instead the P2P-GO remains alone as kind of
autonomous group. We have not found any specific behavior in such a
scenario specified by the Wi-Fi Alliance in the P2P Specifications,
thus how to proceed is a choice. Therefore, we would like to know if
the no-deletion of the group follows a particular request inside the
wpa_supplicant. If it is not true and it does not affect any other
process, we would like to add such a deletion to avoid the P2P-GO
remains alone in the group, which could be done by disabling the
network associated to the group.

What do you think? Any suggestion or comment?

Best Regards,

Jose Blanquicet


From joerg.krause at embedded.rocks  Mon May 23 08:11:47 2016
From: joerg.krause at embedded.rocks (=?UTF-8?q?J=C3=B6rg=20Krause?=)
Date: Mon, 23 May 2016 17:11:47 +0200
Subject: [PATCH] wpa_cli: Run action file in case of an AP event
Message-ID: <1464016307-3420-1-git-send-email-joerg.krause@embedded.rocks>

Run the action script in case of an AP event "AP-ENABLED" or "AP-DISABLED".

Signed-off-by: J?rg Krause <joerg.krause at embedded.rocks>
---
 wpa_supplicant/wpa_cli.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/wpa_supplicant/wpa_cli.c b/wpa_supplicant/wpa_cli.c
index 9b1c802..53036ae 100644
--- a/wpa_supplicant/wpa_cli.c
+++ b/wpa_supplicant/wpa_cli.c
@@ -3777,6 +3777,10 @@ static void wpa_cli_action_process(const char *msg)
 			wpa_cli_connected = 0;
 			wpa_cli_exec(action_file, ifname, "DISCONNECTED");
 		}
+	} else if (str_match(pos, AP_EVENT_ENABLED)) {
+		wpa_cli_exec(action_file, ctrl_ifname, pos);
+	} else if (str_match(pos, AP_EVENT_DISABLED)) {
+		wpa_cli_exec(action_file, ctrl_ifname, pos);
 	} else if (str_match(pos, MESH_GROUP_STARTED)) {
 		wpa_cli_exec(action_file, ctrl_ifname, pos);
 	} else if (str_match(pos, MESH_GROUP_REMOVED)) {
-- 
2.8.2


From j at w1.fi  Mon May 23 08:13:12 2016
From: j at w1.fi (Jouni Malinen)
Date: Mon, 23 May 2016 18:13:12 +0300
Subject: P2P-GO remains in an autonomous group after last P2P-CLI
 disconnection
In-Reply-To: <CAFC8iJJZvFQeHnk0F8_8QLUMMAb0xcjZ5ecM6phrgV4zhz7Zfg@mail.gmail.com>
References: <CAFC8iJJZvFQeHnk0F8_8QLUMMAb0xcjZ5ecM6phrgV4zhz7Zfg@mail.gmail.com>
Message-ID: <20160523151312.GA3630@w1.fi>

On Mon, May 23, 2016 at 11:12:54AM +0200, Jose Blanquicet wrote:
> We have found that when our system is the P2P-GO and the last P2P-CLI
> in the P2P-Group gets disconnected, the wpa_supplicant does not delete
> the P2P-Group and instead the P2P-GO remains alone as kind of
> autonomous group. We have not found any specific behavior in such a
> scenario specified by the Wi-Fi Alliance in the P2P Specifications,
> thus how to proceed is a choice. Therefore, we would like to know if
> the no-deletion of the group follows a particular request inside the
> wpa_supplicant. If it is not true and it does not affect any other
> process, we would like to add such a deletion to avoid the P2P-GO
> remains alone in the group, which could be done by disabling the
> network associated to the group.

That's configurable behavior. By default, the GO role keeps the group
running until explicitly asked to terminate the group. If you want the
group to be terminated automatically when there are no more clients in
it, you can configure that with the p2p_group_idle parameter. That sets
the idle timeout to the specified number of seconds (default: 0 = no
timeout). If there are no clients in the group for that time, GO will
stop the group automatically.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Mon May 23 08:19:21 2016
From: j at w1.fi (Jouni Malinen)
Date: Mon, 23 May 2016 18:19:21 +0300
Subject: [PATCH 2/9] tests: Remote hwsim tests skip broadcast
 connectivity test
In-Reply-To: <CAD8d0+0BBKqvbD0H2PQrOhgzsTEzgnLAMrRMcxnuNOBNjt9yBw@mail.gmail.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
 <1463663210-15610-2-git-send-email-jonathan@wizery.com>
 <20160520213955.GB22197@w1.fi>
 <CAD8d0+0BBKqvbD0H2PQrOhgzsTEzgnLAMrRMcxnuNOBNjt9yBw@mail.gmail.com>
Message-ID: <20160523151921.GB3630@w1.fi>

On Sun, May 22, 2016 at 04:27:45PM +0300, Jonathan Afek wrote:
> On Sat, May 21, 2016 at 12:39 AM, Jouni Malinen <j at w1.fi> wrote:
> > I don't think this is a good idea. Verifying that broadcast delivery
> > works is an important part of connectivity testing especially with all
> > test cases using encrypted connection.
> You are right. What about doing 10 retries for real hardware and
> passing the broadcast connectivity test if one of them is received?

If that means doing up to 10 retries and stopping on the first success,
then yes, that's probably fine. I'd rather not add significant extra
latency here for the success case, but it is fine to make that take
longer if the broadcast frames do not get through and the test case
would fail anyway.

Please also note that there are couple of cases where
hwsim_utils.test_connectivity() is used for negative testing, i.e.,
there is not supposed to be connectivity and the test case fails if that
function does not raise an exception. Doing 10 retries there should
work, but it will add some latency. That said, I think it is justifiable
to do that for the non-hwsim case without more complexity since there
are only couple of such negative testing cases. Though, I'd be fine with
adding a parameter to the function to indicate if it is used for the
negative case so that the retries could be avoided.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Mon May 23 09:56:23 2016
From: j at w1.fi (Jouni Malinen)
Date: Mon, 23 May 2016 19:56:23 +0300
Subject: EAP-FAST PRF hooks and BoringSSL
In-Reply-To: <CAF8qwaCeha_KGz0rt6BJtYpAYt08F=+LL2zLWCjGmwSPQwF=NQ@mail.gmail.com>
References: <CAF8qwaCeha_KGz0rt6BJtYpAYt08F=+LL2zLWCjGmwSPQwF=NQ@mail.gmail.com>
Message-ID: <20160523165623.GA27150@w1.fi>

On Tue, May 10, 2016 at 01:28:22PM -0400, David Benjamin wrote:
> So, you all have this logic to reimplement the TLS PRF and key
> derivation in src/crypto/tls_openssl.c in openssl_get_keyblock_size
> and openssl_tls_prf. It appears these are used for key derivation in
> EAP-TLS, EAP-TTLS, and EAP-FAST. EAP-(T)TLS can just use RFC 5705
> exporters by way of SSL_export_keying_material, which you use. But
> EAP-FAST is a bit of a nightmare. Among other sins, it hooks into
> TLS's internal key derivation, so you all understandably need to do
> some invasive wrangling.
> 
> We took the EAP-FAST bits out of BoringSSL a long time ago. (The way
> it integrated into session resumption was problematic. I know how I'd
> redo it if I had to, but there hasn't been a need yet.) But to keep
> wpa_supplicant compiling, we have to keep some fields around
> (ssl->enc_read_ctx, ssl->read_hash, and
> ssl->s3->tmp.new_mac_secret_size) even though we never fill them in.

There is a lot of history behind this with EAP-FAST being supported with
OpenSSL 0.9.8 using a custom patch and OpenSSL not yet having
SSL_export_keying_material() available at the time.. And obviously the
EAP-FAST PRF being pretty horrible to implement outside the TLS library.

> 1. I can condition the EAP-FAST-only parts of the key derivation
> conditioned on EAP_FAST #defines. With
> df5bde83daaf3c820b6ac1f8d383b16a64ebd2db, we're finally no longer
> defining those symbols, so this would work. I would probably, to make
> this cleaner, split the tls_connection_prf entry-point into two
> functions, one for the reasonable RFC 5705 mechanisms and one for
> EAP-FAST's crazy thing. (Right now the API supports the RFC 5705
> style, but with skip_keyblock set, which is a little odd.)

Now that all supported OpenSSL versions (support for 0.9.8 and 1.0.0 was
dropped) do have SSL_export_keying_material(), doing the additional
cleanup here with a simple tls_connection_export_key() makes sense to
me.

> 2. For OpenSSL 1.1.x, you all use SSL_CIPHER_get_cipher_nid and
> SSL_CIPHER_get_digest_nid. BoringSSL doesn't have these, but I have no
> problems adding them. (I would not have used NIDs for
> SSL_CIPHER_get_kx_nid and SSL_CIPHER_get_auth_nid but whatever.) It's
> a little odd because the computation is wrong for TLS 1.1+ and we
> don't use EVP_CIPHER in our SSL code anymore. But the code will never
> run anyway, and if it were to later, I could make it match OpenSSL.

I didn't really like implementing key block calculations for OpenSSL
1.1.x (well, it is better than the older version, but still..), so I
don't see much need for BoringSSL to implement these.

> 3. For other reasons, we added a pair of functions,
> SSL_get_key_block_len and SSL_generate_key_block which are actually
> exactly what EAP-FAST wants here. I could make
> openssl_get_keyblock_size call SSL_get_key_block_len and even make
> openssl_tls_prf use SSL_generate_key_block. (Probably this would come
> with a similar tls_connection_prf split as in option #1.) But this
> would be BoringSSL-only code to support a feature that doesn't work in
> BoringSSL anyway, so this is of questionable use.
> https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_get_key_block_len

If OpenSSL were to add that function, I'd consider using it. With
BoringSSL, I would not bother changing anything here (other than
commenting this out from the build) before someone first decides that
there is need for supporting EAP-FAST. I know there are such requests
for certain Android devices, but as long as AOSP does not have that
support, vendors will likely need to do whatever patching is needed to
make this work.. Since I know this is happening, I'd kind of like to get
this implemented with BoringSSL in the main repository, if that can be
done easily, but obviously I'll leave it to you to prioritize such a
feature request.

> Do you all have a preference? #2 would be the least invasive option,
> but splitting tls_connection_prf in two for #1 might be preferable, at
> which point you may as well condition on EAP-FAST. In doing so, we can
> probably do away with the fallback from SSL_export_keying_material to
> openssl_tls_prf if SSL_export_keying_material fails (looks like that's
> a remnant of how the #ifdefs worked out while 1.0.0 was supported) and
> not even ship a custom TLS PRF in the no-EAP-FAST config. I'm happy to
> do a bit of cleanup for you along the way here.

Yeah, that's from the pre-SSL_export_keying_material() history.. I think
I like your patches in the newer email, so assuming they pass my test
cases, I'll apply them to address this.

-- 
Jouni Malinen                                            PGP id EFC895FA


From james at nurealm.net  Mon May 23 10:29:46 2016
From: james at nurealm.net (James Feeney)
Date: Mon, 23 May 2016 11:29:46 -0600
Subject: "kernel: BUG: scheduling while atomic:" errors with linux kernel
 4.6
In-Reply-To: <573F2FB3.6090206@lwfinger.net>
References: <e2d89c7d-7567-c3ac-505e-7a9aa887c158@nurealm.net>
 <20160519225612.GB12028@localhost> <573F2FB3.6090206@lwfinger.net>
Message-ID: <e69117a3-50d4-48bc-d67f-c083e6e3af13@nurealm.net>

On 05/20/2016 09:39 AM, Larry Finger wrote:
> @James: Please run the command "dmesg | grep rtl_rfreg_delay". Do any of the
> resulting lines show a value other than "+0x38" for the offset? If that is the
> only one, the attached patch should fix the problem.

Sorry about the delayed response.

$ dmesg | grep rtl_rfreg_delay
[   15.936262]  [<ffffffffa06b1218>] rtl_rfreg_delay+0x38/0x50 [rtlwifi]
[  348.735402]  [<ffffffffa06b1218>] rtl_rfreg_delay+0x38/0x50 [rtlwifi]

So that looks like a no, just the "+0x38" for the offset.

Thanks
James


From j at w1.fi  Mon May 23 14:17:39 2016
From: j at w1.fi (Jouni Malinen)
Date: Tue, 24 May 2016 00:17:39 +0300
Subject: [PATCH] OpenSSL: Remove two more accesses of ssl_ctx->cert_store.
In-Reply-To: <CAF8qwaBLk5-2Ra1jwewsuPGYEDzyBrUpUcPSzaJWbXU-o-4XtQ@mail.gmail.com>
References: <CAF8qwaBLk5-2Ra1jwewsuPGYEDzyBrUpUcPSzaJWbXU-o-4XtQ@mail.gmail.com>
Message-ID: <20160523211739.GA12365@w1.fi>

On Wed, May 18, 2016 at 01:10:07PM -0400, David Benjamin wrote:
> Patch attached.

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Mon May 23 14:19:11 2016
From: j at w1.fi (Jouni Malinen)
Date: Tue, 24 May 2016 00:19:11 +0300
Subject: EAP-FAST PRF hooks and BoringSSL
In-Reply-To: <CAF8qwaBwg-vC3KMEuyXMP2q4++zsbcrzoPWjQEoo2P4hhO6v4A@mail.gmail.com>
References: <CAF8qwaCeha_KGz0rt6BJtYpAYt08F=+LL2zLWCjGmwSPQwF=NQ@mail.gmail.com>
 <CAF8qwaBwg-vC3KMEuyXMP2q4++zsbcrzoPWjQEoo2P4hhO6v4A@mail.gmail.com>
Message-ID: <20160523211911.GB12365@w1.fi>

On Wed, May 18, 2016 at 01:27:17PM -0400, David Benjamin wrote:
> I've attached the cleanup and #ifdefs I was thinking for this option.
> Note: I've only compile-tested this against Android thus far. It's
> mostly to clarify what I mean, and I'm sure I messed up somewhere.

Thanks, applied with some fixes (GnuTLS one did not compile and Android
build with produced warnings about unused functions) and cleanup.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Mon May 23 14:19:30 2016
From: j at w1.fi (Jouni Malinen)
Date: Tue, 24 May 2016 00:19:30 +0300
Subject: [PATCH] wpa_cli: Run action file in case of an AP event
In-Reply-To: <1464016307-3420-1-git-send-email-joerg.krause@embedded.rocks>
References: <1464016307-3420-1-git-send-email-joerg.krause@embedded.rocks>
Message-ID: <20160523211930.GC12365@w1.fi>

On Mon, May 23, 2016 at 05:11:47PM +0200, J?rg Krause wrote:
> Run the action script in case of an AP event "AP-ENABLED" or "AP-DISABLED".

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From johannes at sipsolutions.net  Mon May 23 23:56:42 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Tue, 24 May 2016 08:56:42 +0200
Subject: [PATCH 2/9] tests: Remote hwsim tests skip broadcast
 connectivity test
In-Reply-To: <20160523151921.GB3630@w1.fi>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
 <1463663210-15610-2-git-send-email-jonathan@wizery.com>
 <20160520213955.GB22197@w1.fi>
 <CAD8d0+0BBKqvbD0H2PQrOhgzsTEzgnLAMrRMcxnuNOBNjt9yBw@mail.gmail.com>
 <20160523151921.GB3630@w1.fi>
Message-ID: <1464073002.4888.0.camel@sipsolutions.net>

On Mon, 2016-05-23 at 18:19 +0300, Jouni Malinen wrote:

> Please also note that there are couple of cases where
> hwsim_utils.test_connectivity() is used for negative testing, i.e.,
> there is not supposed to be connectivity and the test case fails if
> that
> function does not raise an exception. Doing 10 retries there should
> work, but it will add some latency. That said, I think it is
> justifiable
> to do that for the non-hwsim case without more complexity since there
> are only couple of such negative testing cases. Though, I'd be fine
> with
> adding a parameter to the function to indicate if it is used for the
> negative case so that the retries could be avoided.

In the OTA case, this might actually want to do 10 tries to not have
spurious successes when the frame is lost?

johannes


From jonathan at wizery.com  Tue May 24 02:54:44 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Tue, 24 May 2016 12:54:44 +0300
Subject: [PATCH 2/9] tests: Remote hwsim tests skip broadcast connectivity
 test
In-Reply-To: <1464073002.4888.0.camel@sipsolutions.net>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
 <1463663210-15610-2-git-send-email-jonathan@wizery.com>
 <20160520213955.GB22197@w1.fi>
 <CAD8d0+0BBKqvbD0H2PQrOhgzsTEzgnLAMrRMcxnuNOBNjt9yBw@mail.gmail.com>
 <20160523151921.GB3630@w1.fi>
 <1464073002.4888.0.camel@sipsolutions.net>
Message-ID: <CAD8d0+3vpK=OYqba4HBdGhtQWo0DPdzLb1xcszu=H+TBu7_zuw@mail.gmail.com>

On Tue, May 24, 2016 at 9:56 AM, Johannes Berg
<johannes at sipsolutions.net> wrote:
> In the OTA case, this might actually want to do 10 tries to not have
> spurious successes when the frame is lost?
In any case it looks like that in the negative cases we will never
reach the broadcast test since the exception will be raised for the
first unicast frame which comes before that.

I will send another patch with 10 retries and no new parameter.

If there will ever be a negative test which expect unicast to pass but
broadcast to fail, this should work fine for such a case and all other
regular cases.


From jonathan at wizery.com  Tue May 24 04:02:33 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Tue, 24 May 2016 14:02:33 +0300
Subject: [PATCH v2 2/9] tests: OTA 10 retries for broadcast connectivity
In-Reply-To: <1463663210-15610-2-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-2-git-send-email-jonathan@wizery.com>
Message-ID: <1464087753-22583-1-git-send-email-jonathan@wizery.com>

The regular hwsim tests use both unicast and broadcast frames to test
the connectivity between 2 interfaces.
For real hardware (remote hwsim tests) the broadcast frames will
sometimes not be seen by all connected stations since they can be in
low power mode during DTIM or because broadcast frames are not
acked.
Use 10 retries for broadcast connectivity tests for real hardware
so that the test will pass if we successfully received 1 of them.

Signed-off-by: Jonathan Afek <jonathanx.afek at intel.com>
---
 tests/hwsim/hostapd.py     |  1 +
 tests/hwsim/hwsim_utils.py | 69 +++++++++++++++++++++++++++++-----------------
 2 files changed, 44 insertions(+), 26 deletions(-)

diff --git a/tests/hwsim/hostapd.py b/tests/hwsim/hostapd.py
index a6d4cad..6d6d641 100644
--- a/tests/hwsim/hostapd.py
+++ b/tests/hwsim/hostapd.py
@@ -119,6 +119,7 @@ class HostapdGlobal:
 
 class Hostapd:
     def __init__(self, ifname, bssidx=0, hostname=None, port=8877):
+        self.hostname = hostname
         self.host = remotehost.Host(hostname, ifname)
         self.ifname = ifname
         if hostname is None:
diff --git a/tests/hwsim/hwsim_utils.py b/tests/hwsim/hwsim_utils.py
index 85f54a2..5deacba 100644
--- a/tests/hwsim/hwsim_utils.py
+++ b/tests/hwsim/hwsim_utils.py
@@ -26,6 +26,11 @@ def run_connectivity_test(dev1, dev2, tos, dev1group=False, dev2group=False,
     dev2.dump_monitor()
 
     try:
+
+        broadcast_retry_c = 10
+        if dev1.hostname is None and dev2.hostname is None:
+            broadcast_retry_c = 1
+
         if config:
             cmd = "DATA_TEST_CONFIG 1"
             if ifname1:
@@ -61,19 +66,25 @@ def run_connectivity_test(dev1, dev2, tos, dev1group=False, dev2group=False,
         if "DATA-TEST-RX {} {}".format(addr2, addr1) not in ev:
             raise Exception("Unexpected dev1->dev2 unicast data result")
 
-        cmd = "DATA_TEST_TX ff:ff:ff:ff:ff:ff {} {}".format(addr1, tos)
-        if dev1group:
-            dev1.group_request(cmd)
-        else:
-            dev1.request(cmd)
-        if dev2group:
-            ev = dev2.wait_group_event(["DATA-TEST-RX"], timeout=timeout)
-        else:
-            ev = dev2.wait_event(["DATA-TEST-RX"], timeout=timeout)
-        if ev is None:
-            raise Exception("dev1->dev2 broadcast data delivery failed")
-        if "DATA-TEST-RX ff:ff:ff:ff:ff:ff {}".format(addr1) not in ev:
-            raise Exception("Unexpected dev1->dev2 broadcast data result")
+        for i in xrange(broadcast_retry_c):
+            try:
+                cmd = "DATA_TEST_TX ff:ff:ff:ff:ff:ff {} {}".format(addr1, tos)
+                if dev1group:
+                    dev1.group_request(cmd)
+                else:
+                    dev1.request(cmd)
+                if dev2group:
+                    ev = dev2.wait_group_event(["DATA-TEST-RX"], timeout=timeout)
+                else:
+                    ev = dev2.wait_event(["DATA-TEST-RX"], timeout=timeout)
+                if ev is None:
+                    raise Exception("dev1->dev2 broadcast data delivery failed")
+                if "DATA-TEST-RX ff:ff:ff:ff:ff:ff {}".format(addr1) not in ev:
+                    raise Exception("Unexpected dev1->dev2 broadcast data result")
+                break
+            except Exception as e:
+                if i == broadcast_retry_c:
+                    raise
 
         cmd = "DATA_TEST_TX {} {} {}".format(addr1, addr2, tos)
         if dev2group:
@@ -89,19 +100,25 @@ def run_connectivity_test(dev1, dev2, tos, dev1group=False, dev2group=False,
         if "DATA-TEST-RX {} {}".format(addr1, addr2) not in ev:
             raise Exception("Unexpected dev2->dev1 unicast data result")
 
-        cmd = "DATA_TEST_TX ff:ff:ff:ff:ff:ff {} {}".format(addr2, tos)
-        if dev2group:
-            dev2.group_request(cmd)
-        else:
-            dev2.request(cmd)
-        if dev1group:
-            ev = dev1.wait_group_event(["DATA-TEST-RX"], timeout=timeout)
-        else:
-            ev = dev1.wait_event(["DATA-TEST-RX"], timeout=timeout)
-        if ev is None:
-            raise Exception("dev2->dev1 broadcast data delivery failed")
-        if "DATA-TEST-RX ff:ff:ff:ff:ff:ff {}".format(addr2) not in ev:
-            raise Exception("Unexpected dev2->dev1 broadcast data result")
+        for i in xrange(broadcast_retry_c):
+            try:
+                cmd = "DATA_TEST_TX ff:ff:ff:ff:ff:ff {} {}".format(addr2, tos)
+                if dev2group:
+                    dev2.group_request(cmd)
+                else:
+                    dev2.request(cmd)
+                if dev1group:
+                    ev = dev1.wait_group_event(["DATA-TEST-RX"], timeout=timeout)
+                else:
+                    ev = dev1.wait_event(["DATA-TEST-RX"], timeout=timeout)
+                if ev is None:
+                    raise Exception("dev2->dev1 broadcast data delivery failed")
+                if "DATA-TEST-RX ff:ff:ff:ff:ff:ff {}".format(addr2) not in ev:
+                    raise Exception("Unexpected dev2->dev1 broadcast data result")
+                break
+            except Exception as e:
+                if i == broadcast_retry_c:
+                    raise
     finally:
         if config:
             if dev1group:
-- 
1.9.1



From pomidorabelisima at gmail.com  Tue May 24 04:22:39 2016
From: pomidorabelisima at gmail.com (poma)
Date: Tue, 24 May 2016 13:22:39 +0200
Subject: How to activate MAC address randomization?
In-Reply-To: <7f4c8daf-3ec3-f960-cbad-9cd819b559a5@gmail.com>
References: <5723BF90.4010701@openmailbox.org>
 <1463091417.20553.1.camel@redhat.com>
 <b640b32b-85b2-4e9b-18af-6e91ac27f108@gmail.com>
 <573A3674.50809@openmailbox.org>
 <9901c3c7-5c73-9d13-72be-1a6b7ddf82e1@gmail.com>
 <1463582960.4426.11.camel@redhat.com>
 <a1f8dee2-33b5-5754-4223-5150944a7915@gmail.com>
 <1463653326.4426.31.camel@redhat.com>
 <66a6e6fa-a31b-33f5-4c07-8f456811bf15@gmail.com>
 <1463765815.32277.21.camel@redhat.com>
 <fba7f9b2-aca0-8273-a333-f4db502a5f04@gmail.com>
 <7f4c8daf-3ec3-f960-cbad-9cd819b559a5@gmail.com>
Message-ID: <2167f384-ae39-6ecd-91aa-470ce19cd8d7@gmail.com>


[...] NetworkManager [...]

WPA Supplicant comparative test
- wpa_supplicant v2.6-devel git a26c9c2 2016-05-20
- Linux 4.6
- QEMU emulator version 2.6.0 (Hotspot)


Pre-association / Scanning random MAC address

 = Client (mt7601u) =

# grep -v '^#\|^$' /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
preassoc_mac_addr=1
network={
        ssid="WiFiRd"
        bssid=ee:dd:cc:bb:aa:00
        key_mgmt=WPA-PSK
        psk="**********"
}


# wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt


# grep -i 'mac\|rand\|connected' wpasuplog.txt
random: Trying to read entropy from /dev/random
preassoc_mac_addr=1
wlp0s2f1u3: Own MAC address: 00:aa:bb:cc:dd:ee
wlp0s2f1u3: WPS: UUID based on MAC address: [...]
EAPOL: SUPP_PAE entering state DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
random: Got 20/20 bytes from /dev/random
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
nl80211: set_mac_addr for wlp0s2f1u3 to 4a:b1:d6:28:4c:90
wlp0s2f1u3: Using random MAC address 4a:b1:d6:28:4c:90
nl80211: set_mac_addr for wlp0s2f1u3 to 00:aa:bb:cc:dd:ee
wlp0s2f1u3: Using permanent MAC address
wlp0s2f1u3: CTRL-EVENT-CONNECTED - Connection to ee:dd:cc:bb:aa:00 completed [id=0 id_str=]
...



 = Hotspot (rt2800usb) =

# grep -v '^#\|^$' /etc/wpa_supplicant.conf 
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
network={
        ssid="WiFiRd"
        key_mgmt=WPA-PSK
        psk="**********"
        mode=2
}


# wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt


# grep -i '4a:b1:d6:28:4c:90\|00:aa:bb:cc:dd:ee' wpasuplog.txt
nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=4a:b1:d6:28:4c:90 bssid=ff:ff:ff:ff:ff:ff freq=2462 ssi_signal=-19 fc=0x40 seq_ctrl=0x3b20 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=83
nl80211: send_mlme - da= 4a:b1:d6:28:4c:90 noack=1 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=00:aa:bb:cc:dd:ee bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-19 fc=0x8b0 seq_ctrl=0x3b60 stype=11 (WLAN_FC_STYPE_AUTH) len=30
...
wlp2s2f7u2: AP-STA-CONNECTED 00:aa:bb:cc:dd:ee
...


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Association / Connection random MAC address


 = Client (mt7601u) =

# grep -v '^#\|^$' /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
mac_addr=1
network={
        ssid="WiFiRd"
        bssid=ee:dd:cc:bb:aa:00
        key_mgmt=WPA-PSK
        psk="**********"
}


# wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt


# grep -i 'mac\|rand\|connected' wpasuplog.txt
random: Trying to read entropy from /dev/random
mac_addr=1
wlp0s2f1u3: Own MAC address: 00:aa:bb:cc:dd:ee
wlp0s2f1u3: WPS: UUID based on MAC address: [...]
EAPOL: SUPP_PAE entering state DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
random: Got 20/20 bytes from /dev/random
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
nl80211: set_mac_addr for wlp0s2f1u3 to 0e:5d:07:b0:73:a6
wlp0s2f1u3: Using random MAC address 0e:5d:07:b0:73:a6
wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
wlp0s2f1u3: Request to deauthenticate - bssid=00:00:00:00:00:00 pending_bssid=00:00:00:00:00:00 reason=3 state=DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED



 = Hotspot (rt2800usb) =

# grep -v '^#\|^$' /etc/wpa_supplicant.conf 
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
network={
        ssid="WiFiRd"
        key_mgmt=WPA-PSK
        psk="**********"
        mode=2
}


# wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt


# grep -i acknowledge wpasuplog.txt
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response


# grep -i '00:aa:bb:cc:dd:ee\|0e:5d:07:b0:73:a6' wpasuplog.txt
nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=00:aa:bb:cc:dd:ee bssid=ff:ff:ff:ff:ff:ff freq=2462 ssi_signal=-17 fc=0x40 seq_ctrl=0x3c30 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=83
nl80211: send_mlme - da= 00:aa:bb:cc:dd:ee noack=1 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0xb0 seq_ctrl=0x3c60 stype=11 (WLAN_FC_STYPE_AUTH) len=30
authentication: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x3c60
ap_sta_add: register ap_handle_timer timeout for 0e:5d:07:b0:73:a6 (300 seconds - ap_max_inactivity)
nl80211: sta_remove -> DEL_STATION wlp2s2f7u2 0e:5d:07:b0:73:a6 --> -2 (No such file or directory)
nl80211: Add STA 0e:5d:07:b0:73:a6
hostapd_logger: STA 0e:5d:07:b0:73:a6 - authentication OK (open system)
hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-AUTHENTICATE.indication(0e:5d:07:b0:73:a6, OPEN_SYSTEM)
hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-DELETEKEYS.request(0e:5d:07:b0:73:a6)
authentication reply: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
nl80211: send_mlme - da= 0e:5d:07:b0:73:a6 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
nl80211: New station 0e:5d:07:b0:73:a6
nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0x8b0 seq_ctrl=0x3c70 stype=11 (WLAN_FC_STYPE_AUTH) len=30
authentication: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x3c70 retry
hostapd_logger: STA 0e:5d:07:b0:73:a6 - authentication OK (open system)
hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-AUTHENTICATE.indication(0e:5d:07:b0:73:a6, OPEN_SYSTEM)
hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-DELETEKEYS.request(0e:5d:07:b0:73:a6)
authentication reply: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
nl80211: send_mlme - da= 0e:5d:07:b0:73:a6 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
wlp2s2f7u2: EVENT_TX_STATUS dst=0e:5d:07:b0:73:a6 type=0 stype=11
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
wlp2s2f7u2: EVENT_TX_STATUS dst=0e:5d:07:b0:73:a6 type=0 stype=11
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0x8b0 seq_ctrl=0x3c80 stype=11 (WLAN_FC_STYPE_AUTH) len=30
authentication: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x3c80 retry
hostapd_logger: STA 0e:5d:07:b0:73:a6 - authentication OK (open system)
hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-AUTHENTICATE.indication(0e:5d:07:b0:73:a6, OPEN_SYSTEM)
hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-DELETEKEYS.request(0e:5d:07:b0:73:a6)
authentication reply: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
nl80211: send_mlme - da= 0e:5d:07:b0:73:a6 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0x8b0 seq_ctrl=0x3c90 stype=11 (WLAN_FC_STYPE_AUTH) len=30
authentication: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x3c90 retry
hostapd_logger: STA 0e:5d:07:b0:73:a6 - authentication OK (open system)
hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-AUTHENTICATE.indication(0e:5d:07:b0:73:a6, OPEN_SYSTEM)
hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-DELETEKEYS.request(0e:5d:07:b0:73:a6)
authentication reply: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
nl80211: send_mlme - da= 0e:5d:07:b0:73:a6 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
wlp2s2f7u2: EVENT_TX_STATUS dst=0e:5d:07:b0:73:a6 type=0 stype=11
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
wlp2s2f7u2: EVENT_TX_STATUS dst=0e:5d:07:b0:73:a6 type=0 stype=11
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0x8b0 seq_ctrl=0x3ca0 stype=11 (WLAN_FC_STYPE_AUTH) len=30
...



Driver's constraint or wpa_supplicant's issue?




From Larry.Finger at lwfinger.net  Mon May 23 10:48:13 2016
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Mon, 23 May 2016 12:48:13 -0500
Subject: "kernel: BUG: scheduling while atomic:" errors with linux kernel
 4.6
In-Reply-To: <e69117a3-50d4-48bc-d67f-c083e6e3af13@nurealm.net>
References: <e2d89c7d-7567-c3ac-505e-7a9aa887c158@nurealm.net>
 <20160519225612.GB12028@localhost> <573F2FB3.6090206@lwfinger.net>
 <e69117a3-50d4-48bc-d67f-c083e6e3af13@nurealm.net>
Message-ID: <5743425D.8020209@lwfinger.net>

On 05/23/2016 12:29 PM, James Feeney wrote:
> On 05/20/2016 09:39 AM, Larry Finger wrote:
>> @James: Please run the command "dmesg | grep rtl_rfreg_delay". Do any of the
>> resulting lines show a value other than "+0x38" for the offset? If that is the
>> only one, the attached patch should fix the problem.
>
> Sorry about the delayed response.
>
> $ dmesg | grep rtl_rfreg_delay
> [   15.936262]  [<ffffffffa06b1218>] rtl_rfreg_delay+0x38/0x50 [rtlwifi]
> [  348.735402]  [<ffffffffa06b1218>] rtl_rfreg_delay+0x38/0x50 [rtlwifi]
>
> So that looks like a no, just the "+0x38" for the offset.

I was able to duplicate the BUG and have submitted a patch. I think you were in 
the Cc list. The patch will appear sometime in the 4.7-rcX series, and will be 
ported to kernel 4.6 once it appears in the mainline repo.

Larry




From pomidorabelisima at gmail.com  Tue May 24 07:46:06 2016
From: pomidorabelisima at gmail.com (poma)
Date: Tue, 24 May 2016 16:46:06 +0200
Subject: How to activate MAC address randomization?
In-Reply-To: <2167f384-ae39-6ecd-91aa-470ce19cd8d7@gmail.com>
References: <5723BF90.4010701@openmailbox.org>
 <1463091417.20553.1.camel@redhat.com>
 <b640b32b-85b2-4e9b-18af-6e91ac27f108@gmail.com>
 <573A3674.50809@openmailbox.org>
 <9901c3c7-5c73-9d13-72be-1a6b7ddf82e1@gmail.com>
 <1463582960.4426.11.camel@redhat.com>
 <a1f8dee2-33b5-5754-4223-5150944a7915@gmail.com>
 <1463653326.4426.31.camel@redhat.com>
 <66a6e6fa-a31b-33f5-4c07-8f456811bf15@gmail.com>
 <1463765815.32277.21.camel@redhat.com>
 <fba7f9b2-aca0-8273-a333-f4db502a5f04@gmail.com>
 <7f4c8daf-3ec3-f960-cbad-9cd819b559a5@gmail.com>
 <2167f384-ae39-6ecd-91aa-470ce19cd8d7@gmail.com>
Message-ID: <086327a1-8410-519d-205c-f65c51843d10@gmail.com>

On 24.05.2016 13:22, poma wrote:
> 
> [...] NetworkManager [...]
> 
> WPA Supplicant comparative test
> - wpa_supplicant v2.6-devel git a26c9c2 2016-05-20
> - Linux 4.6
> - QEMU emulator version 2.6.0 (Hotspot)
> 
> 
> Pre-association / Scanning random MAC address
> 
>  = Client (mt7601u) =
> 
> # grep -v '^#\|^$' /etc/wpa_supplicant.conf
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> preassoc_mac_addr=1
> network={
>         ssid="WiFiRd"
>         bssid=ee:dd:cc:bb:aa:00
>         key_mgmt=WPA-PSK
>         psk="**********"
> }
> 
> 
> # wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt
> 
> 
> # grep -i 'mac\|rand\|connected' wpasuplog.txt
> random: Trying to read entropy from /dev/random
> preassoc_mac_addr=1
> wlp0s2f1u3: Own MAC address: 00:aa:bb:cc:dd:ee
> wlp0s2f1u3: WPS: UUID based on MAC address: [...]
> EAPOL: SUPP_PAE entering state DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
> random: Got 20/20 bytes from /dev/random
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> nl80211: set_mac_addr for wlp0s2f1u3 to 4a:b1:d6:28:4c:90
> wlp0s2f1u3: Using random MAC address 4a:b1:d6:28:4c:90
> nl80211: set_mac_addr for wlp0s2f1u3 to 00:aa:bb:cc:dd:ee
> wlp0s2f1u3: Using permanent MAC address
> wlp0s2f1u3: CTRL-EVENT-CONNECTED - Connection to ee:dd:cc:bb:aa:00 completed [id=0 id_str=]
> ...
> 
> 
> 
>  = Hotspot (rt2800usb) =
> 
> # grep -v '^#\|^$' /etc/wpa_supplicant.conf 
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> network={
>         ssid="WiFiRd"
>         key_mgmt=WPA-PSK
>         psk="**********"
>         mode=2
> }
> 
> 
> # wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt
> 
> 
> # grep -i '4a:b1:d6:28:4c:90\|00:aa:bb:cc:dd:ee' wpasuplog.txt
> nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=4a:b1:d6:28:4c:90 bssid=ff:ff:ff:ff:ff:ff freq=2462 ssi_signal=-19 fc=0x40 seq_ctrl=0x3b20 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=83
> nl80211: send_mlme - da= 4a:b1:d6:28:4c:90 noack=1 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=00:aa:bb:cc:dd:ee bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-19 fc=0x8b0 seq_ctrl=0x3b60 stype=11 (WLAN_FC_STYPE_AUTH) len=30
> ...
> wlp2s2f7u2: AP-STA-CONNECTED 00:aa:bb:cc:dd:ee
> ...
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> Association / Connection random MAC address
> 
> 
>  = Client (mt7601u) =
> 
> # grep -v '^#\|^$' /etc/wpa_supplicant.conf
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> mac_addr=1
> network={
>         ssid="WiFiRd"
>         bssid=ee:dd:cc:bb:aa:00
>         key_mgmt=WPA-PSK
>         psk="**********"
> }
> 
> 
> # wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt
> 
> 
> # grep -i 'mac\|rand\|connected' wpasuplog.txt
> random: Trying to read entropy from /dev/random
> mac_addr=1
> wlp0s2f1u3: Own MAC address: 00:aa:bb:cc:dd:ee
> wlp0s2f1u3: WPS: UUID based on MAC address: [...]
> EAPOL: SUPP_PAE entering state DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
> random: Got 20/20 bytes from /dev/random
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> nl80211: set_mac_addr for wlp0s2f1u3 to 0e:5d:07:b0:73:a6
> wlp0s2f1u3: Using random MAC address 0e:5d:07:b0:73:a6
> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
> wlp0s2f1u3: Request to deauthenticate - bssid=00:00:00:00:00:00 pending_bssid=00:00:00:00:00:00 reason=3 state=DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
> 
> 
> 
>  = Hotspot (rt2800usb) =
> 
> # grep -v '^#\|^$' /etc/wpa_supplicant.conf 
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> network={
>         ssid="WiFiRd"
>         key_mgmt=WPA-PSK
>         psk="**********"
>         mode=2
> }
> 
> 
> # wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt
> 
> 
> # grep -i acknowledge wpasuplog.txt
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> 
> 
> # grep -i '00:aa:bb:cc:dd:ee\|0e:5d:07:b0:73:a6' wpasuplog.txt
> nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=00:aa:bb:cc:dd:ee bssid=ff:ff:ff:ff:ff:ff freq=2462 ssi_signal=-17 fc=0x40 seq_ctrl=0x3c30 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=83
> nl80211: send_mlme - da= 00:aa:bb:cc:dd:ee noack=1 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0xb0 seq_ctrl=0x3c60 stype=11 (WLAN_FC_STYPE_AUTH) len=30
> authentication: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x3c60
> ap_sta_add: register ap_handle_timer timeout for 0e:5d:07:b0:73:a6 (300 seconds - ap_max_inactivity)
> nl80211: sta_remove -> DEL_STATION wlp2s2f7u2 0e:5d:07:b0:73:a6 --> -2 (No such file or directory)
> nl80211: Add STA 0e:5d:07:b0:73:a6
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - authentication OK (open system)
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-AUTHENTICATE.indication(0e:5d:07:b0:73:a6, OPEN_SYSTEM)
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-DELETEKEYS.request(0e:5d:07:b0:73:a6)
> authentication reply: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
> nl80211: send_mlme - da= 0e:5d:07:b0:73:a6 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
> nl80211: New station 0e:5d:07:b0:73:a6
> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0x8b0 seq_ctrl=0x3c70 stype=11 (WLAN_FC_STYPE_AUTH) len=30
> authentication: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x3c70 retry
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - authentication OK (open system)
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-AUTHENTICATE.indication(0e:5d:07:b0:73:a6, OPEN_SYSTEM)
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-DELETEKEYS.request(0e:5d:07:b0:73:a6)
> authentication reply: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
> nl80211: send_mlme - da= 0e:5d:07:b0:73:a6 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
> wlp2s2f7u2: EVENT_TX_STATUS dst=0e:5d:07:b0:73:a6 type=0 stype=11
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> wlp2s2f7u2: EVENT_TX_STATUS dst=0e:5d:07:b0:73:a6 type=0 stype=11
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0x8b0 seq_ctrl=0x3c80 stype=11 (WLAN_FC_STYPE_AUTH) len=30
> authentication: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x3c80 retry
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - authentication OK (open system)
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-AUTHENTICATE.indication(0e:5d:07:b0:73:a6, OPEN_SYSTEM)
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-DELETEKEYS.request(0e:5d:07:b0:73:a6)
> authentication reply: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
> nl80211: send_mlme - da= 0e:5d:07:b0:73:a6 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0x8b0 seq_ctrl=0x3c90 stype=11 (WLAN_FC_STYPE_AUTH) len=30
> authentication: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x3c90 retry
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - authentication OK (open system)
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-AUTHENTICATE.indication(0e:5d:07:b0:73:a6, OPEN_SYSTEM)
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-DELETEKEYS.request(0e:5d:07:b0:73:a6)
> authentication reply: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
> nl80211: send_mlme - da= 0e:5d:07:b0:73:a6 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
> wlp2s2f7u2: EVENT_TX_STATUS dst=0e:5d:07:b0:73:a6 type=0 stype=11
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> wlp2s2f7u2: EVENT_TX_STATUS dst=0e:5d:07:b0:73:a6 type=0 stype=11
> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0x8b0 seq_ctrl=0x3ca0 stype=11 (WLAN_FC_STYPE_AUTH) len=30
> ...
> 
> 
> 
> Driver's constraint or wpa_supplicant's issue?
> 
> 


 = Client (r92su - https://github.com/chunkeey/rtl8192su) =

# wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf
Successfully initialized wpa_supplicant
wlp0s2f1u3: Trying to associate with ee:dd:cc:bb:aa:00 (SSID='WiFiRd' freq=2462 MHz)
wlp0s2f1u3: Associated with ee:dd:cc:bb:aa:00
wlp0s2f1u3: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlp0s2f1u3: WPA: Key negotiation completed with ee:dd:cc:bb:aa:00 [PTK=CCMP GTK=TKIP]
wlp0s2f1u3: CTRL-EVENT-CONNECTED - Connection to ee:dd:cc:bb:aa:00 completed [id=0 id_str=]


$ macchanger -s wlp0s2f1u3
Current MAC:   12:21:64:8a:08:ce (unknown)
Permanent MAC: 00:aa:bb:cc:dd:ee ([...])



 = Hotspot (rt2800usb) =

# wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf
Successfully initialized wpa_supplicant
Using interface wlp2s2f7u2 with hwaddr ee:dd:cc:bb:aa:00 and ssid "WiFiRd"
wlp2s2f7u2: interface state UNINITIALIZED->ENABLED
wlp2s2f7u2: AP-ENABLED 
wlp2s2f7u2: CTRL-EVENT-CONNECTED - Connection to ee:dd:cc:bb:aa:00 completed [id=0 id_str=]
wlp2s2f7u2: AP-STA-CONNECTED 12:21:64:8a:08:ce



It seems, at the current stage of development,
mt7601u.ko cannot cope with the Association / Connection random MAC address
https://github.com/kuba-moo/mt7601u/commits/master

So after all, this is driver's constrain, perhaps a bug.



From pomidorabelisima at gmail.com  Tue May 24 07:56:05 2016
From: pomidorabelisima at gmail.com (poma)
Date: Tue, 24 May 2016 16:56:05 +0200
Subject: How to activate MAC address randomization?
In-Reply-To: <086327a1-8410-519d-205c-f65c51843d10@gmail.com>
References: <5723BF90.4010701@openmailbox.org>
 <1463091417.20553.1.camel@redhat.com>
 <b640b32b-85b2-4e9b-18af-6e91ac27f108@gmail.com>
 <573A3674.50809@openmailbox.org>
 <9901c3c7-5c73-9d13-72be-1a6b7ddf82e1@gmail.com>
 <1463582960.4426.11.camel@redhat.com>
 <a1f8dee2-33b5-5754-4223-5150944a7915@gmail.com>
 <1463653326.4426.31.camel@redhat.com>
 <66a6e6fa-a31b-33f5-4c07-8f456811bf15@gmail.com>
 <1463765815.32277.21.camel@redhat.com>
 <fba7f9b2-aca0-8273-a333-f4db502a5f04@gmail.com>
 <7f4c8daf-3ec3-f960-cbad-9cd819b559a5@gmail.com>
 <2167f384-ae39-6ecd-91aa-470ce19cd8d7@gmail.com>
 <086327a1-8410-519d-205c-f65c51843d10@gmail.com>
Message-ID: <2d8b2e38-56bd-e64f-a524-e0f95ca809e9@gmail.com>

On 24.05.2016 16:46, poma wrote:
> On 24.05.2016 13:22, poma wrote:
>>
>> [...] NetworkManager [...]
>>
>> WPA Supplicant comparative test
>> - wpa_supplicant v2.6-devel git a26c9c2 2016-05-20
>> - Linux 4.6
>> - QEMU emulator version 2.6.0 (Hotspot)
>>
>>
>> Pre-association / Scanning random MAC address
>>
>>  = Client (mt7601u) =
>>
>> # grep -v '^#\|^$' /etc/wpa_supplicant.conf
>> ctrl_interface=/var/run/wpa_supplicant
>> ctrl_interface_group=wheel
>> preassoc_mac_addr=1
>> network={
>>         ssid="WiFiRd"
>>         bssid=ee:dd:cc:bb:aa:00
>>         key_mgmt=WPA-PSK
>>         psk="**********"
>> }
>>
>>
>> # wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt
>>
>>
>> # grep -i 'mac\|rand\|connected' wpasuplog.txt
>> random: Trying to read entropy from /dev/random
>> preassoc_mac_addr=1
>> wlp0s2f1u3: Own MAC address: 00:aa:bb:cc:dd:ee
>> wlp0s2f1u3: WPS: UUID based on MAC address: [...]
>> EAPOL: SUPP_PAE entering state DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
>> random: Got 20/20 bytes from /dev/random
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> nl80211: set_mac_addr for wlp0s2f1u3 to 4a:b1:d6:28:4c:90
>> wlp0s2f1u3: Using random MAC address 4a:b1:d6:28:4c:90
>> nl80211: set_mac_addr for wlp0s2f1u3 to 00:aa:bb:cc:dd:ee
>> wlp0s2f1u3: Using permanent MAC address
>> wlp0s2f1u3: CTRL-EVENT-CONNECTED - Connection to ee:dd:cc:bb:aa:00 completed [id=0 id_str=]
>> ...
>>
>>
>>
>>  = Hotspot (rt2800usb) =
>>
>> # grep -v '^#\|^$' /etc/wpa_supplicant.conf 
>> ctrl_interface=/var/run/wpa_supplicant
>> ctrl_interface_group=wheel
>> network={
>>         ssid="WiFiRd"
>>         key_mgmt=WPA-PSK
>>         psk="**********"
>>         mode=2
>> }
>>
>>
>> # wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt
>>
>>
>> # grep -i '4a:b1:d6:28:4c:90\|00:aa:bb:cc:dd:ee' wpasuplog.txt
>> nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=4a:b1:d6:28:4c:90 bssid=ff:ff:ff:ff:ff:ff freq=2462 ssi_signal=-19 fc=0x40 seq_ctrl=0x3b20 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=83
>> nl80211: send_mlme - da= 4a:b1:d6:28:4c:90 noack=1 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
>> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=00:aa:bb:cc:dd:ee bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-19 fc=0x8b0 seq_ctrl=0x3b60 stype=11 (WLAN_FC_STYPE_AUTH) len=30
>> ...
>> wlp2s2f7u2: AP-STA-CONNECTED 00:aa:bb:cc:dd:ee
>> ...
>>
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>> Association / Connection random MAC address
>>
>>
>>  = Client (mt7601u) =
>>
>> # grep -v '^#\|^$' /etc/wpa_supplicant.conf
>> ctrl_interface=/var/run/wpa_supplicant
>> ctrl_interface_group=wheel
>> mac_addr=1
>> network={
>>         ssid="WiFiRd"
>>         bssid=ee:dd:cc:bb:aa:00
>>         key_mgmt=WPA-PSK
>>         psk="**********"
>> }
>>
>>
>> # wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt
>>
>>
>> # grep -i 'mac\|rand\|connected' wpasuplog.txt
>> random: Trying to read entropy from /dev/random
>> mac_addr=1
>> wlp0s2f1u3: Own MAC address: 00:aa:bb:cc:dd:ee
>> wlp0s2f1u3: WPS: UUID based on MAC address: [...]
>> EAPOL: SUPP_PAE entering state DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
>> random: Got 20/20 bytes from /dev/random
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> nl80211: set_mac_addr for wlp0s2f1u3 to 0e:5d:07:b0:73:a6
>> wlp0s2f1u3: Using random MAC address 0e:5d:07:b0:73:a6
>> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
>> wlp0s2f1u3: Request to deauthenticate - bssid=00:00:00:00:00:00 pending_bssid=00:00:00:00:00:00 reason=3 state=DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
>>
>>
>>
>>  = Hotspot (rt2800usb) =
>>
>> # grep -v '^#\|^$' /etc/wpa_supplicant.conf 
>> ctrl_interface=/var/run/wpa_supplicant
>> ctrl_interface_group=wheel
>> network={
>>         ssid="WiFiRd"
>>         key_mgmt=WPA-PSK
>>         psk="**********"
>>         mode=2
>> }
>>
>>
>> # wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt
>>
>>
>> # grep -i acknowledge wpasuplog.txt
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>>
>>
>> # grep -i '00:aa:bb:cc:dd:ee\|0e:5d:07:b0:73:a6' wpasuplog.txt
>> nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=00:aa:bb:cc:dd:ee bssid=ff:ff:ff:ff:ff:ff freq=2462 ssi_signal=-17 fc=0x40 seq_ctrl=0x3c30 stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=83
>> nl80211: send_mlme - da= 00:aa:bb:cc:dd:ee noack=1 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
>> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0xb0 seq_ctrl=0x3c60 stype=11 (WLAN_FC_STYPE_AUTH) len=30
>> authentication: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x3c60
>> ap_sta_add: register ap_handle_timer timeout for 0e:5d:07:b0:73:a6 (300 seconds - ap_max_inactivity)
>> nl80211: sta_remove -> DEL_STATION wlp2s2f7u2 0e:5d:07:b0:73:a6 --> -2 (No such file or directory)
>> nl80211: Add STA 0e:5d:07:b0:73:a6
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - authentication OK (open system)
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-AUTHENTICATE.indication(0e:5d:07:b0:73:a6, OPEN_SYSTEM)
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-DELETEKEYS.request(0e:5d:07:b0:73:a6)
>> authentication reply: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
>> nl80211: send_mlme - da= 0e:5d:07:b0:73:a6 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
>> nl80211: New station 0e:5d:07:b0:73:a6
>> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0x8b0 seq_ctrl=0x3c70 stype=11 (WLAN_FC_STYPE_AUTH) len=30
>> authentication: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x3c70 retry
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - authentication OK (open system)
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-AUTHENTICATE.indication(0e:5d:07:b0:73:a6, OPEN_SYSTEM)
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-DELETEKEYS.request(0e:5d:07:b0:73:a6)
>> authentication reply: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
>> nl80211: send_mlme - da= 0e:5d:07:b0:73:a6 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
>> wlp2s2f7u2: EVENT_TX_STATUS dst=0e:5d:07:b0:73:a6 type=0 stype=11
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> wlp2s2f7u2: EVENT_TX_STATUS dst=0e:5d:07:b0:73:a6 type=0 stype=11
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0x8b0 seq_ctrl=0x3c80 stype=11 (WLAN_FC_STYPE_AUTH) len=30
>> authentication: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x3c80 retry
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - authentication OK (open system)
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-AUTHENTICATE.indication(0e:5d:07:b0:73:a6, OPEN_SYSTEM)
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-DELETEKEYS.request(0e:5d:07:b0:73:a6)
>> authentication reply: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
>> nl80211: send_mlme - da= 0e:5d:07:b0:73:a6 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
>> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0x8b0 seq_ctrl=0x3c90 stype=11 (WLAN_FC_STYPE_AUTH) len=30
>> authentication: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x3c90 retry
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - authentication OK (open system)
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-AUTHENTICATE.indication(0e:5d:07:b0:73:a6, OPEN_SYSTEM)
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - MLME-DELETEKEYS.request(0e:5d:07:b0:73:a6)
>> authentication reply: STA=0e:5d:07:b0:73:a6 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
>> nl80211: send_mlme - da= 0e:5d:07:b0:73:a6 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
>> wlp2s2f7u2: EVENT_TX_STATUS dst=0e:5d:07:b0:73:a6 type=0 stype=11
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> wlp2s2f7u2: EVENT_TX_STATUS dst=0e:5d:07:b0:73:a6 type=0 stype=11
>> hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication response
>> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=0e:5d:07:b0:73:a6 bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-15 fc=0x8b0 seq_ctrl=0x3ca0 stype=11 (WLAN_FC_STYPE_AUTH) len=30
>> ...
>>
>>
>>
>> Driver's constraint or wpa_supplicant's issue?
>>
>>
> 
> 
>  = Client (r92su - https://github.com/chunkeey/rtl8192su) =
> 
> # wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf
> Successfully initialized wpa_supplicant
> wlp0s2f1u3: Trying to associate with ee:dd:cc:bb:aa:00 (SSID='WiFiRd' freq=2462 MHz)
> wlp0s2f1u3: Associated with ee:dd:cc:bb:aa:00
> wlp0s2f1u3: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
> wlp0s2f1u3: WPA: Key negotiation completed with ee:dd:cc:bb:aa:00 [PTK=CCMP GTK=TKIP]
> wlp0s2f1u3: CTRL-EVENT-CONNECTED - Connection to ee:dd:cc:bb:aa:00 completed [id=0 id_str=]
> 
> 
> $ macchanger -s wlp0s2f1u3
> Current MAC:   12:21:64:8a:08:ce (unknown)
> Permanent MAC: 00:aa:bb:cc:dd:ee ([...])
> 
> 
> 
>  = Hotspot (rt2800usb) =
> 
> # wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf
> Successfully initialized wpa_supplicant
> Using interface wlp2s2f7u2 with hwaddr ee:dd:cc:bb:aa:00 and ssid "WiFiRd"
> wlp2s2f7u2: interface state UNINITIALIZED->ENABLED
> wlp2s2f7u2: AP-ENABLED 
> wlp2s2f7u2: CTRL-EVENT-CONNECTED - Connection to ee:dd:cc:bb:aa:00 completed [id=0 id_str=]
> wlp2s2f7u2: AP-STA-CONNECTED 12:21:64:8a:08:ce
> 
> 
> 
> It seems, at the current stage of development,
> mt7601u.ko cannot cope with the Association / Connection random MAC address
> https://github.com/kuba-moo/mt7601u/commits/master
> 
> So after all, this is driver's constrain, perhaps a bug.
> 


For the record, tricks like this ain't gonna help:
---
 src/ap/ieee802_11.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/src/ap/ieee802_11.c b/src/ap/ieee802_11.c
index 781afa2..16714a3 100644
--- a/src/ap/ieee802_11.c
+++ b/src/ap/ieee802_11.c
@@ -2662,13 +2662,6 @@ static void handle_auth_cb(struct hostapd_data *hapd,
 	auth_transaction = le_to_host16(mgmt->u.auth.auth_transaction);
 	status_code = le_to_host16(mgmt->u.auth.status_code);
 
-	if (!ok) {
-		hostapd_logger(hapd, mgmt->da, HOSTAPD_MODULE_IEEE80211,
-			       HOSTAPD_LEVEL_NOTICE,
-			       "did not acknowledge authentication response");
-		goto fail;
-	}
-
 	if (len < IEEE80211_HDRLEN + sizeof(mgmt->u.auth)) {
 		wpa_printf(MSG_INFO, "handle_auth_cb - too short payload (len=%lu)",
 			   (unsigned long) len);


Bye




From joerg.krause at embedded.rocks  Wed May 25 00:08:11 2016
From: joerg.krause at embedded.rocks (=?ISO-8859-1?Q?J=F6rg?= Krause)
Date: Wed, 25 May 2016 09:08:11 +0200
Subject: [PATCH] wpa_cli: Run action file in case of an AP event
In-Reply-To: <20160523211930.GC12365@w1.fi>
References: <1464016307-3420-1-git-send-email-joerg.krause@embedded.rocks>
 <20160523211930.GC12365@w1.fi>
Message-ID: <1464160091.17440.13.camel@embedded.rocks>

On Di, 2016-05-24 at 00:19 +0300, Jouni Malinen wrote:
> On Mon, May 23, 2016 at 05:11:47PM +0200, J?rg Krause wrote:
> > Run the action script in case of an AP event "AP-ENABLED" or "AP-
> > DISABLED".
> 
> Thanks, applied.

Many thanks!

I would like to pass more events, e.g. ASSOC-REJECT, to the action
script. Do you have any concerns about which events are passed?

Currently, the events are passed in two different ways: Pass a
shortened string like "CONNECTED" and "DISCONNECTED" for CTRL_EVENT_*
or pass a full string for all other events.

As ASSOC-REJECT is of type CTRL_EVENT_* too, do you prefer to pass the
string "ASSOC-REJECT" or CTRL_EVENT_ASSOC_REJECT, e.g.

    wpa_cli_exec(action_file, ifname, "ASSOC-REJECT");

OR

    wpa_cli_exec(action_file, ifname, CTRL_EVENT_ASSOC_REJECT);

Best regards,
J?rg Krause


From Guenther.Kelleter at devolo.de  Wed May 25 05:35:17 2016
From: Guenther.Kelleter at devolo.de (Guenther Kelleter)
Date: Wed, 25 May 2016 12:35:17 +0000
Subject: dynamic vlan with ath10k not working - regression
In-Reply-To: <CA+BoTQ=gFjKOdVCYKVRLuqQo4DOTMtxPOcJ_okh1+d4E5v33dg@mail.gmail.com>
References: <EF6DF72779EE294A8A2425E8DA3BC0CC5434FECF@Pallas.devolo.intern>
 <9d0e461dcbfff4dd81e73cec39e24ba7@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351A8F@Pallas.devolo.intern>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern>
 <57357FCF.4090006@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54351F8C@Pallas.devolo.intern>
 <57388B69.50900@fami-braun.de>
 <EF6DF72779EE294A8A2425E8DA3BC0CC54352FCF@Pallas.devolo.intern>
 <CA+BoTQkgA+UbdKL_ER0r3-eaNqurxUhj8k0Tn4Vkkho_h25cRQ@mail.gmail.com>
 <EF6DF72779EE294A8A2425E8DA3BC0CC543532E9@Pallas.devolo.intern>
 <CA+BoTQ=gFjKOdVCYKVRLuqQo4DOTMtxPOcJ_okh1+d4E5v33dg@mail.gmail.com>
Message-ID: <EF6DF72779EE294A8A2425E8DA3BC0CC54353D1E@Pallas.devolo.intern>

Hi


> -----Original Message-----
> From: Michal Kazior [mailto:michal.kazior at tieto.com]
> Sent: Monday, May 23, 2016 7:31 AM
> To: Guenther Kelleter
> Cc: hostap at lists.infradead.org
> Subject: Re: dynamic vlan with ath10k not working - regression
> 
> On 20 May 2016 at 15:16, Guenther Kelleter <Guenther.Kelleter at devolo.de>
> wrote:
> >
> >> -----Original Message-----
> >> From: Michal Kazior [mailto:michal.kazior at tieto.com]
> >> Sent: Friday, May 20, 2016 8:27 AM
> >> To: Guenther Kelleter
> >> Cc: hostap at lists.infradead.org
> >> Subject: Re: dynamic vlan with ath10k not working - regression
> >>
> >> On 19 May 2016 at 13:45, Guenther Kelleter <Guenther.Kelleter at devolo.de>
> >> wrote:
> >> > Hi
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: Hostap [mailto:hostap-bounces at lists.infradead.org] On Behalf Of M.
> >> Braun
> >> >> Sent: Sunday, May 15, 2016 4:45 PM
> >> >> To: hostap at lists.infradead.org
> >> >> Subject: Re: dynamic vlan with ath10k not working - regression
> >> >>
> >> >> Am 13.05.2016 um 13:46 schrieb Guenther Kelleter:
> >> >> > Let me sum up what I did understand so far:
> >> >> > ...
> >> >> > Is this correct?
> >> >>
> >> >> Yes.
> >> >>
> >> >> To be more precise, that "base" interface is per BSS and has type "AP",
> >> >> but that does not really make a difference here.
> >> >
> >> > Ah, but isn't this exactly the difference that matters here?
> >> > According to a comment in mac80211 an AP_VLAN interface is not
> represented
> >> by a vdev of the driver. And a key cannot be installed for a VLAN. Does
> >> AP_VLAN encryption have to be handled in software? But the
> SW_CRYPTO_CONTROL
> >> flag somehow prevents SW-crypto for ath10k.
> >> > How is this VLAN encryption gonna work at all when for an AP_VLAN neither
> HW
> >> nor SW- crypto are supported?
> >> > I don't get it.
> >>
> >> Some drivers (i.e. ath10k in this case) don't use real 802.11 frames
> >> when talking to device firmware hence it is impossible to pass through
> >> things like IV and MIC unless both FW and HW fully support given
> >> crypto mode.
> >>
> >> See:
> >>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?id=fa7e1fbc
> >> b52cc9efab394526a566d80fb31529bb
> >>
> >> What you can do is to try using raw mode in ath10k (I think recent
> >> 10.2.4.x should do fine) by playing around with "cryptmode" and
> >> "rawmode" ath10k_core module parameters.
> >
> >
> > I tried that already, but neither 10.2.4.70.xx nor 10.2.4.97 support raw
> mode which the driver requires for cryptmode=1.
> >
> > [   13.570000] ath10k_pci 0000:00:00.0: firmware ver 10.2.4.70.42-2 api 5
> features no-p2p,raw-mode,mfp crc32 44f66eae
> 
> 10.2.4.70.42-2 does advertise raw-mode.
> 
> 
> > [   13.620000] ath10k_pci 0000:00:00.0: Direct firmware load for
> ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> > [   13.630000] ath10k_pci 0000:00:00.0: Falling back to user helper
> > [   13.700000] firmware ath10k!QCA988X!hw2.0!board-2.bin:
> firmware_loading_store: map pages failed
> > [   13.720000] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32
> bebc7c08
> > [   14.860000] ath10k_pci 0000:00:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal
> file max-sta 128 raw 0 hwcrypto 1
> 
> But you didn't enable sw crypto in this case (see "raw 0 hwcrypto 1").


My bad. I overlooked the features list and interpreted "raw 0" to mean unsupported.
Now I tried rawmode or hwcrypto, but both turn out to be completely broken since I can't associate even with the crude workaround from further above this thread (disabling GTK installation for the dynamic VLAN). Can't figure out what's happening though.

Now I'm desperately searching for some docs on AP_VLAN and key handling of mac80211. But the kernel-docbooks are empty w.r.t. this subject. Looking at the code to find out how this works seems really useless.
And docs about ath10k FW would be fine too, this must be top secret matter. Not even changelogs seem to exist.


G?nther

> 
> 
> >
> >
> > [   14.366027] ath10k_pci 0000:00:00.0: firmware ver 10.2.4.97 api 5
> features no-p2p crc32 f91e34f2
> 
> 10.2.4.97 does not support raw-mode.
> 
> > [   14.415333] ath10k_pci 0000:00:00.0: Direct firmware load for
> ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> > [   14.425989] ath10k_pci 0000:00:00.0: Falling back to user helper
> > [   14.703039] firmware ath10k!QCA988X!hw2.0!board-2.bin:
> firmware_loading_store: map pages failed
> > [   14.732334] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32
> bebc7c08
> > [   14.739841] ath10k_pci 0000:00:00.0: cryptmode > 0 requires raw mode
> support from firmware
> > [   14.748279] ath10k_pci 0000:00:00.0: fatal problem with firmware
> features: -22
> > [   14.755852] ath10k_pci 0000:00:00.0: could not probe fw (-22)
> 
> And you can see driver telling you it doesn't support sw crypto
> without raw mode support.
> 
> 
> Micha?

From j at w1.fi  Fri May 27 02:04:51 2016
From: j at w1.fi (Jouni Malinen)
Date: Fri, 27 May 2016 12:04:51 +0300
Subject: [PATCH] wpa_cli: Run action file in case of an AP event
In-Reply-To: <1464160091.17440.13.camel@embedded.rocks>
References: <1464016307-3420-1-git-send-email-joerg.krause@embedded.rocks>
 <20160523211930.GC12365@w1.fi>
 <1464160091.17440.13.camel@embedded.rocks>
Message-ID: <20160527090451.GA3052@w1.fi>

On Wed, May 25, 2016 at 09:08:11AM +0200, J?rg Krause wrote:
> I would like to pass more events, e.g. ASSOC-REJECT, to the action
> script. Do you have any concerns about which events are passed?

I do have some concern based on what is actually included in the event
contents, i.e., whether it is something that can be controlled by remote
devices. This is an area that is inconveniently easy to do in a manner
that results in security vulnerabilities.

> Currently, the events are passed in two different ways: Pass a
> shortened string like "CONNECTED" and "DISCONNECTED" for CTRL_EVENT_*
> or pass a full string for all other events.
> 
> As ASSOC-REJECT is of type CTRL_EVENT_* too, do you prefer to pass the
> string "ASSOC-REJECT" or CTRL_EVENT_ASSOC_REJECT, e.g.
> 
>     wpa_cli_exec(action_file, ifname, "ASSOC-REJECT");
> 
> OR
> 
>     wpa_cli_exec(action_file, ifname, CTRL_EVENT_ASSOC_REJECT);

I have no strong preference on that front.

-- 
Jouni Malinen                                            PGP id EFC895FA


From n.chaprana at samsung.com  Fri May 27 02:23:11 2016
From: n.chaprana at samsung.com (Nishant Chaprana)
Date: Fri, 27 May 2016 14:53:11 +0530
Subject: [PATCH] [D-Bus][GroupStarted] Indicate whether created group is
 persistent or not.
Message-ID: <1464340991-3123-1-git-send-email-n.chaprana@samsung.com>

This patch sends extra parameter in GroupStarted event to indicate
whether created group is Persistent or not. It is similar to
[PERSISTENT] tag which comes in P2P-GROUP-STARTED over CTRL interface.

Signed-off-by: Nishant Chaprana <n.chaprana at samsung.com>
---
 wpa_supplicant/dbus/dbus_new.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/wpa_supplicant/dbus/dbus_new.c b/wpa_supplicant/dbus/dbus_new.c
index d894f6a..0827d62 100644
--- a/wpa_supplicant/dbus/dbus_new.c
+++ b/wpa_supplicant/dbus/dbus_new.c
@@ -1300,6 +1300,8 @@ void wpas_dbus_signal_p2p_group_started(struct wpa_supplicant *wpa_s,
 					      wpa_s->dbus_new_path) ||
 	    !wpa_dbus_dict_append_string(&dict_iter, "role",
 					 client ? "client" : "GO") ||
+	    !wpa_dbus_dict_append_bool(&dict_iter, "persistent",
+					 network_id ? 1 : 0) ||
 	    !wpa_dbus_dict_append_object_path(&dict_iter, "group_object",
 					      wpa_s->dbus_groupobj_path) ||
 	    !wpa_dbus_dict_close_write(&iter, &dict_iter)) {
-- 
1.9.1



From reinholds at comcast.net  Fri May 27 20:35:52 2016
From: reinholds at comcast.net (Reinholds@comcast.net)
Date: Fri, 27 May 2016 23:35:52 -0400
Subject: wpa_supplicant not detecting loss of an association with AP
Message-ID: <063b01d1b892$09be2f90$1d3a8eb0$@comcast.net>

Hi,
I am attempting to address a problem in which the wpa_supplicant does not
appear to detect the loss of association with an access point. The problem
is intermittent and does not happen consistently. However, when it does
happen the system on which wpa_supplicant is running does not recover and
manual intervention is necessary. Manual intervention involves disconnecting
wpa_supplicant from the AP, and then reconnecting to the AP.
In debugging the problem we looked at the state of the wifi connection by
using iwconfig which indicates that the wlan0 interface is not-associated.
This is consistent with the output from the ip link command which also
indicates that the wlan0 is "DOWN".
However, if we use D-feet to examine the properties of
fi.w1.wpa_supplicant1.Interface we find that it believes that it is
associated with the wifi AP. Further, there are no indications in the
journalctl log file suggest that wpa_supplicant is seeing the disconnection
and trying to reestablish it.

I am looking for suggestions as to how to further identify what is causing
the problem, and suggestions for work arounds that will allow the Raspberry
PI-3 to remain online.

The testing is being done using wpasupplicant 2.3, on a Raspberry PI-3
running Raspian version 8 (Jessie) and Linux kernel 4.4.10-v7+

A segment of the journalctl output, starting at the detection of the lost
carrier is below:

May 27 10:05:58 raspberrypi systemd-networkd[1032]: wlan0           : lost
carrier
May 27 10:05:58 raspberrypi systemd-networkd[1032]: wlan0           : DHCP
lease lost
May 27 10:05:58 raspberrypi avahi-daemon[402]: Withdrawing address record
for 192.168.0.106 on wlan0.
May 27 10:05:58 raspberrypi avahi-daemon[402]: Leaving mDNS multicast group
on interface wlan0.IPv4 with address 192.168.0.106.
May 27 10:05:58 raspberrypi avahi-daemon[402]: Interface wlan0.IPv4 no
longer relevant for mDNS.
May 27 10:05:58 raspberrypi wpa_supplicant[807]: wlan0:
CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
May 27 10:05:58 raspberrypi kernel: brcmfmac: brcmf_cfg80211_reg_notifier:
not a ISO3166 code
May 27 10:05:58 raspberrypi kernel: cfg80211: World regulatory domain
updated:
May 27 10:05:58 raspberrypi kernel: cfg80211:  DFS Master region: unset
May 27 10:05:58 raspberrypi kernel: cfg80211:   (start_freq - end_freq @
bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
May 27 10:05:58 raspberrypi kernel: cfg80211:   (2402000 KHz - 2472000 KHz @
40000 KHz), (N/A, 2000 mBm), (N/A)
May 27 10:05:58 raspberrypi kernel: cfg80211:   (2457000 KHz - 2482000 KHz @
40000 KHz), (N/A, 2000 mBm), (N/A)
May 27 10:05:58 raspberrypi kernel: cfg80211:   (2474000 KHz - 2494000 KHz @
20000 KHz), (N/A, 2000 mBm), (N/A)
May 27 10:05:58 raspberrypi kernel: cfg80211:   (5170000 KHz - 5250000 KHz @
80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
May 27 10:05:58 raspberrypi kernel: cfg80211:   (5250000 KHz - 5330000 KHz @
80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
May 27 10:05:58 raspberrypi kernel: cfg80211:   (5490000 KHz - 5730000 KHz @
160000 KHz), (N/A, 2000 mBm), (0 s)
May 27 10:05:58 raspberrypi kernel: cfg80211:   (5735000 KHz - 5835000 KHz @
80000 KHz), (N/A, 2000 mBm), (N/A)
May 27 10:05:58 raspberrypi kernel: cfg80211:   (57240000 KHz - 63720000 KHz
@ 2160000 KHz), (N/A, 0 mBm), (N/A)
May 27 10:07:06 raspberrypi start.sh[1098]: 10:07:06.883 [    MQTT Ping:
@7309] ERROR o.e.p.c.m.i.ClientState - @7309: Timed out as no activity,
keepAlive=60,000 lastOutboundActivity=1,464,357,966,877
lastInboundActivity=1,464,357,907,045 time=1,464,358,026,876
lastPing=1,464,357,966,877
May 27 10:07:06 raspberrypi start.sh[1098]: 10:07:06.943 [    MQTT Ping:
@7309]  INFO c.l.h.s.h.a.ApsService - APS connection lost
May 27 10:07:06 raspberrypi start.sh[1098]: 10:07:06.944 [
aps-reconnect]  INFO c.l.h.s.h.a.ApsService - Attempting to reconnect APS
May 27 10:07:07 raspberrypi start.sh[1098]: 10:07:07.082 [
aps-reconnect]  INFO c.l.h.s.h.a.ApsService - Failed to reconnect APS;
retrying in 10000 ms
May 27 10:07:07 raspberrypi start.sh[1098]: com.lni.aps.ApsException: Error
connecting to MQTT broker
May 27 10:07:07 raspberrypi start.sh[1098]: at
com.lni.aps.ahd.AhdMqttClient.connect(AhdMqttClient.java:152)
~[aps-1.0.6.jar!/:na]
May 27 10:07:07 raspberrypi start.sh[1098]: at
com.lni.hhh.service.hdata.aps.ApsService$ReconnectThread.run(ApsService.java
:287) ~[h3l-2.1.0-beta9.jar!/:na]
May 27 10:07:07 raspberrypi start.sh[1098]: Caused by:
org.eclipse.paho.client.mqttv3.MqttException: MqttException

The command line used to start wpa_supplicant is: /sbin/wpa_supplicant -u -s
-O /run/wpa_supplicant

wpa_supplicant config file:
country=GB
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

Barry Reinhold (mailto:reinholds at comcast.net)




From j at w1.fi  Sat May 28 02:38:50 2016
From: j at w1.fi (Jouni Malinen)
Date: Sat, 28 May 2016 12:38:50 +0300
Subject: [PATCH] [D-Bus][GroupStarted] Indicate whether created group is
 persistent or not.
In-Reply-To: <1464340991-3123-1-git-send-email-n.chaprana@samsung.com>
References: <1464340991-3123-1-git-send-email-n.chaprana@samsung.com>
Message-ID: <20160528093850.GA17582@w1.fi>

On Fri, May 27, 2016 at 02:53:11PM +0530, Nishant Chaprana wrote:
> This patch sends extra parameter in GroupStarted event to indicate
> whether created group is Persistent or not. It is similar to
> [PERSISTENT] tag which comes in P2P-GROUP-STARTED over CTRL interface.

This sounds fine..

> diff --git a/wpa_supplicant/dbus/dbus_new.c b/wpa_supplicant/dbus/dbus_new.c
> @@ -1300,6 +1300,8 @@ void wpas_dbus_signal_p2p_group_started(struct wpa_supplicant *wpa_s,
> +	    !wpa_dbus_dict_append_bool(&dict_iter, "persistent",
> +					 network_id ? 1 : 0) ||

.. but this does not do that correctly. network_id is the id of the
network block and it could at least in theory be 0 for the persistent
group parameters and it can certainly be non-zero for a non-persistent
group (if there are other network blocks in the configuration).

network_id is actually unused in the current
wpas_dbus_signal_p2p_group_started(). I think it should actually be
removed since it does not seem to be a very meaningful parameter or at
least not clearly defined (which network? the current ssid block for the
group or the persistent group storage?). The same seems to apply to the
ssid parameter..

In any case, for this new "persistent" parameter, the caller would need
to provide a new function parameter to get this information reliably
into the signal.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat May 28 03:12:15 2016
From: j at w1.fi (Jouni Malinen)
Date: Sat, 28 May 2016 13:12:15 +0300
Subject: [PATCH 1/9] tests: Support p2p group interfaces in hwsim remote
 tests
In-Reply-To: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
Message-ID: <20160528101215.GA30412@w1.fi>

On Thu, May 19, 2016 at 04:06:42PM +0300, Jonathan Afek wrote:
> Start using the wpa_supplicant remote udp interface for the
> control and monitor sockets for p2p group interfaces so
> that p2p tests would work on real hardware.
> Also have the group requests and events show in the test log
> with the hostname and the interface name of the group interface.

> diff --git a/tests/hwsim/wpasupplicant.py b/tests/hwsim/wpasupplicant.py
> @@ -755,7 +765,7 @@ class WpaSupplicant:
>              while True:
>                  while self.gctrl_mon.pending():
>                      ev = self.gctrl_mon.recv()
> -                    logger.debug(self.group_ifname + ": " + ev)
> +                    logger.debug(self.group_dbg + "(group): " + ev)

This breaks grpform_ext_listen_oper:

START grpform_ext_listen_oper 1/1
Traceback (most recent call last):
  File "/hostap/tests/hwsim/run-tests.py", line 451, in main
    t(dev)
  File "hostap/tests/hwsim/test_p2p_grpform.py", line 185, in test_grpform_ext_listen_oper
    _test_grpform_ext_listen_oper(dev)
  File "hostap/tests/hwsim/test_p2p_grpform.py", line 213, in _test_grpform_ext_listen_oper
    if "OK" not in wpas.group_request("STOP_AP"):
  File "hostap/tests/hwsim/wpasupplicant.py", line 166, in group_request
    logger.debug(self.group_dbg + ": CTRL(group): " + cmd)
AttributeError: WpaSupplicant instance has no attribute 'group_dbg'
Exception: WpaSupplicant instance has no attribute 'group_dbg'
FAIL grpform_ext_listen_oper 1.659165 2016-05-28 10:09:06.065236
failed tests: grpform_ext_listen_oper

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat May 28 04:27:42 2016
From: j at w1.fi (Jouni Malinen)
Date: Sat, 28 May 2016 14:27:42 +0300
Subject: [PATCH v2 2/9] tests: OTA 10 retries for broadcast connectivity
In-Reply-To: <1464087753-22583-1-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-2-git-send-email-jonathan@wizery.com>
 <1464087753-22583-1-git-send-email-jonathan@wizery.com>
Message-ID: <20160528112742.GA4426@w1.fi>

On Tue, May 24, 2016 at 02:02:33PM +0300, Jonathan Afek wrote:
> The regular hwsim tests use both unicast and broadcast frames to test
> the connectivity between 2 interfaces.
> For real hardware (remote hwsim tests) the broadcast frames will
> sometimes not be seen by all connected stations since they can be in
> low power mode during DTIM or because broadcast frames are not
> acked.
> Use 10 retries for broadcast connectivity tests for real hardware
> so that the test will pass if we successfully received 1 of them.

How was this tested?

> +        for i in xrange(broadcast_retry_c):

That gives i values 0..0 or 0..9 depending on local vs. remote.

> +            except Exception as e:
> +                if i == broadcast_retry_c:

i would never have value broadcast_retry_c here..

> +            except Exception as e:
> +                if i == broadcast_retry_c:
> +                    raise

Same here.

I'll fix this to use broadcast_retry_c - 1.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat May 28 06:49:22 2016
From: j at w1.fi (Jouni Malinen)
Date: Sat, 28 May 2016 16:49:22 +0300
Subject: wpa_supplicant not detecting loss of an association with AP
In-Reply-To: <063b01d1b892$09be2f90$1d3a8eb0$@comcast.net>
References: <063b01d1b892$09be2f90$1d3a8eb0$@comcast.net>
Message-ID: <20160528134922.GA29060@w1.fi>

On Fri, May 27, 2016 at 11:35:52PM -0400, Reinholds at comcast.net wrote:

> I am looking for suggestions as to how to further identify what is causing
> the problem, and suggestions for work arounds that will allow the Raspberry
> PI-3 to remain online.
> 
> The testing is being done using wpasupplicant 2.3, on a Raspberry PI-3
> running Raspian version 8 (Jessie) and Linux kernel 4.4.10-v7+
> 
> A segment of the journalctl output, starting at the detection of the lost
> carrier is below:

Would you be able to provide a wpa_supplicant debug log (-dt on the
command line) from such a case?

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sat May 28 07:13:49 2016
From: j at w1.fi (Jouni Malinen)
Date: Sat, 28 May 2016 17:13:49 +0300
Subject: [PATCH 3/9] tests: Use a function to add a log file to a remote
 host
In-Reply-To: <1463663210-15610-3-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
 <1463663210-15610-3-git-send-email-jonathan@wizery.com>
Message-ID: <20160528141349.GA3140@w1.fi>

Thanks, applied patches 2..9.

-- 
Jouni Malinen                                            PGP id EFC895FA


From jonathan at wizery.com  Sun May 29 04:59:09 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Sun, 29 May 2016 14:59:09 +0300
Subject: [PATCH 1/9] tests: Support p2p group interfaces in hwsim remote
 tests
In-Reply-To: <20160528101215.GA30412@w1.fi>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
 <20160528101215.GA30412@w1.fi>
Message-ID: <CAD8d0+2NXYrK_q5VDx9VTD2pyDsnJ3UwjSbHW1rj8jEq3JbwHw@mail.gmail.com>

On Sat, May 28, 2016 at 1:12 PM, Jouni Malinen <j at w1.fi> wrote:

> This breaks grpform_ext_listen_oper:
sending a fix patch


From jonathan at wizery.com  Sun May 29 05:03:40 2016
From: jonathan at wizery.com (Jonathan Afek)
Date: Sun, 29 May 2016 15:03:40 +0300
Subject: [PATCH v2 1/9] tests: Support P2P group interfaces in hwsim remote
 tests
In-Reply-To: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
Message-ID: <1464523420-25109-1-git-send-email-jonathan@wizery.com>

Start using the wpa_supplicant remote udp interface for the
control and monitor sockets for P2P group interfaces so
that p2p tests would work on real hardware.
Also have the group requests and events show in the test log
with the hostname and the interface name of the group interface.

Signed-off-by: Jonathan Afek <jonathanx.afek at intel.com>
---
 tests/hwsim/wpasupplicant.py | 29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/tests/hwsim/wpasupplicant.py b/tests/hwsim/wpasupplicant.py
index 77c84f8..9ec820e 100644
--- a/tests/hwsim/wpasupplicant.py
+++ b/tests/hwsim/wpasupplicant.py
@@ -23,6 +23,7 @@ class WpaSupplicant:
         self.group_ifname = None
         self.gctrl_mon = None
         self.host = remotehost.Host(hostname, ifname)
+        self._group_dbg = None
         if ifname:
             self.set_ifname(ifname, hostname, port)
             res = self.get_driver_status()
@@ -156,10 +157,26 @@ class WpaSupplicant:
             logger.debug(self.global_dbg + ifname + ": CTRL(global): " + cmd)
             return self.global_ctrl.request(cmd)
 
+    @property
+    def group_dbg(self):
+        if self._group_dbg is not None:
+            return self._group_dbg
+        if self.group_ifname is None:
+            raise Exception("can't have group_dbg without group_ifname")
+        if self.hostname is None:
+            self._group_dbg = self.group_ifname
+        else:
+            self._group_dbg = self.hostname + "/" + self.group_ifname
+        return self._group_dbg
+
     def group_request(self, cmd):
         if self.group_ifname and self.group_ifname != self.ifname:
-            logger.debug(self.group_ifname + ": CTRL: " + cmd)
-            gctrl = wpaspy.Ctrl(os.path.join(wpas_ctrl, self.group_ifname))
+            if self.hostname is None:
+                gctrl = wpaspy.Ctrl(os.path.join(wpas_ctrl, self.group_ifname))
+            else:
+                port = self.get_ctrl_iface_port(self.group_ifname)
+                gctrl = wpaspy.Ctrl(self.hostname, port)
+            logger.debug(self.group_dbg + ": CTRL(group): " + cmd)
             return gctrl.request(cmd)
         return self.request(cmd)
 
@@ -574,7 +591,11 @@ class WpaSupplicant:
         res['ifname'] = s[2]
         self.group_ifname = s[2]
         try:
-            self.gctrl_mon = wpaspy.Ctrl(os.path.join(wpas_ctrl, self.group_ifname))
+            if self.hostname is None:
+                self.gctrl_mon = wpaspy.Ctrl(os.path.join(wpas_ctrl, self.group_ifname))
+            else:
+                port = self.get_ctrl_iface_port(self.group_ifname)
+                self.gctrl_mon = wpaspy.Ctrl(self.hostname, port)
             self.gctrl_mon.attach()
         except:
             logger.debug("Could not open monitor socket for group interface")
@@ -755,7 +776,7 @@ class WpaSupplicant:
             while True:
                 while self.gctrl_mon.pending():
                     ev = self.gctrl_mon.recv()
-                    logger.debug(self.group_ifname + ": " + ev)
+                    logger.debug(self.group_dbg + "(group): " + ev)
                     for event in events:
                         if event in ev:
                             return ev
-- 
1.9.1



From n.chaprana at samsung.com  Sun May 29 22:51:22 2016
From: n.chaprana at samsung.com (Nishant Chaprana)
Date: Mon, 30 May 2016 11:21:22 +0530
Subject: [PATCHv2] [dbus interface][GroupStarted] Indicate whether created
 group is persistent or not.
In-Reply-To: <1464340991-3123-1-git-send-email-n.chaprana@samsung.com>
References: <1464340991-3123-1-git-send-email-n.chaprana@samsung.com>
Message-ID: <1464587482-15018-1-git-send-email-n.chaprana@samsung.com>

This patch sends extra parameter in GroupStarted event to indicate
whether created group is Persistent or not. It is similar to
[PERSISTENT] tag which comes in P2P-GROUP-STARTED over CTRL interface.

Signed-off-by: Nishant Chaprana <n.chaprana at samsung.com>
---
 wpa_supplicant/dbus/dbus_new.c  |  7 ++++---
 wpa_supplicant/notify.c         |  4 ++--
 wpa_supplicant/notify.h         |  2 +-
 wpa_supplicant/p2p_supplicant.c | 28 +++++++++++-----------------
 4 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/wpa_supplicant/dbus/dbus_new.c b/wpa_supplicant/dbus/dbus_new.c
index d894f6a..968f01f 100644
--- a/wpa_supplicant/dbus/dbus_new.c
+++ b/wpa_supplicant/dbus/dbus_new.c
@@ -1256,12 +1256,11 @@ static void peer_groups_changed(struct wpa_supplicant *wpa_s)
  * @wpa_s: %wpa_supplicant network interface data
  * @ssid: SSID object
  * @client: this device is P2P client
- * @network_id: network id of the group started, use instead of ssid->id
- *	to account for persistent groups
+ * @persistent: 0 - non persistent group, 1 - persistent group
  */
 void wpas_dbus_signal_p2p_group_started(struct wpa_supplicant *wpa_s,
 					const struct wpa_ssid *ssid,
-					int client, int network_id)
+					int client, int persistent)
 {
 	DBusMessage *msg;
 	DBusMessageIter iter, dict_iter;
@@ -1300,6 +1299,8 @@ void wpas_dbus_signal_p2p_group_started(struct wpa_supplicant *wpa_s,
 					      wpa_s->dbus_new_path) ||
 	    !wpa_dbus_dict_append_string(&dict_iter, "role",
 					 client ? "client" : "GO") ||
+	    !wpa_dbus_dict_append_bool(&dict_iter, "persistent",
+					 persistent ? 1 : 0) ||
 	    !wpa_dbus_dict_append_object_path(&dict_iter, "group_object",
 					      wpa_s->dbus_groupobj_path) ||
 	    !wpa_dbus_dict_close_write(&iter, &dict_iter)) {
diff --git a/wpa_supplicant/notify.c b/wpa_supplicant/notify.c
index e739363..9268e44 100644
--- a/wpa_supplicant/notify.c
+++ b/wpa_supplicant/notify.c
@@ -668,13 +668,13 @@ void wpas_notify_p2p_provision_discovery(struct wpa_supplicant *wpa_s,
 
 
 void wpas_notify_p2p_group_started(struct wpa_supplicant *wpa_s,
-				   struct wpa_ssid *ssid, int network_id,
+				   struct wpa_ssid *ssid, int persistent,
 				   int client)
 {
 	/* Notify a group has been started */
 	wpas_dbus_register_p2p_group(wpa_s, ssid);
 
-	wpas_dbus_signal_p2p_group_started(wpa_s, ssid, client, network_id);
+	wpas_dbus_signal_p2p_group_started(wpa_s, ssid, client, persistent);
 }
 
 
diff --git a/wpa_supplicant/notify.h b/wpa_supplicant/notify.h
index 1b7f04d..8cce0f3 100644
--- a/wpa_supplicant/notify.h
+++ b/wpa_supplicant/notify.h
@@ -113,7 +113,7 @@ void wpas_notify_p2p_provision_discovery(struct wpa_supplicant *wpa_s,
 					 u16 config_methods,
 					 unsigned int generated_pin);
 void wpas_notify_p2p_group_started(struct wpa_supplicant *wpa_s,
-				   struct wpa_ssid *ssid, int network_id,
+				   struct wpa_ssid *ssid, int persistent,
 				   int client);
 void wpas_notify_p2p_group_formation_failure(struct wpa_supplicant *wpa_s,
 					     const char *reason);
diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c
index 8f6acd6..decb9ce 100644
--- a/wpa_supplicant/p2p_supplicant.c
+++ b/wpa_supplicant/p2p_supplicant.c
@@ -1301,7 +1301,6 @@ static void wpas_group_formation_completed(struct wpa_supplicant *wpa_s,
 	int client;
 	int persistent;
 	u8 go_dev_addr[ETH_ALEN];
-	int network_id = -1;
 
 	/*
 	 * This callback is likely called for the main interface. Update wpa_s
@@ -1376,16 +1375,15 @@ static void wpas_group_formation_completed(struct wpa_supplicant *wpa_s,
 	}
 
 	if (persistent)
-		network_id = wpas_p2p_store_persistent_group(wpa_s->p2pdev,
-							     ssid, go_dev_addr);
+		wpas_p2p_store_persistent_group(wpa_s->p2pdev,
+						ssid, go_dev_addr);
 	else {
 		os_free(wpa_s->global->add_psk);
 		wpa_s->global->add_psk = NULL;
 	}
-	if (network_id < 0 && ssid)
-		network_id = ssid->id;
+
 	if (!client) {
-		wpas_notify_p2p_group_started(wpa_s, ssid, network_id, 0);
+		wpas_notify_p2p_group_started(wpa_s, ssid, persistent, 0);
 		os_get_reltime(&wpa_s->global->p2p_go_wait_client);
 	}
 }
@@ -1750,7 +1748,6 @@ static void p2p_go_configured(void *ctx, void *data)
 	struct wpa_supplicant *wpa_s = ctx;
 	struct p2p_go_neg_results *params = data;
 	struct wpa_ssid *ssid;
-	int network_id = -1;
 
 	wpa_s->ap_configured_cb = NULL;
 	wpa_s->ap_configured_cb_ctx = NULL;
@@ -1797,14 +1794,13 @@ static void p2p_go_configured(void *ctx, void *data)
 
 		os_get_reltime(&wpa_s->global->p2p_go_wait_client);
 		if (params->persistent_group) {
-			network_id = wpas_p2p_store_persistent_group(
+			wpas_p2p_store_persistent_group(
 				wpa_s->p2pdev, ssid,
 				wpa_s->global->p2p_dev_addr);
 			wpas_p2p_add_psk_list(wpa_s, ssid);
 		}
-		if (network_id < 0)
-			network_id = ssid->id;
-		wpas_notify_p2p_group_started(wpa_s, ssid, network_id, 0);
+
+		wpas_notify_p2p_group_started(wpa_s, ssid, params->persistent_group, 0);
 		wpas_p2p_cross_connect_setup(wpa_s);
 		wpas_p2p_set_group_idle_timeout(wpa_s);
 
@@ -6941,7 +6937,6 @@ void wpas_p2p_completed(struct wpa_supplicant *wpa_s)
 {
 	struct wpa_ssid *ssid = wpa_s->current_ssid;
 	u8 go_dev_addr[ETH_ALEN];
-	int network_id = -1;
 	int persistent;
 	int freq;
 	u8 ip[3 * 4];
@@ -7000,11 +6995,10 @@ void wpas_p2p_completed(struct wpa_supplicant *wpa_s)
 			       ip_addr);
 
 	if (persistent)
-		network_id = wpas_p2p_store_persistent_group(wpa_s->p2pdev,
-							     ssid, go_dev_addr);
-	if (network_id < 0)
-		network_id = ssid->id;
-	wpas_notify_p2p_group_started(wpa_s, ssid, network_id, 1);
+		wpas_p2p_store_persistent_group(wpa_s->p2pdev,
+						ssid, go_dev_addr);
+
+	wpas_notify_p2p_group_started(wpa_s, ssid, persistent, 1);
 }
 
 
-- 
1.9.1



From zajec5 at gmail.com  Sun May 29 23:53:13 2016
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Mon, 30 May 2016 08:53:13 +0200
Subject: [PATCH RFC] AP: Allow using existing interfaces for all BSS-es
Message-ID: <1464591193-13306-1-git-send-email-zajec5@gmail.com>

Some drivers (e.g. brcmfmac) may not support deleting virtual
interfaces. In such cases we can start AP interfaces once only. This can
be easily workarounded by allowing driver(s) to use all existing
interfaces.

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
Hi,

This patch allows me freely use BCM4366 with brcmfmac and multiple AP
interfaces. Unfortunately I don't know reason for having this limiration
in the first place. Do you know if my patch may break anything?
---
 src/ap/hostapd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/ap/hostapd.c b/src/ap/hostapd.c
index 42c1aaa..1974b2f 100644
--- a/src/ap/hostapd.c
+++ b/src/ap/hostapd.c
@@ -941,7 +941,7 @@ static int hostapd_setup_bss(struct hostapd_data *hapd, int first)
 				   conf->iface, addr, hapd,
 				   &hapd->drv_priv, force_ifname, if_addr,
 				   conf->bridge[0] ? conf->bridge : NULL,
-				   first == -1)) {
+				   true)) {
 			wpa_printf(MSG_ERROR, "Failed to add BSS (BSSID="
 				   MACSTR ")", MAC2STR(hapd->own_addr));
 			hapd->interface_added = 0;
-- 
1.8.4.5



From n.chaprana at samsung.com  Mon May 30 00:38:31 2016
From: n.chaprana at samsung.com (Nishant Chaprana)
Date: Mon, 30 May 2016 13:08:31 +0530
Subject: [PATCHv3] [dbus interface][GroupStarted] Indicate whether created
 group is persistent or not.
In-Reply-To: <1464587482-15018-1-git-send-email-n.chaprana@samsung.com>
References: <1464587482-15018-1-git-send-email-n.chaprana@samsung.com>
Message-ID: <1464593911-25735-1-git-send-email-n.chaprana@samsung.com>

This patch sends extra parameter in GroupStarted event to indicate
whether created group is Persistent or not. It is similar to
[PERSISTENT] tag which comes in P2P-GROUP-STARTED over CTRL interface.

Signed-off-by: Nishant Chaprana <n.chaprana at samsung.com>
---
 wpa_supplicant/dbus/dbus_new.c  |  7 ++++---
 wpa_supplicant/dbus/dbus_new.h  |  2 +-
 wpa_supplicant/notify.c         |  4 ++--
 wpa_supplicant/notify.h         |  2 +-
 wpa_supplicant/p2p_supplicant.c | 28 +++++++++++-----------------
 5 files changed, 19 insertions(+), 24 deletions(-)

diff --git a/wpa_supplicant/dbus/dbus_new.c b/wpa_supplicant/dbus/dbus_new.c
index d894f6a..968f01f 100644
--- a/wpa_supplicant/dbus/dbus_new.c
+++ b/wpa_supplicant/dbus/dbus_new.c
@@ -1256,12 +1256,11 @@ static void peer_groups_changed(struct wpa_supplicant *wpa_s)
  * @wpa_s: %wpa_supplicant network interface data
  * @ssid: SSID object
  * @client: this device is P2P client
- * @network_id: network id of the group started, use instead of ssid->id
- *	to account for persistent groups
+ * @persistent: 0 - non persistent group, 1 - persistent group
  */
 void wpas_dbus_signal_p2p_group_started(struct wpa_supplicant *wpa_s,
 					const struct wpa_ssid *ssid,
-					int client, int network_id)
+					int client, int persistent)
 {
 	DBusMessage *msg;
 	DBusMessageIter iter, dict_iter;
@@ -1300,6 +1299,8 @@ void wpas_dbus_signal_p2p_group_started(struct wpa_supplicant *wpa_s,
 					      wpa_s->dbus_new_path) ||
 	    !wpa_dbus_dict_append_string(&dict_iter, "role",
 					 client ? "client" : "GO") ||
+	    !wpa_dbus_dict_append_bool(&dict_iter, "persistent",
+					 persistent ? 1 : 0) ||
 	    !wpa_dbus_dict_append_object_path(&dict_iter, "group_object",
 					      wpa_s->dbus_groupobj_path) ||
 	    !wpa_dbus_dict_close_write(&iter, &dict_iter)) {
diff --git a/wpa_supplicant/dbus/dbus_new.h b/wpa_supplicant/dbus/dbus_new.h
index 3ac66db..74a4fff 100644
--- a/wpa_supplicant/dbus/dbus_new.h
+++ b/wpa_supplicant/dbus/dbus_new.h
@@ -191,7 +191,7 @@ void wpas_dbus_signal_p2p_go_neg_req(struct wpa_supplicant *wpa_s,
 				     u8 go_intent);
 void wpas_dbus_signal_p2p_group_started(struct wpa_supplicant *wpa_s,
 					const struct wpa_ssid *ssid,
-					int client, int network_id);
+					int client, int persistent);
 void wpas_dbus_signal_p2p_group_formation_failure(struct wpa_supplicant *wpa_s,
 						  const char *reason);
 void wpas_dbus_register_p2p_group(struct wpa_supplicant *wpa_s,
diff --git a/wpa_supplicant/notify.c b/wpa_supplicant/notify.c
index e739363..9268e44 100644
--- a/wpa_supplicant/notify.c
+++ b/wpa_supplicant/notify.c
@@ -668,13 +668,13 @@ void wpas_notify_p2p_provision_discovery(struct wpa_supplicant *wpa_s,
 
 
 void wpas_notify_p2p_group_started(struct wpa_supplicant *wpa_s,
-				   struct wpa_ssid *ssid, int network_id,
+				   struct wpa_ssid *ssid, int persistent,
 				   int client)
 {
 	/* Notify a group has been started */
 	wpas_dbus_register_p2p_group(wpa_s, ssid);
 
-	wpas_dbus_signal_p2p_group_started(wpa_s, ssid, client, network_id);
+	wpas_dbus_signal_p2p_group_started(wpa_s, ssid, client, persistent);
 }
 
 
diff --git a/wpa_supplicant/notify.h b/wpa_supplicant/notify.h
index 1b7f04d..8cce0f3 100644
--- a/wpa_supplicant/notify.h
+++ b/wpa_supplicant/notify.h
@@ -113,7 +113,7 @@ void wpas_notify_p2p_provision_discovery(struct wpa_supplicant *wpa_s,
 					 u16 config_methods,
 					 unsigned int generated_pin);
 void wpas_notify_p2p_group_started(struct wpa_supplicant *wpa_s,
-				   struct wpa_ssid *ssid, int network_id,
+				   struct wpa_ssid *ssid, int persistent,
 				   int client);
 void wpas_notify_p2p_group_formation_failure(struct wpa_supplicant *wpa_s,
 					     const char *reason);
diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c
index 8f6acd6..decb9ce 100644
--- a/wpa_supplicant/p2p_supplicant.c
+++ b/wpa_supplicant/p2p_supplicant.c
@@ -1301,7 +1301,6 @@ static void wpas_group_formation_completed(struct wpa_supplicant *wpa_s,
 	int client;
 	int persistent;
 	u8 go_dev_addr[ETH_ALEN];
-	int network_id = -1;
 
 	/*
 	 * This callback is likely called for the main interface. Update wpa_s
@@ -1376,16 +1375,15 @@ static void wpas_group_formation_completed(struct wpa_supplicant *wpa_s,
 	}
 
 	if (persistent)
-		network_id = wpas_p2p_store_persistent_group(wpa_s->p2pdev,
-							     ssid, go_dev_addr);
+		wpas_p2p_store_persistent_group(wpa_s->p2pdev,
+						ssid, go_dev_addr);
 	else {
 		os_free(wpa_s->global->add_psk);
 		wpa_s->global->add_psk = NULL;
 	}
-	if (network_id < 0 && ssid)
-		network_id = ssid->id;
+
 	if (!client) {
-		wpas_notify_p2p_group_started(wpa_s, ssid, network_id, 0);
+		wpas_notify_p2p_group_started(wpa_s, ssid, persistent, 0);
 		os_get_reltime(&wpa_s->global->p2p_go_wait_client);
 	}
 }
@@ -1750,7 +1748,6 @@ static void p2p_go_configured(void *ctx, void *data)
 	struct wpa_supplicant *wpa_s = ctx;
 	struct p2p_go_neg_results *params = data;
 	struct wpa_ssid *ssid;
-	int network_id = -1;
 
 	wpa_s->ap_configured_cb = NULL;
 	wpa_s->ap_configured_cb_ctx = NULL;
@@ -1797,14 +1794,13 @@ static void p2p_go_configured(void *ctx, void *data)
 
 		os_get_reltime(&wpa_s->global->p2p_go_wait_client);
 		if (params->persistent_group) {
-			network_id = wpas_p2p_store_persistent_group(
+			wpas_p2p_store_persistent_group(
 				wpa_s->p2pdev, ssid,
 				wpa_s->global->p2p_dev_addr);
 			wpas_p2p_add_psk_list(wpa_s, ssid);
 		}
-		if (network_id < 0)
-			network_id = ssid->id;
-		wpas_notify_p2p_group_started(wpa_s, ssid, network_id, 0);
+
+		wpas_notify_p2p_group_started(wpa_s, ssid, params->persistent_group, 0);
 		wpas_p2p_cross_connect_setup(wpa_s);
 		wpas_p2p_set_group_idle_timeout(wpa_s);
 
@@ -6941,7 +6937,6 @@ void wpas_p2p_completed(struct wpa_supplicant *wpa_s)
 {
 	struct wpa_ssid *ssid = wpa_s->current_ssid;
 	u8 go_dev_addr[ETH_ALEN];
-	int network_id = -1;
 	int persistent;
 	int freq;
 	u8 ip[3 * 4];
@@ -7000,11 +6995,10 @@ void wpas_p2p_completed(struct wpa_supplicant *wpa_s)
 			       ip_addr);
 
 	if (persistent)
-		network_id = wpas_p2p_store_persistent_group(wpa_s->p2pdev,
-							     ssid, go_dev_addr);
-	if (network_id < 0)
-		network_id = ssid->id;
-	wpas_notify_p2p_group_started(wpa_s, ssid, network_id, 1);
+		wpas_p2p_store_persistent_group(wpa_s->p2pdev,
+						ssid, go_dev_addr);
+
+	wpas_notify_p2p_group_started(wpa_s, ssid, persistent, 1);
 }
 
 
-- 
1.9.1



From j at w1.fi  Mon May 30 07:50:48 2016
From: j at w1.fi (Jouni Malinen)
Date: Mon, 30 May 2016 17:50:48 +0300
Subject: [PATCH RFC] AP: Allow using existing interfaces for all BSS-es
In-Reply-To: <1464591193-13306-1-git-send-email-zajec5@gmail.com>
References: <1464591193-13306-1-git-send-email-zajec5@gmail.com>
Message-ID: <20160530145048.GA7507@w1.fi>

On Mon, May 30, 2016 at 08:53:13AM +0200, Rafa? Mi?ecki wrote:
> Some drivers (e.g. brcmfmac) may not support deleting virtual
> interfaces. In such cases we can start AP interfaces once only. This can
> be easily workarounded by allowing driver(s) to use all existing
> interfaces.

> This patch allows me freely use BCM4366 with brcmfmac and multiple AP
> interfaces. Unfortunately I don't know reason for having this limiration
> in the first place. Do you know if my patch may break anything?

This would leave hapd->interface_added == 1 even for interfaces that
were not added by hostapd. hostapd_free_hapd_data() would then try to
remove this interface which would apparently fail with this driver.

> diff --git a/src/ap/hostapd.c b/src/ap/hostapd.c
> @@ -941,7 +941,7 @@ static int hostapd_setup_bss(struct hostapd_data *hapd, int first)
>  				   conf->iface, addr, hapd,
>  				   &hapd->drv_priv, force_ifname, if_addr,
>  				   conf->bridge[0] ? conf->bridge : NULL,
> -				   first == -1)) {
> +				   true)) {
>  			wpa_printf(MSG_ERROR, "Failed to add BSS (BSSID="
>  				   MACSTR ")", MAC2STR(hapd->own_addr));
>  			hapd->interface_added = 0;

Maybe this should first try first == -1 and if that fails, try with
use_existing parameter value 1 ("true" is not used within most places of
hostapd yet) and if that succeeds, allow operation to continue but with
hapd->interface_added = 0.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Mon May 30 08:40:00 2016
From: j at w1.fi (Jouni Malinen)
Date: Mon, 30 May 2016 18:40:00 +0300
Subject: [PATCH v2 1/9] tests: Support P2P group interfaces in hwsim
 remote tests
In-Reply-To: <1464523420-25109-1-git-send-email-jonathan@wizery.com>
References: <1463663210-15610-1-git-send-email-jonathan@wizery.com>
 <1464523420-25109-1-git-send-email-jonathan@wizery.com>
Message-ID: <20160530154000.GA2543@w1.fi>

On Sun, May 29, 2016 at 03:03:40PM +0300, Jonathan Afek wrote:
> Start using the wpa_supplicant remote udp interface for the
> control and monitor sockets for P2P group interfaces so
> that p2p tests would work on real hardware.
> Also have the group requests and events show in the test log
> with the hostname and the interface name of the group interface.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Mon May 30 08:40:25 2016
From: j at w1.fi (Jouni Malinen)
Date: Mon, 30 May 2016 18:40:25 +0300
Subject: [PATCHv3] [dbus interface][GroupStarted] Indicate whether
 created group is persistent or not.
In-Reply-To: <1464593911-25735-1-git-send-email-n.chaprana@samsung.com>
References: <1464587482-15018-1-git-send-email-n.chaprana@samsung.com>
 <1464593911-25735-1-git-send-email-n.chaprana@samsung.com>
Message-ID: <20160530154025.GB2543@w1.fi>

On Mon, May 30, 2016 at 01:08:31PM +0530, Nishant Chaprana wrote:
> This patch sends extra parameter in GroupStarted event to indicate
> whether created group is Persistent or not. It is similar to
> [PERSISTENT] tag which comes in P2P-GROUP-STARTED over CTRL interface.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From misch at google.com  Mon May 30 10:19:40 2016
From: misch at google.com (Michael Schaller)
Date: Mon, 30 May 2016 19:19:40 +0200
Subject: Bug with OpenSSL engine initialization in
 tls_engine_load_dynamic_generic
Message-ID: <CALt099LSCurvfzNXxt1Ro+rvHpaYfN_k=nmYxCQ+DFYrtwAA6A@mail.gmail.com>

Hi everyone,

The first ENGINE_by_id call (line 730) in
tls_engine_load_dynamic_generic is used to check if a certain OpenSSL
engine is already loaded:
https://w1.fi/cgit/hostap/tree/src/crypto/tls_openssl.c#n730

This ENGINE_by_id call has a side effect though that it automatically
loads that engine with the default options if the shared object of
that engine can be found by openssl. This means that if the autoload
succeeds then this check will always be true and hence this engine
can't ever be loaded with the specific options for WPA supplicant as
specified in the configuration.

The autoload code in OpenSSL was introduced in 2002 with this commit:
https://github.com/openssl/openssl/commit/aae329c447025eb87dab294d909f9fbc48f7174c

I'm not sure what's the best way to fix this issue but you'll find a
patch proposal in the end that iterates over the available engines
instead of using ENGINE_by_id to avoid the engine autoload.

Best,

Michael Schaller



Proposed patch:

--- ./src/crypto/tls_openssl.c.old 2016-05-30 13:35:15.341868226 +0000
+++ ./src/crypto/tls_openssl.c 2016-05-30 16:56:29.880912599 +0000
@@ -617,7 +617,14 @@
  ENGINE *engine;
  const char *dynamic_id = "dynamic";

- engine = ENGINE_by_id(id);
+ /*
+ * Check if engine is already loaded. This intentionally doesn't use
+ * ENGINE_by_id as this would autoload an engine if it isn't loaded yet.
+ */
+ for (engine = ENGINE_get_first(); engine; engine = ENGINE_get_next(engine)) {
+ if(!strcmp(id, ENGINE_get_id(engine)))
+ break;
+ }
  if (engine) {
  ENGINE_free(engine);
  wpa_printf(MSG_DEBUG, "ENGINE: engine '%s' is already "


From zajec5 at gmail.com  Tue May 31 23:33:54 2016
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Wed,  1 Jun 2016 08:33:54 +0200
Subject: [PATCH] AP: Allow using existing interfaces as a fallback
In-Reply-To: <1464591193-13306-1-git-send-email-zajec5@gmail.com>
References: <1464591193-13306-1-git-send-email-zajec5@gmail.com>
Message-ID: <1464762834-26321-1-git-send-email-zajec5@gmail.com>

Some drivers (e.g. brcmfmac) may not support deleting virtual
interfaces. In such cases we can start AP interfaces once only. On next
tries be should try to use existing interfaces as a fallback.

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
 src/ap/hostapd.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/src/ap/hostapd.c b/src/ap/hostapd.c
index 42c1aaa..4e0de0c 100644
--- a/src/ap/hostapd.c
+++ b/src/ap/hostapd.c
@@ -936,16 +936,24 @@ static int hostapd_setup_bss(struct hostapd_data *hapd, int first)
 			} while (mac_in_conf(hapd->iconf, hapd->own_addr));
 		}
 
-		hapd->interface_added = 1;
 		if (hostapd_if_add(hapd->iface->bss[0], WPA_IF_AP_BSS,
 				   conf->iface, addr, hapd,
 				   &hapd->drv_priv, force_ifname, if_addr,
 				   conf->bridge[0] ? conf->bridge : NULL,
 				   first == -1)) {
-			wpa_printf(MSG_ERROR, "Failed to add BSS (BSSID="
-				   MACSTR ")", MAC2STR(hapd->own_addr));
-			hapd->interface_added = 0;
-			return -1;
+			/* Try to use existing interface */
+			if (hostapd_if_add(hapd->iface->bss[0], WPA_IF_AP_BSS,
+					   conf->iface, hapd->own_addr, hapd,
+					   &hapd->drv_priv, force_ifname,
+					   if_addr,
+					   conf->bridge[0] ? conf->bridge : NULL,
+					   1)) {
+				wpa_printf(MSG_ERROR, "Failed to add BSS (BSSID="
+					   MACSTR ")", MAC2STR(hapd->own_addr));
+				return -1;
+			}
+		} else {
+			hapd->interface_added = 1;
 		}
 
 		if (!addr)
-- 
1.8.4.5



