From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20061027 Fedora/220.127.116.11-8.fc6 Firefox/18.104.22.168
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):
Steps to Reproduce:
1. try to query a kdm host from a chooser
kdm greeter dialog
on host "C" kdm -debug 0x85 delivers something like:
Nov 7 20:08:20 kdm debug: select returns 1
Nov 7 20:08:20 kdm debug: ProcessRequestSocket
Nov 7 20:08:20 kdm debug: header: 1 4 11
Nov 7 20:08:20 kdm debug: <forward> respond 11
Nov 7 20:08:20 kdm debug: <forward> client address (port 32981) 192 168 54 107
Nov 7 20:08:22 kdm debug: select returns 1
Nov 7 20:08:22 kdm debug: ProcessRequestSocket
Nov 7 20:08:22 kdm debug: header: 1 4 11
Nov 7 20:08:22 kdm debug: <forward> respond 11
Nov 7 20:08:22 kdm 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.
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!
works fine. but this is NOT the bug reported about "indirect" requests and no
answers to the "forward_query".
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.
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
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:
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*
Specifically: Fedora 8, kernel-22.214.171.124-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 126.96.36.199, 188.8.131.52, 184.108.40.206, etc. Something
in the chooser or some underlying library is generating garbage
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:
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.
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
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? ...