[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20140516.165911.11269553598440450.davem@davemloft.net>
Date: Fri, 16 May 2014 16:59:11 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: timo.teras@....fi
Cc: netdev@...r.kernel.org, therbert@...gle.com, edumazet@...gle.com
Subject: Re: [PATCH net,v2] ipv4: ip_tunnels: disable cache for nbma gre
tunnels
From: Timo Teräs <timo.teras@....fi>
Date: Fri, 16 May 2014 08:34:39 +0300
> The connected check fails to check for ip_gre nbma mode tunnels
> properly. ip_gre creates temporary tnl_params with daddr specified
> to pass-in the actual target on per-packet basis from neighbor
> layer. Detect these tunnels by inspecting the actual tunnel
> configuration.
>
> Minimal test case:
> ip route add 192.168.1.1/32 via 10.0.0.1
> ip route add 192.168.1.2/32 via 10.0.0.2
> ip tunnel add nbma0 mode gre key 1 tos c0
> ip addr add 172.17.0.0/16 dev nbma0
> ip link set nbma0 up
> ip neigh add 172.17.0.1 lladdr 192.168.1.1 dev nbma0
> ip neigh add 172.17.0.2 lladdr 192.168.1.2 dev nbma0
> ping 172.17.0.1
> ping 172.17.0.2
>
> The second ping should be going to 192.168.1.2 and head 10.0.0.2;
> but cached gre tunnel level route is used and it's actually going
> to 192.168.1.1 via 10.0.0.1.
>
> The lladdr's need to go to separate dst for the bug to trigger.
> Test case uses separate route entries, but this can also happen
> when the route entry is same: if there is a nexthop exception or
> the GRE tunnel is IPsec'ed in which case the dst points to xfrm
> bundle unique to the gre lladdr.
>
> Fixes: 7d442fab0a67 ("ipv4: Cache dst in tunnels")
> Signed-off-by: Timo Teräs <timo.teras@....fi>
Yeah, this one compiles :-)
Applied and queued up for -stable, thanks!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists