Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #763777

Bug#836236: prosody: doesn't try IPv4 when IPv6 fails

From Cyril Brulebois <kibi@debian.org>
Newsgroups linux.debian.bugs.dist
Subject Bug#836236: prosody: doesn't try IPv4 when IPv6 fails
Date 2016-09-01 00:30 +0200
Message-ID <scmb7-8fs-7@gated-at.bofh.it> (permalink)
References <sclf4-7DL-7@gated-at.bofh.it> <sclI6-7NG-39@gated-at.bofh.it> <sclRL-86A-7@gated-at.bofh.it>
Organization Debian

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

Cyril Brulebois <kibi@debian.org> (2016-09-01):
> Hi Matthew,
> 
> Matthew Wild <mwild1@gmail.com> (2016-08-31):
> > Thanks for the report. Can you please bump your log level up to
> > 'debug' (there should be comments in your config file explaining how
> > to do this), and include those logs? The 'info' level logs tend to
> > give a high-level approximate view of issues, but only the debug logs
> > can be relied upon when debugging the low-level individual connection
> > attempts.
> 
> This is very strange. While crans.org was still without IPv6, a simple
> restart locally made prosody look at both IPv6 (fail) and IPv4
> (success). I wonder whether something might have been stuck in a bad
> state within prosody after the initial DNS resolution failures which
> happened for various domains…
> 
> Needless to say, I can't really replicate the issue right now, except
> perhaps by rebooting again (which I can't really since I've got ongoing
> maintenance elsewhere already). I would also need to remove things like
> contact presence information from those logs before posting them…

Just in case it helps you figure out what could have happened, messages
right after reboot for this host:
| Aug 31 02:09:46 s2soutf30410    info    Beginning new connection attempt to crans.org ([2a01:240:fe3d:4:200:42ff:fe42:4204]:5269)
| Aug 31 02:09:46 mod_s2s warn    s2s connect() to crans.org (2a01:240:fe3d:4:200:42ff:fe42:4204:5269) failed: Network is unreachable
| Aug 31 02:09:46 s2soutf30410    info    Out of connection options, can't connect to crans.org
| Aug 31 02:09:46 s2soutf30410    info    Sending error replies for 1 queued stanzas because of failed outgoing connection to crans.org
| Aug 31 02:09:46 mod_s2s warn    Connection to crans.org failed already, destroying session...

Also, a bunch of other hostnames had such issues:
| Aug 31 02:11:27 s2sout1007a70   info    Connection failed (name resolution failed). Attempt #2: This time to alt2.xmpp-server.l.google.com.:5269
| Aug 31 02:11:27 s2sout1007a70   info    Connection failed (name resolution failed). Attempt #3: This time to alt4.xmpp-server.l.google.com.:5269
| Aug 31 02:11:27 s2sout1007a70   info    Connection failed (name resolution failed). Attempt #4: This time to alt3.xmpp-server.l.google.com.:5269
| Aug 31 02:11:27 s2sout1007a70   info    Connection failed (name resolution failed). Attempt #5: This time to alt1.xmpp-server.l.google.com.:5269
| Aug 31 02:11:27 s2sout1007a70   info    Out of connection options, can't connect to [anotherserver]
| Aug 31 02:11:27 s2sout1007a70   info    Sending error replies for 1 queued stanzas because of failed outgoing connection to [anotherserver]

so I'm wondering whether there could have been incomplete DNS
resolution(s) at start-up time, which would not have been attempted
again later, leading me to see some contacts offline with “DNS failures”
as error message in Gajim.

After the prosody restart I triggered manually:
| Aug 31 23:37:49 s2sout231c500   info    Beginning new connection attempt to crans.org ([2a01:240:fe3d:4:200:42ff:fe42:4204]:5269)
| Aug 31 23:37:49 s2sout231c500   info    Beginning new connection attempt to crans.org ([138.231.136.66]:5269)
| Aug 31 23:37:49 s2sout231c500   info    outgoing s2s connection mraw.org->crans.org complete

Incidentally, looking at the IPv4 address for crans.org in the log since
the machine reboot, the first occurrence is when I restarted prosody
manually.

So it looks to me like it could be an initial DNS issue (partial and/or
no resolution depending on the domain) which happened at start-up time,
and failed/incomplete resolutions weren't attempted again later on.

Would this seem even remotely plausible?


KiBi.

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Bug#836236: prosody: doesn't try IPv4 when IPv6 fails Cyril Brulebois <kibi@debian.org> - 2016-08-31 23:30 +0200
  Bug#836236: prosody: doesn't try IPv4 when IPv6 fails Matthew Wild <mwild1@gmail.com> - 2016-09-01 00:00 +0200
    Bug#836236: prosody: doesn't try IPv4 when IPv6 fails Cyril Brulebois <kibi@debian.org> - 2016-09-01 00:10 +0200
      Bug#836236: prosody: doesn't try IPv4 when IPv6 fails Cyril Brulebois <kibi@debian.org> - 2016-09-01 00:30 +0200
        Bug#836236: prosody: doesn't try IPv4 when IPv6 fails Matthew Wild <mwild1@gmail.com> - 2016-09-01 10:40 +0200
          Bug#836236: prosody: doesn't try IPv4 when IPv6 fails Cyril Brulebois <kibi@debian.org> - 2016-09-01 17:20 +0200

csiph-web