From: "Andy Gospodarek" <andy@greyhouse.net>
To: "Johannes Berg" <johannes@sipsolutions.net>
Cc: "Stephen Hemminger" <shemminger@linux-foundation.org>,
netdev <netdev@vger.kernel.org>,
bridge <bridge@linux-foundation.org>
Subject: Re: [Bridge] Re: [RFC] bridging: don't forward EAPOL frames
Date: Tue, 27 Nov 2007 10:24:01 -0500 [thread overview]
Message-ID: <bdfc5d6e0711270724i3ce7cf41lb5f01dd5dcac98f9@mail.gmail.com> (raw)
In-Reply-To: <1196169854.6058.16.camel@johannes.berg>
On Nov 27, 2007 8:24 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> > > + if (unlikely(skb->protocol = htons(ETH_P_PAE)))
> > > + goto drop;
> > > +
> > > switch (p->state) {
> > > case BR_STATE_FORWARDING:
> >
> > Not needed because the bridge is already handling it:
> >
> > 1) If running STP (ie true bridge), then all link local multicast is only received by
> > the bridge and never forwarded.
>
> Well, typical access point setups bridge the wireless AP interface with
> wired, EAPOL frames can be unicast (and 802.11 specifies to do so) and
> we want to avoid having them unicast to another host.
>
> Also, 802.1X in C.3.3 recommends not bridging the *ethertype* rather
> than depending on the link-local multicast address because otherwise
> eapol frames can be unicast into the network behind the (authorized)
> port which is undesirable.
>
> johannes
>
>
I agree with Stephen, that based on the way it's likely people use
linux bridges it seems like this is something that could be configured
rather than simply dropping those frames without any chance to forward
them. There are probably quite a few people out there who will not
expect this change, so it should be easy to change during runtime.
Don't forget that a simple ebtables rule could also drop EAPOL if needed.
next prev parent reply other threads:[~2007-11-27 15:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-22 13:23 [RFC] bridging: don't forward EAPOL frames Johannes Berg
2007-11-26 17:36 ` Stephen Hemminger
2007-11-27 13:24 ` Johannes Berg
2007-11-27 15:24 ` Andy Gospodarek [this message]
2007-11-27 15:28 ` [Bridge] " Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bdfc5d6e0711270724i3ce7cf41lb5f01dd5dcac98f9@mail.gmail.com \
--to=andy@greyhouse.net \
--cc=bridge@linux-foundation.org \
--cc=johannes@sipsolutions.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox