From owner-svn-src-head@freebsd.org Thu Jul 19 00:26:09 2018 Return-Path: Delivered-To: svn-src-head@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 AB47C103DD3F; Thu, 19 Jul 2018 00:26:09 +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 56C6474655; Thu, 19 Jul 2018 00:26:09 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (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 E64CD21487; Thu, 19 Jul 2018 00:26:08 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f53.google.com with SMTP id m12-v6so4726573lfc.10; Wed, 18 Jul 2018 17:26:08 -0700 (PDT) X-Gm-Message-State: AOUpUlGl+sJBm9C2QpHbiUGGzida3DRoyEvOICgBDDv5O2I/UpVVv9CO jymjkOk7xGsA2ZozDhTC3arW4yV06ULBjVlmH9U= X-Google-Smtp-Source: AAOMgpcXFxT6DyGrnNDRX7mrPVWhwaTwGJTLu07Jsv7a9XUQrgDDJeNwU95avB6umbdVlW/lRZZv6B6SXPqdnemyFc0= X-Received: by 2002:a19:138b:: with SMTP id 11-v6mr5398793lft.74.1531959967355; Wed, 18 Jul 2018 17:26:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 17:25:46 -0700 (PDT) In-Reply-To: <201807181950.w6IJoPLu005610@slippy.cwsent.com> References: <201807181950.w6IJoPLu005610@slippy.cwsent.com> From: Kyle Evans Date: Wed, 18 Jul 2018 19:25:46 -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: Adrian Chadd , Cy Schubert , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 00:26:09 -0000 Hi, Thanks! No effect, unfortunately. I have confirmed since that this is no longer an issue if I disable re-keying on my AP, so I guess that definitively isolates it to re-keying and gives me a pretty solid workaround. None of the other devices on my network seem affected, but I don't have much access to their logging to confirm that it's not an issue rather than just not as obvious. Thanks, Kyle Evans 2018 at 2:50 PM, Cy Schubert wrote: > Hi Kyle, > > Can you try the attached patch please? > > The upline commit log entry says: > > commit e8d08cf37844f783b389e601ecedd13edd2b9196 > Author: Jouni Malinen > Date: Wed Jun 6 01:22:01 2018 +0300 > > SAE: Do not drop STA entry on reauthentication in infrastructure BSS > > A new SAE Commit message should not be allowed to drop an existing > STA > entry since the sender of that Commit message cannot be > authenticated > before receiving the Confirm message. This is important in > particular > when PMF is used since this would provide a potential new path for > forcing a connection to be dropped. > > Fix this by allowing a new SAE Authentication instance to be started > when the old instance is in Accepted state and the new Commit > message > does not use the same peer-scalar value (checked in > sae_parse_commit_scalar()). When PMF is used, the AP will use SA > Query > procedure when receiving the (Re)Association Request frame. In > theory, > that step could be skipped in case of SAE Authentication since the > non-AP STA is demonstrating knowledge of the password. Anyway, > there is > no allowance for that exception in the IEEE 802.11 standard, so at > least > for now, leave this using SA Query procedure just like any other PMF > case. > > Signed-off-by: Jouni Malinen > > > > In message il.com> > , Kyle Evans writes: >> Poking at the router indicates that it is indeed during a rekey event. >> >> On Wed, Jul 18, 2018 at 12:56 PM, Adrian Chadd wrote >> : >> > Is it during a rekey event? >> > >> > >> > >> > -adrian >> > >> > On Wed, 18 Jul 2018 at 08:16, Kyle Evans wrote: >> >> >> >> On Wed, Jul 11, 2018 at 1:53 PM, Cy Schubert wrote: >> >> > Author: cy >> >> > Date: Wed Jul 11 18:53:18 2018 >> >> > New Revision: 336203 >> >> > URL: https://svnweb.freebsd.org/changeset/base/336203 >> >> > >> >> > Log: >> >> > MFV r324714: >> >> > >> >> > Update wpa 2.5 --> 2.6. >> >> > >> >> > MFC after: 1 month >> >> > >> >> >> >> Hi, >> >> >> >> Thanks again for the update! For some reason with 2.6, I'm seeing >> >> hourly (+/- a minute or two) disconnects: >> >> >> >> Jul 18 08:16:47 shiva wpa_supplicant[63771]: wlan0: >> >> CTRL-EVENT-DISCONNECTED bssid=... reason=1 locally_generated=1 >> >> Jul 18 08:16:47 shiva kernel: wlan0: link state changed to DOWN >> >> Jul 18 08:16:47 shiva wpa_supplicant[63771]: ioctl[SIOCS80211, op=20, >> >> val=0, arg_len=7]: Can't assign requested address >> >> Jul 18 08:18:03 shiva wpa_supplicant[63771]: wlan0: Trying to >> >> associate with ... (SSID='FBI Surveillance Cat' freq=2437 MHz) >> >> Jul 18 08:18:03 shiva wpa_supplicant[63771]: wlan0: Associated with ... >> >> Jul 18 08:18:03 shiva kernel: wlan0: link state changed to UP >> >> Jul 18 08:18:03 shiva dhclient[40889]: send_packet: No buffer space availa >> ble >> >> Jul 18 08:18:03 shiva wpa_supplicant[63771]: wlan0: WPA: Key >> >> negotiation completed with ... [PTK=CCMP GTK=CCMP] >> >> Jul 18 08:18:03 shiva wpa_supplicant[63771]: wlan0: >> >> CTRL-EVENT-CONNECTED - Connection to ... completed [id=0 id_str=] >> >> Jul 18 08:18:06 shiva dhclient[42269]: New IP Address (wlan0): 192.168.1.1 >> 50 >> >> Jul 18 08:18:06 shiva dhclient[42841]: New Subnet Mask (wlan0): 255.255.25 >> 5.0 >> >> Jul 18 08:18:06 shiva dhclient[43080]: New Broadcast Address (wlan0): >> >> 192.168.1.255 >> >> Jul 18 08:18:06 shiva dhclient[43248]: New Routers (wlan0): 192.168.1.1 >> >> >> >> Any idea what that might be about? My wpa_supplicant.conf is fairly >> >> minimal with exactly one network specified. >> >> >> >> Thanks, >> >> >> >> Kyle Evans >> >> > > > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. >