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: <6bc05de3-42ed-2f0a-188b-8dc0297aee5d@gmail.com>
Date:   Thu, 27 Apr 2023 10:26:38 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Content-Language: en-US
To:     linux-wireless@vger.kernel.org
From:   James Prestwood <prestwoj@gmail.com>
Subject: sending disassociate/deauth frames to prior BSS after FT/roam?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi,

I'm tracking down an issue with APs appearing to think a client is still 
associated after it FT roams to another AP. I'll spare everyone the 
details but it got me wondering if a disassociate/deauth frame was 
getting sent to the prior AP by the kernel when reassociating. Following 
the mac80211 logic starting in ieee80211_mgd_assoc():

if (ifmgd->associated) {
	u8 frame_buf[IEEE80211_DEAUTH_FRAME_LEN];

	sdata_info(sdata,
		   "disconnect from AP %pM for new assoc to %pM\n",
		   ifmgd->bssid, req->bss->bssid);
	ieee80211_set_disassoc(sdata, IEEE80211_STYPE_DEAUTH,
			       WLAN_REASON_UNSPECIFIED,
			       false, frame_buf);

	ieee80211_report_disconnect(sdata, frame_buf,
				    sizeof(frame_buf), true,
				    WLAN_REASON_UNSPECIFIED,
				    false);
}

I noticed here the 'tx' argument to ieee80211_set_disassoc() is false. 
Inside ieee80211_set_disassoc() that I see:

if (tx || frame_buf) {
	/*
	 * In multi channel scenarios guarantee that the virtual
	 * interface is granted immediate airtime to transmit the
	 * deauthentication frame by calling mgd_prepare_tx, if the
	 * driver requested so.
	 */
	if (ieee80211_hw_check(&local->hw, DEAUTH_NEED_MGD_TX_PREP) &&
	    !ifmgd->have_beacon) {
		drv_mgd_prepare_tx(sdata->local, sdata, &info);
	}

	ieee80211_send_deauth_disassoc(sdata, ifmgd->bssid,
				       ifmgd->bssid, stype, reason,
				       tx, frame_buf);
}

Where 'tx' (false) is then passed to ieee80211_send_deauth_disassoc(). 
This then builds the frame but doesn't actually send it. I tried finding 
something in the spec about sending a disassociate/deauth when doing FT, 
but can't seem to identify any requirement of that. Logically I would 
expect a disassociate/deauth frame since thats what the client is 
doing... Maybe someone has insight into this?

Overall its a rare issue and the clients are able to roam just fine many 
times. But occasionally the APs exhibit this behavior of thinking the 
client is still connected and it (possibly) causes other connectivity 
issues once those APs react.

Thanks,
James