id summary reporter owner description type status priority milestone component version severity resolution keywords cc 1207 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." Bug / Defect closed major release 2.6 Networking OpenVPN git master branch (Community Ed) Not set (select this one, unless your'e a OpenVPN developer) wontfix