From patchwork Wed Mar 16 06:01:29 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Timo Teras X-Patchwork-Id: 87174 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 82C5AB6FFD for ; Wed, 16 Mar 2011 17:01:46 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751479Ab1CPGBd (ORCPT ); Wed, 16 Mar 2011 02:01:33 -0400 Received: from mail-wy0-f174.google.com ([74.125.82.174]:37622 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751461Ab1CPGBc (ORCPT ); Wed, 16 Mar 2011 02:01:32 -0400 Received: by wya21 with SMTP id 21so1298912wya.19 for ; Tue, 15 Mar 2011 23:01:31 -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=rpOkbfXRkeCtMnbaD2FCI/R1PUS/QP+m9NRGXhp64lg=; b=pNW9xPjT9idFaJVuEoj0CSoKg1cTsIhiVGTgvHncuBl6Q6wQ780bHBZ8lo7OZ5I4hZ eL/QbdIvMk0ZsopMFa5nLZq35kE9bBYgDw8hr93Sw4a6mWQFRKWHzrmRQusx8uy8ejgc CkFLY85+gXQVXiH5XjF36kM2zRG1eEiq72914= 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=MKwtS3Tfnd+5ggGcTm0qzkVtU36LTPfvSPc/A5MD7xutr/Qx1yBfR+D9Yex45GhuIn gOcVs3Tr6+CEDEaisBIAqimYtZVLjKEZRJaE+1X22mFqIAlnm80tRPWmNHLKRT/fStXx qU6mwCWjlQINFBSgq+YiG4Rs2Ly207z7NjYgE= Received: by 10.227.136.204 with SMTP id s12mr381210wbt.15.1300255290880; Tue, 15 Mar 2011 23:01:30 -0700 (PDT) Received: from [10.26.34.2] (mail.fi.jw.org [83.145.235.193]) by mx.google.com with ESMTPS id m2sm330150wer.37.2011.03.15.23.01.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2011 23:01:29 -0700 (PDT) Message-ID: <4D805239.6040905@iki.fi> Date: Wed, 16 Mar 2011 08:01:29 +0200 From: =?ISO-8859-1?Q?Timo_Ter=E4s?= 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: Doug Kehn CC: Eric Dumazet , netdev@vger.kernel.org Subject: Re: Multicast Fails Over Multipoint GRE Tunnel References: <553973.46912.qm@web39301.mail.mud.yahoo.com> In-Reply-To: <553973.46912.qm@web39301.mail.mud.yahoo.com> 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 11:35 PM, Doug Kehn wrote: >> From: Timo Teräs >> Subject: Re: Multicast Fails Over Multipoint GRE Tunnel >> To: "Eric Dumazet" >> Cc: "Doug Kehn" , netdev@vger.kernel.org >> Date: Tuesday, March 15, 2011, 12:36 PM >> 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. > > I wasn't sure if the above patch was in addition too or in lieu of the partial revert of ipgre_header() suggested by Eric; both cases were attempted. It was intended without the ipgre_header revert. The partial revert does not differ from full revert related to my problem. > The multicast scenario described does not work if only the arp_mc_map() patch is applied. Uh. Right, the if test had wrong condition. The intention was to show the idea that we create the multicast-to-multicast GRE NOARP mappings in arp code where it should've been done in the first place (IMHO). Could you try the below patch? That should work better. And the ipgre_header should not be touched. - Timo 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..8c24845 100644 --- a/net/ipv4/arp.c +++ b/net/ipv4/arp.c @@ -215,6 +215,13 @@ 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->addr_len == 4 && + get_unaligned_be32(dev->broadcast) != INADDR_ANY) + memcpy(haddr, dev->broadcast, dev->addr_len); + else + memcpy(haddr, &addr, sizeof(addr)); + return 0; default: if (dir) {