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