On Wed, Nov 06, 2013 at 03:44:53PM +0100, Jiri Pirko wrote: > Wed, Nov 06, 2013 at 03:33:49PM CET, fw@xxxxxxxxx wrote: > >Jiri Pirko <jiri@xxxxxxxxxxx> wrote: > >> >> >So if someone wants to change this, simply *only* pass the reassembled > >> >> >packet through the netfilter hooks and drop the fragments, as in IPv4. > >> >> > >> >> This is unfortunatelly not possible because in forwarding use case, the > >> >> fragments have to be send out as they come in. > >> > > >> >No, the IPv6 NAT patches fixed that, we still do proper refragmentation > >> >and we still respect the original fragment sizes, thus are not responsible > >> >for potentially exceeding the PMTU on the following path. > >> > >> Can you please point where this is done. Where the original fragment > >> sizes are stored and in which code are they restored? Thanks. > > > >Patrick is probably talking about > > > >commit 4cdd34084d539c758d00c5dc7bf95db2e4f2bc70 > >(netfilter: nf_conntrack_ipv6: improve fragmentation handling) > >which introduces 'frag_max_size' in inet6_skb_parm struct. Indeed. > Thanks for the pointer. Interestingly though, according to my testing, > if reassembled packet would fit into outdev mtu, it is not fragmented > to the original frag size and it is send as single big packet. That is > I believe not correct. Hmm right, that wasn't the intention. We currently only use frag_max_size to send PKT_TOOBIG messages if the size exceeds the MTU, but not to trigger fragmentation itself. We probably need to handle this in ip6_finish_output(). Would you mind fixing this up as well in your patches? -- 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
