Hello, Florian Schlichting <fschl...@zedat.fu-berlin.de> (23/01/2013): > > As this only happens for me when connecting to a host that resolves to > > both ipv4 and ipv6 (for irssi-plugin-xmpp that is: '/xmppconnect -h > > localhost <jid>', NOT '/xmppconnect -h 127.0.0.1 <jid>'), I suppose the > > GIO watch is triggered once for each protocol version. This may either > > be a bug in glib, or needs to be caught in libloudmouth. > > I now realize that things may be a bit more complicated than that, as > connections to e.g. 'inva...@twattle.net' result in a faultless ipv6 > connection that continues all the way through to the password prompt. > > Perhaps the issue is limited to cases where the name resolution happens > via /etc/hosts, and returns results for both protocols? (It is *not* > limited to connections to "localhost", it also happens when /etc/hosts > specifies both an ipv4 and an ipv6 address for a remote host.) > > And KiBi, is your use case covered by these considerations?
thanks, that definitely helps. Trying to find where the regression came from, I couldn't find any irssi/xmpp plugin/loudmouth/libasyncns combination allowing me to get back a connection to my server; I even went back to squeeze, and nothing worked. That IPv6 lead looks promising as the bug reporting date is consistent with the IPv6 tunnel request on the server side, according to sixxs' web interface. As for /etc/hosts, I got DNS returning both IPv4 and IPv6 for “mraw.org”; forcing IPv4 only through /etc/hosts leads to a successful connection. Having both IPv4 and IPv6 in there leads to the same kind of breakages. Forcing IPv6 only through /etc/hosts leads to no failure, even if I can check good behaviour for real since ejabberd isn't IPv6 enabled by default, and I'm having troubles making it behave properly on restart (even with its original config). So yeah, double-stack (through DNS and/or /etc/hosts) seems to be the ultimate culprit here. Mraw, KiBi.
signature.asc
Description: Digital signature
