| Summary: | XDMCP sends reverse dns hostname unintentionally | ||
|---|---|---|---|
| Product: | [Unmaintained] kdm | Reporter: | Thomas Bettler <thomas.bettler> |
| Component: | general | Assignee: | kdm bugs tracker <kdm-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Found additional information in the syslog on my server: kdm[15838]: Cannot convert Internet address 192.168.237.10 to host name kdm: uwis-cx-dock-1-0xxx.epfl.ch:1[16042]: Cannot connect to uwis-cx-dock-1-0xxx.epfl.ch:1, giving up kdm[15838]: Display uwis-cx-dock-1-0xxx.epfl.ch:1 cannot be opened It tries to convert although the i set the option SourceAddress=true in kdmrc i already had a report about that problem, but i can't find it anymore ... SourceAddress has an effect only on multi-homed machines. i think i will change it or add another option. however, strictly speaking this is only a workaround. i'm not sure whether your dns config is simply messed up (it should resolve the same things on both ends of the vpn) or kdm's reverse lookup system is too naive - mind investigating it? Thanks a lot for your answear. I try to provide further information. Need even more - just ask and I will provide it. Multihomed: Don't you count my machines as multihomed, even though I got a physical and a virtual tun/tap device? - These virtual adapters behave (on ip traffic level) excatly like physical ones. Therefore my system should be recognized as multihomed, IMHO Network topology: Notebook (at work) - eth0: public range IP (199.x.y.z) - tun0: private range IP (192.168.237.10) Server - eth0: public range IP (84.x.y.z) - eth1: private NAT network (192.168.1.0/24) - tun0: private range IP (192.168.237.1) The server runs DHCP/DNS/OpenVPN/etc servers I try to connect with kdm from my notebook (running X server & kdm session display) to my Server (hosting the kdm session) over the tunnel (tun devices). Other things as NFS mounts, ping, DNS etc work fine. The private and public names of both machines work properly via DNS on the server, as does the dns name resolution from notebook to the server (resolv.conf line) Observed network data flow: - connection1 (initiating): kdm (via UDP) from notebook (192.168.237.10:1346) to server (192.168.1.1:177 routed via tun0) - connection2 (answear): kdm (via UDP) from server (192.168.1.1:177 routed via tun0) to notebook (192.168.237.10:1346) - connection3,4,5... : applications (kdm, kdm_greeet, ... via TCP) from server (192.168.1.1:4942x routed via eth0) to notebook (199.x.y.z:6001) The same time I get in syslog: kdm[15838]: Cannot convert Internet address 192.168.237.10 to host name kdm: uwis-cx-dock-1-0xxx.epfl.ch:1[16042]: Cannot connect to uwis-cx-dock-1-0xxx.epfl.ch:1, giving up kdm[15838]: Display uwis-cx-dock-1-0xxx.epfl.ch:1 cannot be opened The connection is refused by the firewall of my notebook, it only allows new connections trough the tunnel device tun0 in. I won't allow the applications' traffic over internet. The only thing I'd like is that the applications use the same IP (and route) as the XDMCP. I guess the kdm backend (on the notebook) tries to revert the IP back to name (or worse fqdn). I don't see the use of this - yet. Though in my case of virtual adapters and tunnels this current behaviour doesn't make me happy. using tap devices (instead of tun) doesn't seem to work neither yes, your machine is clearly multi-homed.
buuut ... i suppose the local and global host names resolve to only one address each. consequently, no SourceAddress=true would be necessary to obtain unambiguity.
the message about reverse resolution failure does not make too much sense, as it later complains about being unable to connect to a host name. so something *is* b0rked in [gentoo's] kdm.
however, the host name it determined doesn't make too much sense, either ...
you did not state explicitly that you verified that the reverse lookup works as expected, too - that would be the last possibility i can think of for an external error.
fwiw, playing with the settings of the kdm on the client machine should not change anything related to the xdmcp connection, except if you change the ServerArgs{,Remote} in a way that would affect it.
so concentrate on the server.
in any case it should be advantageous if you restart kdm with -debug 1 to get some more "noise" into syslog. observe the host names and addresses used in the messages.
After a lengthy debugging session I have some interesting news: - ReverseDNS was broken, though fixing that didn't help. - Just a reminder: The notebook has a firewall on eth0, (intentionally) that's why the session gets b0rk3d. (It would work if it was down, but I need it to connect on tun) - The syslog (thanks to -debug 1) on the server still reports the external, unintended address. - Noticing that, I looked at the dnsmasq.log (on the server) and recognized the reverse queries are all to the external address. Hmm, so it's definitely the client, who handshakes some address to the server. - Back in syslog I looked for the failing query command. Something like: X -query server - Checking the X client options for XDMCP I found it..... There is an option -from to specify the sender address. Tried X -query server -from notebook and it works fine. So now I'm going to use ServerArgsRemote=1.2.3.4 in kdmrc. The origin of the bug is in the Xserver design, though kdm could provide a workaround via from config option, but that would be a nasty effort. I will open a bug there. Closing. Thank you for your help. |
Version: (using KDE KDE 3.5.5) Installed from: Gentoo Packages OS: Linux I got a OpenVPN tunnel from my laptop to my server running kdm. So I connect trough the tunnel, but the applications kdm{,_greet} etc... try to connect to my laptop to the external IP via FQDN which is reported from reverse dns query. So the applications won't run trough the tunnel and be blocked by my firewall on eth0. Instead I'd like the applications to connect to the same IP I connect from with XDMCP. Any idea how to get this working instead? I belive it's a bug, that the applications try to connect to another IP than the XDMCP connection is initiated from. Feature SourceAddress in kdmrc won't work on neither side.