XMPP connection problem

[R. Mattes]

Dear list wisdom,

I'm experiencing a rather strange problem with my xmpp client.
As long as I'm connected to the network the code does run fine,
but as soon as I try to use it offline the client never establishes a
connection to the server. Running the application with output to stdout
I get the following error:

....
2012-11-06 16:49:24+0100 [-] DNSDatagramProtocol starting on 17787
2012-11-06 16:49:24+0100 [-] Starting protocol
<twisted.names.dns.DNSDatagramProtocol object at 0x1b5e710>
2012-11-06 16:49:24+0100 [-] (UDP Port 64994 Closed)
2012-11-06 16:49:24+0100 [-] Stopping protocol
<twisted.names.dns.DNSDatagramProtocol object at 0x1b65850>
....

ad infinitum ....

Strangely, after further investigation it seems as if the code tries
to resolve "localhost" (the client tries to connect to a local ejabberd
installation). Now, the hostname "localhost" does resolve on this machine
(both ping and a paramiko-SSH connect from the twisted programm do work).
Localhost is configured in /etc/hosts like this:

127.0.0.1 localhost

and /etc/hosts is enabled in /etc/nsswitch.conf like this:

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

(standard Debian setup, IIRC).

Any idea what goes wrong here?

TIA Ralf Mattes

--
R. Mattes -
Hochschule fuer Musik Freiburg
***@inm.mh-freiburg.de

[HoverHell]

....

Not sure how the name resolving works in the twisted in general, but
the logs show the attempt to resolve the name using DNS request
specifically (and, since it fails, I'd assume it doesn't try to
resolve using /etc/hosts). Can't suggest anything better than digging
in the code for the difference in name resolution between paramiko and
xmpp; can also probably note that XMPP would normally try to check SRV
records as well for which reason it might ignore /etc/hosts (or, at
least, try the SRV DNS requests even if the host itself is found).

[R. Mattes]

Post by HoverHell

....

Not sure how the name resolving works in the twisted in general, but
the logs show the attempt to resolve the name using DNS request
specifically (and, since it fails, I'd assume it doesn't try to
resolve using /etc/hosts).

Strange: It seems to ignore my local resolver setup.
Tracing the network on the box I found out that the client tries
to query a dns server at 127.0.0.1 and of course recieves the
(deserved ;-) 'ICMP Port unreachable' response. Why would twisted.names
assume there's a dns server atz that address (totally ignoring the
(unreachable) servers configured in /etc/resolv.conf)?

Cheers, RalfD

--
R. Mattes -
Hochschule fuer Musik Freiburg
***@inm.mh-freiburg.de

[R. Mattes]

Post by R. Mattes

Post by HoverHell

....

Not sure how the name resolving works in the twisted in general, but
the logs show the attempt to resolve the name using DNS request
specifically (and, since it fails, I'd assume it doesn't try to
resolve using /etc/hosts).

Strange: It seems to ignore my local resolver setup.
Tracing the network on the box I found out that the client tries
to query a dns server at 127.0.0.1 and of course recieves the
(deserved ;-) 'ICMP Port unreachable' response. Why would twisted.names
assume there's a dns server atz that address (totally ignoring the
(unreachable) servers configured in /etc/resolv.conf)?

O.k. - I kind of fixed it locally: I ended up changing my /etc/host entry:

127.0.0.1 localhost _xmpp-client._tcp.localhost

I do consider this a bug - there's no need to resolve this address at
all (at least for a xmpp client). Not to mention that
_xmpp-client._tcp.localhost isn't even a valid host/domain name ....

Cheers RalfD


--
R. Mattes -
Hochschule fuer Musik Freiburg
***@inm.mh-freiburg.de

[HoverHell]

Post by R. Mattes
I do consider this a bug - there's no need to resolve this address at
all (at least for a xmpp client). Not to mention that
_xmpp-client._tcp.localhost isn't even a valid host/domain name ....

there is a need and it is a valid name; see “SRV record” for reference.
(though, I really didn't expect it to work that way in /etc/hosts)

[R. Mattes]

Post by R. Mattes
I do consider this a bug - there's no need to resolve this address at
all (at least for a xmpp client). Not to mention that
_xmpp-client._tcp.localhost isn't even a valid host/domain name ....

there is a need and it is a valid name; see [UTF-8?]“SRV [UTF-8?]recordâ€

 for reference.

Yes, sorry, you're right - this is a valid entry for a SRV record.
But still: service discovery is optional. XMPP clients shouldn't stop
working when no server record is found. BTW, even if I'm online and
a real DNS server is available I'm pretty shure it won't find a
xmpp SRV record for localhost - but in this setup twisted.names does
work and my client connects to the server.
And why does the twisted.names code attempt to query a DNS server
on 127.0.0.1? Using 127.0.0.1/53 as a fallback seems like a really bad
idea ....

(though, I really didn't expect it to work that way in /etc/hosts)

Me neither :-) That file is deinitely not meant for SRV records.

Cheers, RalfD


--
R. Mattes -
Hochschule fuer Musik Freiburg
***@inm.mh-freiburg.de

[HoverHell]

Post by R. Mattes
But still: service discovery is optional. XMPP clients shouldn't stop
working when no server record is found. BTW, even if I'm online and
a real DNS server is available I'm pretty shure it won't find a
xmpp SRV record for localhost

It doesn't stop working when no SRV record is found. But when a DNS
server to query is not found… uh… not sure, maybe it should stop
working (or, as you've noticed, *retry*); for example, to avoid a
situation where accidental timeout from DNS could mean connecting to a
wrong server (an unlikely but possibly quite confusing occasion).

Post by R. Mattes
And why does the twisted.names code attempt to query a DNS server
on 127.0.0.1? Using 127.0.0.1/53 as a fallback seems like a really bad
idea ....

Not *really* but yes, seems like a bad idea. Though I feel like there
was some relevant reason, but can't remember >.>

[R. Mattes]

Post by HoverHell

Post by R. Mattes
But still: service discovery is optional. XMPP clients shouldn't stop
working when no server record is found. BTW, even if I'm online and
a real DNS server is available I'm pretty shure it won't find a
xmpp SRV record for localhost

It doesn't stop working when no SRV record is found. But when a DNS
server to query is not [UTF-8?]found… [UTF-8?]uh… not sure, maybe it

should stop

Post by HoverHell
working (or, as you've noticed, *retry*); for example, to avoid a
situation where accidental timeout from DNS could mean connecting to
a wrong server (an unlikely but possibly quite confusing occasion).

But isn't that a solved problem? O.k. twisted seems to ignore the whole
name lookup configuration (/etc/nsswitch.conf). But even then, for
A records it's pretty much: query server A, ... timeout, query server B,
... timeout, ... fallback.

For XMPP it seem the RFC suggests:
SRV query ... (see above) ... fallback to A record (see above)
To me it seems as if the fallback to A record/hosts-file never happens.

Apropos timeout: the query to my non-existing local nameserver does
_not_ timeout - the program receives an 'ICMP Port unreachable'.
Retrying doesn't make sense with such an error response.

Post by HoverHell

Post by R. Mattes
And why does the twisted.names code attempt to query a DNS server
on 127.0.0.1? Using 127.0.0.1/53 as a fallback seems like a really bad
idea ....

Not *really* but yes, seems like a bad idea. Though I feel like there
was some relevant reason, but can't remember

It's hardcoded into the client:

if not servers:
servers.append(('127.0.0.1', dns.PORT))

But that might be a nameserver serving another net. That's why there
is /etc/nsswitch.conf and /etc/hosts. The wrong answer often is worse than
no answer ;-)

Anyway, thanks for your input,

RalfD

Post by HoverHell
.>
_______________________________________________
Twisted-Jabber mailing list
https://mailman.ik.nu/mailman/listinfo/twisted-jabber

--
R. Mattes -
Hochschule fuer Musik Freiburg
***@inm.mh-freiburg.de

[HoverHell]

Post by R. Mattes
SRV query ... (see above) ... fallback to A record (see above)
To me it seems as if the fallback to A record/hosts-file never happens.

for what particular case? For the case of record-not-found —
reasonable; for the case of icmp-unreachable… see below.

Post by R. Mattes
Apropos timeout: the query to my non-existing local nameserver does
_not_ timeout - the program receives an 'ICMP Port unreachable'.
Retrying doesn't make sense with such an error response.

Sample case: system boot (in case xmpp client managed to start before
the DNS server). Also unlikely but also could be quite problematic.

Post by R. Mattes
servers.append(('127.0.0.1', dns.PORT))

A bit of svn blame poking leads to:
r12604 | exarkun | 2004-11-26 09:32:40 +0300 (Fri, 26 Nov 2004) | 2 lines
Handle empty and missing resolv.conf files as though 127.0.0.1 were
configured as the resolver

I presume you have empty /etc/resolv.conf (or… well, trace that
parseConfig to see what is going on), and something in Twisted doesn't
parse the nsswitch.conf (or does but also does parseConfig).
(assuming it's that line that causes it to query dns on localhost)

[R. Mattes]

Post by R. Mattes
SRV query ... (see above) ... fallback to A record (see above)
To me it seems as if the fallback to A record/hosts-file never happens.

for what particular case? For the case of record-not-found [UTF-8?]—
reasonable; for the case of [UTF-8?]icmp-unreachable… see below.

Post by R. Mattes
Apropos timeout: the query to my non-existing local nameserver does
_not_ timeout - the program receives an 'ICMP Port unreachable'.
Retrying doesn't make sense with such an error response.

Sample case: system boot (in case xmpp client managed to start before
the DNS server). Also unlikely but also could be quite problematic.

Yes, but that's pretty much a system misconfiguration, or are you talking about
a remote DNS server boot? Not much you a xmpp client can do about that.
Port unreachable means: networking is up and running but there's no service
where you expected one to be. Retrying would make sense iff the server would
be one configured by the system admin.

Post by R. Mattes
servers.append(('127.0.0.1', dns.PORT))

r12604 | exarkun | 2004-11-26 09:32:40 +0300 (Fri, 26 Nov 2004) | 2 lines
Handle empty and missing resolv.conf files as though 127.0.0.1 were
configured as the resolver
I presume you have empty /etc/resolv.conf [UTF-8?](or… well, trace that
parseConfig to see what is going on),

I did that already. A nonexisting resolf.conf is treated like an empty one:

# Missing resolv.conf is treated the same as an empty resolv.conf
self.parseConfig(())

and something in Twisted
doesn't parse the nsswitch.conf (or does but also does parseConfig).
(assuming it's that line that causes it to query dns on localhost)

I couldn't find any mention of nsswich.conf in the code.

Anyway, my local test setup works (with that kludge in /etc/hosts).

Thanks for your input

RalfD


--
R. Mattes -
Hochschule fuer Musik Freiburg
***@inm.mh-freiburg.de

[e***@twistedmatrix.com]

Post by R. Mattes
Anyway, my local test setup works (with that kludge in /etc/hosts).
Thanks for your input

If you think there is a bug in Twisted, please describe it in a bug
report on <http://twistedmatrix.com/>. If you think there's a bug in
wokkel (are you using wokkel? I'm not sure if you ever mentioned), then
I'm sure its authors would appreciate a bug report on
<http://wokkel.ik.nu/> (which is hopefully only temporarily offline).

One thing I'll point out is that "Twisted" (inasmuch as we can discuss
Twisted as a single fused entity with uniform behavior - which is not so
much) does not automatically use its own Twisted Names based name
resolver, precisely because Twisted Names is *only* a DNS implementation
and ignores nsswitch.conf. Applications must request that Twisted Names
be used, if they want it to be used. Otherwise the system resolver is
used.

Thanks.

Jean-Paul