[PATCH] mac80211: remove special casing of EAPOL on mgmt interface

[PATCH] mac80211: remove special casing of EAPOL on mgmt interface

[Johannes Berg]

This patch removes sending EAPOL frames to the management interface and
sends them to the regular ethernet interface instead.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>

---
 net/mac80211/rx.c |   11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

--- wireless-dev.orig/net/mac80211/rx.c	2007-08-11 00:45:05.647838974 +0200
+++ wireless-dev/net/mac80211/rx.c	2007-08-11 01:45:58.517838974 +0200
@@ -837,15 +837,8 @@ static ieee80211_txrx_result
 ieee80211_rx_h_802_1x_pae(struct ieee80211_txrx_data *rx)
 {
 	if (rx->sdata->eapol && ieee80211_is_eapol(rx->skb) &&
-	    rx->sdata->type != IEEE80211_IF_TYPE_STA && rx->u.rx.ra_match) {
-		/* Pass both encrypted and unencrypted EAPOL frames to user
-		 * space for processing. */
-		if (!rx->local->apdev)
-			return TXRX_DROP;
-		ieee80211_rx_mgmt(rx->local, rx->skb, rx->u.rx.status,
-				  ieee80211_msg_normal);
-		return TXRX_QUEUED;
-	}
+	    rx->sdata->type != IEEE80211_IF_TYPE_STA && rx->u.rx.ra_match)
+		return TXRX_CONTINUE;
 
 	if (unlikely(rx->sdata->ieee802_1x &&
 		     (rx->fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA &&

[PATCH] hostapd: use eapol frames from ethernet device

[Johannes Berg]

Now that the kernel no longer sends them to the management device, grab
them from ethernet instead.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>

---
Maybe the ieee802_1x_receive there should be commented out completely? I
had it commented out for testing but then only added the comment...

 hostapd/driver_devicescape.c |    1 +
 hostapd/hostapd.c            |   30 ++++++++++++++++++++++++------
 hostapd/hostapd.h            |    3 ++-
 3 files changed, 27 insertions(+), 7 deletions(-)

--- hostap.orig/hostapd/driver_devicescape.c	2007-08-11 01:06:26.000000000 +0200
+++ hostap/hostapd/driver_devicescape.c	2007-08-11 01:52:46.000000000 +0200
@@ -1224,6 +1224,7 @@ static void handle_data(struct hostapd_d
 	pos += 2;
 	left -= 2;
 	switch (ethertype) {
+	/* when we run on older wireless-dev kernels we might get this */
 	case ETH_P_PAE:
 		ieee802_1x_receive(hapd, sa, pos, left);
 		break;
--- hostap.orig/hostapd/hostapd.c	2007-08-11 01:20:03.000000000 +0200
+++ hostap/hostapd/hostapd.c	2007-08-11 01:39:00.000000000 +0200
@@ -574,8 +574,10 @@ static void hostapd_cleanup(struct hosta
 	radius_server_deinit(hapd->radius_srv);
 	hapd->radius_srv = NULL;
 
+	l2_packet_deinit(hapd->l2_eapol);
+
 #ifdef CONFIG_IEEE80211R
-	l2_packet_deinit(hapd->l2);
+	l2_packet_deinit(hapd->l2_rrb);
 #endif /* CONFIG_IEEE80211R */
 
 	hostapd_wireless_event_deinit(hapd);
@@ -906,9 +908,9 @@ static int hostapd_wpa_auth_send_ether(v
 		return hapd->driver->send_ether(hapd->drv_priv, dst,
 						hapd->own_addr, proto,
 						data, data_len);
-	if (hapd->l2 == NULL)
+	if (hapd->l2_rrb == NULL)
 		return -1;
-	return l2_packet_send(hapd->l2, dst, proto, data, data_len);
+	return l2_packet_send(hapd->l2_rrb, dst, proto, data, data_len);
 }
 
 
@@ -1080,6 +1082,13 @@ static int mac_in_conf(struct hostapd_co
 	return 0;
 }
 
+static void hostapd_eapol_receive(void *ctx, const u8 *src_addr,
+				  const u8 *buf, size_t len)
+{
+	struct hostapd_data *hapd = ctx;
+
+	ieee802_1x_receive(hapd, src_addr, buf, len);
+}
 
 /**
  * hostapd_setup_bss - Per-BSS setup (initialization)
@@ -1252,6 +1261,15 @@ static int hostapd_setup_bss(struct host
 			       "failed.\n");
 			return -1;
 		}
+
+		hapd->l2_eapol = l2_packet_init(hapd->conf->iface, NULL,
+						ETH_P_EAPOL,
+						hostapd_eapol_receive,
+						hapd, 0);
+		if (!hapd->l2_eapol) {
+			printf("Failed to open l2_packet interface\n");
+			return -1;
+		}
 	}
 
 	if (accounting_init(hapd)) {
@@ -1278,9 +1296,9 @@ static int hostapd_setup_bss(struct host
 	}
 
 #ifdef CONFIG_IEEE80211R
-	hapd->l2 = l2_packet_init(hapd->conf->iface, NULL, ETH_P_RRB,
-				  hostapd_rrb_receive, hapd, 0);
-	if (hapd->l2 == NULL &&
+	hapd->l2_rrb = l2_packet_init(hapd->conf->iface, NULL, ETH_P_RRB,
+				      hostapd_rrb_receive, hapd, 0);
+	if (hapd->l2_rrb == NULL &&
 	    (hapd->driver == NULL || hapd->driver->send_ether == NULL)) {
 		printf("Failed to open l2_packet interface\n");
 		return -1;
--- hostap.orig/hostapd/hostapd.h	2007-08-11 01:19:29.000000000 +0200
+++ hostap/hostapd/hostapd.h	2007-08-11 01:19:56.000000000 +0200
@@ -167,7 +167,8 @@ struct hostapd_data {
 	struct full_dynamic_vlan *full_dynamic_vlan;
 #endif /* CONFIG_FULL_DYNAMIC_VLAN */
 
-	struct l2_packet_data *l2;
+	struct l2_packet_data *l2_rrb;
+	struct l2_packet_data *l2_eapol;
 };
 
 

Re: [PATCH] hostapd: use eapol frames from ethernet device

[Tomas Winkler]

On 8/11/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> Now that the kernel no longer sends them to the management device, grab
> them from ethernet instead.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>
> ---
> Maybe the ieee802_1x_receive there should be commented out completely? I
> had it commented out for testing but then only added the comment...
>
>  hostapd/driver_devicescape.c |    1 +
>  hostapd/hostapd.c            |   30 ++++++++++++++++++++++++------
>  hostapd/hostapd.h            |    3 ++-
>  3 files changed, 27 insertions(+), 7 deletions(-)
>
> --- hostap.orig/hostapd/driver_devicescape.c    2007-08-11 01:06:26.000000000 +0200
> +++ hostap/hostapd/driver_devicescape.c 2007-08-11 01:52:46.000000000 +0200
> @@ -1224,6 +1224,7 @@ static void handle_data(struct hostapd_d
>         pos += 2;
>         left -= 2;
>         switch (ethertype) {
> +       /* when we run on older wireless-dev kernels we might get this */
>         case ETH_P_PAE:
>                 ieee802_1x_receive(hapd, sa, pos, left);
>                 break;
> --- hostap.orig/hostapd/hostapd.c       2007-08-11 01:20:03.000000000 +0200
> +++ hostap/hostapd/hostapd.c    2007-08-11 01:39:00.000000000 +0200
> @@ -574,8 +574,10 @@ static void hostapd_cleanup(struct hosta
>         radius_server_deinit(hapd->radius_srv);
>         hapd->radius_srv = NULL;
>
> +       l2_packet_deinit(hapd->l2_eapol);
> +
>  #ifdef CONFIG_IEEE80211R
> -       l2_packet_deinit(hapd->l2);
> +       l2_packet_deinit(hapd->l2_rrb);
>  #endif /* CONFIG_IEEE80211R */
>
>         hostapd_wireless_event_deinit(hapd);
> @@ -906,9 +908,9 @@ static int hostapd_wpa_auth_send_ether(v
>                 return hapd->driver->send_ether(hapd->drv_priv, dst,
>                                                 hapd->own_addr, proto,
>                                                 data, data_len);
> -       if (hapd->l2 == NULL)
> +       if (hapd->l2_rrb == NULL)
>                 return -1;
> -       return l2_packet_send(hapd->l2, dst, proto, data, data_len);
> +       return l2_packet_send(hapd->l2_rrb, dst, proto, data, data_len);
>  }
>
>
> @@ -1080,6 +1082,13 @@ static int mac_in_conf(struct hostapd_co
>         return 0;
>  }
>
> +static void hostapd_eapol_receive(void *ctx, const u8 *src_addr,
> +                                 const u8 *buf, size_t len)
> +{
> +       struct hostapd_data *hapd = ctx;
> +
> +       ieee802_1x_receive(hapd, src_addr, buf, len);
> +}
>
>  /**
>   * hostapd_setup_bss - Per-BSS setup (initialization)
> @@ -1252,6 +1261,15 @@ static int hostapd_setup_bss(struct host
>                                "failed.\n");
>                         return -1;
>                 }
> +
> +               hapd->l2_eapol = l2_packet_init(hapd->conf->iface, NULL,
> +                                               ETH_P_EAPOL,
> +                                               hostapd_eapol_receive,
> +                                               hapd, 0);
> +               if (!hapd->l2_eapol) {
> +                       printf("Failed to open l2_packet interface\n");
> +                       return -1;
> +               }
>         }
>
>         if (accounting_init(hapd)) {
> @@ -1278,9 +1296,9 @@ static int hostapd_setup_bss(struct host
>         }
>
>  #ifdef CONFIG_IEEE80211R
> -       hapd->l2 = l2_packet_init(hapd->conf->iface, NULL, ETH_P_RRB,
> -                                 hostapd_rrb_receive, hapd, 0);
> -       if (hapd->l2 == NULL &&
> +       hapd->l2_rrb = l2_packet_init(hapd->conf->iface, NULL, ETH_P_RRB,
> +                                     hostapd_rrb_receive, hapd, 0);
> +       if (hapd->l2_rrb == NULL &&
>             (hapd->driver == NULL || hapd->driver->send_ether == NULL)) {
>                 printf("Failed to open l2_packet interface\n");
>                 return -1;
> --- hostap.orig/hostapd/hostapd.h       2007-08-11 01:19:29.000000000 +0200
> +++ hostap/hostapd/hostapd.h    2007-08-11 01:19:56.000000000 +0200
> @@ -167,7 +167,8 @@ struct hostapd_data {
>         struct full_dynamic_vlan *full_dynamic_vlan;
>  #endif /* CONFIG_FULL_DYNAMIC_VLAN */
>
> -       struct l2_packet_data *l2;
> +       struct l2_packet_data *l2_rrb;
> +       struct l2_packet_data *l2_eapol;
>  };
>
>
>
>
Isn't the removal of management interface a bit premature?  I didn't
see any proposal how to move management packets to the application
level?  If not I would prefer eapol packets be treated on management
path. No data should be received on data interface till security
negotiation is done.

Thanks
Tomas

> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH] hostapd: use eapol frames from ethernet device

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

On Sun, 2007-08-12 at 13:58 +0300, Tomas Winkler wrote:

> Isn't the removal of management interface a bit premature?  I didn't
> see any proposal how to move management packets to the application
> level?  If not I would prefer eapol packets be treated on management
> path. No data should be received on data interface till security
> negotiation is done.

Have you read the patch or are you just ranting? I'm guessing the
latter? The patch didn't remove the management interface at all.

Besides, what point is there in not allowing EAPOL packets through? They
are fundamentally data packets so they belong onto the AP mode ethernet
framed device, and they won't be interpreted by any other application.
You'll have to come up with better reasons than "I prefer" blabla.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] hostapd: use eapol frames from ethernet device

[Tomas Winkler]

On 8/13/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Sun, 2007-08-12 at 13:58 +0300, Tomas Winkler wrote:
>
> > Isn't the removal of management interface a bit premature?  I didn't
> > see any proposal how to move management packets to the application
> > level?  If not I would prefer eapol packets be treated on management
> > path. No data should be received on data interface till security
> > negotiation is done.
>
> Have you read the patch or are you just ranting? I'm guessing the
> latter? The patch didn't remove the management interface at all.
>
 I think it was a polite query I've made, don't see any reason to use
this language. If you precept it otherwise I apologize it wasn't my
intention.

> Besides, what point is there in not allowing EAPOL packets through?

On the contrary what I'm saying that EAPOL packets are the only data
packets that should go up until handshake is done.
They

> are fundamentally data packets so they belong onto the AP mode ethernet
They have management meaning. So it was appropriate to route them
through management interface rather then from data interface.
> framed device, and they won't be interpreted by any other application.
> You'll have to come up with better reasons than "I prefer" blabla.
>
Tomas
> johannes
>
>

Re: [PATCH] hostapd: use eapol frames from ethernet device

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

On Mon, 2007-08-13 at 13:46 +0300, Tomas Winkler wrote:

>  I think it was a polite query I've made, don't see any reason to use
> this language. If you precept it otherwise I apologize it wasn't my
> intention.

Apologies. I seriously don't understand that comment though, the patch
didn't touch the management interface at all, in fact it renamed only a
few variables and changed EAPOL frame receiving from using the
management interface to the ethernet framed interface.

> They have management meaning. So it was appropriate to route them
> through management interface rather then from data interface.

I'm not sure we understand each other. The only thing I changed with
this patch and the corresponding kernel patch is that all data frames
including those that are used for management purposes are now routed
through the data interface. Why do you think that is wrong? Reordering
your mail a bit, you also said

> On the contrary what I'm saying that EAPOL packets are the only data
> packets that should go up until handshake is done.

which seems to agree with me. You can achieve the effect of letting
*only* EAPOL packets through by setting the 802.1X protection parameter
on the network interface via the private prism ioctl, hostapd doesn't
seem to do that unless explicitly requested though.

The actual technical reason for doing is that subsequent patches totally
remove the management interface and on the monitor interface the EAPOL
frames show up undecrypted.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] hostapd: use eapol frames from ethernet device

[Tomas Winkler]

On 8/13/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2007-08-13 at 13:46 +0300, Tomas Winkler wrote:
>
> >  I think it was a polite query I've made, don't see any reason to use
> > this language. If you precept it otherwise I apologize it wasn't my
> > intention.
>
> Apologies. I seriously don't understand that comment though, the patch
> didn't touch the management interface at all, in fact it renamed only a
> few variables and changed EAPOL frame receiving from using the
> management interface to the ethernet framed interface.
>
> > They have management meaning. So it was appropriate to route them
> > through management interface rather then from data interface.
>
> I'm not sure we understand each other. The only thing I changed with
> this patch and the corresponding kernel patch is that all data frames
> including those that are used for management purposes are now routed
> through the data interface. Why do you think that is wrong? Reordering
> your mail a bit, you also said
>
> > On the contrary what I'm saying that EAPOL packets are the only data
> > packets that should go up until handshake is done.
>
> which seems to agree with me. You can achieve the effect of letting
> *only* EAPOL packets through by setting the 802.1X protection parameter
> on the network interface via the private prism ioctl, hostapd doesn't
> seem to do that unless explicitly requested though.

> The actual technical reason for doing is that subsequent patches totally
> remove the management interface and on the monitor interface the EAPOL
> frames show up undecrypted.

Can you enlighten me and tell me why the monitor interface is
preferable over management interface? I've probably got busy and
missed the whole conversation.
 I'm not so familiar with monitor interface but isn't it to be
sniffing interface - everything goes up including data raw packets.
Thanks for keeping patience with me :)

What if management frames needs decryption? I think this is 802.11w
specs that defines that.

Thanks
Tomas

> johannes
>
>

Re: [PATCH] hostapd: use eapol frames from ethernet device

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

On Wed, 2007-08-15 at 01:46 +0300, Tomas Winkler wrote:

> Can you enlighten me and tell me why the monitor interface is
> preferable over management interface? I've probably got busy and
> missed the whole conversation.

Oh, I can name a number of reasons :)
 * magic needed to conjure it
 * munged prism2 header that nothing but hostapd/wpa_supplicant
   understands
 * special cases all over the code to stuff frames there

> I'm not so familiar with monitor interface but isn't it to be
> sniffing interface - everything goes up including data raw packets.

Well, in a way you're right. But please review the recent filter flags
patches I posted. And I'm using BPF to avoid seeing data frames other
than those I need.

> What if management frames needs decryption? I think this is 802.11w
> specs that defines that.

I thought radiotap injection could handle that, but it turns out that I
need to think again, especially about EAPOL frames. I'll address these
things in a reply to Jouni's mail, but that'll take a bit longer than
just going through and replying.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] hostapd: use eapol frames from ethernet device

[Jouni Malinen]

On Mon, Aug 13, 2007 at 01:02:01PM +0200, Johannes Berg wrote:

> The actual technical reason for doing is that subsequent patches totally
> remove the management interface and on the monitor interface the EAPOL
> frames show up undecrypted.

I have to admit that I haven't followed the latest changes on this area,
but before this kind of change goes in, I would like to verify that all
the needed cases will be supported with EAPOL and management frames:

- user space needs to be able to transmit EAPOL frames encrypted
  (WPA/WPA2) and in plain (IEEE 802.1X with dynamic WEP) even if keys
  are configured for the receiver; how is this done for the IEEE 802.1X
  rekeying case?

- plaintext EAPOL frames need to be received in some cases (mainly, IEEE
  802.1X with dynamic WEP) even if there is a configured key for the
  sending; ideally, user space apps would know whether the frame was
  encrypted or not

- management frames will need to be encrypted and decrypted in kernel
  (802.11w), e.g., when user space is sending and receiving action
  frames; i.e., there would need to be a mechanism to receive management
  frames that has been decrypted by the kernel and to be able to send
  management frames with kernel doing encryption; both are optional and
  depend on the key configuration for the sender/receiver


I don't really like the idea of having to implement encryption and
decryption for all these frames in both the user and kernel space.
Furthermore, some things like receiption of unencrypted EAPOL frames
would be quite difficult to do in user space unless the kernel were
actually to help here.

For me, the management frame interface provides a good and working
solution for this. I know that some people do not like the idea of
having yet another network device showing up here, but I want to make
sure that the "solution" for this is not breaking some needed
functionality or making this unnecessarily complex to implement for user
space apps.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH] hostapd: use eapol frames from ethernet device

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 3075 bytes --]

On Tue, 2007-08-14 at 21:16 -0700, Jouni Malinen wrote:

> - user space needs to be able to transmit EAPOL frames encrypted
>   (WPA/WPA2) and in plain (IEEE 802.1X with dynamic WEP) even if keys
>   are configured for the receiver; how is this done for the IEEE 802.1X
>   rekeying case?

Indeed, I hadn't fully considered the rekeying case. However, we
currently injected EAPOL frames via the management interface to achieve
this behaviour, it should be easy to achieve the same via the radiotap
injection interface.

> - management frames will need to be encrypted and decrypted in kernel
>   (802.11w), e.g., when user space is sending and receiving action
>   frames; i.e., there would need to be a mechanism to receive management
>   frames that has been decrypted by the kernel and to be able to send
>   management frames with kernel doing encryption; both are optional and
>   depend on the key configuration for the sender/receiver

Again, when sending them this should be part of the radiotap interface,
reception is a bit more complicated, however; see below.

> - plaintext EAPOL frames need to be received in some cases (mainly, IEEE
>   802.1X with dynamic WEP) even if there is a configured key for the
>   sending; ideally, user space apps would know whether the frame was
>   encrypted or not

If they're received unencrypted they will show up on monitor interfaces
regardless of encryption, they may or may not show up on the
802.3-framed device. Currently, EAPOL packets seem to be allowed
through, but if we go for monitor interfaces we might as well not have
them come through the 802.3-framed interface unless 802.1X is configured
to allow unencrypted frames through.

> I don't really like the idea of having to implement encryption and
> decryption for all these frames in both the user and kernel space.
> Furthermore, some things like receiption of unencrypted EAPOL frames
> would be quite difficult to do in user space unless the kernel were
> actually to help here.

I agree. The radiotap injection provides us with a means to fully
control what is happening when we need to send frames, so I wouldn't
worry about that. If anything, we'd need to extend the radiotap a bit;
there is apparently some work underway to make a "vendor-specific"
extension for radiotap that we could use in Linux.

As for receiving encrypted frames, I recently floated the idea to
introduce a crypto hook very early in frame processing so that to the
rest of the code it looks almost though the hardware was fully capable
of doing hardware offload for all encryption operations (might or might
not include MIC etc).

This has some seemingly weird implications, but ultimately it would mean
that the distinction between software and hardware encryption becomes
transparent at all levels which is a good thing. It would also mean that
the decrypted frames (if decryption was possible) show up on monitor
interfaces with a flag indicating that they were encrypted which should
address all needs here.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]