Bug 808490

Maybe you try to add in /etc/xinetd.d/vnc

server_args = .... -securitytypes=none and do a "rcxinetd reload" or a reboot afterwards, for me vnc works after that.

Regards

According to my test, this problem is as follows:
* Service "vnc" activation worked fine;
  "netstat -anp | grep xinetd" contains "0.0.0.0:5801" and "0.0.0.0:5901".
* But SuSEFirewall2 config (/etc/sysconfig/SuSEFirewall2) was not updated;
  it should contain "vnc-server" and "vnc-httpd".

I think that the cause of this problem is:
* Service name for VNC is defined at /usr/share/YaST2/include/network/remote/dialogs.ycp:59,
  but the name ("service:xorg-x11-server") is not exist in /etc/sysconfig/SuSEfirewall2.d/services.

So
"services" : [ "service:xorg-x11-server" ],
should be changed to
"services" : [ "service:vnc-server", "service:vnc-httpd" ],

(In reply to comment #1)
> Maybe you try to add in /etc/xinetd.d/vnc
> 
> server_args = .... -securitytypes=none and do a "rcxinetd reload" or a reboot
> afterwards, for me vnc works after that.
> 
> Regards

Thanks for the reminder.  I also had to use yast
 security and users
 firewall
 allowed services

to manually add 'VNC' from the proposed list to Service to Allow

After that, I can get a black vnc screen.  That's not my definition of 'works'.
If that matters I had chosen the 'Minimal X Window' installation

(In reply to comment #3)
 
> After that, I can get a black vnc screen.  That's not my definition of 'works'.
> If that matters I had chosen the 'Minimal X Window' installation

When I comment out the 

::1             localhost ipv6-localhost ipv6-loopback

line in /etc/hosts, I finally get (after some time, though) a login screen,
and vnc works great

I can confirm that VNC module behaves "strange". What I did so far:
1) with stopped firewall
- enabled vnc access
result:
- no xvnc running, it has to be started manually
- after manual xvnc start I was able to connect.

2) with running firewall
- enabled vnc access
- told vnc module to open port in firewall
result:
- no xvnc running
- after manual restart I wasn't able to connect.

There are obviously two bugs:
1) vnc server is not started when vnc module finishes
2) firewall is not opened even when was told so.

I have just performed a fresh installation of 12.3 and performed an Update to latest patch level and I'm having the same issues as described above.

Therefore I tried implementing the workarounds mention above, that being

1. -securitytypes=none
2. commenting out IPv6 from hosts

With these workarounds I'm able to connect to VNC and are presented with the Gnome login screen, BUT during logon using either my own account or root, the VNC session are drop (session disconnected). 

Note: I have not experienced the black screen bug.

Please add this to the issue list

*** Bug 803618 has been marked as a duplicate of this bug. ***

Updated this bug to show that it is still present in 13.1 M2.

So one problem is that our XDM use case does not work without -securitytypes=none. But it is not a new option, I've found it mentioned in 2004 already: http://www.realvnc.com/pipermail/vnc-list/2004-June/045866.html
How long could this have been broken? Did the default security types change?  Or is there another factor that we are overlooking?

Stefan, do you know if security types default value changed recently?

IPv6 problem (black box when connected) seems as regression - bnc#546632

(Guessing) According changelogs (starts in 2011) for xorg-x11-Xvnc it seems that used Xvnc implementation is different against OS 11.3.

Workaround: disable IPv6 e.g. using "Network Settings) YaST module and restart.

Replacing "*" with  "LISTEN 0.0.0.0" in /etc/X11/xdm/Xaccess as suggested in bnc#546632#c5 didn't helped to me.

Tested in OpenSUSE 12.3.

(In reply to comment #9)
> So one problem is that our XDM use case does not work without
> -securitytypes=none. But it is not a new option, I've found it mentioned in
> 2004 already: http://www.realvnc.com/pipermail/vnc-list/2004-June/045866.html
> How long could this have been broken? Did the default security types change? 
> Or is there another factor that we are overlooking?
> 
> Stefan, do you know if security types default value changed recently?

Yeah. We changed from xf4vnc to tigervnc with openSUSE 12.3. At some time (sorry, can't remember which distribution) we already had shipped tigervnc, but switched back to xf4vnc.

Yes, for tigervnc you apparently need "-securitytypes=none" Xvnc option. :-(

Stefan,

do you have any comments regarding Comment#10?

Thanks

(In reply to comment #13)
> do you have any comments regarding Comment#10?

I already stated that we switched to a different VNC implementation with openSUSE 12.3. I'm not an expert at all WRT Ipv6. Sorry.

Well, I've fixed issues in yast2-network (set proper security type, open firewall).

IPv6 issue is still open and only workaround with disabling IPv6 is available now.

Reinhard,

there is problem when connecting vnc session with IPv6 enabled. VNC is connected, however no login screen appears - only black screen and cross mouse cursor.

I've looked into xdm sources and it seems that patch form bnc#546632 is present. Workaround described in https://bugzilla.novell.com/show_bug.cgi?id=546632#c5 doesn't work.

When IPv6 is disabled, connection works fine.

Sorry, what info is needed for this bug report exactly?

This is not YaST issue anymore. It should be xdm or kdm issue now. Reinhard did fix last time ...

I was able to reproduce this with xdm and kdm. (I failed to make gdm work on my test machine with factory.)

After the Xvnc is started, it connects to xdm using XDMCP (*). Xvnc sends a list of IP addresses where xdm should connect using X11 to display the login screen. xdm attempts to connect using the first IP address but that fails with EINVAL in connect() call.

The problem is that the first address is IPv6 link-local scope address. I don't understand IPv6 much, but I found that connect() will always return EINVAL if the address is link-local and no interface is specified. I've got the same result from experiment with netcat.

Interestingly, after a while, another two IPv6 addresses appear on my test machine. Those addresses are global scope and are send in beginning of the list and connecting to them works. (So everything works correctly few minutes after boot.)

I compared XDMCP responses of Xserver and Xvnc and the difference is that Xserver never sends IPv6 link-local scope addresses. It only sends IPv4 and IPv6 global scope. So this looks like it is already solved in Xserver and it just has to be ported to Xvnc.

(*) The first connection XDMCP connection is made to "localhost" name. In default configuration with IPv6 this is resolved to ::1 and because of that Xvnc places IPv6 addresses before IPv4. The workaround described in comment 4 causes "localhost" to be resolved to 127.0.0.1 and so Xvnc places IPv4 first and following connection works.

(In reply to comment #19)
> I compared XDMCP responses of Xserver and Xvnc and the difference is that
> Xserver never sends IPv6 link-local scope addresses. It only sends IPv4 and
> IPv6 global scope. So this looks like it is already solved in Xserver and it
> just has to be ported to Xvnc.

Found the difference; There is a patch that wasn't upstreamed in our xorg-x11-server package: N_xorg-server-xdmcp.patch

Comment in it describes the same issue:

  /* Ignore IPv6 link local addresses (fe80::/10), because
   * they need a scope identifier, which we have no way
   * of telling to the other end.

So this patch should be added to xorg-x11-Xvnc as well and probably should be sent upstream.

Yes, this has been bnc#625593.

This is an autogenerated message for OBS integration:
This bug (808490) was mentioned in
https://build.opensuse.org/request/show/181877 Factory / xorg-x11-Xvnc

*** Bug 808077 has been marked as a duplicate of this bug. ***

Ok. Fixed for obs://X11:XOrg/xorg-x11-Xvnc and openSUSE:Factory/xorg-x11-Xvnc.

(In reply to comment #24)
> Ok. Fixed for obs://X11:XOrg/xorg-x11-Xvnc and openSUSE:Factory/xorg-x11-Xvnc.

Is the fixed rpm available for online update in 12.3 ?

(In reply to comment #25)
> Is the fixed rpm available for online update in 12.3 ?

Not yet.

I am still getting the black screen with ipv6 disabled an updated xorg-x11-Xvnc package from aforementioned repository (although i used package built for 12.3).

Is anyone else hitting this ? 

When using xdm, everything works fine, regardless of version of xorg-x11-Xvnc used (stock 12.3 or one from obs). When using any other display manager, it fails with black screen, or shows login screen, but doesn't load desktop session.

This is on 12.3 i586.

I thought no patch had been released for 12.3?

(In reply to comment #28)
> I thought no patch had been released for 12.3?

the patch is in obs and package has been rebuilt for 12.3 after including that patch (it's listed in the spec). So i thought patched package was finally rebuilt for 12.3. Perhaps i am wrong here.

I will retry with factory package, then.

Just tested X11:XOrg factory subrepository package xorg-x11-Xvnc-7.6_1.0.1-38.23.i586.rpm, and i still get a black screen when using lxdm. Oh well.

This issue is definitely not fixed yet.

Perhaps this issue (and the comment) could be of service: https://bugzilla.novell.com/show_bug.cgi?id=808077#c6

This is an autogenerated message for OBS integration:
This bug (808490) was mentioned in
https://build.opensuse.org/request/show/197260 12.3 / xorg-x11-Xvnc

*** Bug 808077 has been marked as a duplicate of this bug. ***

Update released for openSUSE 12.3. Resolved fixed again.

openSUSE-RU-2013:1428-1: An update that has one recommended fix can now be installed.

Category: recommended (moderate)
Bug References: 808490
CVE References: 
Sources used:
openSUSE 12.3 (src):    xorg-x11-Xvnc-7.6_1.0.1-3.16.3

With the latest updates, the following procedure (mentioned here https://bugzilla.novell.com/show_bug.cgi?id=808077#c6 ) does not lead to a working system, any input?

Some additional information here, the error in xdm.errors is:
xdm error (pid 3755): server open failed for _____ local:1 giving up
xdm error (pid 3366): Diplay ____local:1 cannot be opened

Anything i could test?

Well apparently Xvnc is running, accepted VNC connection, asked xdm to connect back to it and display login screen, but xdm failed to do that.

The display name "____local:1" looks weird..
Do you have some special entries for localhost in /etc/hosts? Do you have ipv6 enabled on the computer? If yes, could you try it without it?

The ____ indicates the hostname, but because of security reasons i didnt include it (sorry, should have mentioned that).

The /etc/hosts file is pristine on this machine. And ipv6 has been disabled (because of the history in this thread), no luck there.
Anything else i can do?

Ok, please check this:
* Is xinetd listening on tcp port 5901?
* Do you get black screen when you connect with vnc client?
* Once you are connected, there will be Xvnc process running. Is it listening on one of tcp ports 6000-6063? (The last two digits doesn't have to match the VNC port, but should match with the display number in xdm.error.)
* While the Xvnc is running, try to connect some X client to it:
  "DISPLAY=____local:1 xeyes"
  It will fail, but either because it can't connect, or because it isn't authorized. Please copy the error message.
* Could you try if it works if you switch display manager to kdm or gdm or something else?

Closing because of no response. Please reopen if you can still reproduce the issue.

Definitely seems to be fixed in 13.1 Final.

(In reply to comment #43)
> Definitely seems to be fixed in 13.1 Final.

This is indeed fixed in 13.1. 

But for the reference to get back on the previous points asked by Michal:

- xinetd is listening on port 5901 (vnc is active and configured correctly)
- the black screen is indeed the result
- the port i havent checked, nor the actual error, because updating to 13.1 did fix this problem.
- a different displaymanager did not matter.

Unfortunately, no it is not fixed completely, some machines work, some dont.

Here is the answer to the questions asked by Michal on a 13.1 installation:

* Is xinetd listening on tcp port 5901?
Yes, netstat:
tcp        0      0 192.168.0.91:5901       192.168.0.79:34966      ESTABLISHED 


* Do you get black screen when you connect with vnc client?
Yes

* Once you are connected, there will be Xvnc process running. Is it listening
on one of tcp ports 6000-6063? (The last two digits doesn't have to match the
VNC port, but should match with the display number in xdm.error.)


* While the Xvnc is running, try to connect some X client to it:
  "DISPLAY=____local:1 xeyes"
  It will fail, but either because it can't connect, or because it isn't
authorized. Please copy the error message.

Error: Can't open display: ____local:1

* Could you try if it works if you switch display manager to kdm or gdm or
something else?

Tried, xdm, kdm and gdm, not working.

Apologies, one answer got missing:

* Once you are connected, there will be Xvnc process running. Is it listening
on one of tcp ports 6000-6063? (The last two digits doesn't have to match the
VNC port, but should match with the display number in xdm.error.)

Yes, it listens on 6001. And from xdm-errors:
xdm info (pid 3669): Starting X server on laptop-ivan.iks.local:1
xdm error (pid 4606): server open failed for SERVERNAME.local:1, giving up
xdm error (pid 3669): Display SERVERNAME.local:1 cannot be opened
xdm error (pid 3669): Display SERVERNAME.local:1 is being disabled
xdm info (pid 3669): Shutting down

One more update, setting the network device settings to a fixed ip (and changing hostname) fixes the connection. How can this be network related???

When vnc client connects to Xvnc, it first talks to xdm over XDMC protocol. This part seems to work. It asks it to connect back to it (with normal X protocol) and display the login screen. It sends a list of addresses on which xdm can try to connect to Xvnc. But when xdm tries to connect, it fails.

So this can be easily affected by network configuration. There was once issue with ipv6 enabled...

Could you record what is happening on network during the connection? Ideally on all interfaces, for example like this:
tcpdump -i any -s 0 -w dump

Hans?

I'm afraid we need to close this one as NORESPONSE. :-(

I stumbled onto the thread from reviewing an openSuse forum issue.

I am running 13.1

I was at the point where I could establish a connection to a vnc server on :1, got login greeter but after login (user and password), the session would immediately close.

Discussion above on use of XDMCP reminded me - XDMCP is Enabled=false on a new install. The only way I know to fix that I learned way back in 11.x: Edit /usr/share/kde4/config/kdm/kdmrc and change XDMCP setup to Enable=true.

After reboot, my vnc connection completed, login completed and good to go.

There should probably be a better/clearer way to administer XDMCP.
There may be, I do it this way for historical reasons (not always the best).

See comment above

(In reply to carl mcgrath from comment #51)
> I was at the point where I could establish a connection to a vnc server on
> :1, got login greeter but after login (user and password), the session would
> immediately close.
>
> Discussion above on use of XDMCP reminded me - XDMCP is Enabled=false on a
> new install. The only way I know to fix that I learned way back in 11.x:
> Edit /usr/share/kde4/config/kdm/kdmrc and change XDMCP setup to Enable=true.
> 
> After reboot, my vnc connection completed, login completed and good to go.

If you got the login greeter, then XDMCP was already on and working. The session closing after login is some unrelated problem, probably some starting process of your desktop environment died. Apparently it happened only the first time and not after reboot.

> There should probably be a better/clearer way to administer XDMCP.
> There may be, I do it this way for historical reasons (not always the best).

The XDMCP is normally enabled by YaST (/etc/sysconfig/displaymanager: DISPLAYMANAGER_REMOTE_ACCESS), unless you change the configuration directly in the kdmrc file.

If you run again into this or other VNC issue, please open new bug. This bug was already reopened several times, each time for different issue... This is not a general "VNC not working" bug.