Opened 2 years ago

Closed 4 months ago

#1207 closed Bug / Defect (wontfix)

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

Reported by: Gert Döring Owned by:
Priority: major Milestone: release 2.6
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 (2)

comment:1 Changed 10 months ago by Gert Döring

Milestone: release 2.5release 2.6

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...

comment:2 Changed 4 months ago by Gert Döring

Resolution: wontfix
Status: newclosed

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

Note: See TracTickets for help on using tickets.