(2010/03/25 18:23), Jozsef Kadlecsik wrote:
First of all. in "sane" setup, people should configure according
to their own requirements. They may or may not want send back
icmp packet. And, even if the core is to send icmp back, the
state would be correctly assigned.
I meant the state of the fragmented packets. If we let the uncompleted
fragments to enter conntrack, as far as I see their state will be INVALID.
Or should we add an exception and set their state to UNTRACKED in
conntrack?
Got it. INVALID seems fine to me so far
while further consideration might be needed.
For my conclusion, first option is just to drop
uncompleted fragments as we do today. Second option
would be to forward them to the next process so that
core code could send ICMPv6 etc. or, we could have
new code to send ICMPV6_TIME_EXCEED in REJECT target.
In longer term, I think it is better to introduce
per-exthdr hooks.
I agree with your conclusion too, except a few question.
It is unclear for me how can you forward the packets to the next process:
above you pointed out that in defrag/reassembly before conntrack we do not
know yet whether the packets are destined to the host or not. So again,
how would you let through the fragments on conntrack then?
I don't know how could the REJECT target help in any way.
Argh, more explanation.
If you unconditionally send ICMPv6, behavior would be
broken.
If you do really want to send ICMP in netfilter,
you could pretend additional rules in filter table.
For example, ICMP to be sent back only if other exthdrs
do not exist, and other packets to be silently dropped.
This cannot be our clean/final/full answer, so I said it'd
be better to introduce per-exthdr hooks in longer term.
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
