all: implement peer config change detection

[systemcrash]

all: implement peer config change detection

netifd detects when an interface config changes by
declaring various parameters the interface has. But if
an interface has separate config sections for peer configs,
netifd is blind to those changes. This requires a manual
call to renew, whereby proto_x_renew() accounts for
peer changes.

This change allows netifd to see when peer entries change.
The proto script shall define:

peer_detect=1

For example, defining this for WireGuard:

proto_wireguard_init_config() {
	...
	peer_detect=1

	...
}

is enough for netifd to detect when any wireguard_wgX peer
entries change, avoid disruptive network restarts, and simply
renew.

netifd now hashes interface peer entries prefixed
<proto>_<interface>, and if its config entries change, netifd
issues a renew or restart. Example: for WireGuard interface
foo, WireGuard entries config wireguard_foo are hashed.
For Yggdrasil interface test, Yggdrasil entries
config yggdrasil_test_peer are hashed. Each interface
requires an additional 8 bytes for the 64 bit hash.

The hash is not chosen for security or integrity,
but to detect change. It's low complexity, quick and requires
no extra .h or lib.

https://datatracker.ietf.org/doc/draft-eastlake-fnv/

We add also the peer_detect property to get_proto_handlers:

"wireguard": {
	"validate": {
		"private_key": "string",
		"listen_port": "uinteger",
		"mtu": "uinteger",
		"fwmark": "string",
		"addresses": "string"
	},
	"immediate": false,
	"no_device": false,
	"init_available": true,
	"renew_available": true,
	"peer_detect": true,
	"force_link_default": false,
	"last_error": false,
	"teardown_on_l3_link_down": false,
	"no_task": true
},...

ping @nbd168 who is familiar with netifd for an opinion.

Perhaps also @jow- and @hauke

[systemcrash]

@efahl - don't know whether you run WireGuard anywhere, but could I trouble you for a SoB line with this if you do? Or even if you don't that you've run it in place and nothing blew up :D

[efahl]

Oh, sorry, I missed this last week. No, I don't have WG on anything, but from a superficial scan of the code it looks reasonable...

[nbd168]

I'm planning on adding netifd ucode proto handlers soon, which will have more flexibility in parsing the configuration. I expect that this will make the extra C code you're adding obsolete.

[systemcrash]

Oh that would be amazing. I was looking at the same thing wondering how I can make the openvpn proto conversion that I made also work in ucode. ( netifd only globs for *.sh ).

I hope you're right - even with the scripts of today, netifd is blind to peer entries.

[nbd168]

I'm planning on giving ucode proto handlers potential access to the full uci config (or even files if needed), while still leaving in enough of a framework that they don't have to worry about things like config change detection.

[nbd168]

Please test the netifd update and wireguard-tools change from https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=summary

[systemcrash]

Built a fresh rc4 VM, apk add, network restart. Crash loop. Tried removing old files, netifd_loglevel 7 no help. ONLY when I added

procd_set_param stderr 1 to /etc/init.d/network did I start to see something. We should fix that.

When I added the updated libblobmsg that it was complaining about to /dev/null, did it start to work ;)

You can add my SoB if you want. Excellent work. Smash it in and pick it to 25.12.

Edit: didn't think to try the ubus debug stuff, but it's kinda tough without network :)

Edit 2:

I think we should still use

	$(INSTALL_BIN) ./files/wireguard.uc $(1)/lib/netifd/proto/

since we want to ensure +x permissions on the 'bin' - then it can be called directly....

[nbd168]

Thanks for testing. By the way the +x is completely unnecessary, because the script cannot be run directly - it can only be loaded by netifd. I will remove the #!/usr/bin/env ucode instead to make that clear.

[systemcrash]

Well, at least for testing, it has utility. Calling the script directly, or ucode script.uc to validate it has no problems is useful.

The examples/proto.uc could do with getting some more "meat".

[nbd168]

It cannot be run directly, since it depends on API provided by netifd (and the handler stub). netifd should emit log messages when the script doesn't compile, so it's not like there is no way of checking it.

[systemcrash]

It cannot be run directly, since it depends on API provided by netifd (and the handler stub). netifd should emit log messages when the script doesn't compile, so it's not like there is no way of checking it.

Yes, you're correct there. I'm wondering about process management. Do we need to check return values of proto.run_command(cmd);?

Would be happy if you could check my usage in openwrt/packages#28533