Hi Arend,
- Is RTNL LINK_MODE / OPER_STATE status being (supposed to be?)
affected by the driver during a roam? E.g. if we're in a 802.1X
network with userspace authentication, and driver roamed requiring a
new 802.1X auth, then in theory the RTNL mode needs to be brought
back out of UP state...
So do you expect the driver/cfg80211 to take care of that or the
supplicant? I assumed wpa_supplicant would be doing that.
With regular roaming where we trigger a Deassociate/Deathenticate
(either explicitly or implicitly) first, the interface goes into
dormant mode by virtue of the carrier going down.
With this it isn't really clear whether the same is happening and who
(kernel/userspace) should be doing what. I would actually assume the
kernel is/should be turning carrier off for the duration of the roam
operation?
On what layer do we know 802.1X re-auth is required?
Not sure what you mean by 'layer'? If re-auth is required, then only
the supplicant has the proper info and it will handle this via EAPoL frames.
But that is besides the point. Regardless of whether a roam needs
re-auth or not, network interface dormant notification is needed. For
example: userspace DHCP clients need to know when to renew the address.
And yes, there are weird networks out there that expect you to
re-negotiate your DHCP address on a roam. Such clients are not
integrated in any way with a supplicant and rely on rtnl.
Regards,
-Denis
