<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - ip6_tables connmark or connlabel never matches"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1128#c2">Comment # 2</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - ip6_tables connmark or connlabel never matches"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1128">bug 1128</a>
from <span class="vcard"><a class="email" href="mailto:fw@strlen.de" title="Florian Westphal <fw@strlen.de>"> <span class="fn">Florian Westphal</span></a>
</span></b>
<pre>(In reply to Jim Carter from <a href="show_bug.cgi?id=1128#c1">comment #1</a>)
<span class="quote">> Created <span class=""><a href="attachment.cgi?id=498" name="attach_498" title="Test ruleset using connlabel">attachment 498</a> <a href="attachment.cgi?id=498&action=edit" title="Test ruleset using connlabel">[details]</a></span>
> Test ruleset using connlabel</span >
Thanks, the reproducer works for me.
This is caused by
netfilter: connmark: ignore skbs with magic untracked conntrack objects
<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fb9c9649a1d0a65a8f94f784aa18252a0dd584c1">https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fb9c9649a1d0a65a8f94f784aa18252a0dd584c1</a>
but unfortunately that change is/was intentional.
The problem is that in ipv6, mac address <-> ipv6 address resolution is handled
by icmpv6, and netfilters connection tracker intentionally ignores them
(ipv4 uses arp which isn't handled by iptables).
Before the commit, this worked because the mark would be added to the percpu
untracked object. It never worked for connlabels as the match always contained
the ct_is_untracked() test.
The test works fine when adding
ip6tables -I INPUT -p icmpv6 -m conntrack --ctstate UNTRACKED -j ACCEPT
to pass neigh resolution packets.
I see no way to fix this, reverting is possible of course but has other
side effects, the percpu object is never reset so when doing something like
-m <some condition> -j CONNMARK --set-mark 42
-m connmark --mark 42
... the 2nd rule will match other UNTRACKED packets too.
Resetting the untracked object is possible, but will need more code to avoid
problems when NFQUEUE gets used (so multiple packets can refer to same
untracked
entry).
Furthermore, this would force us to retain the UNTRACKED object, so we won't be
able to remove it as done in this pending patch (not yet applied):
<a href="https://patchwork.ozlabs.org/patch/736578/">https://patchwork.ozlabs.org/patch/736578/</a></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>