|
Bugzilla – Full Text Bug Listing |
| Summary: | GDM does not respond to XDMCP queries (VNC vncserver remote administration) | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.3 | Reporter: | Forgotten User 6yMpDEBP2y <forgotten_6yMpDEBP2y> |
| Component: | GNOME | Assignee: | E-mail List <gnome-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | dliang, forgotten_CHC7OcAR44, forgotten_DVCmqapd48, forgotten_xs3PtXj4XH, martin.matuska, martinpirata, max, milan.zimmermann, peterbelm, richard.wellhouse, s2, tinchogauna, vuntz, walter.haidinger |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | openSUSE 11.3 | ||
| Whiteboard: | maint:released:11.3:35046 | ||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | tcpdump capture | ||
|
Description
Forgotten User 6yMpDEBP2y
2010-07-18 01:29:39 UTC
This debug messages previously listed are repeated several times until the client or server gives up.
moya.hopnet.lan resolves in /etc/hosts to 172.0.0.2 and in DNS to 192.168.101.31.
(ifconfig didn't show the complete addresses)
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:15:60:b7:2c:4f brd ff:ff:ff:ff:ff:ff
inet 192.168.101.31/24 brd 192.168.101.255 scope global eth0
inet6 fe80::215:60ff:feb7:2c4f/64 scope link
valid_lft forever preferred_lft forever
Keith, The bug has been fixed, but did not make it into final. The fix will be released as an update. You can read about it here: https://bugzilla.novell.com/show_bug.cgi?id=591664#c13 Closing as duplicate. *** This bug has been marked as a duplicate of bug 591664 *** Malvern, Are you referring to updating xorg-x11-Xvnc from http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.3/i586/ as suggested by Reinhard Max in 591664 ? Is there any more to it? I now have xorg-x11-Xvnc-7.5_1.8.0-54.1.i586 on the remote machine, and it did NOT resolve the problem. It mentions the loopback fixes in the changelog. I don't know if it's been updated since I tested, sorry - there might have been a regression for all I know. Let's wait for the fix to hit the update repo and then re-open our respective bugs if necessary. I'm going to re-open this for a couple of reason (and reassign it to Gnome): a) I think this is a GDM specific problem (not an Xorg/VNC issue). b) I can change the DM to xdm, and using vnc, I get a login screen, and can login and see the desktop (although, there seems to be Gnome/DBUS issues past this, but that's another bug) c) I can use Xnest w/gdm, instead of vnc, and the black screen problem is the same. This produces the same "I want to use inet6" messages from gdm, when the request comes from an IPv4 address. running this on my workstation keithh@x4:~> Xnest :1 -geometry 1024x768 -query moya produces this debug output on the remote 11.3 boxen (which repeats) gdm[12245]: DEBUG(+): GdmXdmcpDisplayFactory: decode_packet: GIOCondition 1 gdm[12245]: DEBUG(+): Address family:2 (inet) hostname:(null) host:(null) port:(null) local:1 loopback:1 gdm[12245]: DEBUG(+): Address family:2 (inet) hostname:(null) host:(null) port:(null) local:1 loopback:1 gdm[12245]: DEBUG(+): Address family:2 (inet) hostname:(null) host:(null) port:(null) local:0 loopback:0 gdm[12245]: DEBUG(+): Address family:2 (inet) hostname:(null) host:(null) port:(null) local:1 loopback:0 gdm[12245]: DEBUG(+): GdmAddress: looking up hostname: moya.hopnet.lan gdm[12245]: DEBUG(+): family=2 sock_type=1 protocol=6 flags=0x2 canonname=moya.hopnet.lan gdm[12245]: DEBUG(+): family=2 sock_type=2 protocol=17 flags=0x2 canonname=(null) gdm[12245]: DEBUG(+): family=2 sock_type=3 protocol=0 flags=0x2 canonname=(null) gdm[12245]: DEBUG(+): Address family:10 (inet6) hostname:(null) host:(null) port:(null) local:0 loopback:0 gdm[12245]: DEBUG(+): GdmXdmcpDisplayFactory: Received opcode QUERY from client ::ec51:86b7:2fff:82b7%3075911668 : 34422 gdm[12245]: DEBUG(+): GdmXdmcpDisplayFactory: Sending WILLING to ::ec51:86b7:2fff:82b7%3075911668 Keith, the bug I fixed was in the generic X server code, so it can be reproduced with the unpatched versions of all kinds of X servers that are built from the xorg-x11-server source package (e.g. /usr/bin/Xorg, /usr/bin/Xnest, and /usr/bin/Xvnc). To check that the gdm issue you are seeing is really a separate one, please make sure that you have the patched version of Xnest. For the patched version, it should look like this: --- snip --- $ rpm -qf /usr/bin/Xnest --changelog | head -9 * Do Jul 08 2010 max@suse.de - Fix some shortcomings in the xdmcp implementation. It used to suppress loopback addresses from the list of potential display addresses to report to xdm, even when talking to xdm through a loopback address. Now only display addresses of the same kind as the xdm connection are reported to xdm. This most notably helps Xvnc servers contacting the local xdm, because they were severely affected by the suppression of loopback addresses. --- snap --- Ah - I just see you are connecting to a remote xdm (or gdm), not a local one, so it is outside the scope of my fix. In that case, please check if that problem was actually caused by my fix, i.e. if the Xnest problem disappears when you downgrade the xorg-x11-server-extra package to the stock 11.3 version. BTW, the IPv6 address gdm prints out in the logs you pasted looks a bit strange to me: ::ec51:86b7:2fff:82b7 . What kind of address is this supposed to be? It looks neither like an IPv4 mapped address nor like a link local or global address. Reinhard, The problems and symptoms are the same, with or without your fix. IPv6 addresses look a bit strange to me in general, and I don't know where gdm is getting that one from. Capturing all interfaces with wireshark on the remote machines shows lots of IPv6 traffic to and from ::1 banging the x11 port, but nothing for any other IPv6 address. OK, a few more questions: 1. The host you are querying from Xnest (moya) is not the same machine on which Xnest itself is running (x4), right? 2. The /etc/hosts entry "127.0.0.2 moya.hopnet.lan moya" from comment #1 exists only on moya, not on x4? 3. What's the output of "host moya" when run on x4? 4. Please attach a dump of the xdmcp traffic on moya while you try to start Xnest on x4, so that I can analyze it myself ("tcpdump -i any -w xdmcp.cap -s 1600 udp port xdmcp"). If you don't want to attach it, you can also email it directly to me. Created attachment 377460 [details]
tcpdump capture
Ran for 30 seconds
x4:~ # Xnest :1 -geometry 1024x768 -query moya
and
moya:~ # tcpdump -i any -w xdmcp.cap -s 1600 udp port xdmcp
1. Correct. Different machines (X4 is 11.2, moya is 11.3).
2. Correct.
3. keithh@x4:~> host moya
moya.hopnet.lan has address 192.168.101.31
4. tcpdump -i any -w xdmcp.cap -s 1600 udp port xdmcp
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 1600 bytes
^C
4 packets captured
6 packets received by filter
0 packets dropped by kernel
just 4??? (double checks, no firewall)
moya:~ # tcpdump -vvv -r xdmcp.cap
reading from file xdmcp.cap, link-type LINUX_SLL (Linux cooked)
20:19:27.892739 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 35)
x4.hopnet.lan.57702 > moya.hopnet.lan.xdmcp: [udp sum ok] UDP, length 7
20:19:31.896884 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 35)
x4.hopnet.lan.57702 > moya.hopnet.lan.xdmcp: [udp sum ok] UDP, length 7
20:19:39.904992 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 35)
x4.hopnet.lan.57702 > moya.hopnet.lan.xdmcp: [udp sum ok] UDP, length 7
20:19:55.919018 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 35)
x4.hopnet.lan.57702 > moya.hopnet.lan.xdmcp: [udp sum ok] UDP, length 7
Hmm - these are only query packets, no responses. I wonder if gdm listens for xdmcp queries at all. Please re-try the dump with "udp port xdmcp or icmp" as the filter, so that we also get the "port unreachable" packets if there are any. Additionally you can check directly if the xdmcp port is open on moya: # netstat -anp | grep :177 moya:~ # tcpdump -i any -w xdmcp.cap -s 1600 udp port xdmcp or icmp tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 1600 bytes ^C 5 packets captured 5 packets received by filter 0 packets dropped by kernel I decoded the dump, and it is the same as before, just requests, no icmp replies. (so I won't bother to paste/attach it) The netstat looks wrong to me, as I expect to see an IPv4 address here (even if it is just 127.0.0.1), but I've read (Googling) that this actually listens to v4 & v6. moya:~ # netstat -anp | grep :177 udp 0 0 :::177 :::* 1641/gdm FWIW /etc/gdm/custom.conf looks like this: [daemon] [security] [xdmcp] Enable=true Port=177 DisplaysPerHost=4 [greeter] [chooser] Multicast=false [debug] Enable=true [servers] 0=Standard and /etc/sysconfig/displaymanager has these entries: DISPLAYMANAGER="gdm" DISPLAYMANAGER_REMOTE_ACCESS="yes" DISPLAYMANAGER_ROOT_LOGIN_REMOTE="yes" DISPLAYMANAGER_STARTS_XSERVER="yes" DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes" *** Bug 624135 has been marked as a duplicate of this bug. *** (In reply to comment #5) > b) I can change the DM to xdm, and using vnc, I get a login screen, and can > login and see the desktop (although, there seems to be Gnome/DBUS issues past > this, but that's another bug) I can confirm too. Only switching to kdm allowed me to use vnc Here is something else interesting: https://bugzilla.novell.com/show_bug.cgi?id=546632 I get a black screen if IPv6 is enabled and I connect using an IPv4 address. These must all be related. I have ipv6 disabled and all ipv6 hosts entries in the /etc/hosts file deleted. Still have the same issue. The behavior is the same in OpenSuse 11.3 64 bit [gdm]. We are also encountering this bug and it is a show-stopper for our site-wide update of OpenSUSE to version 11.3. As a temporary workaround reinstalling (rpm -U --force) old gdm and gdm-lang version 2.28 from OpenSUSE 11.2 release makes remote VNC administration work again. That also indicites that the problem might be very well in gdm and not elsewhere. It is a combination of bugs in the X server and display managers that lead to the "no login screen" situation, but at least some versions of gdm seem to contain a dirty workaround that violates the XDMCP specification, but brings back the login screen. A solution for the X server side is already being worked on... *** This bug has been marked as a duplicate of bug 625593 *** 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) Version 7.5_1.8.0-10.3.1 of xorg-x11-Xvnc, xorg-x11-server-extra and xorg-x11-server do not resolve the issues for gdm. (In reply to comment #19) > *** This bug has been marked as a duplicate of bug 625593 *** The fixes for bug 625593 do not resolve this issue. Indeed, this is a bug in gdm and separate from the XDMCP fix I put into the X server code. Sorry for the confusion. I just tried it with a newly installed 11.3 plus all current updates. * The X server (Xvnc or Xnest) correctly sends XDMCP query packets to port 177. * strace shows that gdm receives these packets seemingly comming from a bogus IPv6 address (::ecb1:6ab7:2f5f:67b7) in my case. * It then shows some activity including attempts to open /etc/gdm/Xwilling which doesn't exist. * It then tries to respond to the bogus address and of course gets back error that the address it is unreachable. As the other display managers can receive these packets, I think it is a problem in gdm's XDMCP handling. The fact that I see the same bogus address regardless whether the X server runs on the same or on a different machine seems to indicate some memory corruption in the address handling of the receive routine. Sorry for commenting the other thread. I found a similar workaround. Please see comment 24 for steps and details. Kind regards. https://bugzilla.novell.com/show_bug.cgi?id=625593#c24 A working workaround for this problem is to use GDM without ipv6 support. I have rebuilt gdm from the official 11.3 sources without ipv6 support: http://www.vx.sk/download/packages/opensuse/11.3/ Is there any further news on this bug? We released an update of gdm with XDMCP fixes sometime ago. Did you test with this update? Right, just tested: works for me with the update running opensuse 11.2/x86_64. (In reply to comment #27) > We released an update of gdm with XDMCP fixes sometime ago. Did you test with > this update? "sometime ago"? Sorry mate, but that's too vague to answer. In the future, provide the versions you are talking about. Also, see comment #22 above. (In reply to comment #29) > (In reply to comment #27) > > We released an update of gdm with XDMCP fixes sometime ago. Did you test with > > this update? > > "sometime ago"? Sorry mate, but that's too vague to answer. In the future, > provide the versions you are talking about. Also, see comment #22 above. I don't see how comment #22 is relevant to my question, but I might miss something. You can simply check if you have this version by looking at "rpm -q --changelog gdm" and seeing if the last entry is from September, with this mention "Add gdm-xdmcp-fixes.patch to fix connection with XDMCP. Fix bnc#637069". I believe this is gdm-2.30.2-6.1.1, but I'm not 100% sure and I can't check right now. (In reply to comment #30) > I don't see how comment #22 is relevant to my question, but I might miss > something.> My bad, it's comment #21 :) > You can simply check if you have this version by looking at "rpm -q --changelog > gdm" and seeing if the last entry is from September, with this mention "Add > gdm-xdmcp-fixes.patch to fix connection with XDMCP. Fix bnc#637069". I believe > this is gdm-2.30.2-6.1.1, but I'm not 100% sure and I can't check right now. Yes, it's gdm-2.30.2-6.1.1 * Mon Sep 13 2010 vuntz@opensuse.org - Add gdm-fix-dbus-properties.patch: org.gnome.DBus.Properties was referenced instead of org.freedesktop.DBus.Properties in the dbus configuration. Fix bnc#633655. - Add gdm-xdmcp-fixes.patch to fix connection with XDMCP. Fix bnc#637069. It is the one I have installed, and it does not resolve this issue. Please note, this bug is specific to GDM compiled with IPv6 support. It is different from the plethora of XDMCP issues affecting all/other window managers. To clarify must "works for me" comment #28: I run opensuse 11.2/x86_64 (yes, not 11.3) and also had exactly the problem as described in the initial bug report. That's why I joined the CC: list of this bug. Because of comment #27 and me recalling the update of the gdm package, I've tried "vncviewer host:1" again and it works for me now with gdm-2.28.2-0.2.2.x86_64. Please note: Also installed previous gdm-2.28.2-0.1.3.x86_64 and it still works. Odd. Maybe not entirely gdm-package related and fixed by some other update? Dear people, have you noticed that when a monitor is plugged into the computer acting as vnc server all runs fine (at least with the latest kernel and the packages related to this subject and even with the monitor turned off), BUT when it is started without monitor connected to the vga or dvi output, black screen with X shaped cursor comes! When this happens, X logs says that it could not initialize display. Thus, I cannot move that cpu to a rack unit the way I initially wanted :) Just my two cents Few weeks before I played with "Amazon WS Free Tier" and again I freeze with gdm (Amazon does not allow monitors at all :) So, after checking few DMs I end with wdm - while it look slightly ugly - it work without any troubles Is this bug still an issue? Is it present in openSuSE 11.4? If nobody is able to reproduce any more, it should be closed. Hi Malvern, I'd call it fixed. I cannot reproduce the issue (as initially reported) in openSuSE 11.4 + updates. --Keith Hi Malvern, Contrary to Keiths' results I'm still seeing this problem on 11.4 + updates. I'm using gdm-2.32.0-9.16.1.x86_64. No errors in Xorg log, getting original bugs symptoms, the VNC client is being given the title "nobody's x11 desktop (peterdesktop:1)" with a black screen and default X cursor. The connection times out after about 30 seconds. I've made the changes to hosts and the xinetd line, but no joy. Suggestions? Correction, after disabling IPV6 and restarting, the issue is now fixed. Still a bug since this should have worked straight away, but no longer this GDM bug. It should still work even with IPv6 enabled. Go ahead and re-open I say. Also, can you test against openSUSE 12.1 milestone 3? Thanks! |