Greg Scott wrote:
Indeed, on output bridge netfilter will run after IPv4 netfilter.
Does that explain things?
Well, not really. 2.6.23-2 behaves differently than 2.6.18. My
ebtables marks get set and read by iptables in 2.6.18. iptables does
not see them in 2.6.23.
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
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.
I set my ebtables mark for outbound packets in two places - in the
OUTPUT chain and the FORWARD chain. I was looking mostly at the
ebtables FORWARD chain for packets that pass thru the box. I set the
mark in ebtables FORWARD and OUTPUT. Iptables POSTROUTING needs to see
them so it knows to MASQUERADE. Otherwise, things get really weird. :)
iptables sees the marks in 2.6.18, but does not see them in 2.6.23.
I have a couple of 2.6.23 systems here and I can brew up a 2.6.18 fc6
system later on for testing if needed. (All the 2.6.18 stuff I have
built up right now is in production.) I can set up some tests similarly
to Jan's testing from last night for packets passing through the box.
Or if there's a better way to do this, I'm open.
For routed packets you can't make any decisions in iptables based
on the outgoing bridge port, thats only possible for purely bridged
traffic.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
