Re: [PATCH] ipvs: fix ipv6 icmp forwarding in natted services

To: Julian Anastasov <ja@xxxxxx>
Subject: Re: [PATCH] ipvs: fix ipv6 icmp forwarding in natted services
Cc: lvs-devel@xxxxxxxxxxxxxxx, Jesper Dangaard Brouer <brouer@xxxxxxxxxx>, aatteka@xxxxxxxxxx, kaber@xxxxxxxxx, hans@xxxxxxxxxxxxxxx
From: Art -kwaak- van Breemen <ard@xxxxxxxxxxxxxxx>
Date: Thu, 20 Feb 2014 09:40:09 +0100

On Wed, Feb 19, 2014 at 10:44:02PM +0200, Julian Anastasov wrote:
> On Wed, 19 Feb 2014, Art -kwaak- van Breemen wrote:
> > I could not clearly see what really generatd the "invalid header"
> > error message in the log.
>       You mean "IPv6 header not found" ?
> I guess it happens for the second
> protocol = ipv6_find_hdr(skb, &offs, -1, &fragoffs, NULL);
> when icmp_offset was 0. Message is from ipv6_find_hdr.

Yes :-). I figured that after I added debugging to pinpoint it

I always saw that message in the log but I thought that's some
new warning about other devices bugs.
The message as it is right now, states something is wrong, and
please go find out yourself :-).
It would be handy if it could be either quiet "Yes, I know it can
fail but it's usually right", or stack trace it once every...
The use of ipv6_find_hdr is not that widespread yet. And in the
current case the IPPROTO_ICMPV6 is the only test in the kernel
that searches for a non ext hdr.
To be clear: if I look at my 1200+ client wireless network the
ipv6 takes up 30% of the traffic. That means ipv6 gets more and
more important (== more code) and a clear understanding of
ipv6_find_hdr is important.

Thanks for all the work guys!


Ard van Breemen
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

<Prev in Thread] Current Thread [Next in Thread>