From owner-svn-src-head@freebsd.org Thu Jul 19 14:29:21 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F683103C413 for ; Thu, 19 Jul 2018 14:29:21 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from ns.it.odessa.ua (ns.it.odessa.ua [195.128.182.40]) by mx1.freebsd.org (Postfix) with ESMTP id B10E893CB0; Thu, 19 Jul 2018 14:29:20 +0000 (UTC) (envelope-from oleg@theweb.org.ua) Received: from ns.it.odessa.ua (localhost [127.0.0.1]) by ns.it.odessa.ua (Sendmail) with ESMTP id 1C3107CB54C; Thu, 19 Jul 2018 17:29:20 +0300 (EEST) X-Virus-Scanned: amavisd-new at it.odessa.ua Received: from ns.it.odessa.ua ([127.0.0.1]) by ns.it.odessa.ua (ns.it.odessa.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUBTCIKwBOae; Thu, 19 Jul 2018 17:29:19 +0300 (EEST) Received: from asus.theweb.org.ua (unknown [10.133.23.176]) by ns.it.odessa.ua (Sendmail) with SMTP id 5B5087CB432; Thu, 19 Jul 2018 17:29:19 +0300 (EEST) Received: from asus.theweb.org.ua (localhost [127.0.0.1]) by asus.theweb.org.ua (8.15.2/8.15.2) with ESMTPS id w6JEQd8h021829 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Jul 2018 17:26:39 +0300 (EEST) (envelope-from oleg@theweb.org.ua) Received: (from oleg@localhost) by asus.theweb.org.ua (8.15.2/8.15.2/Submit) id w6JEQcUP021828; Thu, 19 Jul 2018 17:26:38 +0300 (EEST) (envelope-from oleg@theweb.org.ua) X-Authentication-Warning: asus.theweb.org.ua: oleg set sender to oleg@theweb.org.ua using -f From: "Oleg V. Nauman" To: svn-src-all@freebsd.org, Cy Schubert Cc: src-committers , svn-src-head@freebsd.org, Cy Schubert Subject: Re: 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... Date: Thu, 19 Jul 2018 17:26:38 +0300 Message-ID: <17042686.Mc0X0P6XHu@asus.theweb.org.ua> Organization: Private person In-Reply-To: <201807191354.w6JDsgo7034009@slippy.cwsent.com> References: <201807191354.w6JDsgo7034009@slippy.cwsent.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:29:21 -0000 On Thursday, July 19, 2018 4:54:42 PM EEST Cy Schubert wrote: > In message il.com> > > , Kyle Evans writes: > > On Thu, Jul 19, 2018 at 7:13 AM, Niclas Zeising > > > > 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 > > >> > > >> 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 > 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 > > > 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.