Subject: Re: Multicast Fails Over Multipoint GRE Tunnel

From: Doug Kehn <[email-masked]>
Date: Tue, 15 Mar 2011 14:24:42 -0700 (PDT)

Hi Eric,

--- On Tue, 3/15/11, Eric Dumazet <[email-masked]> wrote:

> From: Eric Dumazet <[email-masked]>
> Subject: Re: Multicast Fails Over Multipoint GRE Tunnel
> To: "Doug Kehn" <[email-masked]>
> Cc: [email-masked], "Timo Teras" <[email-masked]>
> 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 <[email-masked]>
> 
> 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