Opened 7 months ago

#1207 new Bug / Defect

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

Reported by: Gert Döring Owned by:
Priority: major Milestone: release 2.5
Component: Networking Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

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.

Change History (0)

Note: See TracTickets for help on using tickets.