| Message ID | 1300203277.2927.9.camel@edumazet-laptop |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
Hi Eric, --- On Tue, 3/15/11, Eric Dumazet <eric.dumazet@gmail.com> wrote: > From: Eric Dumazet <eric.dumazet@gmail.com> > Subject: Re: Multicast Fails Over Multipoint GRE Tunnel > To: "Doug Kehn" <rdkehn@yahoo.com> > Cc: netdev@vger.kernel.org, "Timo Teras" <timo.teras@iki.fi> > Date: Tuesday, March 15, 2011, 11:34 AM > Le lundi 14 mars 2011 à 16:34 -0700, > Doug Kehn a écrit : > > Hi All, > > > > 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: <MULTICAST,NOARP,UP,10000> 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 <timo.teras@iki.fi> > > 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 ? > > diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c > index da5941f..47844fa2 100644 > --- a/net/ipv4/ip_gre.c > +++ b/net/ipv4/ip_gre.c > @@ -1170,8 +1170,10 @@ static int ipgre_header(struct > sk_buff *skb, struct net_device *dev, > > if (saddr) > > memcpy(&iph->saddr, saddr, 4); > - if (daddr) > + if (daddr) { > > memcpy(&iph->daddr, daddr, 4); > + return t->hlen; > + } > if (iph->daddr) > return t->hlen; > Yes, the partial revert does work. Regards, ...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
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c index da5941f..47844fa2 100644 --- a/net/ipv4/ip_gre.c +++ b/net/ipv4/ip_gre.c @@ -1170,8 +1170,10 @@ static int ipgre_header(struct sk_buff *skb, struct net_device *dev, if (saddr) memcpy(&iph->saddr, saddr, 4); - if (daddr) + if (daddr) { memcpy(&iph->daddr, daddr, 4); + return t->hlen; + } if (iph->daddr) return t->hlen;