Some users cannot connect after upgrade from 2.2.17 to 2.3.2
Tomasz (and maybe others), After an upgrade today from 2.2.17 to 2.3.2 a small number of users are unable to connect. The strange thing is that they seem to be thrown out AFTER they have authenticated correctly and the session has started. I have looked but I cannot see why it suddenly should not work any more. Here is some more info: I have built with experimental options disabled and superseded options enabled. (The last option was added because many other users could not connect either including myself using the latest Xabber on Android): ../configure --sysconfdir=/etc/jabberd --enable-mysql --enable-mio=epoll --enable-debug --enable-ssl --with-zlib --disable-experimental --enable-superseded In SM the following is logged (one particular user is chosen): Sun Dec 21 14:00:38 2014 [notice] session started: jid=xadvente...@jabber.no-sense.net/WippienIM3 Sun Dec 21 14:00:39 2014 [notice] session ended: jid=xadvente...@jabber.no-sense.net/WippienIM3 Sun Dec 21 14:00:39 2014 [notice] user unloaded jid=xadvente...@jabber.no-sense.net So it seems the session is started but ended at the same second. in c2s, with debugging on, I see the following: [.] Sun Dec 21 14:00:38 2014 [notice] [20] [IP removed, port=63359] connect Sun Dec 21 14:00:38 2014 c2s.c:37 want read Sun Dec 21 14:00:38 2014 c2s.c:547 read action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:47 reading from 20 Sun Dec 21 14:00:38 2014 c2s.c:106 read 144 bytes Sun Dec 21 14:00:38 2014 ack.c:30 hacking ack namespace decl onto stream header Sun Dec 21 14:00:38 2014 c2s.c:42 want write Sun Dec 21 14:00:38 2014 c2s.c:561 write action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:144 writing to 20 Sun Dec 21 14:00:38 2014 c2s.c:148 253 bytes written Sun Dec 21 14:00:38 2014 bind.c:38 not auth'd, offering auth and register Sun Dec 21 14:00:38 2014 c2s.c:37 want read Sun Dec 21 14:00:38 2014 c2s.c:561 write action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:144 writing to 20 Sun Dec 21 14:00:38 2014 c2s.c:148 278 bytes written Sun Dec 21 14:00:38 2014 c2s.c:37 want read Sun Dec 21 14:00:38 2014 c2s.c:547 read action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:47 reading from 20 Sun Dec 21 14:00:38 2014 c2s.c:106 read 51 bytes Sun Dec 21 14:00:38 2014 c2s.c:42 want write Sun Dec 21 14:00:38 2014 c2s.c:561 write action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:144 writing to 20 Sun Dec 21 14:00:38 2014 c2s.c:148 50 bytes written Sun Dec 21 14:00:38 2014 c2s.c:37 want read Sun Dec 21 14:00:38 2014 c2s.c:37 want read Sun Dec 21 14:00:38 2014 c2s.c:547 read action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:47 reading from 20 Sun Dec 21 14:00:38 2014 c2s.c:106 read 124 bytes Sun Dec 21 14:00:38 2014 c2s.c:42 want write Sun Dec 21 14:00:38 2014 c2s.c:561 write action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:144 writing to 20 Sun Dec 21 14:00:38 2014 c2s.c:148 3626 bytes written Sun Dec 21 14:00:38 2014 c2s.c:37 want read Sun Dec 21 14:00:38 2014 c2s.c:547 read action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:47 reading from 20 Sun Dec 21 14:00:38 2014 c2s.c:106 read 326 bytes Sun Dec 21 14:00:38 2014 c2s.c:42 want write Sun Dec 21 14:00:38 2014 c2s.c:561 write action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:144 writing to 20 Sun Dec 21 14:00:38 2014 c2s.c:148 59 bytes written Sun Dec 21 14:00:38 2014 c2s.c:37 want read Sun Dec 21 14:00:38 2014 c2s.c:547 read action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:47 reading from 20 Sun Dec 21 14:00:38 2014 c2s.c:106 read 218 bytes Sun Dec 21 14:00:38 2014 ack.c:30 hacking ack namespace decl onto stream header Sun Dec 21 14:00:38 2014 c2s.c:42 want write Sun Dec 21 14:00:38 2014 c2s.c:561 write action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:144 writing to 20 Sun Dec 21 14:00:38 2014 c2s.c:148 330 bytes written Sun Dec 21 14:00:38 2014 bind.c:38 not auth'd, offering auth and register Sun Dec 21 14:00:38 2014 c2s.c:37 want read Sun Dec 21 14:00:38 2014 c2s.c:561 write action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:144 writing to 20 Sun Dec 21 14:00:38 2014 c2s.c:148 490 bytes written Sun Dec 21 14:00:38 2014 c2s.c:37 want read Sun Dec 21 14:00:38 2014 c2s.c:547 read action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:47 reading from 20 Sun Dec 21 14:00:38 2014 c2s.c:106 read 170 bytes Sun Dec 21 14:00:38 2014 main.c:437 sx sasl callback: get realm: realm is 'jabber.no-sense.net' Sun Dec 21 14:00:38 2014 main.c:456 sx sasl callback: check pass (authnid=xadventerur, realm=jabber.no-sense.net) Sun Dec 21 14:00:38 2014 authreg_mysql.c:109 prepared sql: SELECT `password` FROM `authreg` WHERE `username` = 'xadventerur' AND `realm` = 'jabber.no-sense.net' Sun Dec 21 14:00:38 2014 c2s.c:42 want write Sun Dec 21 14:00:38 2014 c2s.c:561 write action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:144 writing to 20 Sun Dec 21 14:00:38 2014 c2s.c:148 122 bytes written Sun Dec 21 14:00:38 2014 c2s.c:37 want read Sun Dec 21 14:00:38 2014 c2s.c:37 want read Sun Dec 21 14:00:38 2014 c2s.c:547 read action on fd 20 Sun Dec 21 14:00:38 2014 c2s.c:47
Re: s2s: timed out dns lookups
Guido, This looks like a problem with your system, not your jabber setup. What happens is simple, udns is trying to resolve the hostnames but this takes too long. From the jabberd2 source code I can see that the timeout is set to 5 seconds. The fact you didnt see it with jabberd 1.4 is most likely that it does not have a timeout and will wait forever. My suspicion is that there is a problem with a name server you are using. if you look at the file /etc/resolv.conf you will see one or more lines saying nameserver ip_addr. The resolver will ask each name server in turn to resolve the host name for it, switching to the next one if it does not respond. My guess is that the first name server in your list does not respond or does not respond in time and the timeout occurs. There are several things you can try: First, check if the resolve really takes so long. Do the dig command again but add time in front of it: prompt$ time dig -t any _xmpp-server._tcp.jabber.org This works on unix-like operating systems only I think. In my case (I run a name server locally) it responded with: eric@polaris:~$ dig -t any _xmpp-server._tcp.jabber.org ; DiG 9.8.1-P1 -t any _xmpp-server._tcp.jabber.org ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 46367 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 0 [..] ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Dec 28 08:11:52 2013 ;; MSG SIZE rcvd: 225 real0m0.007s user0m0.000s sys0m0.004s As you can see it took 7 millisec, well within the timeout. If you see times of several seconds or more you have found your problem. Also try other sites like dig jabber.ccc.de etc. If this is the problem, here are some ideas on how to fix: Use a different nameserver as first in /etc/resolve.conf. If you do not have another nameserver try nameserver 8.8.8.8 instead (Google's public name server) Set up your own name service (actually not that hard to do) and set the first nameserver line to nameserver 127.0.0.1. This will usually give the best results (as long as the name server is configured correctly) If you cannot improve your nameserver you can try to increase the timeout. For that you need to edit the file s2s/main.c. Somewhere there is a line saying something like: mio_run(s2s-mio, dns_timeouts(0, 5, time(NULL))); The 5 is the number of seconds the resolver will wait... Increase it and see what happens. Of course fixing the resolver is better, long waits for a resolver will be noticed by your users. Regards, Eric. On 12/27/2013 10:41 PM, Guido Winkelmann wrote: Hi, I've recently switched from jabberd14 (yeah, I know...) to jabberd2, and I'm having trouble with s2s timing out a lot on trying to resolve the names of other Jabber servers from contacts on my roster. I'm getting a lot of lines like these in /var/log/messages: Dec 27 22:15:21 blish jabberd/s2s[20464]: dns lookup for jabber.ccc.de timed out Dec 27 22:15:22 blish jabberd/s2s[20464]: dns lookup for freistaat-linden.de timed out Dec 27 22:15:22 blish jabberd/s2s[20464]: dns lookup for arara.de timed out Dec 27 22:15:22 blish jabberd/s2s[20464]: dns lookup for jabber.org timed out Sometimes, but rarely, the lookup for a server works and I can see the online status of a contact or two, but most of the time, most of my roster is crossed out as unreachable. Manual lookup of these names with, for example dig -t any _xmpp-server._tcp.jabber.org works with no problems. I'm using jabberd2 2.3.1 on Gentoo, installed from portage, and udns 0.2, both compiled with GCC 4.7.3. The problem also exists with udns 0.1 and GCC 4.5.4, though. Does anyone have any idea what might be the problem here? Guido
Re: s2s: timed out dns lookups
Guido, Does your server have IPv6 connectivity? If not try to edit resolver.xml and comment out the line saying ipv6/. I do not know for sure if it's your problem but it has given me similar connectivity issues in the past. Also from your log I see that not an answer but an error is returned: NXDomain means the nameserver reported that the requested domain does not exist. I have no idea why it would report that but maybe it's something like the Google DNS has some throttling, not allowing more than a certain amount of requests per second or something similar. Another possibility is a firewall issue. DNS uses UDP port 53 normally but it switches to TCP port 53 when the amount of information to transfer becomes larger. It might be possible that TCP port 53 is blocked while UDP port 53 is still open. It's a long shot but worth looking into. I think you should install a nameserver like bind. All Linux distros I know (assuming you're running a Linux variant) offer bind and in almost all of them the caching nameserver is the default setting (so you won't need to configure anything to make it work). All you need to do is add nameserver 127.0.0.1 before all other nameserver lines in your /etc/resolv.conf and my guess is that you will not be troubled by timeouts any more. Regards, Eric. Also what I see is that On 28-Dec-13 14:23, Guido Winkelmann wrote: Am Samstag, 28. Dezember 2013, 11:05:33 schrieb Tomasz Sterna: Dnia 2013-12-28, sob o godzinie 09:10 +0100, Eric Koldeweij pisze: My suspicion is that there is a problem with a name server you are using. if you look at the file /etc/resolv.conf you will see one or more lines saying nameserver ip_addr. The resolver will ask each name server in turn to resolve the host name for it, I second that. This is what immediately came to my mind as a probable answer to your issue. No, this is not it. My /etc/resolv.conf contains only one line, and it is nameserver 8.8.8.8 Both dig and host can use this nameserver to resolve the names in question with very little delay: $ time host -t SRV _xmpp-server._tcp.jabber.org. 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: _xmpp-server._tcp.jabber.org has SRV record 30 30 5269 hermes2.jabber.org. _xmpp-server._tcp.jabber.org has SRV record 31 30 5269 hermes2v6.jabber.org. real0m0.034s user0m0.000s sys 0m0.020s $ time host -t SRV _xmpp-server._tcp.jabber.ccc.de. 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: _xmpp-server._tcp.jabber.ccc.de has SRV record 5 0 5269 jabberd.jabber.ccc.de. real0m0.034s user0m0.000s sys 0m0.020s $ time dig -t srv _xmpp-server._tcp.jabber.org. ; DiG 9.9.3-P2 -t srv _xmpp-server._tcp.jabber.org. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 28840 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;_xmpp-server._tcp.jabber.org. IN SRV ;; ANSWER SECTION: _xmpp-server._tcp.jabber.org. 247 INSRV 30 30 5269 hermes2.jabber.org. _xmpp-server._tcp.jabber.org. 247 INSRV 31 30 5269 hermes2v6.jabber.org. ;; Query time: 10 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Dec 28 14:07:01 CET 2013 ;; MSG SIZE rcvd: 135 real0m0.035s user0m0.020s sys 0m0.000s dig command works independently of stub resolver in your system and is more of a DNS servers test tool, not your system setup test tool. Take a look at each of your 'nameserver' line in /etc/resolv.conf and check each server first pinging it, then asking directly: host -t SRV _xmpp-server._tcp.jabber.org. dns.server.ip.123 See above, resolving these names with either dig or host works fine, using the nameserver from /etc/resolv.conf I just ran tcpdump while restarting jabberd, this is what I saw (excerpt): 14:19:06.638847 IP 62.48.88.30.47380 8.8.8.8.domain: 35840+ [1au] SRV? _xmpp-server._tcp.jabber.org. (57) 14:19:06.644226 IP 62.48.88.30.47380 8.8.8.8.domain: 32182+ [1au] SRV? _xmpp-server._tcp.jabber.eof.name. (62) 14:19:06.646615 IP 62.48.88.30.47380 8.8.8.8.domain: 34426+ [1au] SRV? _xmpp-server._tcp.freistaat-linden.de. (66) 14:19:06.648101 IP 8.8.8.8.domain 62.48.88.30.47380: 35840 2/0/1 SRV hermes2v6.jabber.org.:5269 31 30, SRV hermes2.jabber.org.:5269 30 30 (135) 14:19:06.654613 IP 8.8.8.8.domain 62.48.88.30.47380: 32182 NXDomain 0/1/1 (119) So there is an answer at least for one of the requests (jabber.org), but jabberd2 still says Dec 28 14:21:02 blish jabberd/s2s[14802]: dns lookup for jabber.org timed out in its logs. Guido Guido
Re: s2s: timed out dns lookups
Guido, I forgot one thing: For the IPv6 thing you should also edit s2s.xml and comment out the line resolve-ipv6/ if it isn't commented out already. Sorry. Regards, Eric. On 28-Dec-13 15:59, Eric Koldeweij wrote: Guido, Does your server have IPv6 connectivity? If not try to edit resolver.xml and comment out the line saying ipv6/. I do not know for sure if it's your problem but it has given me similar connectivity issues in the past. Also from your log I see that not an answer but an error is returned: NXDomain means the nameserver reported that the requested domain does not exist. I have no idea why it would report that but maybe it's something like the Google DNS has some throttling, not allowing more than a certain amount of requests per second or something similar. Another possibility is a firewall issue. DNS uses UDP port 53 normally but it switches to TCP port 53 when the amount of information to transfer becomes larger. It might be possible that TCP port 53 is blocked while UDP port 53 is still open. It's a long shot but worth looking into. I think you should install a nameserver like bind. All Linux distros I know (assuming you're running a Linux variant) offer bind and in almost all of them the caching nameserver is the default setting (so you won't need to configure anything to make it work). All you need to do is add nameserver 127.0.0.1 before all other nameserver lines in your /etc/resolv.conf and my guess is that you will not be troubled by timeouts any more. Regards, Eric. Also what I see is that On 28-Dec-13 14:23, Guido Winkelmann wrote: Am Samstag, 28. Dezember 2013, 11:05:33 schrieb Tomasz Sterna: Dnia 2013-12-28, sob o godzinie 09:10 +0100, Eric Koldeweij pisze: My suspicion is that there is a problem with a name server you are using. if you look at the file /etc/resolv.conf you will see one or more lines saying nameserver ip_addr. The resolver will ask each name server in turn to resolve the host name for it, I second that. This is what immediately came to my mind as a probable answer to your issue. No, this is not it. My /etc/resolv.conf contains only one line, and it is nameserver 8.8.8.8 Both dig and host can use this nameserver to resolve the names in question with very little delay: $ time host -t SRV _xmpp-server._tcp.jabber.org. 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: _xmpp-server._tcp.jabber.org has SRV record 30 30 5269 hermes2.jabber.org. _xmpp-server._tcp.jabber.org has SRV record 31 30 5269 hermes2v6.jabber.org. real0m0.034s user0m0.000s sys 0m0.020s $ time host -t SRV _xmpp-server._tcp.jabber.ccc.de. 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: _xmpp-server._tcp.jabber.ccc.de has SRV record 5 0 5269 jabberd.jabber.ccc.de. real0m0.034s user0m0.000s sys 0m0.020s $ time dig -t srv _xmpp-server._tcp.jabber.org. ; DiG 9.9.3-P2 -t srv _xmpp-server._tcp.jabber.org. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 28840 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;_xmpp-server._tcp.jabber.org. IN SRV ;; ANSWER SECTION: _xmpp-server._tcp.jabber.org. 247 INSRV 30 30 5269 hermes2.jabber.org. _xmpp-server._tcp.jabber.org. 247 INSRV 31 30 5269 hermes2v6.jabber.org. ;; Query time: 10 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Dec 28 14:07:01 CET 2013 ;; MSG SIZE rcvd: 135 real0m0.035s user0m0.020s sys 0m0.000s dig command works independently of stub resolver in your system and is more of a DNS servers test tool, not your system setup test tool. Take a look at each of your 'nameserver' line in /etc/resolv.conf and check each server first pinging it, then asking directly: host -t SRV _xmpp-server._tcp.jabber.org. dns.server.ip.123 See above, resolving these names with either dig or host works fine, using the nameserver from /etc/resolv.conf I just ran tcpdump while restarting jabberd, this is what I saw (excerpt): 14:19:06.638847 IP 62.48.88.30.47380 8.8.8.8.domain: 35840+ [1au] SRV? _xmpp-server._tcp.jabber.org. (57) 14:19:06.644226 IP 62.48.88.30.47380 8.8.8.8.domain: 32182+ [1au] SRV? _xmpp-server._tcp.jabber.eof.name. (62) 14:19:06.646615 IP 62.48.88.30.47380 8.8.8.8.domain: 34426+ [1au] SRV? _xmpp-server._tcp.freistaat-linden.de. (66) 14:19:06.648101 IP 8.8.8.8.domain 62.48.88.30.47380: 35840 2/0/1 SRV hermes2v6.jabber.org.:5269 31 30, SRV hermes2.jabber.org.:5269 30 30 (135) 14:19:06.654613 IP 8.8.8.8.domain 62.48.88.30.47380: 32182 NXDomain 0/1/1 (119) So there is an answer at least for one of the requests (jabber.org), but jabberd2 still says Dec 28 14:21:02 blish jabberd/s2s[14802]: dns lookup for jabber.org timed out in its logs. Guido Guido
Re: jabberd-2.3.0 release
Christof, I had the same problem, luckily I ran on a test server. I could not even login with my client. There has been a change in sx/ssl.c line 899. The line now reads ctx = SSL_CTX_new(TLSv1_2_method()); This means that it will support TLS v1.2 only. Connections using SSLv3 or TLS v1.1 and earlier are not accepted any more. There is also another issue that if a secure connection cannot be established for any reason (incompatible protocol or verification failed or similar) it will retry many times in very rapid succession for 10 minutes. You can get the old behavior back by changing the line above back to the 2.2.17 version: ctx = SSL_CTX_new(SSLv23_method()); I think a better solution would be to use the SSLv23_method and disable SSLv3 with an option immediately after: SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3); I have not tested this yet but as far as I can see it will leave you with support for TLS v1.0, v1.1 and v1.2. An even better solution would be to make the SSL settings user-configurable. This is not trivial to do though. Regards, Eric. On 11/26/13 07:40, Christof Meerwald wrote: On Mon, 18 Nov 2013 17:18:07 +0100, Tomasz Sterna wrote: Next jabberd2 release is finally available. Get 2.3.0 release at GitHub: https://github.com/jabberd2/jabberd2/releases I tried upgrading from 2.2.17 to 2.3.0 yesterday, but that left me with a broken server. The s2s component now just connects to a remote server, switches the stream to TLS, gets the certificate, disconnects and immediately connects again. The log file doesn't give any reason for this connection/disconnection loop and it's not clear what configuration settings need to be updated to make it work again (as the NEWS file isn't that helpful). But as there is no delay between the connects/disconnects (and no useful error message), this behaviour might be considered a bug anyway... Guess I'll have to do some debugging and code reviewing in the next few days... Christof
Re: XMPP connections
Hello, A typical XMPP server will open only one port, port 5222. All clients will connect to that port so in theory an almost unlimited number of connections are possible to that server. This is not particular to XMPP but is a basic TCP/IP client/server feature, exactly the same goes for other services for instance a web server. The 65536 port limit is a client limit, not a server limit. A client can not have more than 65536 connections open to any other host at the same time (65536 is theoretical, in reality this number will be much lower). Regards, Eric. On 11/26/13 11:41, Haider Ali wrote: Hi Everyone Can anyone let me know that how XMPP handle so many connections. Since we know that we can only open 2 ^ 16 = 65536 ports ( connections ) with a single machine. But i came to know that single xmpp server can handle more connections than 65536.
mod-status entering wrong values in status
Tomasz and others,
I'm using jabberd2 v2.2.17. For a while now I have experienced strange
values in the status database table for some users, including myself.
The most obvious problem is that the status field can show online even
if the user is offline and last-login and last-logout are both zero.
I have done some debugging and I found what is causing it. This problem
occurs if the user has the server itself added to his/her roster. I am
running jabberd2 on jabber.no-sense.net and when I add
jabber.no-sense.net as Agent/Transport to my roster the problem starts
occurring. I have traced the problem to mod_status handling a presence
status which it should ignore, it thinks a presence message from sm
itself to jabber.no-sense.net (announcing to the agent that the user
is present) is mistakenly handled as a presence packet from another server.
This is what the packet looks like:
route xmlns='http://jabberd.jabberstudio.org/ns/component/1.0'
from='sm' to='jabber.no-sense.net'presence xmlns='jabber:client'
to='jabber.no-sense.net' from='ara...@jabber.no-sense.net/Psi+'
priority50/priority
c xmlns='http://jabber.org/protocol/caps' ext='cs e-time ep-notify-2
html last-act mr sxe whiteboard' ver='0.15'
node='http://psi-dev.googlecode.com/caps'/
/presence/route
This will be caught by mod_status in function _status_pkt_sm(). This
function only checks whether it's a presence packet and not where it
originated from. It is a presence packet and therefore the status for
the user will always be set to online and the login times to zero.
I have made a quick fix by changing mod_status.c:195 :
if((pkt-type == pkt_PRESENCE || pkt-type == pkt_PRESENCE_UN)) {
into
if((pkt-type == pkt_PRESENCE || pkt-type == pkt_PRESENCE_UN)
strcmp(jid_full(pkt-rfrom), sm) != 0)
but I doubt if this is acceptable as real fix.
Does someone have a better idea? Thanks in advance!
Regards,
Eric.
Re: no SASL backend available out of: gsasl
Niamh Having no further information, it looks to me that you might have a too old version of gsasl... checking for gsasl_check_version in -lgsasl... yes This line says it can find gsasl and its library. checking for GnuSASL version= 0.2.27... no This line says it fails the version check. Do you have GSASL 0.2.27 or later installed? What does config.log say about it? Regards, Eric. On 10/25/13 15:10, Niamh Holding wrote: Hello Tomasz, Friday, October 25, 2013, 1:08:38 PM, you wrote: TS Try: TS ./configure --with-extra-library-path=/usr/local/lib Makes no difference checking for gsasl.h... yes checking for gsasl_check_version in -lgsasl... yes checking for GnuSASL version= 0.2.27... no configure: error: no SASL backend available out of: gsasl ../conftest: error while loading shared libraries: libgsasl.so.7: cannot open shared object file: No such file or directory
