| Message ID | 4D805239.6040905@iki.fi |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
Hi Timo, --- On Wed, 3/16/11, Timo Teräs <timo.teras@iki.fi> wrote: > From: Timo Teräs <timo.teras@iki.fi> > Subject: Re: Multicast Fails Over Multipoint GRE Tunnel > To: "Doug Kehn" <rdkehn@yahoo.com> > Cc: "Eric Dumazet" <eric.dumazet@gmail.com>, netdev@vger.kernel.org > Date: Wednesday, March 16, 2011, 2:01 AM > On 03/15/2011 11:35 PM, Doug Kehn > wrote: > >> From: Timo Teräs <timo.teras@iki.fi> > >> Subject: Re: Multicast Fails Over Multipoint GRE > Tunnel > >> To: "Eric Dumazet" <eric.dumazet@gmail.com> > >> Cc: "Doug Kehn" <rdkehn@yahoo.com>, > 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 > > 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) { > > memcpy(haddr, dev->broadcast, dev->addr_len); > -- It does! With this patch my configuration works. Thanks, ...doug -- 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
On 03/16/2011 10:02 PM, Doug Kehn wrote: >> From: Timo Teräs <timo.teras@iki.fi> >> Subject: Re: Multicast Fails Over Multipoint GRE Tunnel >> To: "Doug Kehn" <rdkehn@yahoo.com> >> Cc: "Eric Dumazet" <eric.dumazet@gmail.com>, netdev@vger.kernel.org >> Date: Wednesday, March 16, 2011, 2:01 AM >> On 03/15/2011 11:35 PM, Doug Kehn >> wrote: >>>> From: Timo Teräs <timo.teras@iki.fi> >>>> Subject: Re: Multicast Fails Over Multipoint GRE Tunnel >>>> To: "Eric Dumazet" <eric.dumazet@gmail.com> >>>> Cc: "Doug Kehn" <rdkehn@yahoo.com>, 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. > > It does! With this patch my configuration works. I've been trying to think what would be the proper way to handle multicast in ip_gre. I would also hope to get the ipmr code integrated with opennhrp and ip_gre (see my earlier mail from couple of years ago: http://lists.openwall.net/netdev/2009/08/11/27). I believe we should just create the noarp multicast mappings as my patch suggests. Both for IPv4 and IPv6 we map the inner multicast group to the IPv4 header of GRE. And I believe we should drop the support of auto-mapping unicast addresses to unicast address. Does anyone think it's useful if sending to 1.2.3.4 in gre1, would result in automapping the outer IP also to 1.2.3.4 in case the interface was in NOARP mode? I believe the user should just insert manually the ARP entries in this case. Also, I noticed that ipmr got support for multiple tables, that fixes one of the problem I stated along with the old patch. So I'm planning to reimplement at some point the patch from the above link. It'd probably involve also hooking link-local multicast traffic through the ipmr engine when using the NBMA mode. Obviously the ipmr when configured would override the static NOARP multicast mappings. If no one has objections I'll write up an official-looking patch that adds the IPv4 multicast mappings, and try to fix up the same for IPv6 side. When this is done, it should be possible the get rid of the "if ((dst = tiph->daddr) == 0) {" block in ipgre_tunnel_xmit(), since we are then creating all the mappings from the ARP code where it should be done anyway. Any comments for this plan? Eric? Dave? Cheers, Timo -- 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) {