s2s dns lookup timed out and router + sm shutdown
Hello I am running jabberd 2.3.1 on FreeBSD 9.1. After I did the upgrade from Perl 5.12.5 to 5.16.3 (now with threads enabled) and rebuild all ports depending on Perl (which includes jabberd), I see the following behavior. 1) jabberd starts up just fine 2) I connect with my client and a few hostname are resolved just fine 3) after about 90 seconds a whole bunch of hostnames give the 'dns lookup for .xx timed out' error followed with router and sm 'shutting down' and then followed by c2s and s2s core dumping Since the rebuild restart of jabberd before, the following probably relevant things also have changed: - Ports gcc had been upgraded from gcc47-4.7.4.20131214 to gcc47-4.7.4.20140118 (required dependency from jabberd port) - Ports udns had been upgraded from udns-0.2 to udns-0.3_1 I did see the thread s2s: timed out dns lookups and tried with the suggestion from there, but this did not help. This server does resolve just fine, as it did before, nothing has changed here. The working or failing hostname with dns lookup change with every startup / connnect I try. What else could I test or try to resolve this? bye Fabian
Re: Cannot connect with android clients xabber or yaxim to jabberd2
Hello Guido On 08.01.2014 21:01, Guido Winkelmann wrote: On Monday 06 January 2014 22:06:32 Fabian Wenk wrote: A friend also had the problem with his xabber client connecting after he did upgrade jabberd from 2.2.17 to 2.3.1. After I have just discussed this issue with him again (as I did not had any problems, but I do not use it from Android), he pocked around in the settings and did deactivate the option (translated from German): use SASL authentication (recommended) (deactivate for very old servers) in xabber and he is able to connect again. You are right, if I disable SASL auth, I can login via xabber again. Tomasz had a private conversation with me. Our conclusion was, that this must be a bug or wrong implementation or translation in xabber. According to Tomasz the '--enable-superseded' build option in jabberd 2.3.1 does enable legacy (non-SASL) authentication. According to [1], the following entry is added in the 0.9.19 (release date 2011-12-21): Don't use SASL Authentication option for old servers [1] http://redmine.xabber.com/projects/1/wiki/History The xabber client from a friend in German language has the following option (in version 0.9.30b): SASL-Authentifizierung nutzen (empfohlen) Für sehr alte Server deaktivieren It seems that this option is somehow inverted, or miss-translated in xabber, as our findings would show what we have tested so far. My friend has reported this to the author of xabber, but did not hear anything back yet. Maybe you could also add this information (I guess you are also using xabber in German) to the bug report you already created. I do not know if maybe other clients (like yaxim you mention) share the same code base and those some of the same bugs. bye Fabian
Re: Cannot connect with android clients xabber or yaxim to jabberd2
Hello Tomasz On 07.01.2014 00:29, Tomasz Sterna wrote: Dnia 2014-01-06, pon o godzinie 22:06 +0100, Fabian Wenk pisze: @Tomasz, could this be a bug or change from in jabberd 2.2.17 to 2.3.1? In 2.3.0 GnuSASL =1.1 dependency was introduced. So could there be an incompatibility between your client and new GnuSASL? I do not think so, see below. Also since 2.3.0 CyrusSASL backend is broken. Although it is disabled by default, there are still people using it. Are you using CyrusSASL backend? No, we are using the GSASL backend config option from FreeBSD port, as the CYRUS has the remark not supported. GnuSASL in use is and was before with jabberd 2.2.17: fabian@superman:~ $ pkg_info | grep sasl gsasl-1.8.0_2 GNU SASL Library fabian@superman:~ $ In 2.3.1 --enable-superseded and --enable-experimental defaults were changed. So if you rely on superseeded and/or experimental features, you need to enable them explicitly. Enabling superseded did help and xabber could connect again with the use SASL authentication (recommended) option activated. bye Fabian
Re: Adium 1.5.9 works with 5223, not with 5222+starttls
Hello Joe On 30.12.2013 00:44, Joe Malcolm wrote: Anyone else running into a problem with 5222 starttls for Adium? I'm running jabberd2 2.2.17 on FreeBSD-10RC2. I am using Adium 1.5.9 now (1.5.7 before) with jabberd-2.2.17_1 on FreeBSD 9.1 and it works. Adium says: 17:47:20: (Libpurple: cdsa) SSLHandshake failed with error -9806 17:47:20: (Libpurple: connection) Connection error on 0x10e056c50 (reason: 5 description: SSL Handshake Failed) Is the SSL configuration correct in the c2s.xml? Did you create the correct file .pem file with the following order of the certificates / keys in PEM format? host certificate host private key issuse CA certificate root CA certificate Is your configuration correct and is jabberd (c2s) able to ready the file with the certificates? Check permissions and path to file. Also check your options in the c2s.xml for id realm= part. It all works if I force 5223 old-style SSL. Can not test, this is not active on my system. bye Fabian
running with IPv6 on FreeBSD 9.1
Hello
I finally took the time to activate IPv6 in my jabberd (2.2.17)
installation. My systems are running with IPv6 since many years
and jabberd is one of the last services, which still was running
on IPv4 only. After many trial and errors I got it partly
running. When I did set ip::/ip instead of ip0.0.0.0/ip
in u2s.xml and s2s.xml it was listening on IPv6, but not on IPv4
any more. After I did activate IPv4 mapped IPv6 addresses
('sysctl net.inet6.ip6.v6only=0', or adding
'ipv6_ipv4mapping=YES' to /etc/rc.conf to activate at boot
time) jabberd was listening on IPv4 + IPv6.
But this causes other problems on my system, which is also a NFS
server, see FreeBSD PR #177781 rpc.statd / rpc.lockd do not
start when used with -p option and ipv6_ipv4mapping=YES is set
in /etc/rc.conf [1]. This report is from an other system of
mine, with other software in use, where the current used version
needs this mapping, but this is fixed in a newer version, which
will obsolete this mapping.
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=177781
I tried an other approach with setting up a second c2s (and also
s2s) instance. A second c2s which is only listening on IPv6 is
working fine. But I also would like to have second s2s which is
working only on IPv6. But as I do understand, this is not easily
possible, or only if I would probably create manual routing
entries for some domains to force them over the IPv6 enabled s2s.
So my question is, is there an other / better approach to have
this running more flexible? Or would it be possible to change /
fix jabberd, that it does not need this IPv4 mapped IPv6
addresses any more?
netstat output with IPv4 mapped IPv6:
tcp46 0 0 *.5222 *.* LISTEN
tcp46 0 0 *.5269 *.* LISTEN
netstat output with native IPv4 + IPv6 (with 2x u2s and 1x s2s
with IPv4 only). All other daemons / services, e.g. like sshd,
are doing it this way:
tcp4 0 0 *.5222*.*LISTEN
tcp6 0 0 *.5222*.*LISTEN
tcp4 0 0 *.5269*.*LISTEN
bye
Fabian
Re: Need help with remote-server-timeout errors in S2S component and s2s.xml file[version 2.2.16]
Hello Auro On 27.07.2012 02:17, Auro Tripathy wrote: I have set up a jabberd2 test server at 'engdev1.remotewd2.com' and I'm now using the S2S component to setup a chat session with my gmail account. Note, within my domain, my test server does fine with chat sessions. I get timeouts and I'm wondering if the s2s.xml file is setup correctly. I did not wade through your very large log file, because I think you should be able to identify the interesting lines on your own and then pasting them into Google. So I just shoot into the dark and hope I do not miss. ;) First, Google had yesterday some trouble with their Google Talk (which is their jabber/xmpp service). Maybe you got affected by this. Second, I had only to configure quite little in the s2s.xml, mainly only setting a useful password for the communication with the jabberd2 router, and adjusting / enabling the SSL certificates (but I guess this is optional). Third, do you have the correct DNS entries for the domain you are using with jabberd? I have e.g. the following entries in my example.com DNS zone (the jabber accounts are u...@example.com): ; entries for jabber jabber IN AIP-address _xmpp-server._tcp IN SRV 5 0 5269 jabber.example.com. _xmpp-client._tcp IN SRV 5 0 5222 jabber.example.com. The numbers 5269 and 5222 correspond to the port which are used (and in jabberd2 configured) for server to server (s2s) and client to server (c2s) communication with the jabberd server. bye Fabian
Re: [jabberd2] Using server x509 certs
Hello Ismael On 13.10.08 16:31, Ismael Olea wrote: sx (ssl.c:762) couldn't load certificate from /etc/pki/tls/private/tormento-jabber-cert.pem; error:0906D06C:PEM routines:PEM_read_bio:no start line Mon Oct 13 15:27:35 2008 [error] failed to load olea SSL pemfile It looks like the .pem file is corrupted, it should be like this: -BEGIN CERTIFICATE- many---lines---with---just---7bit---ASCII---at---this---length -END CERTIFICATE- I had the problem with missing one of the - because of an copypaste error from the CAcert.org output. In detail I did the following steps (adjust paths according to your system, this was done on FreeBSD): $ openssl req -nodes -new -keyout jabber.key -out jabber.csr (only enter CN) submit jabber.csr to CAcert.org for signing (class3) save respond in jabber.pub $ scp jabber.key jabber.pub [EMAIL PROTECTED]:/usr/local/etc/jabberd/ # cd /usr/local/etc/jabberd # wget http://www.cacert.org/certs/class3.crt # wget http://www.cacert.org/certs/root.crt # cat jabber.pub jabber.key class3.crt root.crt jabber.pem # chown root:jabber jabber.pem # chmod 640 jabber.pem # openssl x509 -text -in jabber.pem (to check the cert) # rm jabber.pub jabber.key class3.crt root.crt # $EDITOR /usr/local/etc/jabberd/c2s.xml adjust path / file name to the .pem in pemfile and add pemfile='/usr/local/etc/jabberd/jabber.pem' to id password-change='true' and id register-enable='true' # /usr/local/etc/rc.d/jabberd restart Hope this helps. bye Fabian -- To unsubscribe send a mail to [EMAIL PROTECTED]
