Re: WLAN 802.1x authentication problems
Hi, On Fri, Jan 21, 2022 at 12:00:54AM -0700, Theo de Raadt wrote: > > 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. > > dhclient is being used by fewer and fewer people. Please focus on the > other route socket listeners, there are many. I did grep all of "src" before and added all the patches in "ports", now. I'm grepping for the RTM_80211INFO constant as the change only affects when this particular message type is sent. Any user of the message would have to use this constant somehow, right? Apart from wpa_supplicant the only users are: - dhclient which is fine. - route prints the message contents in monitor mode but does not use the message otherwise. regards Christian -- 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
Re: WLAN 802.1x authentication problems
> 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. dhclient is being used by fewer and fewer people. Please focus on the other route socket listeners, there are many.
Re: WLAN 802.1x authentication problems
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.
regardsChristian
> > 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_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_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(, 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
Re: crash on booting GENERIC.MP since upgrade to Jan 18 snapshot
On Fri, Jan 21, 2022 at 12:22:49AM +1100, Jonathan Gray wrote: > On Wed, Jan 19, 2022 at 11:04:26PM -0800, guent...@openbsd.org wrote: [...] > > The backtrace is kinda nonsensical, showing a copyout() call with no > > predecessor, but maybe that's just from copy*() not setting up a proper > > frame? However, that's not a change. Neither has there been any change > > in the pmap layer in multiple months. The areas of concern IMO are DRM > > and (because it was the last thing mentioned) iwm, but the former seems > > _much_ more likely. > > Booting bsd.mp with inteldrm disabled works? yes, boots and uses llvmpipe after I disable inteldrm* > > boot -c > disable inteldrm* > q
Re: WLAN 802.1x authentication problems
On Thu, Jan 20, 2022 at 05:13:22PM +0100, Christian Ehrhardt wrote:
>
> Hi,
>
> 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.
Can this not be fixed in another way? Would generating routing messages
for both link down+up be enough to fix 802.1x?
Could we generate a routing message to announce that roaming has succeeded
and make wpa_supplicant listen for this?
> 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_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_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(, 0, sizeof(ifie));
> ifie.ifie_nwid_len = ic->ic_bss->ni_esslen;
> memcpy(ifie.ifie_nwid, ic->ic_bss->ni_essid,
WLAN 802.1x authentication problems
Hi,
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.
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_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_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(, 0, sizeof(ifie));
ifie.ifie_nwid_len = ic->ic_bss->ni_esslen;
memcpy(ifie.ifie_nwid, ic->ic_bss->ni_essid,
smime.p7s
Description: S/MIME cryptographic signature
Re: crash on booting GENERIC.MP since upgrade to Jan 18 snapshot
On Wed, Jan 19, 2022 at 11:04:26PM -0800, guent...@openbsd.org wrote: > On Wed, 19 Jan 2022, Thomas Frohwein wrote: > > >Synopsis: crash on booting GENERIC.MP since upgrade to Jan 18 snapshot > > >Category: kernel amd64 > > >Environment: > > System : OpenBSD 7.0 > > Details : OpenBSD 7.0-current (GENERIC) #265: Wed Jan 19 11:41:29 > > MST 2022 > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > Since I upgraded to from a Jan 5 snapshot to Jan 18, I am > > unable to boot GENERIC.MP anymore. I am still able to boot > > bsd.rd and bsd.sp - I am sending this bug report from this > > computer running bsd.sp. > > > > When I boot the MP kernel, it fails after the lines: > > > > wsdisplay0: screen 1-5 added (std, vt100 emulation) > > iwm0: hw rev 0x200, rw ver 36.ca7b901d.0, address a4:34:d9:9f:c7:e3 > ... > > The backtrace is kinda nonsensical, showing a copyout() call with no > predecessor, but maybe that's just from copy*() not setting up a proper > frame? However, that's not a change. Neither has there been any change > in the pmap layer in multiple months. The areas of concern IMO are DRM > and (because it was the last thing mentioned) iwm, but the former seems > _much_ more likely. Booting bsd.mp with inteldrm disabled works? boot -c disable inteldrm* q > > > Philip Guenther > > ... > > sd2 at scsibus4 targ 1 lun 0: > > sd2: 1953513MB, 512 bytes/sector, 4000795775 sectors > > root on sd2a (66c54421b07c8a9f.a) swap on sd2b dump on sd2b > > inteldrm0: 1920x1080, 32bpp > > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 > > wskbd1: connecting to wsdisplay0 > > wskbd2: connecting to wsdisplay0 > > wskbd3: connecting to wsdisplay0 > > wsdisplay0: screen 1-5 added (std, vt100 emulation) > > iwm0: hw rev 0x200, fw ver 36.ca7b901d.0, address a4:34:d9:9f:c7:e3
