netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: davidn@davidnewall.com
Cc: Valdis.Kletnieks@vt.edu, netdev@vger.kernel.org,
	bridge@lists.linux-foundation.org, fw@strlen.de,
	linux-kernel@vger.kernel.org, stephen@networkplumber.org
Subject: Re: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)
Date: Wed, 21 May 2014 16:14:48 -0400 (EDT)	[thread overview]
Message-ID: <20140521.161448.716446182526388511.davem@davemloft.net> (raw)
In-Reply-To: <537C5F71.6000204@davidnewall.com>

From: David Newall <davidn@davidnewall.com>
Date: Wed, 21 May 2014 17:40:25 +0930

> 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.

I completely agree with you.

I also just want to state for the record, and I know some people will
disagree with me, that I think the bridging netfilter layer should
never have been integrated into the tree.

And I've been saying this for more than a decade.

It takes layering violations to a whole new level, and it's why we see
problems like this.

Besides this IP options issue, it also creates fake ipv4 routes, so
every time someone tries to do anything non-trivial with the ipv4
routing code the bridging netfilter fake route code had to be adjusted
or else we'd get crashes.

It has also held back many potential improvements to iptables in
general over the years because it does so many things differently
than the rest of the iptables modules.

It stinks, we never should have added it, and now since we have people
have been perversely convinced that doing stuff like this is actually
sane.  It's not.

  reply	other threads:[~2014-05-21 20:14 UTC|newest]

Thread overview: 46+ 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           ` David Newall
2014-05-19 14:01             ` Florian Westphal
2014-05-19 14:19               ` David Newall
2014-05-19 17:09                 ` Florian Westphal
2014-05-19 20:49                   ` Bart De Schuymer
2014-05-21  7:49                     ` David Newall
2014-05-21 18:51                       ` Bart De Schuymer
2014-05-21 20:18                         ` David Miller
2014-05-22 18:57                           ` Bart De Schuymer
2014-05-24 18:00                             ` David Miller
2014-05-24  5:56                           ` David Newall
2014-05-24 17:43                             ` David Miller
2014-05-25  2:32                               ` David Newall
2014-05-25  3:02                                 ` David Miller
2014-05-25  6:37                                   ` David Newall
2014-05-27  8:55                                 ` David Laight
2014-05-29 22:34                                 ` David Miller
2014-05-30  9:17                                   ` David Newall
2014-05-31  0:46                                     ` David Miller
2014-05-31  6:13                                       ` David Newall
2014-05-31  6:37                                         ` David Miller
2014-05-22  3:50                         ` David Newall
2014-05-22 18:57                           ` Bart De Schuymer
2014-05-20  3:57                   ` David Newall
2014-05-20  4:55                 ` Valdis.Kletnieks
2014-05-20 16:05                   ` Vlad Yasevich
2014-05-21  8:10                   ` David Newall
2014-05-21 20:14                     ` David Miller [this message]
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=20140521.161448.716446182526388511.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davidn@davidnewall.com \
    --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 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).