Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Won't Fix
-
None
Description
I installed the latest version of this plugin and wanted to test it in our environment. But we use as default display port something in the range 10-99.
Noticing the console output, i saw, that the display got replaced by :59xx.
Thus it wont be able to connect.
The corresponding source code line is:
if (vncServReplaced.split(":")[1].length() == 2)
{
vncServReplaced = vncServReplaced.replace(":", ":59");
}
In my opinion this does not really make sense, the user should define what display port is correct.
Some fallback if it is not given or the ENV couldn't dispatched correctly is valid.
Attachments
Activity
This is now embarrassing to me but i thought that the display port is used to connect to a vncserver. Never thought that there is a TCP port in behind :/
As i looked over it again, and changed the hostname to the correct ENV variable i could connect from console.
So this bug is not valid anymore - i'm so sorry.
Dimitri Tenenbaum
added a comment - No problem at all! 
VNC by default uses TCP port 5900+XX, where XX is the display number.
Here are some examples from tigervnc implementation:
My plugin uses the same approach.
Your usage of privileged 2 digits ports for VNC connections is a very special case.
For simple workaround you can simply put a leading zero into your 2 digits port number in the job configuration. See source code above for more details
For the next version (probably tomorrow) I would take a more clean solution with display/port distinction from: http://tightvnc.com/vncviewer.1.html:
vncviewer [options] [host][:display]
vncviewer [options] [host][::port]