Presently, --explicit-exit-notify is fatally disallowed as an option if you have TCP mode (init.c and options.c). I can imagine the thinking here was something like, 'TCP closes connections explicitly, so why bother?'
I wish, and have a case for, allowing explicit-exit-notify to be at least an allowed option, if not something actually sent upon connection closure.
Under --remote or <connection>, you can have your clients specify a proto. My fleet gets a config:
remote hostname 1194 udp
remote hostname 1194 tcp-client
remote hostname 443 tcp-client
remote hostname 80 tcp-client
(this is to get people connected when they run into silly firewalls, which is reasonably common). Because of having TCP in there, explicit-exit-notify is invalid, even if it would be valid for UDP.
I think explicit-exit-notify should be allowed for all clients, and filtered out at the sending-the-notify point, rather than at the option-parsing point. I mean, certainly it's worth a caution in the logs along the lines of "in TCP mode this will do nothing", but I don't believe that it should be immediately fatal.
