On Sun, 24 Apr 2016 13:00:20 +0200, Jiri Benc wrote: > In ipgre mode (i.e. not gretap) with collect metadata flag set, the tunnel > is incorrectly assumed to be mGRE in NBMA mode (see commit 6a5f44d7a048c). > This is not the case, we're controlling the encapsulation addresses by > lwtunnel metadata. And anyway, assigning dev->header_ops in collect metadata > mode does not make sense. > > Similarly, when a multicast remote IP address is set together with the > collect metadata flag, the processing described above would happen, too. As > there's not much sense in specifying remote/local IP address for lwtunnels, > reject such configuration. > > v2: Reject configuration specifying both remote/local address and collect > metadata flag.
Thinking about this more, this *is* uAPI breakage and we can't do that. It affects also gretap and current users of gretap lwtunnels would be broken. This is even more likely as it's not possible to create gretap lwtunnel using iproute2 without specifying a fake remote address. In theory, we could wrap the current ipgre_tunnel_validate with a new function that would be set as ipgre_link_ops->validate but that would add unnecessary complexity and would make ipgre and gretap behavior different. I'm sorry, we have to live with what we have. This should have been taken into account when you implemented lwtunnels for GRE, we can't change this now, it's too late. I'll send v3 with this patch being restored to exactly what I had in v1. Jiri
