netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* EAPOL bridging
@ 2010-10-17 18:06 Benjamin Poirier
  2010-10-18 16:38 ` [Bridge] " Stephen Hemminger
  0 siblings, 1 reply; 5+ messages in thread
From: Benjamin Poirier @ 2010-10-17 18:06 UTC (permalink / raw)
  To: bridge; +Cc: netdev, linux-kernel

Hello,

I have some trouble bridging EAPOL frames. I'd like to do this to allow 
wired 802.1x authentication from within a kvm virtual machine. I have 
the following setup:

kvm -- tap0 -- br0 -- eth1 -- 802.1x authenticator (switch) -- more network

and it doesn't work. I've added a few logging rules to ebtables. I only 
see an EAPOL frame going through the INPUT chain of tap0. It seems to be 
dropped by the bridge. The EAPOL frame is an ethernet link local 
multicast frame with destination address 01-80-C2-00-00-03, "IEEE Std 
802.1X PAE address".

I've looked at http://standards.ieee.org/regauth/groupmac/tutorial.html, 
which says that frames with a destination in the range 01-80-C2-00-00-00 
to 01-80-C2-00-00-0F should not be forwarded by standard conformant 
bridges. I've also looked at net/bridge/br_input.c and br_handle_frame() 
seems quite intent on "bending" the standard when STP is disabled, but 
only for 01-80-C2-00-00-00. However there are more applications that use 
similar addresses, EAPOL included: 
http://standards.ieee.org/regauth/groupmac/Standard_Group_MAC_Address_assignments.pdf

Given the current state of affairs, would it be acceptable to make the 
code more permissive by forwarding all the range of reserved group 
addresses when STP is disabled? If not, what would be the way to go 
about enabling 802.1x authentication from within a virtual machine?

BTW, it seems this issue has been raised before, 
https://lists.linux-foundation.org/pipermail/bridge/2007-November/005629.html
with the conclusion that
> Despite what the standards say, many users are using bridging code for invisible
> firewalls etc, and in those cases they want STP and EAPOL frames to be forwarded.

Thanks,
-Ben

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bridge] EAPOL bridging
  2010-10-17 18:06 EAPOL bridging Benjamin Poirier
@ 2010-10-18 16:38 ` Stephen Hemminger
  2010-10-19  2:09   ` [PATCH] bridge: Forward reserved group addresses if !STP Benjamin Poirier
  0 siblings, 1 reply; 5+ messages in thread
From: Stephen Hemminger @ 2010-10-18 16:38 UTC (permalink / raw)
  To: Benjamin Poirier; +Cc: bridge, netdev, linux-kernel

On Sun, 17 Oct 2010 14:06:28 -0400
Benjamin Poirier <benjamin.poirier@gmail.com> wrote:

> Hello,
> 
> I have some trouble bridging EAPOL frames. I'd like to do this to allow 
> wired 802.1x authentication from within a kvm virtual machine. I have 
> the following setup:
> 
> kvm -- tap0 -- br0 -- eth1 -- 802.1x authenticator (switch) -- more network
> 
> and it doesn't work. I've added a few logging rules to ebtables. I only 
> see an EAPOL frame going through the INPUT chain of tap0. It seems to be 
> dropped by the bridge. The EAPOL frame is an ethernet link local 
> multicast frame with destination address 01-80-C2-00-00-03, "IEEE Std 
> 802.1X PAE address".
> 
> I've looked at http://standards.ieee.org/regauth/groupmac/tutorial.html, 
> which says that frames with a destination in the range 01-80-C2-00-00-00 
> to 01-80-C2-00-00-0F should not be forwarded by standard conformant 
> bridges. I've also looked at net/bridge/br_input.c and br_handle_frame() 
> seems quite intent on "bending" the standard when STP is disabled, but 
> only for 01-80-C2-00-00-00. However there are more applications that use 
> similar addresses, EAPOL included: 
> http://standards.ieee.org/regauth/groupmac/Standard_Group_MAC_Address_assignments.pdf
> 
> Given the current state of affairs, would it be acceptable to make the 
> code more permissive by forwarding all the range of reserved group 
> addresses when STP is disabled? If not, what would be the way to go 
> about enabling 802.1x authentication from within a virtual machine?
> 
> BTW, it seems this issue has been raised before, 
> https://lists.linux-foundation.org/pipermail/bridge/2007-November/005629.html
> with the conclusion that
> > Despite what the standards say, many users are using bridging code for invisible
> > firewalls etc, and in those cases they want STP and EAPOL frames to be forwarded.

I would just take off the last byte (dest check).



-- 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH] bridge: Forward reserved group addresses if !STP
  2010-10-18 16:38 ` [Bridge] " Stephen Hemminger
@ 2010-10-19  2:09   ` Benjamin Poirier
  2010-10-19  3:28     ` Stephen Hemminger
  0 siblings, 1 reply; 5+ messages in thread
From: Benjamin Poirier @ 2010-10-19  2:09 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: David S. Miller, Herbert Xu, Eric Dumazet, Jiri Pirko, bridge,
	netdev, linux-kernel

Make all frames sent to reserved group MAC addresses (01:80:c2:00:00:00 to
01:80:c2:00:00:0f) be forwarded if STP is disabled. This enables
forwarding EAPOL frames, among other things.

Signed-off-by: Benjamin Poirier <benjamin.poirier@polymtl.ca>
---
 net/bridge/br_input.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 826cd52..436488c 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -159,7 +159,7 @@ struct sk_buff *br_handle_frame(struct sk_buff *skb)
 			goto drop;
 
 		/* If STP is turned off, then forward */
-		if (p->br->stp_enabled == BR_NO_STP && dest[5] == 0)
+		if (p->br->stp_enabled == BR_NO_STP)
 			goto forward;
 
 		if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] bridge: Forward reserved group addresses if !STP
  2010-10-19  2:09   ` [PATCH] bridge: Forward reserved group addresses if !STP Benjamin Poirier
@ 2010-10-19  3:28     ` Stephen Hemminger
  2010-10-21 11:29       ` David Miller
  0 siblings, 1 reply; 5+ messages in thread
From: Stephen Hemminger @ 2010-10-19  3:28 UTC (permalink / raw)
  To: Benjamin Poirier
  Cc: David S. Miller, Herbert Xu, Eric Dumazet, Jiri Pirko, bridge,
	netdev, linux-kernel

On Mon, 18 Oct 2010 22:09:35 -0400
Benjamin Poirier <benjamin.poirier@polymtl.ca> wrote:

> Make all frames sent to reserved group MAC addresses (01:80:c2:00:00:00 to
> 01:80:c2:00:00:0f) be forwarded if STP is disabled. This enables
> forwarding EAPOL frames, among other things.
> 
> Signed-off-by: Benjamin Poirier <benjamin.poirier@polymtl.ca>

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] bridge: Forward reserved group addresses if !STP
  2010-10-19  3:28     ` Stephen Hemminger
@ 2010-10-21 11:29       ` David Miller
  0 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2010-10-21 11:29 UTC (permalink / raw)
  To: shemminger
  Cc: benjamin.poirier, herbert, eric.dumazet, jpirko, bridge, netdev,
	linux-kernel

From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Mon, 18 Oct 2010 20:28:58 -0700

> On Mon, 18 Oct 2010 22:09:35 -0400
> Benjamin Poirier <benjamin.poirier@polymtl.ca> wrote:
> 
>> Make all frames sent to reserved group MAC addresses (01:80:c2:00:00:00 to
>> 01:80:c2:00:00:0f) be forwarded if STP is disabled. This enables
>> forwarding EAPOL frames, among other things.
>> 
>> Signed-off-by: Benjamin Poirier <benjamin.poirier@polymtl.ca>
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

Applied, thanks.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-10-21 11:29 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-17 18:06 EAPOL bridging Benjamin Poirier
2010-10-18 16:38 ` [Bridge] " Stephen Hemminger
2010-10-19  2:09   ` [PATCH] bridge: Forward reserved group addresses if !STP Benjamin Poirier
2010-10-19  3:28     ` Stephen Hemminger
2010-10-21 11:29       ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).