iproute2 tunnel name parsing

iproute2 tunnel name parsing

[Wilhelm Wijkander]

Hi,

I'm trying to create a sit tunnel called "hel": ip tun add hel mode
sit remote 10.200.0.2 local 10.200.1.2 ttl 255, however it seems like
this is interpreted as the help argument and I get the usage text. Is
there a way to escape names that I've missed, or is this an error
somewhere in argv parsing?

(I'm not subscribed, so a cc would be appreciated)
Thanks,
Wilhelm

Re: iproute2 tunnel name parsing

[Vadim Kochan]

On Thu, Sep 17, 2015 at 09:55:29PM +0200, Wilhelm Wijkander wrote:
> Hi,
> 
> I'm trying to create a sit tunnel called "hel": ip tun add hel mode
> sit remote 10.200.0.2 local 10.200.1.2 ttl 255, however it seems like
> this is interpreted as the help argument and I get the usage text. Is
> there a way to escape names that I've missed, or is this an error
> somewhere in argv parsing?
> 
> (I'm not subscribed, so a cc would be appreciated)
> Thanks,
> Wilhelm
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Wilhelm,

You can use 'name' before 'hel' like:

    $ ip tun add name hel mode sit remote 10.200.0.2 local 10.200.1.2 ttl 255

and it should work, actually I just tried and it works.

Regards,
Vadim Kochan

Re: iproute2 tunnel name parsing

[Wilhelm Wijkander]

Thanks for the reply Vadim,

2015-09-17 22:10 GMT+02:00 Vadim Kochan <vadim4j@gmail.com>:
> You can use 'name' before 'hel'

Yes, "name" enables me to create the tunnel, things do get trickier
when I'm trying to bring the tunnel device up:

   # ip link set dev hel up
   Usage: ip link add [link DEV] [ name ] NAME
   [snip]
   # ip link set dev name hel up
   Usage: ip link add [link DEV] [ name ] NAME
   [snip]
Adding an address to the tunnel device on the other hand:

   ip addr add 2001:db8:a:a::2/64 dev hel
 is no issue.

Regards,
Wilhelm

[iproute2 PATCH] ip-link: do not support 'ip link add dev help'

[Phil Sutter]

Commit 0532555 ('Support "ip link add help" for rtnl_link API') added a
check for specified help parameter. Though due to the place where it has
been added to, it is not possible anymore to force a given parameter to
be interpreted as interface name by prefixing it with 'dev '. Fix this
by forcing whatever follows 'dev' to be presumed as interface name.

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 ip/iplink.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ip/iplink.c b/ip/iplink.c
index 97f46cd..1c45205 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -647,11 +647,11 @@ int iplink_parse(int argc, char **argv, struct iplink_req *req,
 			addattr8(&req->n, sizeof(*req), IFLA_PROTO_DOWN,
 				 proto_down);
 		} else {
-			if (strcmp(*argv, "dev") == 0)
-				NEXT_ARG();
-
 			if (matches(*argv, "help") == 0)
 				usage();
+
+			if (strcmp(*argv, "dev") == 0)
+				NEXT_ARG();
 			if (*dev)
 				duparg2("dev", *argv);
 			*dev = *argv;
-- 
2.1.2

Re: [iproute2 PATCH] ip-link: do not support 'ip link add dev help'

[Christoph Schulz]

Hello!

Phil Sutter schrieb am Mon, 21 Sep 2015 21:33:01 +0200:

> Commit 0532555 ('Support "ip link add help" for rtnl_link API') added a
> check for specified help parameter. Though due to the place where it has
> been added to, it is not possible anymore to force a given parameter to
> be interpreted as interface name by prefixing it with 'dev '. Fix this
> by forcing whatever follows 'dev' to be presumed as interface name.

I proposed a similar fix which also handles other ip commands, see  
http://patchwork.ozlabs.org/patch/519171/ . Does my patch also work  
for you?


Regards,

Christoph Schulz

Re: [iproute2 PATCH] ip-link: do not support 'ip link add dev help'

[Phil Sutter]

On Mon, Sep 21, 2015 at 10:13:49PM +0200, Christoph Schulz wrote:
> Phil Sutter schrieb am Mon, 21 Sep 2015 21:33:01 +0200:
> 
> > Commit 0532555 ('Support "ip link add help" for rtnl_link API') added a
> > check for specified help parameter. Though due to the place where it has
> > been added to, it is not possible anymore to force a given parameter to
> > be interpreted as interface name by prefixing it with 'dev '. Fix this
> > by forcing whatever follows 'dev' to be presumed as interface name.
> 
> I proposed a similar fix which also handles other ip commands, see  
> http://patchwork.ozlabs.org/patch/519171/ . Does my patch also work  
> for you?

Yes, this works just as well. Although I would personally prefer
reordering the conditionals, but that's probably just a matter of taste.

Cheers, Phil