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

Fri Jul 20 00:33:37 UTC 2018

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.com> wrote:
> >> In message <201807192114.w6JLEapA097589 at slippy.cwsent.com>, Cy Schubert
> >> writes:
> >>> In message <17042686.Mc0X0P6XHu at 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 at mail.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, 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 at 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 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 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 at 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 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 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.)

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.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        lattera at is.a.hacker.sx
GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20180719/85f9f830/attachment.sig>