From: Steffen Klassert <steffen.klassert@secunet.com>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: Christophe Gouault <christophe.gouault@6wind.com>,
network dev <netdev@vger.kernel.org>,
Cong Wang <xiyou.wangcong@gmail.com>,
Saurabh Mohan <saurabh.mohan@vyatta.com>
Subject: Re: [PATCH] vti: remove GRE_KEY flag for vti tunnel
Date: Thu, 5 Dec 2013 11:51:43 +0100 [thread overview]
Message-ID: <20131205105143.GU31491@secunet.com> (raw)
In-Reply-To: <20131205094708.GQ1258@localhost.localdomain>
On Thu, Dec 05, 2013 at 05:47:08PM +0800, Hangbin Liu wrote:
> On Thu, Dec 05, 2013 at 09:47:27AM +0100, Steffen Klassert wrote:
> >
> > I've already metntioned that I'am a bit disappointed on how the gre
> > keys and flags are used with vti. But I fear we need to keep it
> > as it is for now, because it would at least change the behaviour
> > of iproute2 if we remove the flags.
>
> I submit this patch just beacuse iproute2 will return fail when we modify vti
> parameters. Code here
>
> ip/iptunnel.c#L226:
> if (p->iph.protocol == IPPROTO_IPIP || p->iph.protocol == IPPROTO_IPV6) {
> if ((p->i_flags & GRE_KEY) || (p->o_flags & GRE_KEY)) {
> fprintf(stderr, "Keys are not allowed with ipip and sit tunnels\n");
> return -1;
> }
> }
>
> So should we modify iproute2 or kernel code?
Update iproute2 to allow GRE_KEY if the VTI_ISVTI flag is set.
The handling of vti keys inside the kernel needs to be redesigned too,
but this requires a concept such that the existing userspace API still
works.
next prev parent reply other threads:[~2013-12-05 10:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-04 8:48 [PATCH] vti: remove GRE_KEY flag for vti tunnel Hangbin Liu
2013-12-04 12:46 ` Christophe Gouault
2013-12-05 8:47 ` Steffen Klassert
2013-12-05 9:47 ` Hangbin Liu
2013-12-05 10:51 ` Steffen Klassert [this message]
2013-12-05 16:15 ` Hangbin Liu
2013-12-05 9:47 ` Hangbin Liu
2013-12-05 10:58 ` Steffen Klassert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131205105143.GU31491@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=christophe.gouault@6wind.com \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=saurabh.mohan@vyatta.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.