Opened 6 years ago

Closed 6 years ago

#722 closed Bug / Defect (wontfix)

management interface is stuck

Reported by: kotique Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.3.11 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


I'm reporting 2 issues here, split if necessary.

We're building a system that needs to check currently connected clients IP params in client connect hook. This leads to 2 issues:


When trying to work with management interface inside --client-connect script, management is stuck (no welcome text, nothing). I smell a single-threaded process here.


--status file is not updated when client connect script returns non-zero (forcing client to disconnect). Instead, it adds that client to list of active clients and pretends the client is connected, while it surely not. After "Inactivity timeout (--ping-restart)" passes, client is removed from the list. This is not what I'd expect.
As doc states, "If script returns a non-zero error status, it will cause the client to be disconnected."
Disconnected client should be immediately reflected as such in status file.

With all these problems, I'm now not sure how to proceed. We need to know currently connected client list (and their information) when another client connects.


Change History (2)

comment:1 Changed 6 years ago by David Sommerseth

First of all, yes, OpenVPN is designed as single-threaded application. It's a result that it was written in a time SMP enabled servers where not that widely accessible and those which existed were expensive and not necessarily used as entry points from the Internet - where you typically have VPN concentrators. There are no plans to change OpenVPN currently to a multi-threaded application in the 2.x code-base though.

Can you please provide a gdb backtrace of the openvpn process when you experience this? We need full debug symbols to be able to see which code paths being used.

Regarding --status file not getting updated. Are you using UDP? If yes, can you test if the same happens with TCP? It might be we need to look at doing something similar to what --explicit-exit-notify (client side option) on the server side when clients are killed off from server side. Or to say it differently, I believe this issue is related to that UDP is a stateless connection while TCP is statefull, hence the server doesn't notice the client is gone until the timeout happens.

comment:2 Changed 6 years ago by David Sommerseth

Resolution: wontfix
Status: newclosed

Looking back at this. As the use-case is to connect to the management interface from a client-connect script, it will hang if there is already a connected management interface. This is considered to be by design, as the management interface as it is today is not suitable for this kind of usage.

Closing as wontfix, as we don't see we will change the TCP based management interface implementation in the foreseeable future. Rather recommend to have a separate process which keeps the connection to the management interface which the client-connect scripts can connect to. Have a look at the D-Bus proof-of-concept how to get some ideas how this can be done (this POC is not production ready code''' Consider yourself warned!).

Note: See TracTickets for help on using tickets.