Hi.
(2010/03/11 18:16), Shan Wei wrote:
yoshifuji-san:
YOSHIFUJI Hideaki wrote, at 03/11/2010 01:13 AM:
Well, because the context of defragment are different
from standard ones (e.g., In netfilter, defragment can
happen even on forwarding path, and the result is always
thrown away anyway), I think it is not a good idea to
touch standard MIB here. However I'm okay to increment
other stats like InDiscards, OurDiscards and netfilter
specific stats.
Not only on router, but also on host, if conntrack fails to reassemble
fragments, the fragments will not be forwarded to IPv4/IPv6 stack.
So, these fragments can't be traced from MIB counter.
And, IPv4 conntrack records these fragments.
Is the context of IPv4 defragment different from IPv6?
Yes, it is different.
As you know, defragment can not happen on routers in IPv6.
Because we do want to preserve hop-by-hop option etc,
we preserve original packets in netfilter code.
In IPv6, defragment in netfilter is a temporary just
for conntrack. The state (including defragmented packet)
is not preserved, and original fragments are used in further
process (including local processing or forwarding).
So, please take that defragment failure is same as other
random reasons what netfilter code thinks. Of course,
you can introduce nf-specific counters that show reasons
why packets are discarded in netfilter module.
On the other hand, I'd even say we should NOT send
icmp here (at least by default) because standard routers
never send such packet.
Yes，for routers, the patch-set does not send icmp message to
source host. It only does on destination host with IPv6 connection
track enable.
Please make it optional (via parameter) at least.
Regards,
--yoshfuji
--
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
