On Sat, 23 Apr 2016 03:41:43 +0200, Thomas Graf wrote:
> On 04/22/16 at 11:20pm, Jiri Benc wrote:
> > On Fri, 22 Apr 2016 14:04:48 -0700, pravin shelar wrote:
> > > I think we should we return error in case of such configuration rather
> > > than silently ignoring it.
> >
> > I thought about it an
On 04/22/16 at 11:20pm, Jiri Benc wrote:
> On Fri, 22 Apr 2016 14:04:48 -0700, pravin shelar wrote:
> > I think we should we return error in case of such configuration rather
> > than silently ignoring it.
>
> I thought about it and I'm not sure. We're not returning an error
> currently, starting
On Fri, 22 Apr 2016 14:04:48 -0700, pravin shelar wrote:
> I think we should we return error in case of such configuration rather
> than silently ignoring it.
I thought about it and I'm not sure. We're not returning an error
currently, starting returning it now might be perceived as uAPI
breakage.
On Fri, Apr 22, 2016 at 10:44 AM, 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.
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
m
