svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers c...

[Oleg V. Nauman]

On Thursday, July 19, 2018 4:54:42 PM EEST Cy Schubert wrote:
> In message <CACNAnaEaMtRfHTXyCcGGmVP_37=gjLfDjPD5yd1gZqmpC0Z0Rg at mail.gma
> il.com>
> 
> , Kyle Evans writes:
> > On Thu, Jul 19, 2018 at 7:13 AM, Niclas Zeising
> > 
> > <zeising+freebsd at daemonic.se> wrote:
> > > [ sending this again since I missed the list the first time, apologies
> > > if
> > > anyone receives a duplicate ]
> > > 
> > > On 07/19/18 13:57, Kyle Evans wrote:
> > >> On Thu, Jul 19, 2018 at 4:51 AM, Alexey Dokuchaev <danfe at freebsd.org>
> > >> 
> > >> wrote:
> > >>> On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsukov wrote:
> > >>>> ...
> > >>>> Yesterday I updated my notebook (with iwm(4)) and also noticed that
> > >>>> wi-fi connection periodically breaks. /etc/rc.d/wpa_supplicant
> > >>>> restart
> > >>>> wlan0 helps. After your message I reinstalled wpa_supplicant from old
> > >>>> source and now it works stable already about 2 hours.
> > >>> 
> > >>> So, right now, we have broken wpa_supplicant(8) in -CURRENT? :-/
> > >> 
> > >> Well, "broken". It's incredibly stable outside of rekeying events, and
> > >> further testing shows that I don't actually notice these disconnects
> > >> most of the time because it reassociates fast enough. I noticed it the
> > >> first time because apparently I had both SSIDs from my AP uncommented
> > >> in my wpa_supplicant.conf and it decided at that point to connect to
> > >> the other one, which took a little longer.
> > >> 
> > >> Contrary to Andrey's report, though, I don't have to kick
> > >> wpa_supplicant at all. It will reassociate on its own every single
> > >> time.
> > > 
> > > Hi!
> > > I have the exact same problem as Andrey, with the same driver.  I've not
> > > investigated very much, but when using the 2.8 wpa_supplicant the wifi
> > > network dies after a little while, and I have to restart it (usually
> > > with
> > > /etc/rc.d/netif restart).  Then it works for a little while, before
> > > going
> > > down again.  With the old wpa_supplicant I didn't have this problem.
> > > 
> > > I don't have very much else to add except noting that I'm affected as
> > > well.
> > > I haven't had time to debug it properly (which is why I've never
> > > reported
> > > it)
> > 
> > I plan on trying out the latest from upstream beyond the patch Cy sent
> > along earlier to see if it's perhaps been addressed elsewhere in the
> > past two years since this release was made.
> 
> A point of reference. I've had no issues here with any of the networks
> I use. All the networks I use are either WPA-PSK or open. The last
> WPA-EAP I used was at former $JOB a few years ago. However, at the Link
> Lounge just outside where $JOB is at my wifi would disconnect every 30
> minutes using our old wpa 2.5, requiring a netif restart. 2.6 resolved
> that issue.
> 
> Upline git commit 0adc9b28b39d414d5febfff752f6a1576f785c85 also looks
> interesting.
> 
> ommit 0adc9b28b39d414d5febfff752f6a1576f785c85
> Author: Jouni Malinen <j at w1.fi>
> Date:   Sun Oct 1 12:32:57 2017 +0300
> 
>     Fix PTK rekeying to generate a new ANonce
> 
>     The Authenticator state machine path for PTK rekeying ended up
> bypassing
>     the AUTHENTICATION2 state where a new ANonce is generated when going
>     directly to the PTKSTART state since there is no need to try to
>     determine the PMK again in such a case. This is far from ideal
> since the
>     new PTK would depend on a new nonce only from the supplicant.
> 
>     Fix this by generating a new ANonce when moving to the PTKSTART
> state
>     for the purpose of starting new 4-way handshake to rekey PTK.
> 
>     Signed-off-by: Jouni Malinen <j at w1.fi>
> 
> 
> I suspect a timeout because reason=1 in Kyle's log.


 I have two systems experienced wifi connection issues after recent HEAD 
update.
 Both of them experiencing frequent up/down wlan0 events on boot so wireless 
connection can not negotiate DHCP requests, possibly due to fact that both 
connecting to the same AP.
 AP capabilities list:

*****   f8:1a:67:56:16:16    1   54M  -74:-96   100 EPS  WPA WME ATH WPS

Interesting enough that switching wpa_supplicant to version 2.6 from ports 
fixes that issue completely.

Hopefully it helps.

 Thank you.