Bug#4757: XDMCP problem with multihomed X servers (design error?)
Package: xbase
Version: 3.1.2-9
I have an X server running on a machine with two different network
interfaces (ethernet and ppp) onto separate networks.
I've been trying to get that X server to talk to an xdm on one of
those networks (ppp), by using X -query <name-of-xdm-host>.
This appears to work correctly (XDMCP UDP packets are exchanged) until
xdm tries to make an actual X connection to the X server. It seems
that xdm has synthesised a DISPLAY value containing the hostname of
the X server's ethernet interface, by doing a reverse lookup of an IP
address provided by the X server (both the X server and xdm have
access to name/address mappings for all the interfaces involved, all
of which have distinct canonical names and reverse map correctly).
Examining the source code I can see that XDMCP has a facility for the
X server to tell its address to xdm, other than by having xdm examine
the IP headers on the (UDP) XDMCP query. This message has room for
several addresses in different address families (connection types in
X speak).
I presume that this facility is there so that an X server which
supports several different connection types can advertise them all,
and xdm can pick the right one.
However:
(a) the X server always advertises all of its IP interfaces in this
message, in the order they were configured.
(b) the function in xdm which is supposed to choose which entry from
the table to pick always returns 0, so that the first entry is always
used.
In my situation this causes xdm to try to make an X connection to the
X server's ethernet interface, which doesn't work (because the two
networks are partitioned).
There appear to be no options to X or xdm which help the situation.
Interestingly, the X server does have access to a more appropriate
address: when it does XDMCP it uses a UDP socket to send packets to
the xdm's ppp interface and the kernel does select an appropriate
source address: the X server's ppp interface.
I've managed to find a workaround: using LD_PRELOAD to override ioctl
so that SIOCGIFCONFIG (used by the X server to find which interfaces
are available) doesn't return the ethernet interface at all. However
this is a horrible hack.
I'm not entirely sure, but I think that the right fix is something
like the following:
* xdm should have a way to configure `preferred' addresses, much as
named does for returning RRs.
* xdm should try all the addresses it has been given in order, and its
timeout for going on to the next one should be shorter than the X
server's timeout for giving up on the XDMCP session.
* xdm should disregard addresses with connection types it doesn't
understand (at the moment it doesn't appear to do this).
* X should make sure that the local address of the UDP port it's using
to communicate with xdm is first on the list of addresses it
advertises.
* X should have an option to specify which local address to use.
An alternative strategy would be:
* X should only advertise one address with each connection type.
* If it has many possible addresses to choose from X should try doing
a session with each.
* X should try the local address it is using for its XDMCP session
first.
* X should have a way to specify an order for the interfaces it
advertises; there needs to be a default (which just overrides the
list from SIOCGIFCONFIG) and an overriding version (which can
override the local end of the XDMCP session too).
* xdm should skip down the list of addresses until it finds a type it
supports. (Currently I believe it will fail if the first connection
type advertised is not supported.)
What the strategy should be will need to be decided globally, perhaps
by fiat by the X consortium if there is no obvious right answer to
those who know this area better than I do.
Ian.
PS: I'm using the xdm from Debian's xbase 3.1.2-9 and the XF86_S3 from
3.1.2-5.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: