Bug#497278: [PATCH] Re: Bug#497278: tunnel name "he" invalid, but nowhere documented

On sön, 2008-08-31 at 15:15 +0100, martin f krafft wrote:

I cannot create a tunnel named "he", but "HE" and "ab" work. If
I try "he", I just get the usage output. This is confusing and
I could not figure it out, other than he being parsed as help.

  ip tun add he mode sit remote 1.2.3.4 ttl 64

I wouldn't expect "help" at this point. I think the parser shouldn't
either.

From the ip manpage:

"The help command is  available  for all objects.  It prints out a list
of available commands and argument syntax conventions."
... so it doesn't look like a documentation problem to me.

To make it more obvious maybe we could add a "helpusage" wrapper that
prints out which argument was interpreted as a call for help.

... if (matches(*argv, "help"))
	helpusage(*argv);
...

void helpusage(char *arg) {
	fprintf(stderr, "Argument '%s' interpreted as a call for help.\n\n", arg);
	usage();
}

Would be lots of places to update to call the new helper function, so
I'm holding off on creating a patch for that until I get some feedback
if people think it would be a good idea.


Anyway, here's a patch that makes it possible to add and, probably more
importantly as it could have been added by other tool (ifconfig), delete
tunnels matching help if you explicitly state the name argument. (ip tun
del name he)

Signed-off-by: Andreas Henriksson <redacted>

diff --git a/ip/iptunnel.c b/ip/iptunnel.c
index 769e845..0d9a17f 100644
--- a/ip/iptunnel.c
+++ b/ip/iptunnel.c

@@ -196,8 +196,7 @@ static int parse_args(int argc, char **argv, int cmd, struct ip_tunnel_parm *p)
 		} else {
 			if (strcmp(*argv, "name") == 0) {
 				NEXT_ARG();
-			}
-			if (matches(*argv, "help") == 0)
+			} else if (matches(*argv, "help") == 0)
 				usage();
 			if (p->name[0])
 				duparg2("name", *argv);