[PW_SID:991975] [1/3] netdev: check connected in channel switch event #476
Conversation
This is taken care of by the individual cache items and if none exist, tar fails.
In an ideal world userspace should never be getting a channel switch event unless connected to an AP, but alas this has been seen at least with ath10k hardware. This causes IWD to crash since the logic assumes netdev->handshake is set.
This is the station portion of a 2 part patch (netdev being the other piece). After CSA IE parsing was added to the kernel this opened up the possibility that associations could be rejected locally based on the contents of this CSA IE in the AP's beacons. Overall, it was always possible for a local rejection but this case was never considered by IWD. The CSA-based rejection is something that can and does happen out in the wild. When this association rejection happens it desync's IWD and the kernel's state: 1. IWD begins an FT roam. Authenticates successfully, then proceeds to calling netdev_ft_reassociate(). 2. Immediately IWD transitions to a ft-roaming state and waits for an association response. 3. CMD_ASSOCIATE is rejected by the kernel in the ACK which IWD handles by sending a deauthenticate command to the kernel (since we have a valid authentication to the new BSS). 4. Due to a bug IWD uses the target BSSID to deauthenticate which the kernel rejects since it has no knowledge of this auth. This error is not handled or logged. 5. IWD proceeds, assuming its deauthenticated, and transitions to a disconnected state. The kernel remains "connected" which of course prevents any future connections. This patch addresses IWD's recovery behavior when the kernel rejects a CMD_ASSOCIATION (for any reason, not just CSA-rejection) - Now IWD will not change state until netdev signals that CMD_ASSOCIATE was accepted (in subsequent patch). This signal will come via the NETDEV_EVENT_ASSOCIATING event. If this event arrives, and IWD is still in a "preparing_roam" state, we can proceed to ft-roaming. - If station_reassociate_cb() is called with a failure result but IWD is still in a "preparing_roam" state the connection to the current AP is assumed to be maintained and IWD can proceed to trying more BSS's. Otherwise this indicates a failed roam. Notes: - The station_ft_work_ready() callback did need to be reworked to keep the target roam_bss in the list when FT-Association is started. This required modifying some of the other paths to pop and free the roam_bss rather than doing that by default.
The issue surrounding this was described in detail in the previous patch. The netdev piece simple and does two things: 1. Don't deauthenticate and fail the connection if the CMD_ASSOCIATE ACK comes back with a failure. A local rejection like this should not change the kernels internal state, so we can recover. In this case call the connect callback directly with a failure which station will handle. 2. Upon a successful CMD_ASSOCIATE ACK, signal NETDEV_EVENT_ASSOCIATING to let station know. This did require modifying the netdev_associate_event() to not duplicate event calls, specifically when FT is being used.
|
Fetch PR Prep - Setup ELL Make Distcheck Build - Configure Make Check Make Check w/Valgrind Incremental Build with patches |
|
Fetch PR GitLint Prep - Setup ELL Make Distcheck Build - Configure Make Check Make Check w/Valgrind Incremental Build with patches Autotest Runner Clang Build |
github-actions
bot
force-pushed
the
workflow
branch
3 times, most recently
from
e4aa359 to
0e452d2
Compare
github-actions
bot
force-pushed
the
workflow
branch
from
0e452d2 to
d035ebb
Compare
github-actions
bot
force-pushed
the
workflow
branch
from
d035ebb to
25a40e4
Compare
In an ideal world userspace should never be getting a channel switch
event unless connected to an AP, but alas this has been seen at least
with ath10k hardware. This causes IWD to crash since the logic
assumes netdev->handshake is set.
src/netdev.c | 3 +++
1 file changed, 3 insertions(+)