Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <6a81f3d5f25a9a7258587e469209f48bdeac558f.camel@sipsolutions.net>
Subject: Re: [PATCH] wifi: mac80211: handle connection loss in
 __ieee80211_disconnect
From:   Johannes Berg <johannes@sipsolutions.net>
To:     James Prestwood <prestwoj@gmail.com>,
        linux-wireless@vger.kernel.org
Date:   Wed, 18 Jan 2023 17:04:27 +0100
In-Reply-To: <20221025203443.410121-2-prestwoj@gmail.com>
References: <20221025203443.410121-1-prestwoj@gmail.com>
         <20221025203443.410121-2-prestwoj@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Tue, 2022-10-25 at 13:34 -0700, James Prestwood wrote:
> The ieee80211_connection_loss() can be called during times when the
> kernels state is in flux, such as after a successful authentication
> but prior to successful association. This can result in the kernel
> never telling userspace due to __ieee80211_disconnect bailing out
> if !ifmgd->associated. This has been seen out in the wild on
> iwlwifi:
>=20
> [503619.324379] wlan0: disconnect from AP d0:15:a6:70:e1:20 for new auth =
to d0:15:a6:70:b5:40
> [503619.367204] wlan0: authenticate with d0:15:a6:70:b5:40
> [503619.367233] wlan0: bad VHT capabilities, disabling VHT
> [503619.367236] wlan0: Invalid HE elem, Disable HE
> [503619.367237] wlan0: 80 MHz not supported, disabling VHT
> [503619.371184] wlan0: send auth to d0:15:a6:70:b5:40 (try 1/3)
> [503619.406401] wlan0: authenticated
> [503620.270833] iwlwifi 0000:00:14.3: Not associated and the session prot=
ection is over already...
> [503620.270943] wlan0: Connection to AP d0:15:a6:70:b5:40 lost
>=20
> At this point userspace has received a CMD_AUTHENTICATE event but
> nothing else. No disconnect or anything to indicate something is
> wrong. Userspace supplicants expect _something_ to come after a
> successful authentication.
>=20

I'm not sure I understand this scenario - there's nothing wrong with
this, is there?

The way I read this is that userspace simply asked for auth, but then
didn't (quickly enough) ask for assoc? Or got a comeback or something
(though we would log that too, I think)?

Userspace got a successful NL80211_CMD_AUTHENTICATE event at this point,
but didn't associate (yet anyway).

You could argue that iwlwifi shouldn't be waiting for an association if
nobody ever requested association, but that's a driver bug, and
shouldn't cause any problem with state between userspace and kernel.

johannes