error handling in --inetd mode can caused a tight loop

[Gert Döring]

there seems to be a race somewhere in the --inetd socket handling - I think it might be "if the client connection for whatever reason fails before accept() is called, we enter a loop". Maybe triggerable by adding a sleep() before the accept, haven't tried.

The loop looks like this:

messages-20190728.gz:Jul 26 21:24:27 gentoo openvpn[20393]: TCP: getpeername() failed: Transport endpoint is not connected (errno=107)
messages-20190728.gz:Jul 26 21:24:27 gentoo openvpn[20393]: TCP: accept(3) failed: Transport endpoint is not connected (errno=107)
messages-20190728.gz:Jul 26 21:24:28 gentoo openvpn[20393]: TCP: getpeername() failed: Transport endpoint is not connected (errno=107)
messages-20190728.gz:Jul 26 21:24:28 gentoo openvpn[20393]: TCP: accept(3) failed: Transport endpoint is not connected (errno=107)
messages-20190728.gz:Jul 26 21:24:29 gentoo openvpn[20393]: TCP: getpeername() failed: Transport endpoint is not connected (errno=107)
messages-20190728.gz:Jul 26 21:24:29 gentoo openvpn[20393]: TCP: accept(3) failed: Transport endpoint is not connected (errno=107)
messages-20190728.gz:Jul 26 21:24:30 gentoo openvpn[20393]: TCP: getpeername() failed: Transport endpoint is not connected (errno=107)
messages-20190728.gz:Jul 26 21:24:30 gentoo openvpn[20393]: TCP: accept(3) failed: Transport endpoint is not connected (errno=107)

I assume this is master and 2.4 - it was observed in master.

[Gert Döring]

It's not trivial to reproduce - if the socket is closed before openvpn starts up (insert a sleep(5) in a wrapper script, kill the client in between) openvpn logs

Sep  8 12:40:20 gentoo openvpn[23963]: TCP connection established with [AF_INET6]2001:608:4::ce:c0f:43882
Sep  8 12:40:20 gentoo openvpn[23963]: TCP_SERVER link local: [inetd]
Sep  8 12:40:20 gentoo openvpn[23963]: TCP_SERVER link remote: [AF_INET6]2001:608:4::ce:c0f:43882
Sep  8 12:40:20 gentoo openvpn[23963]: Connection reset, inetd/xinetd exit [0]

Even if sleep(5)'ing inside phase2_inetd(), this is not triggering.

If it happens, it's most annoying (because openvpn will never recover, the socket_listen_accept() function has no error-exit on accept() failure).

Revisit eventually...

[Gert Döring]

Nah, this goes to WONTFIX.

There is no --inetd mode in master anymore :-)

commit ce652e7d3865dcdebfdc9233d9f46dfbcc2a6e2b (vweb1/master)
Author: Arne Schwabe <arne@…>
Date: Mon Dec 14 18:24:07 2020 +0100

Remove inetd support from OpenVPN