Re: [Bridge] EAPOL bridging

From: Stephen Hemminger
Date: Mon Oct 18 2010 - 12:39:35 EST

On Sun, 17 Oct 2010 14:06:28 -0400
Benjamin Poirier <benjamin.poirier@xxxxxxxxx> 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,
> 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:
> 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,
> 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).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at