From patchwork Tue Mar 15 16:36:34 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Timo Teras X-Patchwork-Id: 87011 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 9536FB7014 for ; Wed, 16 Mar 2011 03:36:49 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932359Ab1COQgo (ORCPT ); Tue, 15 Mar 2011 12:36:44 -0400 Received: from mail-ww0-f44.google.com ([74.125.82.44]:64941 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932351Ab1COQgo (ORCPT ); Tue, 15 Mar 2011 12:36:44 -0400 Received: by wwa36 with SMTP id 36so960689wwa.1 for ; Tue, 15 Mar 2011 09:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=sN2gChpTCbE9diBoWMSOqsmfjBsM0F+HujXMGJ6aMG8=; b=Qj7AypxxndZr9YrN4M9DerLzfLldf/l7TKJMUJ9Wm+jkTlE0CCDnttwaSZut9iYJeg BUHEboTEGbt8XYYMVwRc23RzzxNgs1WzAZigc9CdISz0c+AL2H54MxWzRV9vKlO25Lus BoGUZ3QOOsY98qnMT4ZGhVTRWZ9AfrrOeiCUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=FrwmrJ/7qK6kVxxKUVTxYzJ4+IQaUdbAyHPvHDPsJjtqvtjuNIP7zmuXM6mSdujsMV W9Ao2/uuuCnwFTgkmnJtKkopRSkCaTZyK72cZHb11+M6lA4M9DQbIgv/e+asHFwPrl1o uHe0a0mCGE99n8nyBtkRK+5BL3Fqcu7isUe4c= Received: by 10.227.173.66 with SMTP id o2mr5183536wbz.182.1300207001728; Tue, 15 Mar 2011 09:36:41 -0700 (PDT) Received: from [10.26.34.2] (mail.fi.jw.org [83.145.235.193]) by mx.google.com with ESMTPS id w25sm1110849wbd.23.2011.03.15.09.36.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2011 09:36:40 -0700 (PDT) Message-ID: <4D7F9592.5050408@iki.fi> Date: Tue, 15 Mar 2011 18:36:34 +0200 From: =?UTF-8?B?VGltbyBUZXLDpHM=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Eric Dumazet CC: Doug Kehn , netdev@vger.kernel.org Subject: Re: Multicast Fails Over Multipoint GRE Tunnel References: <998769.91206.qm@web39301.mail.mud.yahoo.com> <1300203277.2927.9.camel@edumazet-laptop> In-Reply-To: <1300203277.2927.9.camel@edumazet-laptop> X-Enigmail-Version: 1.1.2 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 03/15/2011 05:34 PM, Eric Dumazet wrote: > Le lundi 14 mars 2011 à 16:34 -0700, Doug Kehn a écrit : >> I'm running kernel version 2.6.36 on ARM XSCALE (big-endian) and multicast over a multipoint GRE tunnel isn't working. For my architecture, this worked on 2.6.26.8. For x86, multicast over a multipoint GRE tunnel worked with kernel version 2.6.31 but failed with version 2.6.35. Multicast over a multipoint GRE tunnel fails because ipgre_header() fails the 'if (iph->daddr)' check and reutrns -t->hlen. ipgre_header() is being called, from neigh_connected_output(), with a non-null daddr; the contents of daddr is zero. >> >> Reverting the ip_gre.c patch posted in http://marc.info/?l=linux-netdev&m=126762491525281&w=2 resolves the problem. (Reviewing the HEAD of net-next-2.6 it appears that ipgre_header() remains unchanged from 2.6.36.) >> >> The configuration used to discover/diagnose the problem: >> >> ip tunnel add tun1 mode gre key 11223344 ttl 64 csum remote any >> ip link set dev tun1 up >> ip link set dev tun1 multicast on >> ip addr flush dev tun1 >> ip addr add 10.40.92.114/24 broadcast 10.40.92.255 dev tun1 >> >> 12: tun1: mtu 1468 qdisc noqueue >> link/gre 0.0.0.0 brd 0.0.0.0 >> inet 10.40.92.114/24 brd 10.40.92.255 scope global tun1 >> >> Then attempt: >> ping -I tun1 224.0.0.9 >> >> Are additional configuration steps now required for multicast over multipoint GRE tunnel or is ipgre_header() in error? > > Hi Doug > > CC Timo Teras > > I would do a partial revert of Timo patch, but this means initial > concern should be addressed ? > > (Timo mentioned : > If the NOARP packets are not dropped, ipgre_tunnel_xmit() will > take rt->rt_gateway (= NBMA IP) and use that for route > look up (and may lead to bogus xfrm acquires).) > > > Is the following works for you ? I have memory that _header() is called with daddr being valid pointer, but pointing to zero memory. So basically my situation would break with this. The above configuration would be fixable by setting broadcast to tun1 interface explicitly. But I'm not sure if the above configuration is somehow different that it'd need to work. Basically how things work on send path is: 1. arp_constructor maps multicast address to NUD_NOARP 2. arp_mc_map in turn copies dev->broadcast to haddr (so you get the ip packet pointing to zero ip) - i assumed normally gre tunnels would have the broadcast address set 3. ipgre_tunnel_xmit checks for daddr==0 and uses the rt_gateway then, which would map to the multicast address So I assume that the above ping command not working would end up sending gre encapsulated packet where both the inner and outer IP address is the same multicast address? Looks like my patch also broke the default behaviour that if one has such GRE tunnel, and you send unicast packets, it would default the link destination to be same as the inner destination. Not sure if this would be useful. So basically my situation is undistinguishable from the above one. The only difference is that the above problems only with multicast, and I'm having with unicast. I think the fundamental problem is that arp_mc_map maps the multicast address to zeroes (due to device broadcast being zero). Could we instead maybe do something like: memcpy(haddr, dev->broadcast, dev->addr_len); --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c index 7927589..372448a 100644 --- a/net/ipv4/arp.c +++ b/net/ipv4/arp.c @@ -215,6 +215,12 @@ int arp_mc_map(__be32 addr, u8 *haddr, struct net_device *dev, int dir) case ARPHRD_INFINIBAND: ip_ib_mc_map(addr, dev->broadcast, haddr); return 0; + case ARPHRD_IPGRE: + if (dev->broadcast) + memcpy(haddr, dev->broadcast, dev->addr_len); + else + memcpy(haddr, &addr, sizeof(addr)); + return 0; default: if (dir) {