From owner-svn-src-all@freebsd.org Thu Jul 19 13:54:46 2018 Return-Path: Delivered-To: svn-src-all@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 9A01E103ACC9; Thu, 19 Jul 2018 13:54:46 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B6D3792816; Thu, 19 Jul 2018 13:54:45 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id g9OFfLZnXWppDg9OGfrodi; Thu, 19 Jul 2018 07:54:44 -0600 X-Authority-Analysis: v=2.3 cv=YIcrNiOx c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=R9QF1RCXAYgA:10 a=xfDLHkLGAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=FIMBM9iY4BZSq5QqqwYA:9 a=CjuIK1q_8ugA:10 a=IfaqVvZgccqrtc8gcwf2:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id DE76DB00; Thu, 19 Jul 2018 06:54:42 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w6JDsgHI034012; Thu, 19 Jul 2018 06:54:42 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w6JDsgo7034009; Thu, 19 Jul 2018 06:54:42 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201807191354.w6JDsgo7034009@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Kyle Evans cc: Niclas Zeising , Alexey Dokuchaev , svn-src-head@freebsd.org, svn-src-all@freebsd.org, "Andrey V. Elsukov" , src-committers , 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... In-Reply-To: Message from Kyle Evans of "Thu, 19 Jul 2018 08:25:49 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Jul 2018 06:54:42 -0700 X-CMAE-Envelope: MS4wfB+QS6T0SKAt5Ro2r2EqUtMR+aKE4p8yoiyc1FKSrgkn2jaJNxpt5x87erwShSNRQEW5CSlyc5afMnEAzWqQYPS/KVrfw8sZ2tKFl7us1h2bfU1rBLvF aLrlAbf6D0F/7iIWli8YWJ0wHTq2ubLsOZRi2AG4egzkL6IqPiGTevDchQRi2Z19ZASod7MZVCmkauE0NCCZk14S0enkC3e0NYL05bgWwTWhR7aMvnXFNEsu fnWZIZDhillBvVbM/Q1zMP9+sbEm/FWZTe7dpxd7TU8nV+zMvSHmWJRGY2uFMN3AnY2dkm134RajQsgSsZ5pKFUpC1nM+3Xt1wDXo5IfR58K89n3jy1pzCOb 3FOXJ2vz8g1+HCQ7gE0UUdI7zLf3fQ== X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 13:54:46 -0000 In message , 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. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.