|
Bugzilla – Full Text Bug Listing |
| Summary: | X server fails to connect to xdm/kdm when IPv6 is enabled | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.3 | Reporter: | Zsolt Sági <novell.admin> |
| Component: | X.Org | Assignee: | Reinhard Max <max> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | bartoschek, forgotten_7bFuVpfALd, forgotten_xs3PtXj4XH, ian.cheong, max, mt, sndirsch, sysop |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | openSUSE 11.3 | ||
| Whiteboard: | maint:released:11.3:35046 maint:released:11.1:36029 | ||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
vncviewer hostname:1
vncviewer port confusion works on a port it thinks it isn't using xsession errors Fix for xdm Fix for kdm |
||
|
Description
Zsolt Sági
2009-10-13 19:54:11 UTC
> when I connect by vncclient to localhost's 5901th port, I get a black screen
> with a default X shaped X.org cursor.
So Xvnc works fine. Reassigning.
OK, I've opened a different report for the second issue ( https://bugzilla.novell.com/show_bug.cgi?id=547309 ). Consider this one to regard only xvnc unable to connect to kdm (I installed openSUSE with KDE). Still applies to RC1, even when network is not managed by NetworkManager and IPv6 is disabled. Created attachment 323399 [details]
vncviewer hostname:1
This is not directly related to vnc. It appears to be a problem with the IPv6 implementations of the Xorg server and the display managers kdm and xdm (probably gdm as well). As a workaround, adding a line that says "LISTEN 0.0.0.0" to /etc/X11/xdm/Xaccess will force xdm and kdm to listen for IPv4 connections only. Reinhard, should we add this line for 11.2-RC2? Could you make a SR for X11:XOrg/xorg-x11.(Xaccess is in xdm.tar.bz2). Created attachment 324018 [details]
vncviewer port confusion works on a port it thinks it isn't using
Created attachment 324019 [details]
xsession errors
I am completely confused by the remote desktop/administration function. I have seen all the problems mentioned at variosu time. Happy to provide more information but don't know what you need. Problems existed on 11.1 as well, but have changed now that 11.2 has different mechansim for setting up graphics devices (I thought not using xorg.conf) My machine has two graphics devices, onboard and nvidia card, with different resolution. As far as I can figure there are several issues: 1. YaST/Gnome in 11.2RC1 has no "Graphics and monitor" control panel, so no way to set up dual display mode using gui. I thought it should be set up to use mirroring. 2. Remote Management is a bit unclear about which service/port it is using. See attached screenshot. Remote is functioning on port 5801 with no password. Remote desktop preferences thinks it is using port 5802, but this doesn't work. Somehow my remote session is using a separate session rather than desktop sharing and applications which are open on the primary desktop are unaccessible to the remote session. 3. I'm presently presuming I have logged in using user switching and the system has let me in with more than one session on different desktops without access to the original desktop. I have done nothing special to the 11.2rc1 install to try make remote management work. (YaST2> Only running "sax2 -r -m0=nvidia" from command line because when the system crashes, X seems to lose configuration and I get wallpaper and a mouse pointer and no GUI. Running sax2 then rebooting fixes it. Let me know what other information you need to debug. (In reply to comment #9) > 1. YaST/Gnome in 11.2RC1 has no "Graphics and monitor" control panel, so > no way to set up dual display mode using gui. I thought it should be > set up to use mirroring. Please open a new bug report for this. For the rest of your comments: It looks like you are confusing two different mechanisms that only have in common that both are using the vnc protocol: * The first is called remote administration and can be enabled in YaST. When you connect to it, you get a login screen from xdm, kdm or gdm, which leads to a new session that is unrelated to any sessions that might exist on the local display. That's what this bug report is about. * The other one is that with KDE and Gnome you can export the currently running session through vnc. That's what the screenshot from your first attachment is about. Please open a new bug report if you find issues in this area. I think your port confusion comes from the fact that you enabled both mechanisms at the same time, so remote admin is listening on port 5801 and your local desktop is exported through 5802. (In reply to comment #10) > (In reply to comment #9) > > > 1. YaST/Gnome in 11.2RC1 has no "Graphics and monitor" control panel, so > > no way to set up dual display mode using gui. I thought it should be > > set up to use mirroring. > > Please open a new bug report for this. Please do not. We won't reintroduce that. Instead use the standard tools for KDE/GNOME to configure "dual display". In any case this is a different topic than the initial one. No wonder I'm confused. Where is the documentation that describes how Remote Administration is different from Remote Desktop over vnc. The only instructions can find are in http://en.opensuse.org/YaST_Remote_Administration (Yes I know it says 10.3 but I can't find one newer.) The the link at the bottom to "Remote Desktop" refers to RDP and not vnc. According to the manual page: 5900 is display 0 5901 is display 1 at 1024x768 5902 is display 1 at 1280x760 5903 is display 1 at 1600x1200 5801 is display 1 via java/http 5802 is not described Sax2 I understand is no longer used in 11.2RC1, so there is no GUI to configure display 1. (I said originally the standard tools for "dual display" are missing in 11.2RC1.) What of all the Xsession errors???? If what I describe is a different topic from "VNC remote administration does not work", I suggest bug topics be refined to describe exactly what the experts think they are. Since there are two problems in bugzilla: 1. Reporters being chastised for opening new bugs that are apparent duplicates. 2. Reporters being chastised for not opening new bugs. Chastising bug reporters makes them go away, but the bugs don't always. Otherwise, an automated bug reporting tool would enable you to collect the information you want and analyse it automaticaly without requiring user input. As far as I can tell, 11.2RC1 behaves like this: http:...:5800 no connection http http:...:5801 is "remote administration" via http/java without vnc authentication http:...:5802 no connection http vnc:...:5900 is "remote desktop" with vnc authentication to display 0 (but I only get a black screen and no cursor) vnc:...:5901 is "remote administration" without vnc authentication to a new xsession vnc:...:5902 is "remote desktop" with vnc authentication to display 1; does not work unless display 1 is already open vnc:...:5903 is not active So I figure my system is probably working as intended but the instructions/help are still wrong/very unclear. I manually opened the relevant firewall ports. (In reply to comment #12) > What of all the Xsession errors???? That's just the debugging output of the various programs you've been running during the X session (including startup). At first glance, I've not seen anything unusual in there. > If what I describe is a different topic from "VNC remote administration does > not work", I suggest bug topics be refined to describe exactly what the experts > think they are. Well, the scope of a bug report is not only defined by the summary line, but also (at least) by the initial comment that describes the problem in more detail. I've now refined the summary line, and kindly ask you to limit further commands to that topic. This is not to chastise you, but to simplify your and our work. The other topics you've raised have to be handled by different people and that's easiest done by having them in separate bug reports. (In reply to comment #6) > Reinhard, should we add this line for 11.2-RC2? done. Likely fixed in RC3/final. Already in obs://X11:XOrg/xorg-x11. I upgraded RC2 to final but still does not work. Should I reinstall it from scratch or wait for updates? It looks like the workaround I described in comment #5 didn't make it into final, but you can apply it manually. Please report back whether it works for you. Indeed this workaround didn't make it into 11.2 final. :-( (In reply to comment #17) > It looks like the workaround I described in comment #5 didn't make it into > final, but you can apply it manually. > > Please report back whether it works for you. Yes, it works regardless of whether IPv6 is enabled or not. However, https://bugzilla.novell.com/show_bug.cgi?id=400520 is still an issue :(((((((( *** Bug 558531 has been marked as a duplicate of this bug. *** The bug should be renamed. One gets the impression that this has something to do with vnc. However this bug is only related to xdm and ipv6. Additionally I would not consider this bug fixed as long as there is only a workaround active. The real problem is in the xdm implementation. Is upstream notified? (In reply to comment #21) > The bug should be renamed. One gets the impression that this has something to > do with vnc. However this bug is only related to xdm and ipv6. Indeed. Done. > Is upstream notified? As far as I understood Stefan, there doesn't exist much of an upstream for xdm, so we'll have to look into it ourselves. (In reply to comment #22) > > Is upstream notified? > > As far as I understood Stefan, there doesn't exist much of an upstream for xdm, > so we'll have to look into it ourselves. Well. You could try https://bugs.freedesktop.org/enter_bug.cgi?product=xorg --> Component: App/xdm Good luck! The problem is that xdm/kdm expect ipv6 addresses on a dual stacked hosts. I've made patches for xdm and kdm that resolve this. There is no need for a LISTEN 0.0.0.0. Created attachment 330012 [details]
Fix for xdm
Created attachment 330013 [details]
Fix for kdm
Thanks for the patches, Christoph. Stefan, please add it to the xdm package, so that we can test it. Thanks. Patch is now applied to obs://X11:XOrg/xorg-x11. Packages are currently building. Reinhard, could you give it a try? Packages are available for testing: http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.2/i586/xorg-x11-7.4-62.1.i586.rpm http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.2/x86_64/xorg-x11-7.4-62.1.x86_64.rpm I've checked the 64bit package. It works fine. What about kdm packages? Thanks. kdm needs to be built by our KDE package maintainers. BTW, we also need to look into gdm ... Reinhard? ping. :-) According to Reinhard this patch didn't help at all, but he's currently digging into this. Thus I reassign this one to him for now. I'm not sure if this counts as a duplicate (though the symptom is the same), but I just created this report: https://bugzilla.novell.com/show_bug.cgi?id=591664 It is happening even though IPv6 is disabled. Has anyone tested this against openSuSE 11.3 Milestone 5? My related problem is fixed in that build: https://bugzilla.novell.com/show_bug.cgi?id=591664 Sadly, the problem is back in 11.3 Milestone 6. Any further comments? *** Bug 607874 has been marked as a duplicate of this bug. *** Yup, I can confirm this problem made it into openSuSE 11.3 final. If I try to connect using IPv4 and IPv6 is enabled, I get a black screen. As soon as I disable IPv6, reboot and connect, I get the normal login screen. Any fixes out there for this? I am wondering if it is any way related to the following bug: https://bugzilla.novell.com/show_bug.cgi?id=591664 Commenting out the IPv6 entries in the hosts file served as a "workaround" if you were on IPv4. This obviously isn't possible if you want IPv6 enabled, but the problem may still be connected. Fixed the platform information. Possibly fixed with addressing Bug #625593. AFAICS this issue has been addressed. *** This bug has been marked as a duplicate of bug 625593 *** Thanks Stefan. Is this fix to be backported to 11.2? (In reply to comment #42) > Thanks Stefan. Is this fix to be backported to 11.2? Yes. Update released for: xorg-x11-Xvnc, xorg-x11-Xvnc-debuginfo, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-extra-debuginfo, xorg-x11-server-sdk Products: openSUSE 11.3 (debug, i586, x86_64) Update released for: xorg-x11-Xvnc, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk Products: openSUSE 11.1 (debug, i586, ppc, x86_64) I have kdm 4.3.5-0.3.1 installed on opensuse 11.2 and I still see the problem. Login with ipv6 enabled does not work. XDM however works. I've looked into the kdm source rpm package and I do not see that my patch is applied. Please apply it to fix the issue. AFAIK this issue has only been fixed for xdm. Feel free to open a *seperate* bugreport for kdm/gdm. *** This bug has been marked as a duplicate of bug 625593 *** Christoph, to our knowledge the problem occured because the X server submitted its IPv6 link local address to xdm as the first item in the potential display address, which is useless for this purpose and so the connection failed. We fixed this on the X server side, so that's why you don't see your patch in xdm or kdm. If it still fails for you when the fixed xorg-x11-Xvnc package is installed on your machine, please provide more details how we can reproduce it and/or attach a netork dump of the failing xdmcp conversation. Make sure that "rpm --changelog -q xorg-x11-Xvnc" contains the following entry: * Thu Aug 19 15:30:39 CEST 2010 - max@suse.de - Replaced the previous xdmcp fix with a simpler approach that doesn't cause login problems in xdm and kdm. (bnc#625593) Otherwise the xdmcp fix is not active on your system. Here are the last two entries I get from "rpm --changelog -q xorg-x11-Xvnc": * Fr Sep 17 2010 bitshuffler@opensuse.org - xorg-x11-server-1.6.5-backport_bnc546062.patch * fixes a regression in XResetScreenSaver(), which resulted in applications like screensaver kicking in while watching a movie (bnc #546062) * Do Aug 19 2010 max@novell.com - Prevent the xdmcp code from sending IPv6 link local addresses to xdm as potential display numbers, because they are unusable for xdm and e.g. break vnc based remote adminstration. (bnc#546632). Therefore I do not have your last fix. However "zypper up -t package" does not want to install anything. I do not see what the whole isssue has to do with Xvnc. My problem is that thin clients do not get a login screen from kdm now. Last year when 10.2 was released xdm and kdm did not work. The reason was that both got the XDMCP requests via IPv6 and could not handle mapped IPv4 addresses. (kdm had the additional problem that it did not answer correctly to IPv6 packets). My patches fixed that. The xdm patch was applied by opensuse and now xdm works for me. I've patched kdm locally and it worked till I upgraded to the newest packages last week which still did not work. That's why I was now reporting the issue again. In the meantime both upstream projects, xdm and kdm, merged my patches. Therefore I expect no problems with kdm in opensuse 11.3. If Xvnc cannot handle IPv6 then this is a bug in Xvnc that should be fixed. There is no reason why xdm or kdm should not get the IPv6 address. Hmm. Apparently the fix has never been checked in into openSUSE 11.2. I checked openSUSE:11.2 openSUSE:11.2:Update openSUSE:11.2:Update:Test There's also no submit (SR) for 11.2 pending. I'm afraid we only fixed it for openSUSE 11.3. :-( I've used the packages mentioned in this bugreport above for 11.2 and they worked fine. (In reply to comment #50) > I do not see what the whole isssue has to do with Xvnc. Well, this bug report here was about remote administration based on Xvnc. Only during debugging it turned out that the the problem was caused by the xdmcp client code in X.org. By posting your patches here, you proposed them as a fix to that particular problem. We tested them and found that they didn't fix the problem at hand, so we didn't use them. Also, they looked to me more like a workaround rather than a fix (one shouldn't have to hand-craft IPv4 mapped addresses), but I didn't have a closer look, because they didn't fix our problem and I wasn't aware that you meant them to fix something else. > If Xvnc cannot handle IPv6 then this is a bug in Xvnc that should be fixed. > There is no reason why xdm or kdm should not get the IPv6 address. It is not Xvnc itself, but the xdmcp implementation in the X.org server code that was using IPv6 link local addresses (FE80::/64) as display addresses. But these addresses are only meant to be used during IPv6 auto configuration and are mostly unusable for normal network communication (details available on request). That's why we changed the xdmcp client code to skip these addresses. Other types of IPv6 addresses are not affected by this change, i.e. the X server still uses them as potential display addresses when building the list for the display manager. Ok. I posted my patches only here because my original bug report: Bug #558531 was marked as duplicate of this one. I also thought that the focus shifted away from Xvnc to the IPv6 issue and I suggested the rename of the bug report. After you performed the rename it was clear for me that this bug now left the Xvnc realms. Given this, I think it was wrong to mark my bug report as a duplicate just because a workaround here fixed the symptoms. (In reply to comment #54) > Ok. I posted my patches only here because my original bug report: Bug #558531 > was marked as duplicate of this one. Oh - that indeed was a mistake. Sorry for that. As your bug report describes very similar symptoms and we didn't know the real reason for the Xvnc problem at that point in time, we concluded that the two bug reports are duplicates, which later turned out to be wrong, but we didn't notice. Sorry again. > Given this, I think it was wrong to mark my bug report as a duplicate Indeed. Feel free to reopen bug #558531 and remove the duplicate flag. This is an autogenerated message for OBS integration: This bug (546632) was mentioned in https://build.opensuse.org/request/show/48736 11.2:Test / xorg-x11-server |