[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#251037: Strange xdmcp behavior, maybe a trojan horse?

Branden Robinson wrote:

That's probably a bug.  It may have something to do with:


*That* bug has been open for over 8 years. :(
[and from another mail]:

> Does it sound like this one?:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=4757

First thing first, in my opinion xdm works perfectly well in all those situations. I think I understand now *why* it behaves this way. And what's worst, it can be assumed as the right behavior. :-(

As far as I can understand the situation, the problem is caused by Xserver and RFC1122, where "weak end host" is defined. During connection setup, Xserver sends its IP address in a XDMCP packet to a xdm process on a remote host. But which IP should be sent by a multihomed Xserver? The logic says, the IP of the interface which leads to a remote xdm. But in a consequence of RFC1122, all host's IPs are local on every interface (for incomming packets, of course). One can easily check it's true, just traceroute to a box with more than one interface:

fback@obora:~$ traceroute
traceroute to (, 30 hops max, 38 byte packets
 1  chlew-wifi.home.fback.net (  2.649 ms  1.878 ms  1.961 ms

fback@obora:~$ traceroute
traceroute to (, 30 hops max, 38 byte packets
 1 (  2.221 ms  2.474 ms  1.974 ms

fback@obora:~$ traceroute chlew
traceroute to chlew.home.fback.net (, 30 hops max, 38 byte packets
 1  chlew.home.fback.net (  2.232 ms  1.744 ms  2.751 ms

I can even add some public IP to a chlew's loopback interface and:

chlew:~# ifconfig lo:1 netmask broadcast

fback@obora:~$ traceroute
traceroute to (, 30 hops max, 38 byte packets
 1 (  2.216 ms  2.327 ms  2.360 ms

So Xserver takes all the local IPs and sends them to a remote xdm process, allowing him to choose the best. When it's in the same subnet, it will choose local address (and that's why it worked for me within the same subnet), but what when all IPs are non-local? It will take the first one and will try to connect to it.

Everything is OK according to RFCs. But on the other hand, loopback is only a local interface, which never sends packets to a network. So in my opinion, Xserver should never advertise its loopbacks. As far as I checked, it doesn't send, except the situation when connecting to it explicitely. I think it should never send *any* IP assigned to a loopback [sub]interface(s). Unfortunately, I'm not sure there's easy way to check, if an address is assigned to a loopback.

Sending loopback would make sense only in a situation, when the Xserver is running on a multihomed box, with 2 (or more) interfaces which are available through different paths. But who runs Xserver on a BGP router? ;-)

I guess, that a scenario in #4757 was as follow:
First interface up was eth0, possibly with a private IP. Second interface up was ppp0 (so Xserver advertised private IP as the first one, and public as the second). It caused remote xdm connects to an unavailable IP.

Would configuring interfaces in some explicit order solve my (and all other) problems? I'll try this next week.


PS. Sorry for my english. :(

Reply to: