ratnix
Spinning up a 2.4.5 proto-udp server on a CentOS 7 box, I added 'explicit-exit-notify 1' to the server conf to give that a try. I only have the one instance of openvpn, with clients connecting to it. (client-server, not site-to-site).
If I then restart the openvpn instance, the clients get the command-channel RESTART, but they immediately reconnect. Then the server process dies (as expected), which makes the clients lose connection just like they would've been normally. This puts the clients (usually Viscosity because we have a lot of Mac people) into about a 1min client-induced hold before they come back in, because they offered a connection negotiation to a server process that just went away.
My C is rusty, but looking over the source, in src/openvpn/multi.c , multi_push_restart_schedule_exit has a 'reschedule signal' section that I think pushes the server-side process termination out 2 seconds (to give the RESTARTs time to get to the clients?). Meaning the server waits around for 2s while just-disconnected clients rush back in.
This feels like a server bug, or at least a protocol design failure. I can take the blame for only having the one server and not having 'explicit-exit-notify 2' as an option. But if seems like there should be some way to "stun" the clients. have them introduce a small delay before connecting right back (maybe 5 seconds default, and a cap of 30s on an option you push? I could see wanting to limit it for inadvertent DoS'ing of your users). Otherwise, as a server option, 'explicit-exit-notify 1' is just going to end in tears when there's delay <= 2s and you're reconfig'ing a server.
Any ideas here? IS this bug-worthy? OR, I have missed something amazingly simple and you can have great fun pointing out how I've spent a day reading man pages / source code and missed something obvious. :)
