From owner-svn-src-all@freebsd.org Fri Jul 20 01:27:54 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 AE22D1029D36; Fri, 20 Jul 2018 01:27:54 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E62D854D2; Fri, 20 Jul 2018 01:27:54 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id EF149AD04; Fri, 20 Jul 2018 01:27:53 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f44.google.com with SMTP id b22-v6so652961lfa.3; Thu, 19 Jul 2018 18:27:53 -0700 (PDT) X-Gm-Message-State: AOUpUlEhb5nSzbnmYHOTdbxebqB0GyK0dBXONqqCzar0j82h+ucKaIT7 u5BiI4J1OQdp1c8o0gGj2cvx/0BfhRNZDNb3Fvc= X-Google-Smtp-Source: AAOMgpdHa2KJtMr9c61U3Uzn49/UwuIUQddztyYC6S/U/JZlysRoqfHrOh+mqzqzY1QIdzWHrCfArQ49ER0sSfcDSCw= X-Received: by 2002:a19:9481:: with SMTP id o1-v6mr22915lfk.38.1532050072415; Thu, 19 Jul 2018 18:27:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 18:27:31 -0700 (PDT) In-Reply-To: <201807200057.w6K0vqV9055341@slippy.cwsent.com> References: <201807200057.w6K0vqV9055341@slippy.cwsent.com> From: Kyle Evans Date: Thu, 19 Jul 2018 20:27:31 -0500 X-Gmail-Original-Message-ID: Message-ID: 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... To: Cy Schubert Cc: Shawn Webb , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org, Cy Schubert , "Oleg V. Nauman" Content-Type: text/plain; charset="UTF-8" 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: Fri, 20 Jul 2018 01:27:55 -0000 On Thu, Jul 19, 2018 at 7:57 PM, Cy Schubert wrote: > In message il.com> > , Kyle Evans writes: >> On Thu, Jul 19, 2018 at 7:32 PM, Shawn Webb wrot >> e: >> > On Thu, Jul 19, 2018 at 07:24:46PM -0500, Kyle Evans wrote: >> >> On Thu, Jul 19, 2018 at 6:21 PM, Kyle Evans wrote: >> >> > On Thu, Jul 19, 2018 at 4:33 PM, Cy Schubert >> wrote: >> >> >> In message <201807192114.w6JLEapA097589@slippy.cwsent.com>, Cy Schubert >> >> >> writes: >> >> >>> In message <17042686.Mc0X0P6XHu@asus.theweb.org.ua>, "Oleg V. Nauman" >> >> >>> writes: >> >> >>> > On Thursday, July 19, 2018 4:54:42 PM EEST Cy Schubert wrote: >> >> >>> > > In message > il.gma >> >> >>> > > 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, a >> pologie >> >> >>> s >> >> >>> > > > > 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 > bsd.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 noti >> ced tha >> >> >>> t >> >> >>> > > > >>>> wi-fi connection periodically breaks. /etc/rc.d/wpa_supplic >> ant >> >> >>> > > > >>>> restart >> >> >>> > > > >>>> wlan0 helps. After your message I reinstalled wpa_supplican >> t from >> >> >>> ol >> >> >>> > d >> >> >>> > > > >>>> 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 ev >> ents, a >> >> >>> nd >> >> >>> > > > >> further testing shows that I don't actually notice these disc >> onnects >> >> >>> > > > >> most of the time because it reassociates fast enough. I notic >> ed it t >> >> >>> he >> >> >>> > > > >> first time because apparently I had both SSIDs from my AP unc >> ommente >> >> >>> d >> >> >>> > > > >> in my wpa_supplicant.conf and it decided at that point to con >> nect 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 s >> ingle >> >> >>> > > > >> time. >> >> >>> > > > > >> >> >>> > > > > Hi! >> >> >>> > > > > I have the exact same problem as Andrey, with the same driver. >> I've >> >> >>> no >> >> >>> > t >> >> >>> > > > > investigated very much, but when using the 2.8 wpa_supplicant >> the wif >> >> >>> i >> >> >>> > > > > network dies after a little while, and I have to restart it (u >> sually >> >> >>> > > > > with >> >> >>> > > > > /etc/rc.d/netif restart). Then it works for a little while, b >> efore >> >> >>> > > > > going >> >> >>> > > > > down again. With the old wpa_supplicant I didn't have this pr >> oblem. >> >> >>> > > > > >> >> >>> > > > > I don't have very much else to add except noting that I'm affe >> cted as >> >> >>> > > > > well. >> >> >>> > > > > I haven't had time to debug it properly (which is why I've nev >> er >> >> >>> > > > > reported >> >> >>> > > > > it) >> >> >>> > > > >> >> >>> > > > I plan on trying out the latest from upstream beyond the patch C >> y 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 netw >> orks >> >> >>> > > 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 ever >> y 30 >> >> >>> > > minutes using our old wpa 2.5, requiring a netif restart. 2.6 reso >> lved >> >> >>> > > that issue. >> >> >>> > > >> >> >>> > > Upline git commit 0adc9b28b39d414d5febfff752f6a1576f785c85 also lo >> oks >> >> >>> > > 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 t >> o >> >> >>> > > 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 PTKSTAR >> T >> >> >>> > > 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 >> wireles >> >> >>> s >> >> >>> > connection can not negotiate DHCP requests, possibly due to fact tha >> t 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. >> >> >>> >> >> >>> I've imported all the patches in the port, from our upline into base. >> >> >>> Some were already committed to >> >> >>> -- >> >> >>> Cheers, >> >> >>> Cy Schubert >> >> >>> FreeBSD UNIX: Web: http://www.FreeBSD.org >> >> >>> >> >> >>> The need of the many outweighs the greed of the few. >> >> >>> base 2.5 others not. This should bring base up to par with the port, >> >> >>> address the remaining security issues, and probably fix this thread to >> o. >> >> >> >> >> >> exmh. I had my cursor in the wrong place when I hit send. >> >> >> >> >> >> I've imported all the patches in the port, from our upline into base. >> >> >> Some were already committed to base 2.5 others not. This should bring >> >> >> base up to par with the port, address the remaining security issues, >> >> >> and probably fix this thread too. >> >> >> >> >> > >> >> > FWIW- with ports 2.6 I've confirmed that instead of the reassociation I >> get: >> >> > >> >> > Jul 19 18:17:30 shiva wpa_supplicant[34199]: wlan0: WPA: Group >> >> > rekeying completed with ... [GTK=CCMP] >> >> > >> >> > I'll try with base 2.6 now that you've updated with all of these patches >> . >> >> >> >> Alright, base 2.6 is still no good here. I note that there's still >> >> some diff between ports and base [1] (about 252 lines of diff to sort >> >> through, nothing serious... I removed the obviously-for-libressl >> >> diff). >> >> >> >> Some of it looks kind of suspicious, but I'd guess the changes in >> >> ./src/rsn_supp/wpa.c are mostly what make the difference for me. How >> >> much of this really needs to stick around, given that ports >> >> wpa_supplicant is actually pretty stable? >> > >> > (Attempting to read between the lines, forgive me if I >> > misinterpreted.) >> >> Sorry, I seem to have missed a word there. I meant "How much of this >> [diff] really needs to stick around, given that ports wpa_supplicant >> is actually pretty stable?" -- we've had a couple reports of >> improvements from the 2.6 in ports, so I wonder if some of our local >> diffs should have gone away with the 2.6 update but we didn't quite >> get there. >> >> > Some of the systems I've set up recently are more easily set up with >> > wireless. Running a 100ft cable in an office building isn't that fun. >> > >> >> Ahh, indeed- at $work we have tons of those, with 2ft thick concrete >> walls sprinkled conservatively and legacy wire runs -everywhere-, and >> not necessarily with drop ceilings or conduit... ugh. > > I'm on a $work issue right now. I'll get back to this in an hour. > FWIW- extracting the src/rsn_supp/wpa.c diff from the aforementioned diff between ports 2.6 and base 2.6 and doing a patch -R of that on the base 2.6 fixes my problem, at least.