Last Activity returns 0 seconds for unavailable sessions

[hhravn]

What version of ejabberd are you using?

18.01

What operating system (version) are you using?

Debian GNU/Linux 8 (jessie)

How did you install ejabberd (source, package, distribution)?

package

What did not work as expected? Are there error messages in the log? What
was the unexpected behaviour? What was the expected result?

I recently upgraded from 16.09 to 18.01, and now XEP-0012 returns 0 seconds even for a session that has been set to unavailable, e.g.

$ejabberdctl user_sessions_info 5a701b0e952602000f9fb3d2 domain.com
websocket	172.21.0.1	46758	undefined	ejabberd@localhost	8	unavailable	react-native-xmpp-client

The moment i kick the user, XEP-0012 will start correctly returning the last time any activity was seen from the user.

[hhravn]

Ok, as far as i can figure out, i end up about here;

ejabberd/src/mod_last.erl

Line 226 in 4b012a9

xmpp:make_iq_result(IQ, #last{seconds = 0})

Which means that the user has resources that are not offline. What exactly does it take for a resource (session?) to be offline? I noticed that setting priority < 0 results in get_presence returning nil for priority after we upgraded.

[badlop]

a session that has been set to unavailable

And why do you set presence to Unavailable, but still keep the XMPP session alive?

When i tell my client to logout, it sends presence to unavailable, and closes the immediately the XMPP session:

<presence type='unavailable'>
  <priority>8</priority>
  <status>testing the disconnection reason22</status>
</presence>

[hhravn]

We're connecting from an app, and leave our websocket open when the app goes to the background, indicating that we're offline by setting presence=unavailable, priority=-1. By not disconnecting the session entirely, we reuse it by setting presence=available, priority=1 if the socket is still intact when we come back from the background. This worked fine on 16.09, and 'last seen' returned time since session was set to unavailable.

Do you have a suggestion for a better strategy? Should we simply disconnect entirely when going to the background?

[badlop]

Sending a "presence=unavailable" is a graceful presence broadcasted to the contacts [1], but ejabberd does not unbind the resource from the stream, so it doesn't close the session, nor closes the stream. That's why, in the code you referenced, if there's any resource, whatever its kind, the user is considered to be online.

Is that the expected behavior according to the protocols, or is a bug in ejabberd? Sorry, I don't know. Also I don't know if there's a more recomended way for you to achieve what you want.

Let's see if somebody else can help here.
[1] https://tools.ietf.org/html/rfc6121#section-4.5.1
[2] https://tools.ietf.org/html/rfc6120#section-7

[hhravn]

I guess i always just assumed that the semantics were the same as in mod_offline, in that priority <= 0 would mean that the session is offline ;)

The XEP was not entirely clear to me in its wording before;

If the user has at least one connected or available resource when the server receives the request, the response MUST (subject to local security policies) contain an empty element whose 'seconds' attribute is set to a value of '0'.

but reading it again, i reckon it means that if the session (socket in this case) is alive the server must return seconds=0, even if type=unavailable. On the other hand, if type=available the server must return seconds=0 even if the session (socket in this case) is not really connected.

Anyways, thanks for having a look at it. I guess i'll see if someone has anything to add in the next few days and, if not, apply the workaround of disconnecting the session entirely, even when the app is only left momentarily.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.