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...

Cy Schubert Cy.Schubert at cschubert.com
Fri Jul 20 01:37:33 UTC 2018


In message <CACNAnaG3D2M2PxOgR-VYFbFsqw=bfP-Kzp6DN-5hjZrRa=o91A at mail.gma
il.com>
, Kyle Evans writes:
> On Thu, Jul 19, 2018 at 7:57 PM, Cy Schubert <Cy.Schubert at cschubert.com> wrot
> e:
> > In message <CACNAnaFJvAq4h5hCu7HezfRtvovKWhZGZdtfooQmnR84HWGqKQ at mail.gma
> > il.com>
> > , Kyle Evans writes:
> >> On Thu, Jul 19, 2018 at 7:32 PM, Shawn Webb <shawn.webb at hardenedbsd.org> w
> rot
> >> 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 <kevans at freebsd.org> wrote:
> >> >> > On Thu, Jul 19, 2018 at 4:33 PM, Cy Schubert <Cy.Schubert at cschubert.c
> om>
> >>  wrote:
> >> >> >> In message <201807192114.w6JLEapA097589 at slippy.cwsent.com>, Cy Schub
> ert
> >> >> >> writes:
> >> >> >>> In message <17042686.Mc0X0P6XHu at asus.theweb.org.ua>, "Oleg V. Nauma
> n"
> >> >> >>> writes:
> >> >> >>> > On Thursday, July 19, 2018 4:54:42 PM EEST Cy Schubert wrote:
> >> >> >>> > > In message <CACNAnaEaMtRfHTXyCcGGmVP_37=gjLfDjPD5yd1gZqmpC0Z0Rg
> @ma
> >> il.gma
> >> >> >>> > > il.com>
> >> >> >>> > >
> >> >> >>> > > , Kyle Evans writes:
> >> >> >>> > > > On Thu, Jul 19, 2018 at 7:13 AM, Niclas Zeising
> >> >> >>> > > >
> >> >> >>> > > > <zeising+freebsd at daemonic.se> 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 <danfe at f
> ree
> >> bsd.org
> >> >> >>> >
> >> >> >>> > > > >>
> >> >> >>> > > > >> wrote:
> >> >> >>> > > > >>> On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsuk
> ov
> >> wrote:
> >> >> >>> > > > >>>> ...
> >> >> >>> > > > >>>> Yesterday I updated my notebook (with iwm(4)) and also n
> oti
> >> ced tha
> >> >> >>> t
> >> >> >>> > > > >>>> wi-fi connection periodically breaks. /etc/rc.d/wpa_supp
> lic
> >> ant
> >> >> >>> > > > >>>> restart
> >> >> >>> > > > >>>> wlan0 helps. After your message I reinstalled wpa_suppli
> can
> >> t from
> >> >> >>> ol
> >> >> >>> > d
> >> >> >>> > > > >>>> source and now it works stable already about 2 hours.
> >> >> >>> > > > >>>
> >> >> >>> > > > >>> So, right now, we have broken wpa_supplicant(8) in -CURRE
> NT?
> >>  :-/
> >> >> >>> > > > >>
> >> >> >>> > > > >> Well, "broken". It's incredibly stable outside of rekeying
>  ev
> >> ents, a
> >> >> >>> nd
> >> >> >>> > > > >> further testing shows that I don't actually notice these d
> isc
> >> onnects
> >> >> >>> > > > >> most of the time because it reassociates fast enough. I no
> tic
> >> 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 ever
> y s
> >> ingle
> >> >> >>> > > > >> time.
> >> >> >>> > > > >
> >> >> >>> > > > > Hi!
> >> >> >>> > > > > I have the exact same problem as Andrey, with the same driv
> er.
> >>   I've
> >> >> >>> no
> >> >> >>> > t
> >> >> >>> > > > > investigated very much, but when using the 2.8 wpa_supplica
> nt
> >> 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 a
> ffe
> >> 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 patc
> h 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 n
> etw
> >> orks
> >> >> >>> > > I use. All the networks I use are either WPA-PSK or open. The l
> ast
> >> >> >>> > > 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 e
> ver
> >> y 30
> >> >> >>> > > minutes using our old wpa 2.5, requiring a netif restart. 2.6 r
> eso
> >> lved
> >> >> >>> > > that issue.
> >> >> >>> > >
> >> >> >>> > > Upline git commit 0adc9b28b39d414d5febfff752f6a1576f785c85 also
>  lo
> >> oks
> >> >> >>> > > interesting.
> >> >> >>> > >
> >> >> >>> > > ommit 0adc9b28b39d414d5febfff752f6a1576f785c85
> >> >> >>> > > Author: Jouni Malinen <j at 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 w
> hen
> >>  going
> >> >> >>> > >     directly to the PTKSTART state since there is no need to tr
> y t
> >> o
> >> >> >>> > >     determine the PMK again in such a case. This is far from id
> eal
> >> >> >>> > > since the
> >> >> >>> > >     new PTK would depend on a new nonce only from the supplican
> t.
> >> >> >>> > >
> >> >> >>> > >     Fix this by generating a new ANonce when moving to the PTKS
> TAR
> >> T
> >> >> >>> > > state
> >> >> >>> > >     for the purpose of starting new 4-way handshake to rekey PT
> K.
> >> >> >>> > >
> >> >> >>> > >     Signed-off-by: Jouni Malinen <j at w1.fi>
> >> >> >>> > >
> >> >> >>> > >
> >> >> >>> > > I suspect a timeout because reason=1 in Kyle's log.
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >  I have two systems experienced wifi connection issues after rece
> nt
> >> 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 f
> rom
> >>  ports
> >> >> >>> > fixes that issue completely.
> >> >> >>> >
> >> >> >>> > Hopefully it helps.
> >> >> >>> >
> >> >> >>> >  Thank you.
> >> >> >>>
> >> >> >>> I've imported all the patches in the port, from our upline into bas
> e.
> >> >> >>> Some were already committed to
> >> >> >>> --
> >> >> >>> Cheers,
> >> >> >>> Cy Schubert <Cy.Schubert at cschubert.com>
> >> >> >>> FreeBSD UNIX:  <cy at 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 por
> t,
> >> >> >>> 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 brin
> g
> >> >> >> 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 patc
> hes
> >> .
> >> >>
> >> >> 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.

Yes, I'm looking at that now. (I fixed the NFS issue -- firewall out of 
state impacting NFS -- at $JOB sooner than expected. I'm on it now.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.





More information about the svn-src-head mailing list