Date: Thu, 19 Jul 2018 19:24:46 -0500 From: Kyle Evans <kevans@freebsd.org> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, "Oleg V. Nauman" <oleg@theweb.org.ua>, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org>, svn-src-head@freebsd.org, Cy Schubert <cy@freebsd.org> 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... Message-ID: <CACNAnaHFyB5FdWVpd3jOa5rpDtBdEm3Z0%2Bsx6jb_nXj8mQ5=CQ@mail.gmail.com> In-Reply-To: <CACNAnaHqg%2BaE7xyeq30egw5sEWYrcsF9T4hv=U7Qmh38jXcFwQ@mail.gmail.com> References: <Cy.Schubert@cschubert.com> <201807192114.w6JLEapA097589@slippy.cwsent.com> <201807192133.w6JLXRX4066519@slippy.cwsent.com> <CACNAnaHqg%2BaE7xyeq30egw5sEWYrcsF9T4hv=U7Qmh38jXcFwQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 19, 2018 at 6:21 PM, Kyle Evans <kevans@freebsd.org> wrote: > On Thu, Jul 19, 2018 at 4:33 PM, Cy Schubert <Cy.Schubert@cschubert.com> 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 <CACNAnaEaMtRfHTXyCcGGmVP_37=gjLfDjPD5yd1gZqmpC0Z0Rg@mail.gma >>> > > il.com> >>> > > >>> > > , Kyle Evans writes: >>> > > > On Thu, Jul 19, 2018 at 7:13 AM, Niclas Zeising >>> > > > >>> > > > <zeising+freebsd@daemonic.se> wrote: >>> > > > > [ sending this again since I missed the list the first time, apologie >>> 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 <danfe@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 tha >>> t >>> > > > >>>> wi-fi connection periodically breaks. /etc/rc.d/wpa_supplicant >>> > > > >>>> restart >>> > > > >>>> wlan0 helps. After your message I reinstalled wpa_supplicant 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 events, a >>> nd >>> > > > >> further testing shows that I don't actually notice these disconnects >>> > > > >> most of the time because it reassociates fast enough. I noticed it t >>> he >>> > > > >> first time because apparently I had both SSIDs from my AP uncommente >>> d >>> > > > >> 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 >>> 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 (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@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@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 wireles >>> s >>> > 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. >>> >>> I've imported all the patches in the port, from our upline into base. >>> Some were already committed to >>> -- >>> Cheers, >>> Cy Schubert <Cy.Schubert@cschubert.com> >>> FreeBSD UNIX: <cy@FreeBSD.org> 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 too. >> >> 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? [1] https://people.freebsd.org/~kevans/wpa.diff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaHFyB5FdWVpd3jOa5rpDtBdEm3Z0%2Bsx6jb_nXj8mQ5=CQ>