martin f krafft a écrit :
This bug I see with 2.6.18
Of course, Debian's 2.6.18 does not support IPv6 conntrack.
Okay, this is all I was asking in the original mail.
Note, however, that the 2.6.18 kernel modules exist and everything
can be set up without errors, it then just doesn't work.
This is getting confused. Didn't you wrote "I can confirm that nf_*
modules are not present in Debian's 2.6.18" ?
and someone else with 2.6.22.
Nicolas ? He just wrote he couldn't reproduce it.
Okay, I have not tried.
But you reply him that "this is still the case with 2.6.24."
So what exactly is wrong with IPv6 conntrack in 2.6.24 ?
On which pre-2.6.24 versions - besides Debian's 2.6.18 image which has
IPv6 conntrack support disable at build time, this is not a bug but a
feature - do you see an IPv6 conntrack bug such as the "don't seem to
register OUTGOING packets in the connection table" bug you described ?
Or are you saying that if you ping6 from the machine with the
iptables rules to somewhere else, the echo-reply gets matched by
RELATED or ESTABLISHED?
Yes, of course. The outgoing echo request is in the NEW state and
the incoming echo reply is in the ESTABLISHED state. Same with an
incoming echo request.
... except for 2.6.18, where everything seems like that should be
the case, but it doesn't work at all. Packets aren't even in the NEW
state, it seems.
On 2.6.18, I've observed that --state INVALID seems to match *all*
IPv6 packets, and NEW,ESTABLISHED,RELATED match *none*.
If I understood correctly, that's just because Debian's 2.6.18 kernel
image has NF_CONNTRACK disabled at build time and lacks IPv6 conntrack
support. So using the 'state' match in ip6tables rules with this kernel
just makes no sense. If you build a custom 2.6.18 kernel with
NF_CONNTRACK and IPv6 conntrack support enabled instead of
IP_NF_CONNTRACK, I bet that IPv6 packets will have the proper state.
There must be something wrong with your kernel.
Yeah, it's 2.6.18.
I thought you meant a pre-2.6.24 kernel other than the Debian's 2.6.18.
You have 2.6.20. Apparently conntrack has been
worked on.
AFAIK, the only improvement in the area of this thread is that an error
"can't load conntrack support for proto=10" is triggered when you try to
use the 'state' match in ip6tables if the kernel is built with
ip_conntrack, thus lacks IPv6 conntrack support.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
