On Thu, 20 Feb 2014, Art -kwaak- van Breemen wrote:
> I ack the working of that change for my specific case: passing
> pmtud's correctly:
> Feb 20 18:58:59 c43236 kernel: [ 721.473388] IPVS: Enter:
> ip_vs_icmp_xmit_v6, net/netfilter/ipvs/ip_vs_xmit.c line 1186
> Feb 20 18:58:59 c43236 kernel: [ 721.473389] IPVS: Enter: ip_vs_nat_icmp_v6,
> net/netfilter/ipvs/ip_vs_core.c line 738
> Feb 20 18:58:59 c43236 kernel: [ 721.473390] IPVS: icmp_offset=40,protocol=58
> Feb 20 18:58:59 c43236 kernel: [ 721.473391] IPVS: ip_vs_nat_icmp_v6()
> changed port 80 to 80
> Feb 20 18:58:59 c43236 kernel: [ 721.473393] IPVS: Leave: ip_vs_nat_icmp_v6,
> net/netfilter/ipvs/ip_vs_core.c line 786
> Feb 20 18:58:59 c43236 kernel: [ 721.473396] IPVS: Leave:
> ip_vs_icmp_xmit_v6, net/netfilter/ipvs/ip_vs_xmit.c line 1263
> 18:58:59.067282 00:23:24:26:b4:5c > 00:23:24:26:b4:34, ethertype IPv6
> (0x86dd), length 1294: 2001:7b8:2ff:6f::1 > 2a02:310:0:1013::1003: ICMP6,
> packet too big, mtu 1472, length 1240
> So the "|| found" sounds sane.
Thanks for the confirmation. Then may be Hans
can post a fix for this problem after checking the callers
> But now I'm going to be an ass by saying that maybe both patches must be
> applied because we only get into ip_vs_nat_icmp_v6 by ip_vs_fill_iph_skb in
> include/net/ip_vs.h, which determines the protocol and the start of the
> protocol header by using -1 as target in ipv6_find_hdr.
> Actually, before we reach that nat function we have traversed several
> constructs of:
> protocol,offset = ipv6_find_hdr (target = -1 )
> if ( protocol != IPPROTO_ICMPV6)
> bail out (return NF_ACCEPT actually) .
Yes, it is not expected, the protocol was
already validated. May be we will save some cycles
without such check...
> (and maybe use offset)
> So I think it's clearer for the total code if we follow the exact same
> find a protocol, bail out if protocol wrong.
> It should never happen at that point, but there are more things that never
> should happen :-).
> Anyway: whatever you guys decide, I owe you all beer. I think we are one of
> few companies that assume a working pmtud for ipv6. Most of the top companies
> just use an mtu of 1280 because the "hardware" loadbalancer cannot handle it
> (yet) or just want to prevent the hassle. Thanks!
> Ard van Breemen
Julian Anastasov <ja@xxxxxx>
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html