QEMU no longer allows to use full TCP port range for VNC

Bug #1388735 reported by Sergey
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Expired
Undecided
Unassigned

Bug Description

After upgrade to QEMU version 2.1.0 (Debian 2.1+dfsg-4ubuntu6), I am no longer able to use any TCP port for VNC display.
For example, if I need to assign VNC server a TCP port 443, I used to run:
# qemu-system-x86_64 -vnc :-5457
qemu-system-x86_64: Failed to start VNC server on `:-1000': can't convert to a number:-5457
expected behavior: as any VNC software, take port base of 5900, substract 5457 display number, and use TCP port 443

I ask to change vnc port conversion routine to allow input values in range of all TCP ports, from 1 to 65535.

I really depend on ability to use full TCP range for VNC port numbers, and inablity to do so in new version of QEMU is very disappointing.

Revision history for this message
Michael Tokarev (mjt+launchpad-tls) wrote :

I disagree. This is a vnc port number, and by definition it can't really be negative. The fact that some vnc software allows negative port like this, or that some software uses tcp port number in place of vnc port number, does not make it more valid.

We're talking about an issue in original vnc specification, -- maybe they should have used tcp port in the first place.

And yes, this way we can't specify tcp port less than 5900.

In order to solve this issue for real, I think the best way is to allow specifying tcp port somehow. How does other vnc software deal with this? One example I can think of is to use double-semicolon syntax, like this: -vnc ::443. But we should just agree on some common way, already used by other vnc software.

What is in use today?

Thanks,

/mjt

Revision history for this message
Sergey (megaexception) wrote :

Unfortunately, standard (eirther RFB Protocl V 3.X or RFC 6143) doesn't define bahavior with ports different from 5900:
   Note that the only port number assigned by IANA for RFB is port 5900,
   so RFB clients and servers should avoid using other port numbers
   unless they are communicating with servers or clients known to use
   the non-standard ports.

So it is absolutely dependant on implementation, how to handle non-standard port numbers.
Both implementations from RealNetworks (authors of original VNC) and all other implementations (Tight, and numberous java applets) are allowing negative display numbers with one of two options:
* negative port number accepted, like :-5457 (like QEMU allowed to do before),
* ::<port number> allowed for direct port number instead of display number, like ::443.

It will be best for me, to allow behavior of QEMU before 2.1 (with negative display numbers).
But notation of ::<tcp portnumber> would also solve my problem.

Use for this is very simple - in hosting environment, I am not able to adjust firewall to allow inbound connections for not privileged ports.

Revision history for this message
Thomas Huth (th-huth) wrote :

The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.

Changed in qemu:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for QEMU because there has been no activity for 60 days.]

Changed in qemu:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.