Core: [6rd] deconfiguring a 6rd tunnel does not delete the underlying _stf interface

[paride]

Steps to reproduce:

• Configure a 6rd tunnel for an interface
• Deconfigure it (from the webui set ipv6: none)
• Run ifconfig from the shell. The _stf interface will still be there, down but configured.

This means that it is not possible to configure a 6rd tunnel on another interface with the same parameters as we encounter the error: ifconfig: ioctl (SIOCAIFADDR): File exists.

Expected result: the _stf interface is deleted when deconfiguring the tunnel.

[fichtner]

Are you sure? I know that the device is not destroyed, yet it would seem to be reused if reconfigured by the GUI. Is this not the case?

On the 19.1 development version we write proper names now for hardware interfaces, e.g. WAN is em1 so 6rd is em1_stf which minimises unwanted collisions further, but the question is if that matters at all since both wan and em1 are unique identifiers in the first place.

If the reuse does not work, we can try the destroy, but we would try avoid this because destroying interfaces have been known to cause kernel panics due to code paths least tested.

[paride]

I think the reuse does not work because, e.g.:

1. WAN is configured with ipv6 = 6rd tunnel, wan_stf is created and configured with inet6 (say) 2001:b07:xx:yy::
2. WAN is then reconfigured with ipv6 = none, wan_stf is brought down but not destroyed. It is still configured with inet6 2001:b07:xx:yy::
3. LAN is configured with ipv6 = 6rd tunnel, using the same parameters used before. lan_stf is created, but its configuration fails as inet6 2001:b07:xx:yy:: is still assigned to wan_stf.

I hope the issue is clearer now. There is no need to actually destroy the _stf interface when 6rd is deconfigured, it would be enough to remove the inet6 address associated with the interface.

[fichtner]

That makes sense. I’ll look into it. 😊

[fichtner]

We'll destroy it as that is what the reconfigure does anyway. Thanks for spotting this!