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

[Kyle Evans]

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 <Cy.Schubert at cschubert.com> wrote:
> Hi Kyle,
>
> Can you try the attached patch please?
>
> The upline commit log entry says:
>
> commit e8d08cf37844f783b389e601ecedd13edd2b9196
> Author: Jouni Malinen <jouni at codeaurora.org>
> 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 <jouni at codeaurora.org>
>
>
>
> In message <CACNAnaETEVRsGFXc-P+Ht3f-ZeZyVShHDOh_mVkccqkC12tPPw at mail.gma
> 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 <adrian.chadd at gmail.com> wrote
>> :
>> > Is it during a rekey event?
>> >
>> >
>> >
>> > -adrian
>> >
>> > On Wed, 18 Jul 2018 at 08:16, Kyle Evans <kevans at freebsd.org> wrote:
>> >>
>> >> On Wed, Jul 11, 2018 at 1:53 PM, Cy Schubert <cy at freebsd.org> 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 <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.
>