All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Jan Engelhardt <jengelh@computergmbh.de>
Cc: Greg Scott <GregScott@InfraSupportEtc.com>,
	Netfilter Developer Mailing List
	<netfilter-devel@vger.kernel.org>
Subject: Re: Ebtables hook order anomaly
Date: Tue, 25 Mar 2008 16:30:25 +0100	[thread overview]
Message-ID: <47E91A91.6000007@trash.net> (raw)
In-Reply-To: <alpine.LNX.1.10.0803251607450.9368@fbirervta.pbzchgretzou.qr>

Jan Engelhardt wrote:
> 
> On Tuesday 2008-03-25 14:49, Patrick McHardy wrote:
>> Greg Scott wrote:
>>>
>>>  It could be something in the order of execution changed.  I'm using
>>>  RedHat kernels right now and I know they tweak the kernels a little 
>>> bit.
>>>  But surely the RedHat guys would not change something this fundamental?
>>
>> No, that was us :) Bridge-netfilter used to defer the IPv4 OUTPUT
> 
> Do you have the commit id at hand? Was it
> 2bf540b73ed5b304e84bb4d4c390d49d1cfa0ef8?

Yes.

>> and POSTROUTING hook until the outgoing bridge port was determined
>> by the bridge code. This "feature" was removed because it broke
>> all kinds of things, now the order matches the layering and IPv4
>> hooks are always processed entirely before bridging.
> 
> Now the order is .. non-consistent.
> On a pure bridge forward (-i br -o br), as I have determined,
> ebtables-nat-POSTROUTING comes _before_ the IPv4 hooks.

Thats indeed inconsistent. I don't believe this has changed
however, the IPv4 POSTROUTING hook was always called from
the bridge POSTROUTING hook (with similar priorities).


  reply	other threads:[~2008-03-25 15:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-25 13:32 Ebtables hook order anomaly Greg Scott
2008-03-25 13:49 ` Patrick McHardy
2008-03-25 15:22   ` Jan Engelhardt
2008-03-25 15:30     ` Patrick McHardy [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-03-30 21:21 Greg Scott
2008-03-27  7:55 Greg Scott
2008-03-25 17:02 Greg Scott
2008-03-26  7:16 ` Patrick McHardy
2008-03-25 14:17 Greg Scott
2008-03-25  1:18 ebtables and iptables different behavior between 2.6.18 on fc6 and 2.6.23 on fc8 Greg Scott
2008-03-25  2:28 ` Jan Engelhardt
2008-03-25  6:48   ` Ebtables hook order anomaly (was: ebtables and iptables different behavior between 2.6.18 on fc6 and 2.6.23 on fc8) Jan Engelhardt
2008-03-25 12:57     ` Ebtables hook order anomaly Patrick McHardy
2008-04-09 14:07       ` Jan Engelhardt
2008-04-09 14:36         ` Patrick McHardy
2008-04-09 14:54           ` Jan Engelhardt
2008-04-09 15:04             ` Patrick McHardy
2008-04-09 15:12               ` Greg Scott
2008-04-09 16:11               ` Jan Engelhardt
2008-04-09 16:18                 ` Greg Scott
2008-04-09 15:05             ` Greg Scott
2008-04-09 15:11               ` Patrick McHardy
2008-04-09 15:21                 ` Greg Scott
2008-04-09 15:23                   ` Patrick McHardy
2008-04-09 15:39                     ` Greg Scott

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=47E91A91.6000007@trash.net \
    --to=kaber@trash.net \
    --cc=GregScott@InfraSupportEtc.com \
    --cc=jengelh@computergmbh.de \
    --cc=netfilter-devel@vger.kernel.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.