|
On 08/21/2014 05:22 PM, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 21 Aug 2014, Chris J Arges wrote:
>
>> A bug was reported against our kernel, which looks to be an upstream
>> issue after some testing (as of 3.17-rc1).
>>
>> In short, it seems that using ip_vs with something like dnsmasq-tftp to
>> send data will cause the transfer to stop at some point where the read
>> will error giving EPERM. It was discovered that CONFIG_IP_VS_IPV6 was
>> the change that introduce this difference in behavor.
>>
>> The bug report is here:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349768
>
> ...
>
>> We've just recently enabled CONFIG_IP_VS_IPV6, which exposed this issue;
>> and the user is not using IPV6 functionality.
>>
>> I've traced through the code and found that this segment in
>> net/netfilter/ipvs/ip_vs_core.c
>> function ip_vs_out is what triggers this issue, if commented out the
>> problem does not occur:
>>
>> #ifdef CONFIG_IP_VS_IPV6
>> if (af == AF_INET6) {
>> if (unlikely(iph.protocol == IPPROTO_ICMPV6)) {
>> int related;
>> int verdict = ip_vs_out_icmp_v6(skb, &related,
>> hooknum, &iph);
>>
>> if (related)
>> return verdict;
>> }
>> } else
>> #endif
>>
>> Printk'ing further into this, I see that ip_vs_out_icmp_v6 utimately
>> fails as frag_safe_skb_hp return NULL when packets are no longer being
>> sent with the test case.
>
> Looking at the stack trace in your bug report it is
> strange to see ip_vs_local_reply6 called by ip_local_out (v4).
> It can also explain the ipv6_find_hdr errors, we are providing
> IPv4 packet to IPv6 code... OK, found it, my fault:
>
> commit fc604767613b6d2036cdc35b660bc39451040a47
> Author: Julian Anastasov <ja@xxxxxx>
> Date: Sun Oct 17 16:38:15 2010 +0300
>
> ipvs: changes for local real server
>
> It is evident that ip_vs_local_reply6() is
> registered in PF_INET, not in PF_INET6. Later commit
> 4c809d630c17af0e8112d5362367ced9b44b009b
> renames it to NFPROTO_IPV4.
>
>> Any suggestions for a fix for this issue, or a places to continue
>> looking? I'd be happy to continue hacking on this and provide testing.
>
> IPPROTO_ICMPV6 is 58 (0x3A). Not sure how
> ipv6_find_hdr() finds it in some of the IPv4 packets,
> it is at offset 6 which is frag_off word in IPv4 header.
> In all other cases I think traffic is passed because
> it does not look like IPPROTO_ICMPV6. I think, it
> depends on IPPROTO_ICMPV6 being found in the header
> and the ipvsh->len which is again something wrong.
>
> Please, try this patch and report for result:
>
> [PATCH net] ipvs: fix ipv6 hook registration for local replies
>
> From: Julian Anastasov <ja@xxxxxx>
>
> commit fc604767613b6d2036cdc35b660bc39451040a47
> ("ipvs: changes for local real server") from 2.6.37
> introduced support for replies from local real server
> but the IPv6 handler ip_vs_local_reply6() is registered
> incorrectly as IPv4 hook leading to dropped traffic
> depending on IPv4 header values.
>
> Reported-by: Chris J Arges <chris.j.arges@xxxxxxxxxxxxx>
> Signed-off-by: Julian Anastasov <ja@xxxxxx>
> ---
> net/netfilter/ipvs/ip_vs_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> index e683675..5c34e8d 100644
> --- a/net/netfilter/ipvs/ip_vs_core.c
> +++ b/net/netfilter/ipvs/ip_vs_core.c
> @@ -1906,7 +1906,7 @@ static struct nf_hook_ops ip_vs_ops[] __read_mostly = {
> {
> .hook = ip_vs_local_reply6,
> .owner = THIS_MODULE,
> - .pf = NFPROTO_IPV4,
> + .pf = NFPROTO_IPV6,
> .hooknum = NF_INET_LOCAL_OUT,
> .priority = NF_IP6_PRI_NAT_DST + 1,
> },
>
Julian,
My initial testing of this patch shows that it works. The test case
passes. Thanks!
--chris j arges
--
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
|
