Re: security/wpa_supplicant: Reassoc on NWID change

[Raf Czlonka]

On Fri, Jan 04, 2019 at 10:51:50PM GMT, Stuart Henderson wrote:
> 
> Probably obvious anyway but just checking... you haven't forced bssid
> or chan via hostname.if / ifconfig have you?
> 

It is *always* worth checking for the obvious, IMHO :^)

No, hostname.if is pretty vanilla:

join home wpakey abc
join other wpakey xyz
join work wpaakms 802.1x
join eduroam wpaakms 802.1x
dhcp

Thanks for checking anyway,

Raf

Re: security/wpa_supplicant: Reassoc on NWID change

[Raf Czlonka]

On Fri, Jan 04, 2019 at 10:43:14PM GMT, Peter Hessler wrote:
> 
> Yes, can you turn on debug for the interface: ifconfig iwm0 debug
> (replace iwm0 with your actual wifi device if it is different).
> 
> That will give a lot more output in the dmesg buffer, but also the
> results of channel scans and when it is looking for a new bssid to
> connect to.
> 
> The kernel needs to select a new bssid to connect to, move to it, then
> this patch lets wpa_supplicant listen for those changes and react to
> them.
> 

I focused on wpa_supplicant and hadn't actually thought of doing that.

I'll do it all next week.

Ta,

Raf

Re: security/wpa_supplicant: Reassoc on NWID change

[Stuart Henderson]

On 2019/01/04 23:43, Peter Hessler wrote:
> On 2019 Jan 04 (Fri) at 17:38:56 + (+), Raf Czlonka wrote:
> :
> :Absolute silence when I move around - only when I move back near the AP,
> :the laptop associated with first, do I get this:
> :
> : $ route monitor
> : got message of size 192 on Fri Jan  4 17:28:11 2019
> : RTM_GET: Report Metrics: len 192, priority 12, table 0, ifidx 4, pid: 
> 86459, seq -904765000, errno 0
> : flags:
> : fmask:
> : use:   42   mtu:0expire:0
> : locks:  inits:
> : sockaddrs: 
> :  0.0.0.0 gate.domain.example.com 0.0.0.0 ab:cd:ef:01:23:45 
> host.domain.example.com
> :
> :Apart from both FQDNs and the MAC address, nothing has been redacted.
> :
> :I'll be back here on Monday. Is there anything else I should try?
> :
> :Cheers,
> :
> :Raf
> 
> Yes, can you turn on debug for the interface: ifconfig iwm0 debug
> (replace iwm0 with your actual wifi device if it is different).
> 
> That will give a lot more output in the dmesg buffer, but also the
> results of channel scans and when it is looking for a new bssid to
> connect to.
> 
> The kernel needs to select a new bssid to connect to, move to it, then
> this patch lets wpa_supplicant listen for those changes and react to
> them.

Probably obvious anyway but just checking... you haven't forced bssid
or chan via hostname.if / ifconfig have you?

Re: security/wpa_supplicant: Reassoc on NWID change

[Peter Hessler]

On 2019 Jan 04 (Fri) at 17:38:56 + (+), Raf Czlonka wrote:
:On Fri, Jan 04, 2019 at 05:03:44PM GMT, Gregor Best wrote:
:> Hi Raf,
:
:Hi Gregor,
:
:> > [...]
:> > I've re-tested it, now that the new package includes the patch, but
:> > I'm left with the same behaviour as before - when I move around,
:> > the laptop does not connect to any other APs. It *does* reconnect
:> > to the AP it has originally associated with and, only then, do I
:> > see any output in 'wpa_cli', which stays silent otherwise (i.e. as
:> > I walk around the building).
:> >
:> > I've tested both eduroam and one other 802.1x network.
:> >
:> > I'd like to get this diagnosed but could do with some pointers...
:> > [...]
:> 
:> Have you tried running `route monitor`, keeping that running and walking
:> around to see what happens if you go out of range? Sometimes, the kernel
:> takes a bit of time to actually switch APs, but if it does, you should
:> see an RTM_80211INFO or RTM_IFINFO message in `route monitor`'s output.
:> 
:> If you do get such a message, could you paste it for us so we can take a
:> peek at it?
:> 
:
:Absolute silence when I move around - only when I move back near the AP,
:the laptop associated with first, do I get this:
:
:   $ route monitor
:   got message of size 192 on Fri Jan  4 17:28:11 2019
:   RTM_GET: Report Metrics: len 192, priority 12, table 0, ifidx 4, pid: 
86459, seq -904765000, errno 0
:   flags:
:   fmask:
:   use:   42   mtu:0expire:0
:   locks:  inits:
:   sockaddrs: 
:0.0.0.0 gate.domain.example.com 0.0.0.0 ab:cd:ef:01:23:45 
host.domain.example.com
:
:Apart from both FQDNs and the MAC address, nothing has been redacted.
:
:I'll be back here on Monday. Is there anything else I should try?
:
:Cheers,
:
:Raf

Yes, can you turn on debug for the interface: ifconfig iwm0 debug
(replace iwm0 with your actual wifi device if it is different).

That will give a lot more output in the dmesg buffer, but also the
results of channel scans and when it is looking for a new bssid to
connect to.

The kernel needs to select a new bssid to connect to, move to it, then
this patch lets wpa_supplicant listen for those changes and react to
them.


-- 
Economists state their GNP growth projections to the nearest tenth of a
percentage point to prove they have a sense of humor.
-- Edgar R. Fiedler

Re: security/wpa_supplicant: Reassoc on NWID change

[Raf Czlonka]

On Fri, Jan 04, 2019 at 05:03:44PM GMT, Gregor Best wrote:
> Hi Raf,

Hi Gregor,

> > [...]
> > I've re-tested it, now that the new package includes the patch, but
> > I'm left with the same behaviour as before - when I move around,
> > the laptop does not connect to any other APs. It *does* reconnect
> > to the AP it has originally associated with and, only then, do I
> > see any output in 'wpa_cli', which stays silent otherwise (i.e. as
> > I walk around the building).
> >
> > I've tested both eduroam and one other 802.1x network.
> >
> > I'd like to get this diagnosed but could do with some pointers...
> > [...]
> 
> Have you tried running `route monitor`, keeping that running and walking
> around to see what happens if you go out of range? Sometimes, the kernel
> takes a bit of time to actually switch APs, but if it does, you should
> see an RTM_80211INFO or RTM_IFINFO message in `route monitor`'s output.
> 
> If you do get such a message, could you paste it for us so we can take a
> peek at it?
> 

Absolute silence when I move around - only when I move back near the AP,
the laptop associated with first, do I get this:

$ route monitor
got message of size 192 on Fri Jan  4 17:28:11 2019
RTM_GET: Report Metrics: len 192, priority 12, table 0, ifidx 4, pid: 
86459, seq -904765000, errno 0
flags:
fmask:
use:   42   mtu:0expire:0
locks:  inits:
sockaddrs: 
 0.0.0.0 gate.domain.example.com 0.0.0.0 ab:cd:ef:01:23:45 
host.domain.example.com

Apart from both FQDNs and the MAC address, nothing has been redacted.

I'll be back here on Monday. Is there anything else I should try?

Cheers,

Raf

Re: security/wpa_supplicant: Reassoc on NWID change

[Gregor Best]

Hi Raf,

> [...]
> I've re-tested it, now that the new package includes the patch, but
> I'm left with the same behaviour as before - when I move around,
> the laptop does not connect to any other APs. It *does* reconnect
> to the AP it has originally associated with and, only then, do I
> see any output in 'wpa_cli', which stays silent otherwise (i.e. as
> I walk around the building).
>
> I've tested both eduroam and one other 802.1x network.
>
> I'd like to get this diagnosed but could do with some pointers...
> [...]

Have you tried running `route monitor`, keeping that running and walking
around to see what happens if you go out of range? Sometimes, the kernel
takes a bit of time to actually switch APs, but if it does, you should
see an RTM_80211INFO or RTM_IFINFO message in `route monitor`'s output.

If you do get such a message, could you paste it for us so we can take a
peek at it?

--
Gregor


signature.asc
Description: PGP signature

Re: security/wpa_supplicant: Reassoc on NWID change

[Raf Czlonka]

Hi all,

I've re-tested it, now that the new package includes the patch, but
I'm left with the same behaviour as before - when I move around,
the laptop does not connect to any other APs. It *does* reconnect
to the AP it has originally associated with and, only then, do I
see any output in 'wpa_cli', which stays silent otherwise (i.e. as
I walk around the building).

I've tested both eduroam and one other 802.1x network.

I'd like to get this diagnosed but could do with some pointers...

Thanks in advance,

Raf

On Fri, Dec 28, 2018 at 06:05:59PM GMT, Peter Hessler wrote:
> I gave this a spin, and seems to work in my testing.
> 
> I did a few suspend/resumes, manual if down/up, forced a chan NN, and
> walked around to do some roaming between 8 bssids.  Recovery took a
> short period of time, but was as expected.
> 
> OK
> 
> 
> On 2018 Dec 28 (Fri) at 17:15:48 +0100 (+0100), Gregor Best wrote:
> :
> :Peter pointed out that my previous patch doesn't apply. Sorry for that,
> :a fixed one is below my signature.
> :
> :--
> : Gregor
> :
> :Index: Makefile
> :===
> :RCS file: /home/cvs/ports/security/wpa_supplicant/Makefile,v
> :retrieving revision 1.39
> :diff -u -p -r1.39 Makefile
> :--- Makefile 24 Oct 2018 17:16:19 -  1.39
> :+++ Makefile 25 Dec 2018 23:19:24 -
> :@@ -3,7 +3,7 @@
> : COMMENT=IEEE 802.1X supplicant
> : 
> : DISTNAME=   wpa_supplicant-2.6
> :-REVISION=   4
> :+REVISION=   5
> : CATEGORIES= security net
> : 
> : HOMEPAGE=   http://w1.fi/wpa_supplicant/
> :Index: patches/patch-src_drivers_driver_openbsd_c
> :===
> :RCS file: 
> /home/cvs/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
> :retrieving revision 1.5
> :diff -u -p -r1.5 patch-src_drivers_driver_openbsd_c
> :--- patches/patch-src_drivers_driver_openbsd_c   17 May 2016 08:29:27 
> -  1.5
> :+++ patches/patch-src_drivers_driver_openbsd_c   25 Dec 2018 23:05:46 
> -
> :@@ -1,24 +1,187 @@
> : $OpenBSD: patch-src_drivers_driver_openbsd_c,v 1.5 2016/05/17 08:29:27 
> dcoppa Exp $
> : 
> :-Fix includes
> :+Fix includes and react to NWID changes and suspend/resume.
> : 
> : src/drivers/driver_openbsd.c.orig   Sun Sep 27 21:02:05 2015
> :-+++ src/drivers/driver_openbsd.cMon Sep 28 09:51:53 2015
> :-@@ -9,13 +9,14 @@
> :+Index: src/drivers/driver_openbsd.c
> :+--- src/drivers/driver_openbsd.c.orig
> : src/drivers/driver_openbsd.c
> :+@@ -9,19 +9,34 @@
> :  #include "includes.h"
> :  #include 
> :  
> : +#include "common.h"
> : +#include "driver.h"
> :++#include "eloop.h"
> : +
> :++#include 
> :  #include 
> : +#include 
> :++#include 
> :  #include 
> :  #include 
> :  #include 
> :--
> :+ 
> : -#include "common.h"
> : -#include "driver.h"
> :++#define RTM_BUFSZ 2048
> :  
> :  struct openbsd_driver_data {
> :-char ifname[IFNAMSIZ + 1];
> :+-   char ifname[IFNAMSIZ + 1];
> :+void *ctx;
> :+ 
> :+-   int sock;   /* open socket for 802.11 ioctls */
> :++   char ifname[IFNAMSIZ + 1];
> :++   int ifindex;  /* Ifindex of the configured interface */
> :++
> :++   int sock; /* open socket for 802.11 ioctls */
> :++   int rtsock;   /* routing socket for interface state messages */
> :++
> :++   /* These fields are used to track the last seen (and associated) access
> :++   point to determine whether we should kick off an association 
> event */
> :++   int nwid_len; /* Length of last seen SSID (as per routing message) */
> :++   char nwid[IEEE80211_NWID_LEN]; /* Last seen SSID (per routing msg) */
> :++   char addr[IEEE80211_ADDR_LEN]; /* Last seen BSSID (per routing msg) */
> :+ };
> :+ 
> :+ 
> :+@@ -90,10 +105,99 @@ wpa_driver_openbsd_set_key(const char *ifname, void *p
> :+return 0;
> :+ }
> :+ 
> :+-static void *
> :+-wpa_driver_openbsd_init(void *ctx, const char *ifname)
> :++static void
> :++wpa_driver_openbsd_rtmsg_80211(struct if_ieee80211_data *ifie,
> :++   struct openbsd_driver_data *drv) {
> :++   if ((ifie->ifie_nwid_len != drv->nwid_len) ||
> :++   (os_memcmp(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len)) ||
> :++   (os_memcmp(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN))) {
> :++   wpa_printf(MSG_INFO, "SSID changed");
> :++   os_memcpy(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN);
> :++
> :++   os_memcpy(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len);
> :++   drv->nwid_len = ifie->ifie_nwid_len;
> :++
> :++   wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
> :++   }
> :++}
> :++
> :++static void
> :++wpa_driver_openbsd_rtmsg_ifinfo(struct rt_msghdr *rtm,
> :++   struct openbsd_driver_data *drv) {
> :++   /* This is here so we can react to suspend/resume.
> :++
> :++  This is a bit rough, sometimes there are two or more IFINFOs
> :++  notifying us that the device just got "up" again. It doesn't
> :++  

Re: security/wpa_supplicant: Reassoc on NWID change

[Stuart Henderson]

On 2018/12/28 19:05, Peter Hessler wrote:
> I gave this a spin, and seems to work in my testing.
> 
> I did a few suspend/resumes, manual if down/up, forced a chan NN, and
> walked around to do some roaming between 8 bssids.  Recovery took a
> short period of time, but was as expected.
> 
> OK

I'm OK with committing and tweaking later, but ...

> :++   for (offset = 0; offset < n;) {
> :++   rtm = (struct rt_msghdr *)(rtmmsg + offset);
> :++
> :++   if ((size_t)(n - offset) < sizeof(rtm->rtm_msglen) ||
> :++   (n - offset) < rtm->rtm_msglen ||
> :++   rtm->rtm_version != RTM_VERSION)
> :++   goto done;
> :++   offset += rtm->rtm_msglen;

... I'm pretty sure "rtm->rtm_version != RTM_VERSION" should "continue"
as well.

> :++
> :++   if (rtm->rtm_index != drv->ifindex)
> :++   continue;
> :++
> :++   switch (rtm->rtm_type) {
> :++   case RTM_80211INFO:
> :++   ifie = &((struct if_ieee80211_msghdr *)rtm)->ifim_ifie;
> :++   wpa_driver_openbsd_rtmsg_80211(ifie, drv);
> :++   break;
> :++   case RTM_IFINFO:
> :++   wpa_driver_openbsd_rtmsg_ifinfo(rtm, drv);
> :++   break;
> :++   default:
> :++   wpa_printf(MSG_ERROR, "Unexpected route message of type"
> :++  " %d received", rtm->rtm_type);
> :++   break;
> :++   }
> :++   }
> :++
> :++done:
> :++   os_free(rtmmsg);
> :++}
> :++
> :++static void *
> :++wpa_driver_openbsd_init(void *ctx, const char *ifname) {
> :+struct openbsd_driver_data *drv;
> :++   unsigned int rtfilter = ROUTE_FILTER(RTM_80211INFO) | \
> :++   ROUTE_FILTER(RTM_IFINFO);
> :+ 
> :+drv = os_zalloc(sizeof(*drv));
> :+if (drv == NULL)
> :+@@ -103,9 +207,26 @@ wpa_driver_openbsd_init(void *ctx, const char *ifname)
> :+if (drv->sock < 0)
> :+goto fail;
> :+ 
> :++
> :++   drv->rtsock = socket(PF_ROUTE, SOCK_RAW, AF_UNSPEC);
> :++   if (drv->rtsock < 0)
> :++   goto fail;
> :++   if (setsockopt(drv->rtsock, PF_ROUTE, ROUTE_MSGFILTER,
> :++  , sizeof(rtfilter)) == -1)
> :++   goto fail;
> :++
> :+drv->ctx = ctx;
> :+os_strlcpy(drv->ifname, ifname, sizeof(drv->ifname));
> :+ 
> :++   drv->ifindex = if_nametoindex(drv->ifname);
> :++   if (drv->ifindex == 0) /* No interface with that name */
> :++   goto fail;
> :++
> :++   drv->nwid_len = wpa_driver_openbsd_get_ssid(drv, drv->nwid);
> :++   wpa_driver_openbsd_get_bssid(drv, drv->addr);
> :++
> :++   eloop_register_read_sock(drv->rtsock, wpa_driver_openbsd_event_receive,
> :++NULL, drv);
> :+return drv;
> :+ 
> :+ fail:
> :+@@ -119,7 +240,11 @@ wpa_driver_openbsd_deinit(void *priv)
> :+ {
> :+struct openbsd_driver_data *drv = priv;
> :+ 
> :++   eloop_unregister_read_sock(drv->rtsock);
> :++
> :+close(drv->sock);
> :++   close(drv->rtsock);
> :++
> :+os_free(drv);
> :+ }
> :+ 
> :
> 
> -- 
> The camel has a single hump;
> The dromedary two;
> Or else the other way around.
> I'm never sure.  Are you?
>   -- Ogden Nash

Re: security/wpa_supplicant: Reassoc on NWID change

[Peter Hessler]

I gave this a spin, and seems to work in my testing.

I did a few suspend/resumes, manual if down/up, forced a chan NN, and
walked around to do some roaming between 8 bssids.  Recovery took a
short period of time, but was as expected.

OK


On 2018 Dec 28 (Fri) at 17:15:48 +0100 (+0100), Gregor Best wrote:
:
:Peter pointed out that my previous patch doesn't apply. Sorry for that,
:a fixed one is below my signature.
:
:--
:   Gregor
:
:Index: Makefile
:===
:RCS file: /home/cvs/ports/security/wpa_supplicant/Makefile,v
:retrieving revision 1.39
:diff -u -p -r1.39 Makefile
:--- Makefile   24 Oct 2018 17:16:19 -  1.39
:+++ Makefile   25 Dec 2018 23:19:24 -
:@@ -3,7 +3,7 @@
: COMMENT=  IEEE 802.1X supplicant
: 
: DISTNAME= wpa_supplicant-2.6
:-REVISION= 4
:+REVISION= 5
: CATEGORIES=   security net
: 
: HOMEPAGE= http://w1.fi/wpa_supplicant/
:Index: patches/patch-src_drivers_driver_openbsd_c
:===
:RCS file: 
/home/cvs/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
:retrieving revision 1.5
:diff -u -p -r1.5 patch-src_drivers_driver_openbsd_c
:--- patches/patch-src_drivers_driver_openbsd_c 17 May 2016 08:29:27 -  
1.5
:+++ patches/patch-src_drivers_driver_openbsd_c 25 Dec 2018 23:05:46 -
:@@ -1,24 +1,187 @@
: $OpenBSD: patch-src_drivers_driver_openbsd_c,v 1.5 2016/05/17 08:29:27 dcoppa 
Exp $
: 
:-Fix includes
:+Fix includes and react to NWID changes and suspend/resume.
: 
: src/drivers/driver_openbsd.c.orig Sun Sep 27 21:02:05 2015
:-+++ src/drivers/driver_openbsd.c  Mon Sep 28 09:51:53 2015
:-@@ -9,13 +9,14 @@
:+Index: src/drivers/driver_openbsd.c
:+--- src/drivers/driver_openbsd.c.orig
: src/drivers/driver_openbsd.c
:+@@ -9,19 +9,34 @@
:  #include "includes.h"
:  #include 
:  
: +#include "common.h"
: +#include "driver.h"
:++#include "eloop.h"
: +
:++#include 
:  #include 
: +#include 
:++#include 
:  #include 
:  #include 
:  #include 
:--
:+ 
: -#include "common.h"
: -#include "driver.h"
:++#define RTM_BUFSZ 2048
:  
:  struct openbsd_driver_data {
:-  char ifname[IFNAMSIZ + 1];
:+- char ifname[IFNAMSIZ + 1];
:+  void *ctx;
:+ 
:+- int sock;   /* open socket for 802.11 ioctls */
:++ char ifname[IFNAMSIZ + 1];
:++ int ifindex;  /* Ifindex of the configured interface */
:++
:++ int sock; /* open socket for 802.11 ioctls */
:++ int rtsock;   /* routing socket for interface state messages */
:++
:++ /* These fields are used to track the last seen (and associated) access
:++   point to determine whether we should kick off an association 
event */
:++ int nwid_len; /* Length of last seen SSID (as per routing message) */
:++ char nwid[IEEE80211_NWID_LEN]; /* Last seen SSID (per routing msg) */
:++ char addr[IEEE80211_ADDR_LEN]; /* Last seen BSSID (per routing msg) */
:+ };
:+ 
:+ 
:+@@ -90,10 +105,99 @@ wpa_driver_openbsd_set_key(const char *ifname, void *p
:+  return 0;
:+ }
:+ 
:+-static void *
:+-wpa_driver_openbsd_init(void *ctx, const char *ifname)
:++static void
:++wpa_driver_openbsd_rtmsg_80211(struct if_ieee80211_data *ifie,
:++ struct openbsd_driver_data *drv) {
:++ if ((ifie->ifie_nwid_len != drv->nwid_len) ||
:++ (os_memcmp(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len)) ||
:++ (os_memcmp(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN))) {
:++ wpa_printf(MSG_INFO, "SSID changed");
:++ os_memcpy(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN);
:++
:++ os_memcpy(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len);
:++ drv->nwid_len = ifie->ifie_nwid_len;
:++
:++ wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
:++ }
:++}
:++
:++static void
:++wpa_driver_openbsd_rtmsg_ifinfo(struct rt_msghdr *rtm,
:++ struct openbsd_driver_data *drv) {
:++ /* This is here so we can react to suspend/resume.
:++
:++This is a bit rough, sometimes there are two or more IFINFOs
:++notifying us that the device just got "up" again. It doesn't
:++seem to hurt to issue multiple EVENT_ASSOC in those cases
:++though.
:++ */
:++
:++ if (rtm->rtm_flags & RTF_UP)
:++ wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
:++}
:++
:++static void
:++wpa_driver_openbsd_event_receive(int sock, void *global, void *sock_ctx)
:+ {
:++ struct openbsd_driver_data *drv = sock_ctx;
:++ struct rt_msghdr *rtm;
:++ struct if_ieee80211_data *ifie;
:++ char *rtmmsg;
:++ ssize_t n;
:++ off_t offset;
:++
:++ rtmmsg = os_zalloc(RTM_BUFSZ);
:++ if (rtmmsg == NULL) {
:++ wpa_printf(MSG_ERROR, "Can't allocate space for routing msgs");
:++ return;
:++ }
:++
:++ do {
:++ n = read(sock, rtmmsg, RTM_BUFSZ);
:++ } while (n == -1 && errno == 

Re: security/wpa_supplicant: Reassoc on NWID change

[Gregor Best]

Peter pointed out that my previous patch doesn't apply. Sorry for that,
a fixed one is below my signature.

--
Gregor

Index: Makefile
===
RCS file: /home/cvs/ports/security/wpa_supplicant/Makefile,v
retrieving revision 1.39
diff -u -p -r1.39 Makefile
--- Makefile24 Oct 2018 17:16:19 -  1.39
+++ Makefile25 Dec 2018 23:19:24 -
@@ -3,7 +3,7 @@
 COMMENT=   IEEE 802.1X supplicant
 
 DISTNAME=  wpa_supplicant-2.6
-REVISION=  4
+REVISION=  5
 CATEGORIES=security net
 
 HOMEPAGE=  http://w1.fi/wpa_supplicant/
Index: patches/patch-src_drivers_driver_openbsd_c
===
RCS file: 
/home/cvs/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
retrieving revision 1.5
diff -u -p -r1.5 patch-src_drivers_driver_openbsd_c
--- patches/patch-src_drivers_driver_openbsd_c  17 May 2016 08:29:27 -  
1.5
+++ patches/patch-src_drivers_driver_openbsd_c  25 Dec 2018 23:05:46 -
@@ -1,24 +1,187 @@
 $OpenBSD: patch-src_drivers_driver_openbsd_c,v 1.5 2016/05/17 08:29:27 dcoppa 
Exp $
 
-Fix includes
+Fix includes and react to NWID changes and suspend/resume.
 
 src/drivers/driver_openbsd.c.orig  Sun Sep 27 21:02:05 2015
-+++ src/drivers/driver_openbsd.c   Mon Sep 28 09:51:53 2015
-@@ -9,13 +9,14 @@
+Index: src/drivers/driver_openbsd.c
+--- src/drivers/driver_openbsd.c.orig
 src/drivers/driver_openbsd.c
+@@ -9,19 +9,34 @@
  #include "includes.h"
  #include 
  
 +#include "common.h"
 +#include "driver.h"
++#include "eloop.h"
 +
++#include 
  #include 
 +#include 
++#include 
  #include 
  #include 
  #include 
--
+ 
 -#include "common.h"
 -#include "driver.h"
++#define RTM_BUFSZ 2048
  
  struct openbsd_driver_data {
-   char ifname[IFNAMSIZ + 1];
+-  char ifname[IFNAMSIZ + 1];
+   void *ctx;
+ 
+-  int sock;   /* open socket for 802.11 ioctls */
++  char ifname[IFNAMSIZ + 1];
++  int ifindex;  /* Ifindex of the configured interface */
++
++  int sock; /* open socket for 802.11 ioctls */
++  int rtsock;   /* routing socket for interface state messages */
++
++  /* These fields are used to track the last seen (and associated) access
++   point to determine whether we should kick off an association event 
*/
++  int nwid_len; /* Length of last seen SSID (as per routing message) */
++  char nwid[IEEE80211_NWID_LEN]; /* Last seen SSID (per routing msg) */
++  char addr[IEEE80211_ADDR_LEN]; /* Last seen BSSID (per routing msg) */
+ };
+ 
+ 
+@@ -90,10 +105,99 @@ wpa_driver_openbsd_set_key(const char *ifname, void *p
+   return 0;
+ }
+ 
+-static void *
+-wpa_driver_openbsd_init(void *ctx, const char *ifname)
++static void
++wpa_driver_openbsd_rtmsg_80211(struct if_ieee80211_data *ifie,
++  struct openbsd_driver_data *drv) {
++  if ((ifie->ifie_nwid_len != drv->nwid_len) ||
++  (os_memcmp(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len)) ||
++  (os_memcmp(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN))) {
++  wpa_printf(MSG_INFO, "SSID changed");
++  os_memcpy(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN);
++
++  os_memcpy(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len);
++  drv->nwid_len = ifie->ifie_nwid_len;
++
++  wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
++  }
++}
++
++static void
++wpa_driver_openbsd_rtmsg_ifinfo(struct rt_msghdr *rtm,
++  struct openbsd_driver_data *drv) {
++  /* This is here so we can react to suspend/resume.
++
++ This is a bit rough, sometimes there are two or more IFINFOs
++ notifying us that the device just got "up" again. It doesn't
++ seem to hurt to issue multiple EVENT_ASSOC in those cases
++ though.
++  */
++
++  if (rtm->rtm_flags & RTF_UP)
++  wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
++}
++
++static void
++wpa_driver_openbsd_event_receive(int sock, void *global, void *sock_ctx)
+ {
++  struct openbsd_driver_data *drv = sock_ctx;
++  struct rt_msghdr *rtm;
++  struct if_ieee80211_data *ifie;
++  char *rtmmsg;
++  ssize_t n;
++  off_t offset;
++
++  rtmmsg = os_zalloc(RTM_BUFSZ);
++  if (rtmmsg == NULL) {
++  wpa_printf(MSG_ERROR, "Can't allocate space for routing msgs");
++  return;
++  }
++
++  do {
++  n = read(sock, rtmmsg, RTM_BUFSZ);
++  } while (n == -1 && errno == EINTR);
++
++  if (n == -1) {
++  wpa_printf(MSG_ERROR, "Failed to read from routing socket: %s",
++ strerror(errno));
++  goto done;
++  }
++
++  for (offset = 0; offset < n;) {
++  rtm = (struct rt_msghdr *)(rtmmsg + offset);
++
++  if ((size_t)(n - offset) < sizeof(rtm->rtm_msglen) ||
++  

Re: security/wpa_supplicant: Reassoc on NWID change

[Gregor Best]

Stuart Henderson  writes:

> [...]
> Other programs reading messages from the route socket handle this
> slightly differently. They don't treat a read() as a single message,
> instead they loop over it, looking at the first part, deciding whether
> to act on it ("is it the right rtm_version, are we interested in the
> RTM_*?"), if not then they skip rtm_msglen bytes and start again.
> See e.g. rtmsg_process() in usr.sbin/snmpd/kroute.c.
> [...]

FWIW, /usr/src/sbin/dhclient/dhclient.c (in routehandler()) also
attempts to read 2k chunks at a time and handles only the first message
in the buffer. Since "only one route message per read()" isn't
documented in the manpages though, the loop seems to be a good idea.

During my tests, I've only seen exactly one message per read, even if I
tried to get some messages queued by sleeping a few seconds between
read() calls. I've attached a patch based on Peter's latest diff and
your suggestion though, just to be on the safe side.

I've also fixed some lines that were longer than 80 characters and
cleaned the code up a bit and as usual, any feedback is highly
appreciated there.

While preparing this patch, I played around a bit with the read loop, at
first reading only sizeof(struct rt_msghdr) bytes from the routing
socket and then reading the remaining (sizeof(struct rt_msghdr) -
rtm->rtm_msglen) bytes.

For RTM_IFINFO that worked fine, but for RTM_80211INFO, that resulted in
an RTM header with rtm->rtm_msglen of 64, which is way shorter than even
the header (96 bytes) spread over two read() calls, one returning 64
bytes, the other 32. I'm not really sure what I was holding wrong there.

Things work fine if I try to read at least rtm->rtm_msglen bytes though,
so I've stayed with attempting to read 2048 bytes.

--
Gregor

Index: Makefile
===
RCS file: /home/cvs/ports/security/wpa_supplicant/Makefile,v
retrieving revision 1.39
diff -u -p -r1.39 Makefile
--- Makefile24 Oct 2018 17:16:19 -  1.39
+++ Makefile25 Dec 2018 23:19:24 -
@@ -3,7 +3,7 @@
 COMMENT=   IEEE 802.1X supplicant

 DISTNAME=  wpa_supplicant-2.6
-REVISION=  4
+REVISION=  5
 CATEGORIES=security net

 HOMEPAGE=  http://w1.fi/wpa_supplicant/
Index: patches/patch-src_drivers_driver_openbsd_c
===
RCS file: 
/home/cvs/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
retrieving revision 1.5
diff -u -p -r1.5 patch-src_drivers_driver_openbsd_c
--- patches/patch-src_drivers_driver_openbsd_c  17 May 2016 08:29:27 -  
1.5
+++ patches/patch-src_drivers_driver_openbsd_c  25 Dec 2018 23:05:46 -
@@ -1,24 +1,187 @@
 $OpenBSD: patch-src_drivers_driver_openbsd_c,v 1.5 2016/05/17 08:29:27 dcoppa 
Exp $

-Fix includes
+Fix includes and react to NWID changes and suspend/resume.

 src/drivers/driver_openbsd.c.orig  Sun Sep 27 21:02:05 2015
-+++ src/drivers/driver_openbsd.c   Mon Sep 28 09:51:53 2015
-@@ -9,13 +9,14 @@
+Index: src/drivers/driver_openbsd.c
+--- src/drivers/driver_openbsd.c.orig
 src/drivers/driver_openbsd.c
+@@ -9,19 +9,34 @@
  #include "includes.h"
  #include 

 +#include "common.h"
 +#include "driver.h"
++#include "eloop.h"
 +
++#include 
  #include 
 +#include 
++#include 
  #include 
  #include 
  #include 
--
+
 -#include "common.h"
 -#include "driver.h"
++#define RTM_BUFSZ 2048

  struct openbsd_driver_data {
-   char ifname[IFNAMSIZ + 1];
+-  char ifname[IFNAMSIZ + 1];
+   void *ctx;
+
+-  int sock;   /* open socket for 802.11 ioctls */
++  char ifname[IFNAMSIZ + 1];
++  int ifindex;  /* Ifindex of the configured interface */
++
++  int sock; /* open socket for 802.11 ioctls */
++  int rtsock;   /* routing socket for interface state messages */
++
++  /* These fields are used to track the last seen (and associated) access
++   point to determine whether we should kick off an association event 
*/
++  int nwid_len; /* Length of last seen SSID (as per routing message) */
++  char nwid[IEEE80211_NWID_LEN]; /* Last seen SSID (per routing msg) */
++  char addr[IEEE80211_ADDR_LEN]; /* Last seen BSSID (per routing msg) */
+ };
+
+
+@@ -90,10 +105,99 @@ wpa_driver_openbsd_set_key(const char *ifname, void *p
+   return 0;
+ }
+
+-static void *
+-wpa_driver_openbsd_init(void *ctx, const char *ifname)
++static void
++wpa_driver_openbsd_rtmsg_80211(struct if_ieee80211_data *ifie,
++  struct openbsd_driver_data *drv) {
++  if ((ifie->ifie_nwid_len != drv->nwid_len) ||
++  (os_memcmp(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len)) ||
++  (os_memcmp(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN))) {
++  wpa_printf(MSG_INFO, "SSID changed");
++  os_memcpy(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN);
++
++  os_memcpy(drv->nwid, ifie->ifie_nwid, 

Re: security/wpa_supplicant: Reassoc on NWID change

[Gregor Best]

Hi,

> [...]
> I've started using this at 35C3, and it mostly works for me.
> [...]

Great to hear, using it at the congress was my motivation for adding
this in the first place :)

> The one thing it doesn't handle for me is when I change the lladdr, but
> I have some ideas for it.
>
> I fixed the whitespace, and changed the main bit to use a switch instead
> of an if elseif dance.
>
> This is what I am running right now, what do you think?
> [...]

Looks good to me, though I'll update this with Stuart's suggestion
(skipping only single messages instead of whole reads from the routing
socket) tomorrow.

--
Gregor


signature.asc
Description: PGP signature

Re: security/wpa_supplicant: Reassoc on NWID change

[Stuart Henderson]

> ++static void
> ++wpa_driver_openbsd_event_receive(int sock, void *global, void *sock_ctx)
> ++{
> ++struct openbsd_driver_data *drv = sock_ctx;
> ++struct rt_msghdr *rtm;
> ++struct if_ieee80211_data *ifie;
> ++char *rtmmsg;
> ++ssize_t n;
> ++
> ++rtmmsg = os_zalloc(RTM_READSZ);
> ++if (rtmmsg == NULL) {
> ++wpa_printf(MSG_ERROR, "Can't allocate space for routing 
> message");
> ++return;
> ++}
> ++
> ++do {
> ++n = read(sock, rtmmsg, RTM_READSZ);
> ++} while (n == -1 && errno == EINTR);
> ++
> ++if (n == -1)
> ++goto done;
> ++
> ++rtm = (struct rt_msghdr *)rtmmsg;
> ++
> ++if ((size_t)n < sizeof(rtm->rtm_msglen) ||
> ++n < rtm->rtm_msglen ||
> ++rtm->rtm_version != RTM_VERSION)
> ++goto done;

Other programs reading messages from the route socket handle this
slightly differently. They don't treat a read() as a single message,
instead they loop over it, looking at the first part, deciding whether
to act on it ("is it the right rtm_version, are we interested in the
RTM_*?"), if not then they skip rtm_msglen bytes and start again.
See e.g. rtmsg_process() in usr.sbin/snmpd/kroute.c.


> ++
> ++if (rtm->rtm_index != drv->ifindex)
> ++goto done;
> ++
> ++switch (rtm->rtm_type) {
> ++case RTM_80211INFO:
> ++ifie = &((struct if_ieee80211_msghdr *)rtm)->ifim_ifie;
> ++
> ++if ((ifie->ifie_nwid_len != drv->nwid_len) ||
> ++(os_memcmp(drv->nwid, ifie->ifie_nwid,
> ++ifie->ifie_nwid_len) != 0) ||
> ++(os_memcmp(drv->addr, ifie->ifie_addr,
> ++IEEE80211_ADDR_LEN) != 0)) {
> ++os_memcpy(drv->addr, ifie->ifie_addr,
> ++IEEE80211_ADDR_LEN);
> ++
> ++os_memcpy(drv->nwid, ifie->ifie_nwid,
> ++ifie->ifie_nwid_len);
> ++drv->nwid_len = ifie->ifie_nwid_len;
> ++
> ++/* Emit ASSOC event */
> ++wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
> ++}
> ++break;
> ++case RTM_IFINFO:
> ++/* This is here so we can react to suspend/resume.
> ++ * 
> ++ * This is a bit rough, sometimes there are two or more
> ++ * IFINFOs notifying us that the device just got "up"
> ++ * again. It doesn't seem to hurt to issue multiple
> ++ * EVENT_ASSOC in those cases though.
> ++ */
> ++if (rtm->rtm_flags & RTF_UP)
> ++wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
> ++break;
> ++default:
> ++;;
> ++}
> ++
> ++
> ++done:
> ++os_free(rtmmsg);
> ++}
> ++
> + static void *
> + wpa_driver_openbsd_init(void *ctx, const char *ifname)
> + {
> +@@ -103,9 +190,21 @@ wpa_driver_openbsd_init(void *ctx, const char *ifname)
> + if (drv->sock < 0)
> + goto fail;
> + 
> ++drv->rtsock = socket(PF_ROUTE, SOCK_RAW, AF_UNSPEC);
> ++if (drv->rtsock < 0)
> ++goto fail;
> ++
> + drv->ctx = ctx;
> + os_strlcpy(drv->ifname, ifname, sizeof(drv->ifname));
> + 
> ++drv->ifindex = if_nametoindex(drv->ifname);
> ++if (drv->ifindex == 0) /* No interface with that name */
> ++goto fail;
> ++
> ++drv->nwid_len = wpa_driver_openbsd_get_ssid(drv, drv->nwid);
> ++wpa_driver_openbsd_get_bssid(drv, drv->addr);
> ++
> ++eloop_register_read_sock(drv->rtsock, wpa_driver_openbsd_event_receive, 
> NULL, drv);
> + return drv;
> + 
> + fail:
> +@@ -119,7 +218,11 @@ wpa_driver_openbsd_deinit(void *priv)
> + {
> + struct openbsd_driver_data *drv = priv;
> + 
> ++eloop_unregister_read_sock(drv->rtsock);
> ++
> + close(drv->sock);
> ++close(drv->rtsock);
> ++
> + os_free(drv);
> + }
> + 
> 
> 
> 
> On 2018 Dec 13 (Thu) at 19:30:11 +0100 (+0100), Gregor Best wrote:
> :
> :Hi Mikolaj et al,
> :
> :Mikolaj Kucharski  writes:
> :
> :>
> :> Here is debug output of one day session, with suspend in the middle
> :> when going home, back to work and home again.
> :> [...]
> :> Tomorrow I may give you example of above log when walking around the
> :> office, to compare events while switching APs.
> :> [...]
> :
> :That'd be good, thank you.
> :
> :> The other day I did testing by walking around and it works most of the
> :> time, however there is a race somewhere, as while I was walking around
> :> I sometimes ended up without connection and ifconfig(8) at the same
> :> time was showing:
> :>
> :>status: active
> :>ieee80211: join lighthouse chan 100 bssid  dBm 
> wpaprotos wpa2 wpaakms 802.1x wpaciphers ccmp wpagroupcipher ccmp
> :>
> :> like network should work, but it didn't and connection was totally
> :> offline.
> :
> :> This is very empirical, but it looked to me, when I walked
> :> slower to give wpa_supplicant time to reassoc with 

Re: security/wpa_supplicant: Reassoc on NWID change

[Peter Hessler]

I've started using this at 35C3, and it mostly works for me.

The one thing it doesn't handle for me is when I change the lladdr, but
I have some ideas for it.

I fixed the whitespace, and changed the main bit to use a switch instead
of an if elseif dance.

This is what I am running right now, what do you think?



Index: Makefile
===
RCS file: /cvs/openbsd/ports/security/wpa_supplicant/Makefile,v
retrieving revision 1.39
diff -u -p -u -p -r1.39 Makefile
--- Makefile24 Oct 2018 17:16:19 -  1.39
+++ Makefile20 Dec 2018 19:37:31 -
@@ -3,7 +3,7 @@
 COMMENT=   IEEE 802.1X supplicant
 
 DISTNAME=  wpa_supplicant-2.6
-REVISION=  4
+REVISION=  5
 CATEGORIES=security net
 
 HOMEPAGE=  http://w1.fi/wpa_supplicant/
Index: patches/patch-src_drivers_driver_openbsd_c
===
RCS file: 
/cvs/openbsd/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 patch-src_drivers_driver_openbsd_c
--- patches/patch-src_drivers_driver_openbsd_c  17 May 2016 08:29:27 -  
1.5
+++ patches/patch-src_drivers_driver_openbsd_c  24 Dec 2018 22:46:25 -
@@ -1,24 +1,159 @@
 $OpenBSD: patch-src_drivers_driver_openbsd_c,v 1.5 2016/05/17 08:29:27 dcoppa 
Exp $
 
-Fix includes
+Fix includes and react to NWID changes and suspend/resume.
 
 src/drivers/driver_openbsd.c.orig  Sun Sep 27 21:02:05 2015
-+++ src/drivers/driver_openbsd.c   Mon Sep 28 09:51:53 2015
-@@ -9,13 +9,14 @@
+Index: src/drivers/driver_openbsd.c
+--- src/drivers/driver_openbsd.c.orig
 src/drivers/driver_openbsd.c
+@@ -9,19 +9,34 @@
  #include "includes.h"
  #include 
  
 +#include "common.h"
 +#include "driver.h"
++#include "eloop.h"
 +
++#include 
  #include 
 +#include 
++#include 
  #include 
  #include 
  #include 
--
+ 
 -#include "common.h"
 -#include "driver.h"
++#define RTM_READSZ 2048
  
  struct openbsd_driver_data {
-   char ifname[IFNAMSIZ + 1];
+-  char ifname[IFNAMSIZ + 1];
+   void *ctx;
+ 
+-  int sock;   /* open socket for 802.11 ioctls */
++  char ifname[IFNAMSIZ + 1];
++  int ifindex;  /* Ifindex of the configured interface */
++
++  int sock; /* open socket for 802.11 ioctls */
++  int rtsock;   /* routing socket for interface state messages */
++
++  /* These fields are used to track the last seen (and associated) access 
point
++ to determine whether we should kick off an association event */
++  int nwid_len; /* Length of last seen SSID (as per routing message) */
++  char nwid[IEEE80211_NWID_LEN]; /* Last seen SSID (as per routing 
message) */
++  char addr[IEEE80211_ADDR_LEN]; /* Last seen BSSID (as per routing 
message) */
+ };
+ 
+ 
+@@ -90,6 +105,78 @@ wpa_driver_openbsd_set_key(const char *ifname, void *p
+   return 0;
+ }
+ 
++static void
++wpa_driver_openbsd_event_receive(int sock, void *global, void *sock_ctx)
++{
++  struct openbsd_driver_data *drv = sock_ctx;
++  struct rt_msghdr *rtm;
++  struct if_ieee80211_data *ifie;
++  char *rtmmsg;
++  ssize_t n;
++
++  rtmmsg = os_zalloc(RTM_READSZ);
++  if (rtmmsg == NULL) {
++  wpa_printf(MSG_ERROR, "Can't allocate space for routing 
message");
++  return;
++  }
++
++  do {
++  n = read(sock, rtmmsg, RTM_READSZ);
++  } while (n == -1 && errno == EINTR);
++
++  if (n == -1)
++  goto done;
++
++  rtm = (struct rt_msghdr *)rtmmsg;
++
++  if ((size_t)n < sizeof(rtm->rtm_msglen) ||
++  n < rtm->rtm_msglen ||
++  rtm->rtm_version != RTM_VERSION)
++  goto done;
++
++  if (rtm->rtm_index != drv->ifindex)
++  goto done;
++
++  switch (rtm->rtm_type) {
++  case RTM_80211INFO:
++  ifie = &((struct if_ieee80211_msghdr *)rtm)->ifim_ifie;
++
++  if ((ifie->ifie_nwid_len != drv->nwid_len) ||
++  (os_memcmp(drv->nwid, ifie->ifie_nwid,
++  ifie->ifie_nwid_len) != 0) ||
++  (os_memcmp(drv->addr, ifie->ifie_addr,
++  IEEE80211_ADDR_LEN) != 0)) {
++  os_memcpy(drv->addr, ifie->ifie_addr,
++  IEEE80211_ADDR_LEN);
++
++  os_memcpy(drv->nwid, ifie->ifie_nwid,
++  ifie->ifie_nwid_len);
++  drv->nwid_len = ifie->ifie_nwid_len;
++
++  /* Emit ASSOC event */
++  wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
++  }
++  break;
++  case RTM_IFINFO:
++  /* This is here so we can react to suspend/resume.
++   * 
++   * This is a bit rough, sometimes there are two or more
++   * IFINFOs notifying us that the device just got "up"
++   * 

Re: security/wpa_supplicant: Reassoc on NWID change

[Gregor Best]

Hi Mikolaj et al,

Mikolaj Kucharski  writes:

>
> Here is debug output of one day session, with suspend in the middle
> when going home, back to work and home again.
> [...]
> Tomorrow I may give you example of above log when walking around the
> office, to compare events while switching APs.
> [...]

That'd be good, thank you.

> The other day I did testing by walking around and it works most of the
> time, however there is a race somewhere, as while I was walking around
> I sometimes ended up without connection and ifconfig(8) at the same
> time was showing:
>
>   status: active
>   ieee80211: join lighthouse chan 100 bssid  dBm 
> wpaprotos wpa2 wpaakms 802.1x wpaciphers ccmp wpagroupcipher ccmp
>
> like network should work, but it didn't and connection was totally
> offline.

> This is very empirical, but it looked to me, when I walked
> slower to give wpa_supplicant time to reassoc with each access point on
> the way it all worked. When I got bored and walked faster, passing by
> multiple APs on the way and with reassocs happening one after another,
> before previous assoc was able to finish and me finally stopping, I
> ended up with iwn0 card with status active, but no connectivity.
> Restarting slaacd(8) or dhclient(8) was not helping as problem was layer
> below them.
> [...]

Yeah, I've got the feeling that wpa_supplicant really doesn't like
getting poked while it's doing its thing. Maybe I've got to work on the
timing here a bit or sort of deduplicate ASSOC events after multiple
IFINFO/802INFO are received.

> [...]
> I think your diff makes sense and with handling of RTM_IFINFO it's good
> progress in correct direction. I even took your diff and tested with
> latest wpa_supplicant 2.7 and it works there too.
> [...]

That is good to hear. I'm planning on sending this upstream as soon as
we've agreed it's more or less working.

> [...]
> If you would like to see any specific info tomorrow, please let me know
> I will try to arrange something. After that I'll go offline for family
> time.
> [...]

I'm afraid I don't have anything more specific I could ask you to test.
Thanks a bunch for your help this far. I'll just have to walk around my
university some time next week, I'm not at work then anyway :)

> [...]
>> ++  if (rtm->rtm_type == RTM_80211INFO) {
>> ++printf("RTM_80211INFO received\n");
>
> This printf(3) should be removed or changed into wpa_printf(). For my tests
> I've used wpa_printf(MSG_DEBUG, ...), which I think is good enough balance
> of being not noisy in logs by default, but still providing info when there
> is a need via debug flag to the cli. However this is your call and giving
> the current sparsity of debug log lines in this c-file, I would just remove
> it.
> [...]

Absolutely. This was an oversight that I wanted to remove before sending
out the patch. Same for the weird indentation :)

--
Gregor


signature.asc
Description: PGP signature

Re: security/wpa_supplicant: Reassoc on NWID change

[Mikolaj Kucharski]

Gregor,

Thank you for working on this. I have one comment about your code,
comments inlined in your below diff.

Here is debug output of one day session, with suspend in the middle
when going home, back to work and home again.

# grep -E 'type=0x(15|e)' wpa_supplicant.log
1544550580.320374: XXX evnt_rcv: name=iwn0, type=0x15
1544550580.321089: XXX evnt_rcv: name=iwn0, type=0xe
1544558742.024184: XXX evnt_rcv: name=iwn0, type=0xe
1544558753.880521: XXX evnt_rcv: name=iwn0, type=0x15
1544558753.883372: XXX evnt_rcv: name=iwn0, type=0xe
1544612208.200216: XXX evnt_rcv: name=iwn0, type=0xe
1544612217.053147: XXX evnt_rcv: name=iwn0, type=0x15
1544612217.053676: XXX evnt_rcv: name=iwn0, type=0xe
1544648478.023587: XXX evnt_rcv: name=iwn0, type=0xe

Above is while being sationary and not going around in the office.
This means that I switched only between AP closest to my desk and
to home AP with resume in between. Interestingly it seems that
each RTM_80211INFO is also accompanied with RTM_IFINFO, in random
order.

Tomorrow I may give you example of above log when walking around the
office, to compare events while switching APs. The other day I did
testing by walking around and it works most of the time, however there
is a race somewhere, as while I was walking around I sometimes ended up
without connection and ifconfig(8) at the same time was showing:

status: active
ieee80211: join lighthouse chan 100 bssid  dBm 
wpaprotos wpa2 wpaakms 802.1x wpaciphers ccmp wpagroupcipher ccmp

like network should work, but it didn't and connection was totally
offline. This is very empirical, but it looked to me, when I walked
slower to give wpa_supplicant time to reassoc with each access point on
the way it all worked. When I got bored and walked faster, passing by
multiple APs on the way and with reassocs happening one after another,
before previous assoc was able to finish and me finally stopping, I
ended up with iwn0 card with status active, but no connectivity.
Restarting slaacd(8) or dhclient(8) was not helping as problem was layer
below them.

All in all, I would need to test all of this more and collect more debug
information. Unfortunately this is my last week with my current employer,
so in practice tomorrow is my last day I can test all of this :)

I think your diff makes sense and with handling of RTM_IFINFO it's good
progress in correct direction. I even took your diff and tested with
latest wpa_supplicant 2.7 and it works there too. However I cannot
dive into this more, as I have too many changes in my personal and
professional life in coming days.

If you would like to see any specific info tomorrow, please let me know
I will try to arrange something. After that I'll go offline for family
time.

See comments inline your diff below.

Regards,
 Mikolaj

On Wed, Dec 12, 2018 at 09:44:24PM +0100, Gregor Best wrote:
> 
> Hi Edd, Raf, Mikolaj, ports@
> 
> I just updated my proposed patch with Mikolaj's suggestion of also
> listening to RTM_IFINFO instead of just RTM_80211INFO. The patch is
> attached below the signature.
> 
> It makes reassociation over suspend/resume work (if I resume in the
> same spot I suspended in, haven't checked going out of range). What's
> noteworthy is that it takes a while (in the area of 10 - 15 seconds)
> for wpa_supplicant to re-establish a connection.
> 
> As for Edd's report that moving out of range with the device on doesn't
> cause re-association (did I understand that correctly?), I think the
> output of `route monitor` and `ifconfig $dev scan` before and after
> loss of signal (and going into range of the other AP) might be
> interesting to see if there's another routing message that we have to
> consider.
> 
> Maybe the attached patch also helps Edd's situation. As always, I'm
> grateful for testing and feedback.
> 
> -- 
>   Gregor
> 
> Index: patches/patch-src_drivers_driver_openbsd_c
> ===
> RCS file: 
> /home/cvs/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
> retrieving revision 1.5
> diff -u -p -r1.5 patch-src_drivers_driver_openbsd_c
> --- patches/patch-src_drivers_driver_openbsd_c17 May 2016 08:29:27 
> -  1.5
> +++ patches/patch-src_drivers_driver_openbsd_c12 Dec 2018 20:18:19 
> -
> @@ -1,24 +1,151 @@
>  $OpenBSD: patch-src_drivers_driver_openbsd_c,v 1.5 2016/05/17 08:29:27 
> dcoppa Exp $
>  
> -Fix includes
> +Fix includes and react to NWID changes and suspend/resume.
>  
>  src/drivers/driver_openbsd.c.origSun Sep 27 21:02:05 2015
> -+++ src/drivers/driver_openbsd.c Mon Sep 28 09:51:53 2015
> -@@ -9,13 +9,14 @@
> +Index: src/drivers/driver_openbsd.c
> +--- src/drivers/driver_openbsd.c.orig
>  src/drivers/driver_openbsd.c
> +@@ -9,19 +9,34 @@
>   #include "includes.h"
>   #include 
> - 
> +
>  +#include "common.h"
>  +#include "driver.h"
> ++#include "eloop.h"
>  +
> ++#include 
>   #include 
>  +#include 
> 

Re: security/wpa_supplicant: Reassoc on NWID change

[Gregor Best]

Hi Edd, Raf, Mikolaj, ports@

I just updated my proposed patch with Mikolaj's suggestion of also
listening to RTM_IFINFO instead of just RTM_80211INFO. The patch is
attached below the signature.

It makes reassociation over suspend/resume work (if I resume in the
same spot I suspended in, haven't checked going out of range). What's
noteworthy is that it takes a while (in the area of 10 - 15 seconds)
for wpa_supplicant to re-establish a connection.

As for Edd's report that moving out of range with the device on doesn't
cause re-association (did I understand that correctly?), I think the
output of `route monitor` and `ifconfig $dev scan` before and after
loss of signal (and going into range of the other AP) might be
interesting to see if there's another routing message that we have to
consider.

Maybe the attached patch also helps Edd's situation. As always, I'm
grateful for testing and feedback.

-- 
Gregor

Index: patches/patch-src_drivers_driver_openbsd_c
===
RCS file: 
/home/cvs/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
retrieving revision 1.5
diff -u -p -r1.5 patch-src_drivers_driver_openbsd_c
--- patches/patch-src_drivers_driver_openbsd_c  17 May 2016 08:29:27 -  
1.5
+++ patches/patch-src_drivers_driver_openbsd_c  12 Dec 2018 20:18:19 -
@@ -1,24 +1,151 @@
 $OpenBSD: patch-src_drivers_driver_openbsd_c,v 1.5 2016/05/17 08:29:27 dcoppa 
Exp $
 
-Fix includes
+Fix includes and react to NWID changes and suspend/resume.
 
 src/drivers/driver_openbsd.c.orig  Sun Sep 27 21:02:05 2015
-+++ src/drivers/driver_openbsd.c   Mon Sep 28 09:51:53 2015
-@@ -9,13 +9,14 @@
+Index: src/drivers/driver_openbsd.c
+--- src/drivers/driver_openbsd.c.orig
 src/drivers/driver_openbsd.c
+@@ -9,19 +9,34 @@
  #include "includes.h"
  #include 
- 
+
 +#include "common.h"
 +#include "driver.h"
++#include "eloop.h"
 +
++#include 
  #include 
 +#include 
++#include 
  #include 
  #include 
  #include 
--
+
 -#include "common.h"
 -#include "driver.h"
- 
++#define RTM_READSZ 2048
+
  struct openbsd_driver_data {
-   char ifname[IFNAMSIZ + 1];
+-  char ifname[IFNAMSIZ + 1];
+   void *ctx;
+
+-  int sock;   /* open socket for 802.11 ioctls */
++  char ifname[IFNAMSIZ + 1];
++  int ifindex;  /* Ifindex of the configured interface */
++
++  int sock; /* open socket for 802.11 ioctls */
++  int rtsock;   /* routing socket for interface state messages */
++
++  /* These fields are used to track the last seen (and associated) access 
point
++ to determine whether we should kick off an association event */
++  int nwid_len; /* Length of last seen SSID (as per routing message) */
++  char nwid[IEEE80211_NWID_LEN]; /* Last seen SSID (as per routing 
message) */
++  char addr[IEEE80211_ADDR_LEN]; /* Last seen BSSID (as per routing 
message) */
+ };
+
+
+@@ -90,6 +105,71 @@ wpa_driver_openbsd_set_key(const char *ifname, void *p
+   return 0;
+ }
+
++static void
++wpa_driver_openbsd_event_receive(int sock, void *global, void *sock_ctx)
++{
++  struct openbsd_driver_data *drv = sock_ctx;
++  struct rt_msghdr *rtm;
++  struct if_ieee80211_data *ifie;
++  char *rtmmsg;
++  ssize_t n;
++
++  rtmmsg = os_zalloc(RTM_READSZ);
++  if (rtmmsg == NULL) {
++  wpa_printf(MSG_ERROR, "Can't allocate space for routing 
message");
++  return;
++  }
++
++  do {
++  n = read(sock, rtmmsg, RTM_READSZ);
++  } while (n == -1 && errno == EINTR);
++
++  if (n == -1)
++  goto done;
++
++  rtm = (struct rt_msghdr *)rtmmsg;
++
++  if ((size_t)n < sizeof(rtm->rtm_msglen) ||
++  n < rtm->rtm_msglen ||
++  rtm->rtm_version != RTM_VERSION)
++  goto done;
++
++  if (rtm->rtm_index != drv->ifindex)
++goto done;
++
++  if (rtm->rtm_type == RTM_80211INFO) {
++printf("RTM_80211INFO received\n");
++ifie = &((struct if_ieee80211_msghdr *)rtm)->ifim_ifie;
++
++if ((ifie->ifie_nwid_len != drv->nwid_len) ||
++(os_memcmp(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len) != 0) ||
++(os_memcmp(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN) != 0)) {
++  os_memcpy(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN);
++
++  os_memcpy(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len);
++  drv->nwid_len = ifie->ifie_nwid_len;
++
++  /* Emit ASSOC event */
++  wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
++}
++  } else if (rtm->rtm_type == RTM_IFINFO) {
++/* This is here so we can react to suspend/resume.
++
++   This is a bit rough, sometimes there are two or more IFINFOs notifying
++   us that the device just got "up" again. It doesn't seem to hurt to
++   issue multiple EVENT_ASSOC in those cases though.
++*/
++
++if (rtm->rtm_flags & RTF_UP) {
++  /* Emit ASSOC event */

Re: security/wpa_supplicant: Reassoc on NWID change

[Gregor Best]

Hi Mikolaj,

> [...]
> I'm currently testing your diff with additional condition to also
> handle RTM_IFINFO, as I see it happening just after resume:
>
> 1544537117.597172: XXX wpa_driver_openbsd_event_receive() start
> 1544537117.597197: XXX evnt_rcv: name=iwn0, type=0xe
> [...]

Good idea. How does it work for you? I'll add this to my patch as well
and try it a bit tonight.

--
Gregor


signature.asc
Description: PGP signature

Re: security/wpa_supplicant: Reassoc on NWID change

[Edd Barrett]

On Tue, Dec 11, 2018 at 05:19:26PM +, Raf Czlonka wrote:
> For me this happened *only* after going back near the AP the laptop
> originally associated with.

Ah yes. As it happens, that was when I did it too!

Sorry, I wasn't clear.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: security/wpa_supplicant: Reassoc on NWID change

[Raf Czlonka]

On Tue, Dec 11, 2018 at 11:35:42AM GMT, Edd Barrett wrote:
> On Mon, Dec 10, 2018 at 04:31:02PM +, Raf Czlonka wrote:
> > Hi Gregor,
> > 
> > When I boot my laptop up, it connects to eduroam just fine.
> > 
> > However, when I move around the building, it does not associate
> > with any other AP.
> 
> This was my experience too.
> 
> It seems that you can sometimes jump back on the network by running:
> $ wpa_cli reassoc
> 

Hi Edd,

For me this happened *only* after going back near the AP the laptop
originally associated with.

Regards,

Raf

Re: security/wpa_supplicant: Reassoc on NWID change

[Mikolaj Kucharski]

Comment inlined about RTM_IFINFO

On Wed, Nov 28, 2018 at 06:56:46PM +0100, Gregor Best wrote:
> Index: patches/patch-src_drivers_driver_openbsd_c
> ===
> RCS file: 
> /home/cvs/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
> retrieving revision 1.5
> diff -u -p -r1.5 patch-src_drivers_driver_openbsd_c
> --- patches/patch-src_drivers_driver_openbsd_c17 May 2016 08:29:27 
> -  1.5
> +++ patches/patch-src_drivers_driver_openbsd_c28 Nov 2018 17:51:30 
> -
> @@ -2,23 +2,137 @@ $OpenBSD: patch-src_drivers_driver_openb
>  
>  Fix includes
>  
>  src/drivers/driver_openbsd.c.origSun Sep 27 21:02:05 2015
> -+++ src/drivers/driver_openbsd.c Mon Sep 28 09:51:53 2015
> -@@ -9,13 +9,14 @@
> +Index: src/drivers/driver_openbsd.c
> +--- src/drivers/driver_openbsd.c.orig
>  src/drivers/driver_openbsd.c
> +@@ -9,19 +9,34 @@
>   #include "includes.h"
>   #include 
>   
>  +#include "common.h"
>  +#include "driver.h"
> ++#include "eloop.h"
>  +
> ++#include 
>   #include 
>  +#include 
> ++#include 
>   #include 
>   #include 
>   #include 
> --
> + 
>  -#include "common.h"
>  -#include "driver.h"
> ++#define RTM_READSZ 2048
>   
>   struct openbsd_driver_data {
> - char ifname[IFNAMSIZ + 1];
> +-char ifname[IFNAMSIZ + 1];
> + void *ctx;
> + 
> +-int sock;   /* open socket for 802.11 ioctls */
> ++char ifname[IFNAMSIZ + 1];
> ++int ifindex;  /* Ifindex of the configured interface */
> ++
> ++int sock; /* open socket for 802.11 ioctls */
> ++int rtsock;   /* routing socket for interface state messages */
> ++
> ++/* These fields are used to track the last seen (and associated) access 
> point
> ++   to determine whether we should kick off an association event */
> ++int nwid_len; /* Length of last seen SSID (as per routing message) */
> ++char nwid[IEEE80211_NWID_LEN]; /* Last seen SSID (as per routing 
> message) */
> ++char addr[IEEE80211_ADDR_LEN]; /* Last seen BSSID (as per routing 
> message) */
> + };
> + 
> + 
> +@@ -90,6 +105,57 @@ wpa_driver_openbsd_set_key(const char *ifname, void *p
> + return 0;
> + }
> + 
> ++static void
> ++wpa_driver_openbsd_event_receive(int sock, void *global, void *sock_ctx)
> ++{
> ++struct openbsd_driver_data *drv = sock_ctx;
> ++struct rt_msghdr *rtm;
> ++struct if_ieee80211_data *ifie;
> ++char *rtmmsg;
> ++ssize_t n;
> ++
> ++rtmmsg = os_zalloc(RTM_READSZ);
> ++if (rtmmsg == NULL) {
> ++wpa_printf(MSG_ERROR, "Can't allocate space for routing 
> message");
> ++return;
> ++}
> ++
> ++do {
> ++n = read(sock, rtmmsg, RTM_READSZ);
> ++} while (n == -1 && errno == EINTR);
> ++
> ++if (n == -1)
> ++goto done;
> ++
> ++rtm = (struct rt_msghdr *)rtmmsg;
> ++
> ++if ((size_t)n < sizeof(rtm->rtm_msglen) ||
> ++n < rtm->rtm_msglen ||
> ++rtm->rtm_version != RTM_VERSION)
> ++goto done;
> ++
> ++if ((rtm->rtm_type != RTM_80211INFO) ||

I'm currently testing your diff with additional condition to also
handle RTM_IFINFO, as I see it happening just after resume:

1544537117.597172: XXX wpa_driver_openbsd_event_receive() start
1544537117.597197: XXX evnt_rcv: name=iwn0, type=0xe

> ++(rtm->rtm_index != drv->ifindex))
> ++goto done;
> ++
> ++ifie = &((struct if_ieee80211_msghdr *)rtm)->ifim_ifie;
> ++
> ++if ((ifie->ifie_nwid_len != drv->nwid_len) ||
> ++(os_memcmp(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len) != 0) ||
> ++(os_memcmp(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN) != 0)) {
> ++os_memcpy(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN);
> ++
> ++os_memcpy(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len);
> ++drv->nwid_len = ifie->ifie_nwid_len;
> ++
> ++/* Emit ASSOC event */
> ++wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
> ++}
> ++
> ++done:
> ++os_free(rtmmsg);
> ++}
> ++
> + static void *
> + wpa_driver_openbsd_init(void *ctx, const char *ifname)
> + {
> +@@ -103,9 +169,21 @@ wpa_driver_openbsd_init(void *ctx, const char *ifname)
> + if (drv->sock < 0)
> + goto fail;
> + 
> ++drv->rtsock = socket(PF_ROUTE, SOCK_RAW, AF_UNSPEC);
> ++if (drv->rtsock < 0)
> ++goto fail;
> ++
> + drv->ctx = ctx;
> + os_strlcpy(drv->ifname, ifname, sizeof(drv->ifname));
> + 
> ++drv->ifindex = if_nametoindex(drv->ifname);
> ++if (drv->ifindex == 0) /* No interface with that name */
> ++goto fail;
> ++
> ++drv->nwid_len = wpa_driver_openbsd_get_ssid(drv, drv->nwid);
> ++wpa_driver_openbsd_get_bssid(drv, drv->addr);
> ++
> ++eloop_register_read_sock(drv->rtsock, wpa_driver_openbsd_event_receive, 
> NULL, drv);
> + return drv;
> + 
> + fail:
> +@@ -119,7 +197,11 @@ 

Re: security/wpa_supplicant: Reassoc on NWID change

[Edd Barrett]

On Mon, Dec 10, 2018 at 04:31:02PM +, Raf Czlonka wrote:
> Hi Gregor,
> 
> When I boot my laptop up, it connects to eduroam just fine.
> 
> However, when I move around the building, it does not associate
> with any other AP.

This was my experience too.

It seems that you can sometimes jump back on the network by running:
$ wpa_cli reassoc

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: security/wpa_supplicant: Reassoc on NWID change

[Mikolaj Kucharski]

Hi Gregor,

I've looked into this more and from debugging perspective.
I've added wpa_printf(MSG_DEBUG, "XXX ...") statements
to the top of each function in src/drivers/driver_openbsd.c
and also one additional just before wpa_supplicant_event()
inside an if() statement. That was mostly for me so I know
I'm definately running your code and to understand better
flow of the code.

As I said in my previous email, after suspend/resume wpa
supplicant doesn't reassociate with AP and wireless interface
ends up in state:

status: no network
ieee80211: join lighthouse chan 100 bssid 6c:f3:7f:d6:5e:f0 -47dBm 
wpaprotos wpa2 wpaakms 802.1x wpaciphers ccmp wpagroupcipher ccmp


However by running `wpa_cli reassoc` wpa supplicant triggers
reassociation and successfully authenticates to the network:

status: active
ieee80211: join lighthouse chan 100 bssid 6c:f3:7f:d6:5e:f0 -47dBm 
wpaprotos wpa2 wpaakms 802.1x wpaciphers ccmp wpagroupcipher ccmp


Here is full log, just before the suspend, resume and then waiting a bit
without successful auth to the network and then manual `wpa_cli reassoc`:


# /usr/local/sbin/wpa_supplicant -c /etc/wpa_supplicant.conf -D openbsd -i iwn0 
-dd -t | \
sed -e 's/^\(.*\) hexdump(len=[0-9][0-9]*): .*/\1 hexdump XXX REMOVED 
XXX/'
...
1544451783.290841: XXX wpa_driver_openbsd_event_receive() start
1544451783.356712: XXX wpa_driver_openbsd_event_receive() start
1544451783.356800: XXX wpa_driver_openbsd_event_receive() start
1544451783.356888: XXX wpa_driver_openbsd_event_receive() start
1544451783.356920: XXX wpa_driver_openbsd_event_receive() start
1544451783.356951: XXX wpa_driver_openbsd_event_receive() start
1544451783.357106: XXX wpa_driver_openbsd_event_receive() start
1544451783.357133: XXX wpa_driver_openbsd_event_receive() start
1544451783.357591: XXX wpa_driver_openbsd_event_receive() start
1544451784.223351: XXX wpa_driver_openbsd_event_receive() start
1544451784.245911: XXX wpa_driver_openbsd_event_receive() start
1544451784.397337: XXX wpa_driver_openbsd_event_receive() start
1544451785.410632: XXX wpa_driver_openbsd_event_receive() start
1544451786.417586: XXX wpa_driver_openbsd_event_receive() start
1544451791.519192: XXX wpa_driver_openbsd_event_receive() start
1544451812.501002: EAPOL: authWhile --> 0
1544451812.501016: EAPOL: startWhen --> 0
1544451843.640493: EAPOL: idleWhile --> 0
1544451843.640512: EAPOL: disable timer tick
1544452119.960234: XXX wpa_driver_openbsd_event_receive() start
1544452161.423999: XXX wpa_driver_openbsd_event_receive() start
1544452698.636069: XXX wpa_driver_openbsd_event_receive() start
1544452756.315182: XXX wpa_driver_openbsd_event_receive() start
1544452987.451435: XXX wpa_driver_openbsd_event_receive() start
1544454186.334245: XXX wpa_driver_openbsd_event_receive() start
1544454193.706468: XXX wpa_driver_openbsd_event_receive() start
1544455323.097838: XXX wpa_driver_openbsd_event_receive() start
1544455383.622915: XXX wpa_driver_openbsd_event_receive() start
1544455402.771107: XXX wpa_driver_openbsd_event_receive() start
1544456602.822885: XXX wpa_driver_openbsd_event_receive() start
1544458081.366761: XXX wpa_driver_openbsd_event_receive() start
1544458983.952662: XXX wpa_driver_openbsd_event_receive() start
1544458986.638529: XXX wpa_driver_openbsd_event_receive() start
1544459085.039967: XXX wpa_driver_openbsd_event_receive() start
1544459387.326189: XXX wpa_driver_openbsd_event_receive() start
1544460486.671975: XXX wpa_driver_openbsd_event_receive() start
1544460590.428104: XXX wpa_driver_openbsd_event_receive() start
1544461790.147951: XXX wpa_driver_openbsd_event_receive() start
1544462584.084171: XXX wpa_driver_openbsd_event_receive() start
1544463018.143647: XXX wpa_driver_openbsd_event_receive() start
1544464023.572019: XXX wpa_driver_openbsd_event_receive() start
1544464221.649357: XXX wpa_driver_openbsd_event_receive() start
1544465286.802092: XXX wpa_driver_openbsd_event_receive() start
1544465439.921320: XXX wpa_driver_openbsd_event_receive() start
// laptop suspended and then resumed between those lines
1544514315.067941: XXX wpa_driver_openbsd_event_receive() start
1544514315.067960: XXX wpa_driver_openbsd_event_receive() start
1544514315.067973: XXX wpa_driver_openbsd_event_receive() start
1544514315.067984: XXX wpa_driver_openbsd_event_receive() start
1544514315.068605: XXX wpa_driver_openbsd_event_receive() start
1544514315.068619: XXX wpa_driver_openbsd_event_receive() start
1544514315.085484: XXX wpa_driver_openbsd_event_receive() start
1544514315.085502: XXX wpa_driver_openbsd_event_receive() start
1544514318.914662: iwn0: RX EAPOL from 6c:f3:7f:d6:5e:f0
1544514318.914684: RX EAPOL - hexdump XXX REMOVED XXX
1544514318.914699: iwn0: Not associated - Delay processing of received EAPOL 
frame (state=COMPLETED bssid=04:bd:88:4a:11:50)
1544514323.896880: iwn0: RX EAPOL from 6c:f3:7f:d6:5e:f0
1544514323.896911: RX EAPOL - hexdump XXX REMOVED XXX
1544514323.896926: iwn0: Not associated 

Re: security/wpa_supplicant: Reassoc on NWID change

[Raf Czlonka]

Hi Gregor,

When I boot my laptop up, it connects to eduroam just fine.

However, when I move around the building, it does not associate
with any other AP.

I can't even make it associate if I manually run:

sh /etc/netstart

While running wpa_cli(8) in another tmux(1) window, I see a constant
stream of:

<3>CTRL-EVENT-DISCONNECTED bssid=12:34:56:ab:cd:ef reason=3 
locally_generated=1
<3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0

I don't think this is related to wpa_supplicant(8) but mentioning
it here just in case.

In order to be able to associate with any other IP, I have to run:

ifconfig urtwn0 -nwid

Only then does the laptop reconnect.

I thought that I'll be able to simply use:

ifconfig urtwn0 -joinlist

followed by:

sh /etc/netstart

but, after I run the '-joinlist' option, I see this in ifconfig(8)
output:

ieee80211: nwid eduroam chan 1 bssid 12:34:56:ab:cd:ef -76dBm wpaprotos 
wpa2 wpaakms 802.1x wpaciphers ccmp wpagroupcipher ccmp

This seemed a bit strange since I don't use 'nwid' anywhere in my
hostname.if file - only 'join' - but I guess this is how 'join'
works "under the hood"(?).

To sum it up, unfortunately, the diff doesn't work for me.

Regards,

Raf

On Mon, Dec 10, 2018 at 02:07:32PM GMT, Mikolaj Kucharski wrote:
> Hi Gregor,
> 
> I've tested your diff in recent days and in my case most often
> when I change the physical location (and hence AP) I put my
> laptop into suspend. I've noticed that with your diff wpa
> supplicant is not abble to reassoc to the AP on resume. However
> it looks to me more like wpa supplicant problem than your diff.
> 
> It ends up in infinite loop of:
> 
> 152781.550029: iwn0: RX EAPOL from 04:bd:88:4a:11:50
> 152781.550061: RX EAPOL - hexdump(len=46): 01 00 00 05 01 01 00 05 01 00 
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00 00 00 00 00 00 00 00 00
> 152781.550103: iwn0: Not associated - Delay processing of received EAPOL 
> frame (state=COMPLETED bssid=6c:f3:7f:d6:5e:f0)
> 152786.575010: iwn0: RX EAPOL from 04:bd:88:4a:11:50
> 152786.575042: RX EAPOL - hexdump(len=46): 01 00 00 05 01 01 00 05 01 00 
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00 00 00 00 00 00 00 00 00
> 152786.575085: iwn0: Not associated - Delay processing of received EAPOL 
> frame (state=COMPLETED bssid=6c:f3:7f:d6:5e:f0)
> 152791.593955: iwn0: RX EAPOL from 04:bd:88:4a:11:50
> 152791.593986: RX EAPOL - hexdump(len=46): 01 00 00 05 01 02 00 05 01 00 
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00 00 00 00 00 00 00 00 00
> 152791.594030: iwn0: Not associated - Delay processing of received EAPOL 
> frame (state=COMPLETED bssid=6c:f3:7f:d6:5e:f0)
> 152796.618836: iwn0: RX EAPOL from 04:bd:88:4a:11:50
> 152796.618867: RX EAPOL - hexdump(len=46): 01 00 00 05 01 02 00 05 01 00 
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00 00 00 00 00 00 00 00 00
> 152796.618910: iwn0: Not associated - Delay processing of received EAPOL 
> frame (state=COMPLETED bssid=6c:f3:7f:d6:5e:f0)
> 152801.641262: iwn0: RX EAPOL from 04:bd:88:4a:11:50
> 152801.641293: RX EAPOL - hexdump(len=46): 01 00 00 05 01 02 00 05 01 00 
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00 00 00 00 00 00 00 00 00
> 152801.641335: iwn0: Not associated - Delay processing of received EAPOL 
> frame (state=COMPLETED bssid=6c:f3:7f:d6:5e:f0)
> 152806.684327: iwn0: RX EAPOL from 04:bd:88:4a:11:50
> 152806.684358: RX EAPOL - hexdump(len=46): 01 00 00 05 01 01 00 05 01 00 
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00 00 00 00 00 00 00 00 00
> 152806.684402: iwn0: Not associated - Delay processing of received EAPOL 
> frame (state=COMPLETED bssid=6c:f3:7f:d6:5e:f0)
> 152811.738381: iwn0: RX EAPOL from 04:bd:88:4a:11:50
> 152811.738412: RX EAPOL - hexdump(len=46): 01 00 00 05 01 01 00 05 01 00 
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00 00 00 00 00 00 00 00 00
> 
> in the same time iwn0 interface shows:
> 
>   status: no network
>   ieee80211: join lighthouse chan 132 bssid 04:bd:88:4a:31:50 -52dBm 
> wpaprotos wpa2 wpaakms 802.1x wpaciphers ccmp wpagroupcipher ccmp
> 
> bssid is visible, however status is no network. I also should mention, that
> the problem of reassociating to AP after resume works sometimes.
> 
> However, I can say I don't see any negative effects from your diff, as problem
> of reassociation after resume was always there with wpa supplicant.
> 
> Regards,
>  Mikolaj
> 
> On Wed, Nov 28, 2018 at 06:56:46PM +0100, Gregor Best wrote:
> > Peter Hessler  writes:
> > 
> > > This looks really cool, thank you for looking at it!
> > >
> > > One thing that you may also need, is to may also 

Re: security/wpa_supplicant: Reassoc on NWID change

[Mikolaj Kucharski]

Hi Gregor,

I've tested your diff in recent days and in my case most often
when I change the physical location (and hence AP) I put my
laptop into suspend. I've noticed that with your diff wpa
supplicant is not abble to reassoc to the AP on resume. However
it looks to me more like wpa supplicant problem than your diff.

It ends up in infinite loop of:

152781.550029: iwn0: RX EAPOL from 04:bd:88:4a:11:50
152781.550061: RX EAPOL - hexdump(len=46): 01 00 00 05 01 01 00 05 01 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00
152781.550103: iwn0: Not associated - Delay processing of received EAPOL 
frame (state=COMPLETED bssid=6c:f3:7f:d6:5e:f0)
152786.575010: iwn0: RX EAPOL from 04:bd:88:4a:11:50
152786.575042: RX EAPOL - hexdump(len=46): 01 00 00 05 01 01 00 05 01 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00
152786.575085: iwn0: Not associated - Delay processing of received EAPOL 
frame (state=COMPLETED bssid=6c:f3:7f:d6:5e:f0)
152791.593955: iwn0: RX EAPOL from 04:bd:88:4a:11:50
152791.593986: RX EAPOL - hexdump(len=46): 01 00 00 05 01 02 00 05 01 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00
152791.594030: iwn0: Not associated - Delay processing of received EAPOL 
frame (state=COMPLETED bssid=6c:f3:7f:d6:5e:f0)
152796.618836: iwn0: RX EAPOL from 04:bd:88:4a:11:50
152796.618867: RX EAPOL - hexdump(len=46): 01 00 00 05 01 02 00 05 01 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00
152796.618910: iwn0: Not associated - Delay processing of received EAPOL 
frame (state=COMPLETED bssid=6c:f3:7f:d6:5e:f0)
152801.641262: iwn0: RX EAPOL from 04:bd:88:4a:11:50
152801.641293: RX EAPOL - hexdump(len=46): 01 00 00 05 01 02 00 05 01 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00
152801.641335: iwn0: Not associated - Delay processing of received EAPOL 
frame (state=COMPLETED bssid=6c:f3:7f:d6:5e:f0)
152806.684327: iwn0: RX EAPOL from 04:bd:88:4a:11:50
152806.684358: RX EAPOL - hexdump(len=46): 01 00 00 05 01 01 00 05 01 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00
152806.684402: iwn0: Not associated - Delay processing of received EAPOL 
frame (state=COMPLETED bssid=6c:f3:7f:d6:5e:f0)
152811.738381: iwn0: RX EAPOL from 04:bd:88:4a:11:50
152811.738412: RX EAPOL - hexdump(len=46): 01 00 00 05 01 01 00 05 01 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00

in the same time iwn0 interface shows:

status: no network
ieee80211: join lighthouse chan 132 bssid 04:bd:88:4a:31:50 -52dBm 
wpaprotos wpa2 wpaakms 802.1x wpaciphers ccmp wpagroupcipher ccmp

bssid is visible, however status is no network. I also should mention, that
the problem of reassociating to AP after resume works sometimes.

However, I can say I don't see any negative effects from your diff, as problem
of reassociation after resume was always there with wpa supplicant.

Regards,
 Mikolaj

On Wed, Nov 28, 2018 at 06:56:46PM +0100, Gregor Best wrote:
> Peter Hessler  writes:
> 
> > This looks really cool, thank you for looking at it!
> >
> > One thing that you may also need, is to may also need to reassoc when
> > the bssid changes (roaming between different APs).  Can you also test
> > that when you do your join testing?
> > [...]
> 
> Good call. That does turn out to be necessary, so I've amended my
> original patch. An updated patch is attached below my signature.
> 
> I've tested this with a two-AP 802.1x network now, but since the APs are
> more or less sitting on top of each other, I can't really move out of
> range of only one of them to test organic handover. I've emulated that
> by adding the SSID to my `iwm0`'s joinlist and manually exchanging the
> BSSID.
> 
> I'll try to see if I can squeeze in some time at my local eduroam
> network tomorrow to check out how this works in the "I got out of range
> of one AP and the kernel switched me over to another"-scenario.
> 
> --
>   Gregor
> 
> Index: patches/patch-src_drivers_driver_openbsd_c
> ===
> RCS file: 
> /home/cvs/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
> retrieving revision 1.5
> diff -u -p -r1.5 patch-src_drivers_driver_openbsd_c
> --- patches/patch-src_drivers_driver_openbsd_c17 May 2016 08:29:27 
> -  1.5
> +++ patches/patch-src_drivers_driver_openbsd_c28 Nov 2018 17:51:30 
> -
> @@ -2,23 +2,137 @@ $OpenBSD: patch-src_drivers_driver_openb
>  
>  Fix includes
>  
>  src/drivers/driver_openbsd.c.origSun Sep 27 

Re: security/wpa_supplicant: Reassoc on NWID change

[Peter Hessler]

On 2018 Dec 07 (Fri) at 16:32:53 + (+), Edd Barrett wrote:
:Hi,
:
:On Tue, Nov 20, 2018 at 07:18:37PM +0100, Gregor Best wrote:
:> I've built a little patch to security/wpa_supplicant that lets it listen to
:> changes in the associated network SSID (thanks to Ken's RTM_80211INFO) and
:> reassociate itself.
:> 
:> This essentially means that now you can run `wpa_supplicant` in the 
background
:> and configure e.g. eduroam like `ifconfig iwm0 join eduroam wpaakms 802.1x`
:> without having to manually kick wpa_supplicant by restarting it or running
:> `wpa_cli reassoc`.
:> 
:> I'll be out of range of my usual eduroam access points until next week, so I
:> haven't tested this beyond "wpa_supplicant doesn't crash and it tries to 
reassoc
:> if the NWID changes".
:
:Should wpa-supplicant transition between access points on the same SSID?
:At first I thought this was what this patch proposed, but I think I
:misinterpreted.
:

Yes, it needs to negotiate with every AP (BSSID) that it connects to,
even if it is the same ESSID.


-- 
This sentence contradicts itself -- no actually it doesn't.
-- Hofstadter

Re: security/wpa_supplicant: Reassoc on NWID change

[Edd Barrett]

Hi,

On Tue, Nov 20, 2018 at 07:18:37PM +0100, Gregor Best wrote:
> I've built a little patch to security/wpa_supplicant that lets it listen to
> changes in the associated network SSID (thanks to Ken's RTM_80211INFO) and
> reassociate itself.
> 
> This essentially means that now you can run `wpa_supplicant` in the background
> and configure e.g. eduroam like `ifconfig iwm0 join eduroam wpaakms 802.1x`
> without having to manually kick wpa_supplicant by restarting it or running
> `wpa_cli reassoc`.
> 
> I'll be out of range of my usual eduroam access points until next week, so I
> haven't tested this beyond "wpa_supplicant doesn't crash and it tries to 
> reassoc
> if the NWID changes".

Should wpa-supplicant transition between access points on the same SSID?
At first I thought this was what this patch proposed, but I think I
misinterpreted.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: security/wpa_supplicant: Reassoc on NWID change

[Peter Hessler]

On 2018 Nov 28 (Wed) at 18:56:46 +0100 (+0100), Gregor Best wrote:
:Peter Hessler  writes:
:
:> This looks really cool, thank you for looking at it!
:>
:> One thing that you may also need, is to may also need to reassoc when
:> the bssid changes (roaming between different APs).  Can you also test
:> that when you do your join testing?
:> [...]
:
:Good call. That does turn out to be necessary, so I've amended my
:original patch. An updated patch is attached below my signature.
:
:I've tested this with a two-AP 802.1x network now, but since the APs are
:more or less sitting on top of each other, I can't really move out of
:range of only one of them to test organic handover. I've emulated that
:by adding the SSID to my `iwm0`'s joinlist and manually exchanging the
:BSSID.
:
:I'll try to see if I can squeeze in some time at my local eduroam
:network tomorrow to check out how this works in the "I got out of range
:of one AP and the kernel switched me over to another"-scenario.
:
:--
:   Gregor
:

I'm not able to test this yet, but this looks OK to me (with a REVISION
bump, of course)


:Index: patches/patch-src_drivers_driver_openbsd_c
:===
:RCS file: 
/home/cvs/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
:retrieving revision 1.5
:diff -u -p -r1.5 patch-src_drivers_driver_openbsd_c
:--- patches/patch-src_drivers_driver_openbsd_c 17 May 2016 08:29:27 -  
1.5
:+++ patches/patch-src_drivers_driver_openbsd_c 28 Nov 2018 17:51:30 -
:@@ -2,23 +2,137 @@ $OpenBSD: patch-src_drivers_driver_openb
: 
: Fix includes
: 
: src/drivers/driver_openbsd.c.orig Sun Sep 27 21:02:05 2015
:-+++ src/drivers/driver_openbsd.c  Mon Sep 28 09:51:53 2015
:-@@ -9,13 +9,14 @@
:+Index: src/drivers/driver_openbsd.c
:+--- src/drivers/driver_openbsd.c.orig
: src/drivers/driver_openbsd.c
:+@@ -9,19 +9,34 @@
:  #include "includes.h"
:  #include 
:  
: +#include "common.h"
: +#include "driver.h"
:++#include "eloop.h"
: +
:++#include 
:  #include 
: +#include 
:++#include 
:  #include 
:  #include 
:  #include 
:--
:+ 
: -#include "common.h"
: -#include "driver.h"
:++#define RTM_READSZ 2048
:  
:  struct openbsd_driver_data {
:-  char ifname[IFNAMSIZ + 1];
:+- char ifname[IFNAMSIZ + 1];
:+  void *ctx;
:+ 
:+- int sock;   /* open socket for 802.11 ioctls */
:++ char ifname[IFNAMSIZ + 1];
:++ int ifindex;  /* Ifindex of the configured interface */
:++
:++ int sock; /* open socket for 802.11 ioctls */
:++ int rtsock;   /* routing socket for interface state messages */
:++
:++ /* These fields are used to track the last seen (and associated) access 
point
:++to determine whether we should kick off an association event */
:++ int nwid_len; /* Length of last seen SSID (as per routing message) */
:++ char nwid[IEEE80211_NWID_LEN]; /* Last seen SSID (as per routing 
message) */
:++ char addr[IEEE80211_ADDR_LEN]; /* Last seen BSSID (as per routing 
message) */
:+ };
:+ 
:+ 
:+@@ -90,6 +105,57 @@ wpa_driver_openbsd_set_key(const char *ifname, void *p
:+  return 0;
:+ }
:+ 
:++static void
:++wpa_driver_openbsd_event_receive(int sock, void *global, void *sock_ctx)
:++{
:++ struct openbsd_driver_data *drv = sock_ctx;
:++ struct rt_msghdr *rtm;
:++ struct if_ieee80211_data *ifie;
:++ char *rtmmsg;
:++ ssize_t n;
:++
:++ rtmmsg = os_zalloc(RTM_READSZ);
:++ if (rtmmsg == NULL) {
:++ wpa_printf(MSG_ERROR, "Can't allocate space for routing 
message");
:++ return;
:++ }
:++
:++ do {
:++ n = read(sock, rtmmsg, RTM_READSZ);
:++ } while (n == -1 && errno == EINTR);
:++
:++ if (n == -1)
:++ goto done;
:++
:++ rtm = (struct rt_msghdr *)rtmmsg;
:++
:++ if ((size_t)n < sizeof(rtm->rtm_msglen) ||
:++ n < rtm->rtm_msglen ||
:++ rtm->rtm_version != RTM_VERSION)
:++ goto done;
:++
:++ if ((rtm->rtm_type != RTM_80211INFO) ||
:++ (rtm->rtm_index != drv->ifindex))
:++ goto done;
:++
:++ ifie = &((struct if_ieee80211_msghdr *)rtm)->ifim_ifie;
:++
:++ if ((ifie->ifie_nwid_len != drv->nwid_len) ||
:++ (os_memcmp(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len) != 0) ||
:++ (os_memcmp(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN) != 0)) {
:++ os_memcpy(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN);
:++
:++ os_memcpy(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len);
:++ drv->nwid_len = ifie->ifie_nwid_len;
:++
:++ /* Emit ASSOC event */
:++ wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
:++ }
:++
:++done:
:++ os_free(rtmmsg);
:++}
:++
:+ static void *
:+ wpa_driver_openbsd_init(void *ctx, const char *ifname)
:+ {
:+@@ -103,9 +169,21 @@ wpa_driver_openbsd_init(void *ctx, const char *ifname)
:+  if (drv->sock < 0)
:+  

Re: security/wpa_supplicant: Reassoc on NWID change

[Gregor Best]

Peter Hessler  writes:

> This looks really cool, thank you for looking at it!
>
> One thing that you may also need, is to may also need to reassoc when
> the bssid changes (roaming between different APs).  Can you also test
> that when you do your join testing?
> [...]

Good call. That does turn out to be necessary, so I've amended my
original patch. An updated patch is attached below my signature.

I've tested this with a two-AP 802.1x network now, but since the APs are
more or less sitting on top of each other, I can't really move out of
range of only one of them to test organic handover. I've emulated that
by adding the SSID to my `iwm0`'s joinlist and manually exchanging the
BSSID.

I'll try to see if I can squeeze in some time at my local eduroam
network tomorrow to check out how this works in the "I got out of range
of one AP and the kernel switched me over to another"-scenario.

--
Gregor

Index: patches/patch-src_drivers_driver_openbsd_c
===
RCS file: 
/home/cvs/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
retrieving revision 1.5
diff -u -p -r1.5 patch-src_drivers_driver_openbsd_c
--- patches/patch-src_drivers_driver_openbsd_c  17 May 2016 08:29:27 -  
1.5
+++ patches/patch-src_drivers_driver_openbsd_c  28 Nov 2018 17:51:30 -
@@ -2,23 +2,137 @@ $OpenBSD: patch-src_drivers_driver_openb
 
 Fix includes
 
 src/drivers/driver_openbsd.c.orig  Sun Sep 27 21:02:05 2015
-+++ src/drivers/driver_openbsd.c   Mon Sep 28 09:51:53 2015
-@@ -9,13 +9,14 @@
+Index: src/drivers/driver_openbsd.c
+--- src/drivers/driver_openbsd.c.orig
 src/drivers/driver_openbsd.c
+@@ -9,19 +9,34 @@
  #include "includes.h"
  #include 
  
 +#include "common.h"
 +#include "driver.h"
++#include "eloop.h"
 +
++#include 
  #include 
 +#include 
++#include 
  #include 
  #include 
  #include 
--
+ 
 -#include "common.h"
 -#include "driver.h"
++#define RTM_READSZ 2048
  
  struct openbsd_driver_data {
-   char ifname[IFNAMSIZ + 1];
+-  char ifname[IFNAMSIZ + 1];
+   void *ctx;
+ 
+-  int sock;   /* open socket for 802.11 ioctls */
++  char ifname[IFNAMSIZ + 1];
++  int ifindex;  /* Ifindex of the configured interface */
++
++  int sock; /* open socket for 802.11 ioctls */
++  int rtsock;   /* routing socket for interface state messages */
++
++  /* These fields are used to track the last seen (and associated) access 
point
++ to determine whether we should kick off an association event */
++  int nwid_len; /* Length of last seen SSID (as per routing message) */
++  char nwid[IEEE80211_NWID_LEN]; /* Last seen SSID (as per routing 
message) */
++  char addr[IEEE80211_ADDR_LEN]; /* Last seen BSSID (as per routing 
message) */
+ };
+ 
+ 
+@@ -90,6 +105,57 @@ wpa_driver_openbsd_set_key(const char *ifname, void *p
+   return 0;
+ }
+ 
++static void
++wpa_driver_openbsd_event_receive(int sock, void *global, void *sock_ctx)
++{
++  struct openbsd_driver_data *drv = sock_ctx;
++  struct rt_msghdr *rtm;
++  struct if_ieee80211_data *ifie;
++  char *rtmmsg;
++  ssize_t n;
++
++  rtmmsg = os_zalloc(RTM_READSZ);
++  if (rtmmsg == NULL) {
++  wpa_printf(MSG_ERROR, "Can't allocate space for routing 
message");
++  return;
++  }
++
++  do {
++  n = read(sock, rtmmsg, RTM_READSZ);
++  } while (n == -1 && errno == EINTR);
++
++  if (n == -1)
++  goto done;
++
++  rtm = (struct rt_msghdr *)rtmmsg;
++
++  if ((size_t)n < sizeof(rtm->rtm_msglen) ||
++  n < rtm->rtm_msglen ||
++  rtm->rtm_version != RTM_VERSION)
++  goto done;
++
++  if ((rtm->rtm_type != RTM_80211INFO) ||
++  (rtm->rtm_index != drv->ifindex))
++  goto done;
++
++  ifie = &((struct if_ieee80211_msghdr *)rtm)->ifim_ifie;
++
++  if ((ifie->ifie_nwid_len != drv->nwid_len) ||
++  (os_memcmp(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len) != 0) ||
++  (os_memcmp(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN) != 0)) {
++  os_memcpy(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN);
++
++  os_memcpy(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len);
++  drv->nwid_len = ifie->ifie_nwid_len;
++
++  /* Emit ASSOC event */
++  wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
++  }
++
++done:
++  os_free(rtmmsg);
++}
++
+ static void *
+ wpa_driver_openbsd_init(void *ctx, const char *ifname)
+ {
+@@ -103,9 +169,21 @@ wpa_driver_openbsd_init(void *ctx, const char *ifname)
+   if (drv->sock < 0)
+   goto fail;
+ 
++  drv->rtsock = socket(PF_ROUTE, SOCK_RAW, AF_UNSPEC);
++  if (drv->rtsock < 0)
++  goto fail;
++
+   drv->ctx = ctx;
+   os_strlcpy(drv->ifname, ifname, sizeof(drv->ifname));
+ 
++  drv->ifindex = 

security/wpa_supplicant: Reassoc on NWID change

[Gregor Best]

Hi David and ports@,

I've built a little patch to security/wpa_supplicant that lets it listen to
changes in the associated network SSID (thanks to Ken's RTM_80211INFO) and
reassociate itself.

This essentially means that now you can run `wpa_supplicant` in the background
and configure e.g. eduroam like `ifconfig iwm0 join eduroam wpaakms 802.1x`
without having to manually kick wpa_supplicant by restarting it or running
`wpa_cli reassoc`.

I'll be out of range of my usual eduroam access points until next week, so I
haven't tested this beyond "wpa_supplicant doesn't crash and it tries to reassoc
if the NWID changes".

I'd be really grateful if a few of you who do run wpa_supplicant for wireless
802.1x networks could give this a spin. All that's needed is applying the patch
below my signature to `/usr/ports/security/wpa_supplicant` and running `make
reinstall`.

--
Gregor

Index: patches/patch-src_drivers_driver_openbsd_c
===
RCS file: 
/home/cvs/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
retrieving revision 1.5
diff -u -p -u -r1.5 patch-src_drivers_driver_openbsd_c
--- patches/patch-src_drivers_driver_openbsd_c  17 May 2016 08:29:27 -  
1.5
+++ patches/patch-src_drivers_driver_openbsd_c  20 Nov 2018 17:59:00 -
@@ -2,23 +2,130 @@ $OpenBSD: patch-src_drivers_driver_openb

 Fix includes

 src/drivers/driver_openbsd.c.orig  Sun Sep 27 21:02:05 2015
-+++ src/drivers/driver_openbsd.c   Mon Sep 28 09:51:53 2015
-@@ -9,13 +9,14 @@
+Index: src/drivers/driver_openbsd.c
+--- src/drivers/driver_openbsd.c.orig
 src/drivers/driver_openbsd.c
+@@ -9,19 +9,31 @@
  #include "includes.h"
  #include 

 +#include "common.h"
 +#include "driver.h"
++#include "eloop.h"
 +
++#include 
  #include 
 +#include 
++#include 
  #include 
  #include 
  #include 
--
+
 -#include "common.h"
 -#include "driver.h"
++#define RTM_READSZ 2048

  struct openbsd_driver_data {
-   char ifname[IFNAMSIZ + 1];
+-  char ifname[IFNAMSIZ + 1];
+   void *ctx;
+
+-  int sock;   /* open socket for 802.11 ioctls */
++  char ifname[IFNAMSIZ + 1];
++  int ifindex;  /* Ifindex of the configured interface */
++
++  int sock; /* open socket for 802.11 ioctls */
++  int rtsock;   /* routing socket for interface state messages */
++
++  int nwid_len; /* Length of last seen SSID (as per routing message) */
++  char nwid[IEEE80211_NWID_LEN]; /* Last seen SSID (as per routing 
message) */
+ };
+
+
+@@ -90,6 +102,54 @@ wpa_driver_openbsd_set_key(const char *ifname, void *p
+   return 0;
+ }
+
++static void
++wpa_driver_openbsd_event_receive(int sock, void *global, void *sock_ctx)
++{
++  struct openbsd_driver_data *drv = sock_ctx;
++  struct rt_msghdr *rtm;
++  struct if_ieee80211_data *ifie;
++  char *rtmmsg;
++  ssize_t n;
++
++  rtmmsg = os_zalloc(RTM_READSZ);
++  if (rtmmsg == NULL) {
++  wpa_printf(MSG_ERROR, "Can't allocate space for routing 
message");
++  return;
++  }
++
++  do {
++  n = read(sock, rtmmsg, RTM_READSZ);
++  } while (n == -1 && errno == EINTR);
++
++  if (n == -1)
++  goto done;
++
++  rtm = (struct rt_msghdr *)rtmmsg;
++
++  if ((size_t)n < sizeof(rtm->rtm_msglen) ||
++  n < rtm->rtm_msglen ||
++  rtm->rtm_version != RTM_VERSION)
++  goto done;
++
++  if ((rtm->rtm_type != RTM_80211INFO) ||
++  (rtm->rtm_index != drv->ifindex))
++  goto done;
++
++  ifie = &((struct if_ieee80211_msghdr *)rtm)->ifim_ifie;
++
++  if ((ifie->ifie_nwid_len != drv->nwid_len) ||
++  (os_memcmp(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len) != 0)) {
++  os_memcpy(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len);
++  drv->nwid_len = ifie->ifie_nwid_len;
++
++  /* Emit ASSOC event */
++  wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
++  }
++
++done:
++  os_free(rtmmsg);
++}
++
+ static void *
+ wpa_driver_openbsd_init(void *ctx, const char *ifname)
+ {
+@@ -103,9 +163,20 @@ wpa_driver_openbsd_init(void *ctx, const char *ifname)
+   if (drv->sock < 0)
+   goto fail;
+
++  drv->rtsock = socket(PF_ROUTE, SOCK_RAW, AF_UNSPEC);
++  if (drv->rtsock < 0)
++  goto fail;
++
+   drv->ctx = ctx;
+   os_strlcpy(drv->ifname, ifname, sizeof(drv->ifname));
+
++  drv->ifindex = if_nametoindex(drv->ifname);
++  if (drv->ifindex == 0) /* No interface with that name */
++  goto fail;
++
++  drv->nwid_len = wpa_driver_openbsd_get_ssid(drv, drv->nwid);
++
++  eloop_register_read_sock(drv->rtsock, wpa_driver_openbsd_event_receive, 
NULL, drv);
+   return drv;
+
+ fail:
+@@ -119,7 +190,11 @@ wpa_driver_openbsd_deinit(void *priv)
+ {
+   struct openbsd_driver_data *drv = priv;
+
++