> This doesn't work on Linux as the scripts run after the plugins have > been initialized so `ip xfrm` would flush the bypass policies set on the > UDP sockets used by the daemon.
I have to correct myself here. While socket-specific policies are listed in `ip xfrm policy` they are not actually removed when flushing all policies via XFRM. So as long as charon.plugins.kernel-netlink.port_bypass is disabled (the default) this works fine on Linux too (except for the same race with starter). >>> Wouldn't it be safer to commit this by the way? >> >> No, then we couldn't e.g. run swanctl commands to load connections, as >> the vici plugin wouldn't be able process the requests. >> > Then for the startup scripts I guess there is the same race using swanctl or > starter? > How can one be sure the scripts are completed before loading the connections? By loading the connections with a start script (e.g. `swanctl --load-all --noprompt`) that runs after the two others (scripts are executed in the order defined in the start-scripts section). Or when using charon-systemd (not on FreeBSD obviously as it does not use systemd) load the connections via ExecStartPost (as the strongswan-swanctl service unit does). This command runs after the daemon signals its readiness to systemd, which happens after the scripts ran. Actually, using ExecStartPost is not even necessary as starting the daemon with systemd will block until it is ready (and start scripts were executed) so any swanctl command that's executed directly after e.g. `systemctl start` will run after the start scripts. > By the way, why does starter manage to send the connections with my patch? > I thought the socket was created but no thread was actually accepting on it. > Isn't it the same with the vici plugin? Yes, exactly the same. With the patch the scripts will run and starter will concurrently write connection data to the socket. But here it doesn't matter if nobody is reading from the socket yet as the scripts won't block. After running them the threads are started and the data is read from the socket. However, the start-scripts facility was mainly added to run swanctl commands on systems where starter is not used (Windows, systemd). And swanctl commands are synchronous, i.e. they block until they get a reply. So the patch would create a deadlock if swanctl commands are run as start scripts: swanctl would wait for a response, the daemon's main thread would wait for swanctl to terminate and therefore couldn't continue to start the other threads that would allow the vici plugin to respond to the swanctl request. Regards, Tobias _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
