From: David Newall <davidn@davidnewall.com>
To: Valdis.Kletnieks@vt.edu
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Netdev <netdev@vger.kernel.org>,
bridge@lists.linux-foundation.org,
Florian Westphal <fw@strlen.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Bridge] Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)
Date: Wed, 21 May 2014 17:40:25 +0930 [thread overview]
Message-ID: <537C5F71.6000204@davidnewall.com> (raw)
In-Reply-To: <14456.1400561749@turing-police.cc.vt.edu>
On 20/05/14 14:25, Valdis.Kletnieks@vt.edu wrote:
> So yes, we*do* need to do something sensible there - either frag the packet
> on the way out, or something.
I think the problem is that a bridge cannot be used across incompatible
media. That's the job of a router.
A bridge should act like a bridge, not a router. Fragmenting the packet
is wrong; that's IP's job. Dropping the packet is also arguably wrong;
that's the real device-driver's job. What seems right to me is to act
like a bridge and forward packets by looking inside of them *no more
than is necessary*. Looking beyond MAC address is perhaps too much.
We can finish the job of processing IP options, or at least in this
scenario, but that seems wrong-headed and invites more work as more
problems are discovered; or we could remove the half-hearted attempt it
currently does and leave the bridge as a simple bridge.
This problem wouldn't occur if all devices in a bridge were required to
be compatible media; particularly identical MTU.
WARNING: multiple messages have this Message-ID (diff)
From: David Newall <davidn@davidnewall.com>
To: Valdis.Kletnieks@vt.edu
Cc: Florian Westphal <fw@strlen.de>,
Stephen Hemminger <stephen@networkplumber.org>,
Netdev <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
bridge@lists.linux-foundation.org
Subject: Re: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)
Date: Wed, 21 May 2014 17:40:25 +0930 [thread overview]
Message-ID: <537C5F71.6000204@davidnewall.com> (raw)
In-Reply-To: <14456.1400561749@turing-police.cc.vt.edu>
On 20/05/14 14:25, Valdis.Kletnieks@vt.edu wrote:
> So yes, we*do* need to do something sensible there - either frag the packet
> on the way out, or something.
I think the problem is that a bridge cannot be used across incompatible
media. That's the job of a router.
A bridge should act like a bridge, not a router. Fragmenting the packet
is wrong; that's IP's job. Dropping the packet is also arguably wrong;
that's the real device-driver's job. What seems right to me is to act
like a bridge and forward packets by looking inside of them *no more
than is necessary*. Looking beyond MAC address is perhaps too much.
We can finish the job of processing IP options, or at least in this
scenario, but that seems wrong-headed and invites more work as more
problems are discovered; or we could remove the half-hearted attempt it
currently does and leave the bridge as a simple bridge.
This problem wouldn't occur if all devices in a bridge were required to
be compatible media; particularly identical MTU.
next prev parent reply other threads:[~2014-05-21 8:10 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-11 14:41 Bad checksum on bridge with IP options David Newall
2014-05-11 19:42 ` Lukas Tribus
2014-05-12 8:14 ` David Newall
2014-05-12 10:15 ` Lukas Tribus
2014-05-12 10:25 ` David Newall
2014-05-12 10:31 ` Lukas Tribus
2014-05-12 10:48 ` David Newall
2014-05-12 13:23 ` David Newall
2014-05-12 13:51 ` Florian Westphal
2014-05-12 14:19 ` David Newall
2014-05-12 18:54 ` Lukas Tribus
2014-05-12 23:46 ` David Newall
2014-05-14 13:08 ` David Newall
2014-05-16 14:33 ` Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack) David Newall
2014-05-16 15:19 ` Eric Dumazet
2014-05-16 15:23 ` David Newall
2014-05-16 15:24 ` David Newall
2014-05-19 12:58 ` [Bridge] " David Newall
2014-05-19 12:58 ` David Newall
2014-05-19 14:01 ` [Bridge] " Florian Westphal
2014-05-19 14:01 ` Florian Westphal
2014-05-19 14:19 ` [Bridge] " David Newall
2014-05-19 14:19 ` David Newall
2014-05-19 17:09 ` [Bridge] " Florian Westphal
2014-05-19 17:09 ` Florian Westphal
2014-05-19 20:49 ` [Bridge] " Bart De Schuymer
2014-05-19 20:49 ` Bart De Schuymer
2014-05-21 7:49 ` [Bridge] " David Newall
2014-05-21 7:49 ` David Newall
2014-05-21 18:51 ` [Bridge] " Bart De Schuymer
2014-05-21 18:51 ` Bart De Schuymer
2014-05-21 20:18 ` [Bridge] " David Miller
2014-05-21 20:18 ` David Miller
2014-05-22 18:57 ` [Bridge] " Bart De Schuymer
2014-05-22 18:57 ` Bart De Schuymer
2014-05-24 18:00 ` [Bridge] " David Miller
2014-05-24 18:00 ` David Miller
2014-05-24 5:56 ` [Bridge] " David Newall
2014-05-24 5:56 ` David Newall
2014-05-24 17:43 ` [Bridge] " David Miller
2014-05-24 17:43 ` David Miller
2014-05-25 2:32 ` [Bridge] " David Newall
2014-05-25 2:32 ` David Newall
2014-05-25 3:02 ` [Bridge] " David Miller
2014-05-25 3:02 ` David Miller
2014-05-25 6:37 ` [Bridge] " David Newall
2014-05-25 6:37 ` David Newall
2014-05-27 8:55 ` [Bridge] " David Laight
2014-05-27 8:55 ` David Laight
2014-05-29 22:34 ` [Bridge] " David Miller
2014-05-29 22:34 ` David Miller
2014-05-30 9:17 ` [Bridge] " David Newall
2014-05-30 9:17 ` David Newall
2014-05-31 0:46 ` [Bridge] " David Miller
2014-05-31 0:46 ` David Miller
2014-05-31 6:13 ` [Bridge] " David Newall
2014-05-31 6:13 ` David Newall
2014-05-31 6:37 ` [Bridge] " David Miller
2014-05-31 6:37 ` David Miller
2014-05-22 3:50 ` [Bridge] " David Newall
2014-05-22 3:50 ` David Newall
2014-05-22 18:57 ` [Bridge] " Bart De Schuymer
2014-05-22 18:57 ` Bart De Schuymer
2014-05-20 3:57 ` [Bridge] " David Newall
2014-05-20 3:57 ` David Newall
2014-05-20 4:55 ` [Bridge] " Valdis.Kletnieks
2014-05-20 4:55 ` Valdis.Kletnieks
2014-05-20 16:05 ` [Bridge] " Vlad Yasevich
2014-05-20 16:05 ` Vlad Yasevich
2014-05-20 16:05 ` Vlad Yasevich
2014-05-21 8:10 ` David Newall [this message]
2014-05-21 8:10 ` David Newall
2014-05-21 20:14 ` [Bridge] " David Miller
2014-05-21 20:14 ` David Miller
2014-05-21 20:14 ` David Miller
2014-05-22 20:06 ` Bandan Das
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=537C5F71.6000204@davidnewall.com \
--to=davidn@davidnewall.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=bridge@lists.linux-foundation.org \
--cc=fw@strlen.de \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.