Fedora Account System
Red Hat Associate
Red Hat Customer
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061027 Fedora/1.5.0.7-8.fc6 Firefox/1.5.0.7 Description of problem: querying from xtermianl "A" the chooser "B" with "Xnest :1 -indirect B" gives me a list of hosts including "C". connecting "C" fails. this is reproduceable with Xnest, X or Xming.exe from differnt (including windows) hosts "A". this also reproduceabel withh different hosts "B" or "C". the connection works fine when i replace kdm with gdm. Version-Release number of selected component (if applicable): kdebase-3.5.5-0.1 How reproducible: Always Steps to Reproduce: 1. try to query a kdm host from a chooser 2. 3. Actual Results: black screen Expected Results: kdm greeter dialog Additional info: on host "C" kdm -debug 0x85 delivers something like: Nov 7 20:08:20 kdm[9210] debug: select returns 1 Nov 7 20:08:20 kdm[9210] debug: ProcessRequestSocket Nov 7 20:08:20 kdm[9210] debug: header: 1 4 11 Nov 7 20:08:20 kdm[9210] debug: <forward> respond 11 Nov 7 20:08:20 kdm[9210] debug: <forward> client address (port 32981) 192 168 54 107 Nov 7 20:08:22 kdm[9210] debug: select returns 1 Nov 7 20:08:22 kdm[9210] debug: ProcessRequestSocket Nov 7 20:08:22 kdm[9210] debug: header: 1 4 11 Nov 7 20:08:22 kdm[9210] debug: <forward> respond 11 Nov 7 20:08:22 kdm[9210] debug: <forward> client address (port 32981) 192 168 54 107 after viewing the sources i found that a line with somethning like "debug: all_query_respond:" should be the next line but is missing. wireshark: the forward_query package from "B" to "C" with the correct address of "A" is delivered to "C", but "C" gives no answer at all.
It seems the option "KDM should listen to XDMCP requests" is disable! Could you please change the line "Enable=false" to "Enable=true" from the section [Xdmcp] in /etc/X11/xdm/kdmrc and try again? Thanks
please make sure that you have to restart kdm after changing the kdmrc!
> [Xdmcp] > Enable=true works fine. but this is NOT the bug reported about "indirect" requests and no answers to the "forward_query". if you Xnest :1 -query "C" everything works fine, but Xnest :1 -indirect "B" "C" is listed but the connection fails as discribed.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
For what it's worth, I can report exactly the same trouble symptom that Mr. Dorfmeister describes, except that I am running Fedora *8* and gdm. Specifically: Fedora 8, kernel-2.6.24.4-64.fc8 with gdm-2.20.3-1.fc8. In my case the forward queries do not even go to the correct host, e.g., with my internal net being 192.168.200.0/24 and the selected host being 192.168.200.4, wireshark shows the forward queries being sent to addresses like 112.197.67.9, 53.0.77.101, 53.0.67.9, etc. Something in the chooser or some underlying library is generating garbage destination addresses. As Mr. Dorfmeister describes, the chooser was working with gdm in Fedora 6. Now it's broken in Fedora 8. I use gnome and haven't tested with kde/kdm.
thanks for your update. changing version to '8'
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Hi, I tried cloning this bug to make a new posting out of it, but nothing happened, so let me try just add a comment. This bug occurs identically as described above in Fedora 10 *and* Fedora 11. Since gdm no long supports xdmcp, I am now using kdm like the original reporter. To summarize: 1) kdm correctly configured on machine A and machine B 2) At the graphical login screen of either, select menu->remote login, and see A and B in the chooser list 3) Select the other machine 4) Successful connection occurs, and login to the remote machine is possible So far, so good. Now the failure scenario: 2) Login to either machine, from e.g., a gnome-terminal, run Xephyr -indirect localhost :1 (or substitute the local machine's name for localhost) and see A and B in the chooser list 3) Select the other machine 4) Xephyr screen goes grey with an X cursor and stays that way until the connection attempt times out, then the chooser reappears. During the timeout period, wireshark shows FORWARD_QUERY packets going to the remote machine, and wireshark running on the remote machine shows the arrival of the FORWARD_QUERYs. The remote machine generates no response. When the remote connection is attempted from the login screen menu as in 1-4) earlier, the local machine is not sending FORWARD_QUERYs, it is sending a direct query to the remote. This bug has now been demonstrated using kdm and, previously, gdm, spanning multiple versions of Fedora over a three year period. The three conspicuous features of this bug are: * recipients of xdmcp FORWARD_QUERYs don't seem to know what to do with them * a connection attempt via kdm from the login screen results in a direct query while an attempt via kdm from a nested server such as Xnest or Xephyr results in a forward query. Whey the different behavior? * Xnest or Xephyr both work when a direct query is forced on the command line, e.g., Xephyr -query other_machine :1 Please keep this bug alive. Broken xdmcp/chooser in a nested server is a real sore spot.
Bug persists as of january 2012, with EL6 (Scientific Linux 6.1) It manifests as Dennis has wrote in previous comment. Maybe this should be fixed after 6 years? ...