Some users cannot connect after upgrade from 2.2.17 to 2.3.2

2014-12-21 Thread Eric Koldeweij

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

2013-12-28 Thread Eric Koldeweij

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

2013-12-28 Thread Eric Koldeweij

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

2013-12-28 Thread Eric Koldeweij

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

2013-11-26 Thread Eric Koldeweij

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

2013-11-26 Thread Eric Koldeweij

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

2013-11-01 Thread Eric Koldeweij

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

2013-10-25 Thread Eric Koldeweij

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









Re: no SASL backend available out of: gsasl

2013-10-25 Thread Eric Koldeweij

Niamh,

Is it possible that the library in /usr/local/lib incompatible is with 
your build?

For instance a 32-bit library on a 64-bit system?

Regards,
Eric.

On 10/25/13 16:12, Niamh Holding wrote:


Hello Eric,

Friday, October 25, 2013, 2:32:53 PM, you wrote:

EK  Having no further information, it looks to me that you might have a too
EK  old version of gsasl...

  gsasl --version
gsasl (GNU SASL) 1.8.0
Copyright (C) 2012 Simon Josefsson.
License GPLv3+: GNU GPL version 3 or laterhttp://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Simon Josefsson.

EK  What does config.log say about it?

As the rooot message said-

../conftest: error while loading shared libraries: libgsasl.so.7: cannot open 
shared object file: No such file or directory