wpa_supplicant 2.3 and AP band steering / WEXT being used

[Bjørn Villa]

Yes, using WEXT - so I am sure you are correct that this is the problem. Not
sure why I expected the driver to become directly accessible from
wpa_supplicant, I am sorry about my ignorance in this matter. I guess I
should rather look for another WiFi USB stick with AC support and a driver
supporting nl80211 - instead of waiting for the rtl8812au driver to be
changed. If anyone has a suggestion, it is most welcome. 

Thank you for the response - most appreciated



Message: 2
Date: Wed, 19 Nov 2014 14:14:55 +0200
From: Jouni Malinen <j at w1.fi>
Subject: Re: wpa_supplicant 2.3 and AP band steering
To: hostap at lists.shmoo.com
Message-ID: <20141119121455.GA5305 at w1.fi>
Content-Type: text/plain; charset=utf-8

On Wed, Nov 19, 2014 at 12:45:37PM +0100, Bj?rn Villa wrote:
> I am using a linux driver for the D-Link DWA-171 device
> (https://github.com/gnab/rtl8812au) and I am experiencing problems 
> with that my client (a Raspberry PI) ignores part of my 
> wpa_supplicant.conf file. In particular, it is the scan_freq and 
> freq_list parts which not are working as expected. The problem is that 
> the access points force my client to connect on 5Ghz (band steering). The
same problem was present on wpa_supplicant 2.2.
> However, if I use a WiFi device which can utilize the nl80211 driver, 
> it works perfect.

Which driver interface does that driver use? WEXT? If so, specifying
frequencies for scanning is not supported by the interface.. In other words,
that driver would likely need to be replaced or extended to support nl80211
(well, assuming the device itself supports frequency lists for scans).

-- 
Jouni Malinen                                            PGP id EFC895FA


------------------------------

Message: 3
Date: Wed, 19 Nov 2014 18:29:14 +0200
From: Jouni Malinen <j at w1.fi>
Subject: Re: [PATCH] AP: Drop retransmitted auth/assoc frames
To: hostap at lists.shmoo.com
Message-ID: <20141119162914.GA3578 at w1.fi>
Content-Type: text/plain; charset=us-ascii

On Wed, Nov 19, 2014 at 11:16:35AM +0000, Peer, Ilan wrote:
> Minor comment below. Did not get a chance to test it myself.

Thanks, applied.

> I was concerned about case where the station for some reason does not
complete the association flow and decides to authenticate again, but this is
probably a rare corner case.

That would require a correctly behaving station to transmit 4095 frames
between the two Authentication frames to get the same sequence number again
and then fail to get the first TX attempt through to get Retry=1..
So yes, I think we can safely consider this to be unlikely enough even if a
STA were to misbehave. There would also be clear recovery mechanism by the
STA likely retrying authentication if no response is received.

> > +	/* Last Authentication/(Re)Association Request frame seuence
> > control */
> > +	u16 last_seq_ctrl;
> > +	/* Last Authentication/(Re)Association Request frame subtype */
> 
> Add to the documentation public action frames.

It is more than Public Action frames.. Added Action frame here.

-- 
Jouni Malinen                                            PGP id EFC895FA


------------------------------

Message: 4
Date: Wed, 19 Nov 2014 17:39:07 +0100
From: Helmut Schaa <helmut.schaa at googlemail.com>
Subject: Re: openvswitch and hostap?
To: James Harper <james at ejbdigital.com.au>
Cc: "hostap at lists.shmoo.com" <hostap at lists.shmoo.com>
Message-ID:
	<CAGXE3d9XDAtOia5m1sgOa0jfhPnRimzeuX7w3thfwZ2ndTLsGA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Sat, Nov 15, 2014 at 2:28 AM, James Harper <james at ejbdigital.com.au>
wrote:
> I just threw this patch together. It runs the 'ovs-vsctl port-to-br'
command to determine the name of the bridge, falling back to the old bridge
detection method if that fails.
>
> It could be further developed to also add and remove the interface etc,
but that's not really the way openvswitch works - interfaces are sticky wrt
bridge membership and you don't need to re-add them each boot etc.
>
> Another option would be to add a config parameter that says "don't do any
bridge configuration".

Main problem is that if the wlanX interface is bridged hostapd needs access
for grabbing EAPOL frames off from the bridge device.
So it needs to know the bridge interface.

I'm using this one but did not consider sending it upstream as it is quite a
hack:
https://github.com/hschaa/hostapd/commit/c89daaeca4ee90c8bc158e37acb1b679c82
3d7ab

Helmut


------------------------------

_______________________________________________
HostAP mailing list
HostAP at lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap


End of HostAP Digest, Vol 139, Issue 32
***************************************