net/iproute2: delete IPv6 tunnel.

[stkchp]

ip6ip6/ipip6 tunnel is not shown command ip tunnel show ${IFACE}. should add option -6,

[robbat2]

This should be 2 changes at least: ip6tnl0, and then the -6 fallback. I don't like the -6 fallback however, can we detect what type it is so we know up front to use -6 or not?

[stkchp]

ip6tnl0

When ip6_tunnel module loaded, kernel create undeletable device ip6tnl0.
This behavior same as relation between sit module and sit0 device. But if unneeded, I'll remove it.

-6 fallback:

Do you mean this code?

local ipproto=''
[ -n "$(ip -4 tunnel show "${IFACE}" 2>/dev/null)" ] && ipproto='-4'
[ -n "$(ip -6 tunnel show "${IFACE}" 2>/dev/null)" ] && ipproto='-6'
if [ -n "$ipproto" ]; then
	ebegin "Destroying tunnel ${IFACE}"
	veinfo ip $ipproto tunnel del "${IFACE}"
	ip $ipproto tunnel del "${IFACE}"
	eend $?
fi
	

I'll fix it if it's correct.

[robbat2]

ip6tnl0: just put it in a separate logical commit

That fallback is pretty good, are there any cases where we'd have to omit -4 and -6 entirely? Maybe drop just if conditional.

Additional idea:
if we set ipproto='-4', we don't need to test for -6?

local ipproto=''
if [ -n "$(ip -4 tunnel show "${IFACE}" 2>/dev/null)" ]; then
  ipproto='-4'
elif  [ -n "$(ip -6 tunnel show "${IFACE}" 2>/dev/null)" ]; then
  ipproto='-6'
fi
ebegin "Destroying tunnel ${IFACE}"
veinfo ip $ipproto tunnel del "${IFACE}"
ip $ipproto tunnel del "${IFACE}"
eend $?
unset ipproto

[stkchp]

I fixed it.

That fallback is pretty good, are there any cases where we'd have to omit -4 and -6 entirely?

No. ip tunnel delete equal ip -4 tunnel delete.
There is a possibility that the tunnel does not exist, and an if [ -n "${ipproto}" ] conditional is added.

[robbat2]

Right now the iproute2 codebase the codebase assumes -4 (rather AF_INET) if unspecified, but past development has shown other variations do happen over time. It's reasonable to think there might be ip -f inet_future tunnel or something similar.

If the tunnel doesn't exist, do we lose anything by letting the user try to delete it anyway? Race conditions where it is deleted already would be similar.

As for this PR, please rebase to remove the revert. It should be just 2 commits: ip6tnl0 and the tunnel deletion.

[stkchp]

OK, I tried to fix it!

If the tunnel doesn't exist, do we lose anything by letting the user try to delete it anyway? Race conditions where it is deleted already would be similar.

We will not lose anything. But if the device to be stopped is not tunnel but gretap or vxlan, it will fail with tunnel deletion? There is a code deleting link just below.

It's better not to add option -4. I create _iproute2_tunnel_delete function like link deletion.

I decided this PR not to include ip6tnl0 is handled as a special device.
ip6tnl0 device will fail with not only stop but also start.
If we do, another PR seems to be good.