Hi all, On Thu, Jan 20, 2022 at 08:01:13PM +0100, Stefan Sperling wrote: > On Thu, Jan 20, 2022 at 05:13:22PM +0100, Christian Ehrhardt wrote: > > The wpa supplicant (tries to) use routing messages of type > > RTM_80211INFO to detect WLAN access point changes. If the > > SSID or the BSSID changes compared to the last RTM_80211INFO > > message an ASSOC event is injected into the 802.1x state > > machines. > > > > The problem with this approach is that > > the kernel only generates these events when the WLAN link > > state changes to "UP". In most cases link UP is basically the > > same as the IEEE80211_S_RUN which means that the STA associated > > to an AP and the AP confirmed the association. > > > > However, in the case of 802.1x the flag IEEE80211_F_RSNON > > is set which delays the link up event until after the 802.1x > > handshake is complete. > > > > In the roaming case this means that the WPA supplicant > > does not notice that it was DEAUTH'ed from an access point > > that we are roaming away from. As a result it will drop EAPOL > > packets from the new AP an association with the new AP will fail. > > > > In the case of an initial connection wpa_supplicant will > > try to associate with the BSSID 00:00:00:00:00:00 until this > > attempt times out. Depending on the exact timing a subsequent > > attempt to associate with the correct BSSID may or may not be > > started. > > > > To fix this send the RTM_80211INFO if we reach the > > IEEE80211_S_RUN state even if this does not result in a link > > up event. In the 802.1x case this will result in two of these > > messages with the same SSID and BSSID. The first event when we > > reach the IEEE80211_S_RUN state (before the 802.1x authentication) > > and a second message once the interface is actually up. > > > > A quick grep into userland suggest that this additional message > > is not a problem and it fixes 802.1x. > > The current behaviour was introduced intentionally in order to > unbreak problems with early link-up events and DHCP clients. > > If link goes up before the WPA handshake has completed, DHCP clients try > to send packets too early and can run into DHCP-protocol level timeouts. > A lot of work went into fixing this, so simply undoing all of that work > by sending the routing before packets can be sent does not seem good.
The link state behaviour is _not_ affected by my change.
The proposed diff _only_ changes when and how often the
RTM_80211INFO message (which contains stuff like the BSSID
and SSID but not a link state flag) is sent.
> Can this not be fixed in another way? Would generating routing messages
> for both link down+up be enough to fix 802.1x?
I'm not touching the route messages for link state changes.
> Could we generate a routing message to announce that roaming has succeeded
> and make wpa_supplicant listen for this?
I think we need some kind of notification to the WPA supplicant
whenever the IEEE state reaches RUN. I still think the suggested patch
is a good solution for this.
In addition, I checked the code of dhclient and while it does listen
to the RTM_80211INFO messages it will only use them to do a RESTART (drop
things it thinks it knows about the interface and re-read all the
information) which is a good thing. It will not start sending
messages early while the link is still down.
regards Christian
> > diff --git a/sys/net80211/ieee80211_proto.c b/sys/net80211/ieee80211_proto.c
> > index accec8d74d..a1a99e5024 100644
> > --- a/sys/net80211/ieee80211_proto.c
> > +++ b/sys/net80211/ieee80211_proto.c
> > @@ -1307,6 +1307,8 @@ justcleanup:
> > */
> > ieee80211_set_link_state(ic, LINK_STATE_UP);
> > ni->ni_assoc_fail = 0;
> > + } else {
> > + task_add(systq, &ic->ic_rtm_80211info_task);
> > }
> > ic->ic_mgt_timer = 0;
> > ieee80211_set_beacon_miss_threshold(ic);
> > @@ -1322,11 +1324,10 @@ void
> > ieee80211_rtm_80211info_task(void *arg)
> > {
> > struct ieee80211com *ic = arg;
> > - struct ifnet *ifp = &ic->ic_if;
> > struct if_ieee80211_data ifie;
> > int s = splnet();
> >
> > - if (LINK_STATE_IS_UP(ifp->if_link_state)) {
> > + if (ic->ic_state == IEEE80211_S_RUN) {
> > memset(&ifie, 0, sizeof(ifie));
> > ifie.ifie_nwid_len = ic->ic_bss->ni_esslen;
> > memcpy(ifie.ifie_nwid, ic->ic_bss->ni_essid,
>
>
--
genua GmbH
Domagkstrasse 7, 85551 Kirchheim, Germany
phone +49 89 991950-195, fax -999, www.genua.eu
genua is a member of the Bundesdruckerei Group.
smime.p7s
Description: S/MIME cryptographic signature
