You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
If two or more clients connect to the management port, only the first one will be served (i.e. only its commands will be listened for and responded to). Once that client closes the connection, the pending commands from the next client will be handled.
To Reproduce
Start openvpn with the management port enabled.
Start a telnet session in terminal A (telnet localhost 7505).
Afterwards, start another telnet session in terminal B.
Send commands in terminal A (e.g. help, status).
Send commands in terminal B.
Quit the telnet session in terminal A.
Expected behavior
The commands in both telnet session should be responded to. Instead, only commands in terminal A get responded to. Once the telnet instance in terminal A is closed, suddenly all commands send in terminal B get instantly answered.
Version information (please complete the following information):
OS: Ubuntu 22.04
OpenVPN version: 2.5.11
Additional context
The scenario of multiple concurrent clients of the management port can happen in several ways. Either one long running client similar to the OpenVPN GUI or a third-party management process block all other clients; or multiple shorter lived clients interfere and by chance connect at similar times. These could be management scripts (kick some client), monitoring (get the whole status), supervisor commands (reload etc).
Some of these clients (mostly monitoring) could instead use the status file though that is not always guaranteed to be up-to-date. (Furthermore looking at the code it looks like it is not atomically written so one may obtain an inconsistent/broken status file.)
The text was updated successfully, but these errors were encountered:
This is the way it is. Management-Interface has never been designed as a general purpose interface, but, well, for controlling the OpenVPN process from a management instance.
The code as written expects "zero or one" management interface, and changing this to handle "more than one" is a nontrivial excercise - someone would have to do it, test it, maintain it. I'm not saying it cannot be done, but it's not a bug but a feature wish, and a large one ;-)
Currently management interface services a single client, so others will stay waiting for the accept() call that happens when the first one quits. Supporting multiple clients in parallel could complicate the code for no compelling reason.
In case of Windows GUI multiple connections will not work anyway as the GUI sets a random password for the management interface which is not exposed outside.
Describe the bug
If two or more clients connect to the management port, only the first one will be served (i.e. only its commands will be listened for and responded to). Once that client closes the connection, the pending commands from the next client will be handled.
To Reproduce
telnet localhost 7505
).help
,status
).Expected behavior
The commands in both telnet session should be responded to. Instead, only commands in terminal A get responded to. Once the telnet instance in terminal A is closed, suddenly all commands send in terminal B get instantly answered.
Version information (please complete the following information):
Additional context
The scenario of multiple concurrent clients of the management port can happen in several ways. Either one long running client similar to the OpenVPN GUI or a third-party management process block all other clients; or multiple shorter lived clients interfere and by chance connect at similar times. These could be management scripts (kick some client), monitoring (get the whole status), supervisor commands (reload etc).
Some of these clients (mostly monitoring) could instead use the status file though that is not always guaranteed to be up-to-date. (Furthermore looking at the code it looks like it is not atomically written so one may obtain an inconsistent/broken status file.)
The text was updated successfully, but these errors were encountered: