On Thu, Jul 19, 2018 at 7:32 PM, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > On Thu, Jul 19, 2018 at 07:24:46PM -0500, Kyle Evans wrote: >> On Thu, Jul 19, 2018 at 6:21 PM, Kyle Evans <kev...@freebsd.org> wrote: >> > On Thu, Jul 19, 2018 at 4:33 PM, Cy Schubert <cy.schub...@cschubert.com> >> > wrote: >> >> In message <201807192114.w6jleapa097...@slippy.cwsent.com>, Cy Schubert >> >> writes: >> >>> In message <17042686.mc0x0p6...@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=gjlfdjpd5yd1gzqmpc0z...@mail.gma >> >>> > > il.com> >> >>> > > >> >>> > > , Kyle Evans writes: >> >>> > > > On Thu, Jul 19, 2018 at 7:13 AM, Niclas Zeising >> >>> > > > >> >>> > > > <zeising+free...@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 >> >>> > > > >> <da...@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.schub...@cschubert.com> >> >>> FreeBSD UNIX: <c...@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? > > (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. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"