Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <ada14dfad76b93d654606c3b397de059d968096b.camel@gmail.com>
Subject: Lost beacon behavior changed as of 01afc6fed (hwsim)
From:   James Prestwood <prestwoj@gmail.com>
To:     "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc:     Johannes Berg <johannes@sipsolutions.net>
Date:   Wed, 01 Jul 2020 15:12:40 -0700
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Hi,

First off, everything described here is using mac80211_hwsim. I have
not tested if any of this happens on physical hardware or not.

Commit 01afc6fed seems to have changed the kernel behavior with regard
to lost beacons. So much so that it completely breaks all roaming tests
for IWD and (if kept this way) will require severe changes to the
existing roaming logic we have used for quite a long time. Plus
supporting older kernels AND this new behavior is going to be quite
annoying to deal with.

Before, the kernel would only send a lost beacon QCM event when it
detected beacon loss. This allowed us to scan, find a suitable BSS to
roam to, and then roam.

Now it also sends Del Station, Deauthenticate, and Disconnect all
immediately after a lost beacon, and the disconnect reason being
DISASSOC_DUE_TO_INACTIVITY (4). We handle these extra events as we
would at any other time, and fully disconnect which prevents us from
being able to roam quickly (as well as breaking tests).

Looking at that commit nothing particular jumps out at me, but
obviously those added flags are causing something else to send these
extra events.

Was this change actually intended to cause these extra events? And if
so, why was it changed?

Thanks,
James