Moving to 1.3.x, let's combine this with dropping pre-6.5 compatibility and removal of old migration scripts.

Moving to 1.3.x, since there was no deprecation warning. Let's do it properly.

@UnicronNL also likes constellations, so let's go with it.

Hi @Merijn,
FRR changed quite a few commands here and there, most are easy fixes indeed.

if the interface gets delete from the config, the wg device gets deleted from the OS and all its routes

This is exactly the reason why "set protocols static ..." commands use zebra instead of pushing routes directly to the kernel with iproute2. Zebra takes care of interfaces going up and down and reinstalls the routes when needed.

Now, is that suppose to happen automatically ( i can include it in the wireguard.py script), or is it supposed to be setup via 'set static proto ...'? What would be the better way?

If wireguard cannot create routes on its own, I believe we should leave route setup to the user. Doing it automatically when it's not actually supported is a very leaky abstraction.

Works now, though I need to discuss the pull requests with PPP maintainers.

Should be working now.

I believe I've fixed it, though feedback won't harm.

Closing for now then, let's reopen if needed, or make a separate task for bridging openvpn with new interface types.

@mb300sd The reason we do not allo arbitrary names is that there's no easy way to find out exact interface type, so we forced them to begin with eth, br, tun etc. so that scripts can find out what it is and filter only compatible interfaces.
Relaxing the requirements to "starts with keyword" like eth-lan or tun-office would be an interesting idea, but I'm afraid only in the long run, since a number of scripts have regexes like eth\d+ hardcoded in them and it will take time to clean up.

The renderer works now (for a long time already, even), so it's time to close this task finally. ;)

@UnicronNL @hagbard Please do not use that package! I've inspected it, and it's below any reasonable standards!