Hello On Fri, 2014-02-21 at 00:17 +0200, Julian Anastasov wrote: > Hello, > > 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 > > > > and: > > 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 > of ipv6_find_hdr. I'll do that. > > > 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... We will save some cycles here, very few actually.. I'm not sure about the mobility header if it can break this. Have not read the RFC :-) The -1 is OK for me right now > > (and maybe use offset) > > > > So I think it's clearer for the total code if we follow the exact same construct: > > 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 the > > 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! > > > > Regards, > > > > Ard van Breemen > > Regards > > -- > Julian Anastasov <ja@xxxxxx> Regards Hans
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
