[profanity] Autoping response timed out

DebXWoody stefan+xmpp at debxwoody.de
Sat Apr 18 15:44:04 CEST 2020


Hello,

with one of my accounts I have had an issue with profanity. After connection with
the XMPP Server, profanity started to join the autojoin MUCs. Everting was fine.
Few seconds later, there was a message "Lost connection" and profanity started
to reconnected. See Issue "Autoping response timed out - Lost connection" #1315
[1].

I changed some code and started to look into this issue. There was no disconnect
/ connection problem. It was just because of a very big OMEMO Device List of
another XMPP account.

The response of the device list takes 2min and the autojoin timeout is 20 sec.
See [2].

Anyway, there is a second issue. This xmpp account with the big OMEMO device
list, is not in by roster. I'm just in anonymous MUCS, but I'm owner or moderator
in some of those MUCs.

It seems that there is a Request of OMEMO Devices, of all members within a MUC,
when you are able to see the JIDs of the members. Profanity will request all
OMEMO devices and keys.

I think there is no need and it also doesn't make senses to do this. I recommend
to skip this for anonymous MUCs. This will not solve the issue with the big
device list, but I will save traffic and resources and the issue may not occurs, if
the account is not in your contact list.

For this fix, I create a PR [3]. Maybe the author of OMEMO code can review the PR.

diff --git a/src/xmpp/muc.c b/src/xmpp/muc.c
index 1cc48b31..172bdb80 100644
--- a/src/xmpp/muc.c
+++ b/src/xmpp/muc.c
@@ -885,11 +885,13 @@ muc_members_add(const char *const room, const char *const jid)
     if (chat_room) {
         if (g_hash_table_insert(chat_room->members, strdup(jid), NULL)) {
 #ifdef HAVE_OMEMO
-            Jid *our_jid = jid_create(connection_get_fulljid());
-            if (strcmp(jid, our_jid->barejid) != 0) {
-                omemo_start_session(jid);
+            if(chat_room->anonymity_type == MUC_ANONYMITY_TYPE_NONANONYMOUS ) {
+                Jid *our_jid = jid_create(connection_get_fulljid());
+                if (strcmp(jid, our_jid->barejid) != 0) {
+                    omemo_start_session(jid);
+                }
+                jid_destroy(our_jid);
             }
-            jid_destroy(our_jid);
 #endif
         }
     }

During investigation I found some more issues. For example iq_handlers. This PR
[4] should be reviewed or just drop the PR (see later).

One example is here:
https://github.com/profanity-im/profanity/blob/master/src/xmpp/session.c#L216
The function is called session_disconnect.

216         iq_rooms_cache_clear();
217         iq_handlers_clear();
218 
219         connection_disconnect();
220         message_handlers_clear();
221 
222         connection_clear_data();
223         chat_sessions_clear();

iq_handlers_clear is removing the id_handlers from a hash_table: iq.c:253.

 250 void
 251 iq_handlers_clear()
 252 {
 253     if (id_handlers) {
 254         g_hash_table_remove_all(id_handlers);
 255         g_hash_table_destroy(id_handlers);
 256         id_handlers = NULL;
 257     }
 258 }

The disconnect isn't doing disconnecting directly, so we may not handle some
things during disconnecting.

I stopped investigating on this topic, because there is maybe a third problem
"chat closure on autoreconnect?" #1275 [5]. I think a reconnect is not like a
disconnect + connect. You may close everything for a disconnect. Maybe the user
could like to connect with another account. For reconnect you may keep the
context and just reconnect but not setup a new context (MUCs, dialog,...).

Maybe we should check, if in such case line 223 (chat_sessions_clear - see
above) is required for disconnect but maybe not for reconnect.

[1] https://github.com/profanity-im/profanity/issues/1315
[2] https://github.com/profanity-im/profanity/issues/1315#issuecomment-613533797
[3] https://github.com/profanity-im/profanity/pull/1318
[4] https://github.com/profanity-im/profanity/pull/1316
[5] https://github.com/profanity-im/profanity/issues/1275

-- 
Mit freundlichen Grüßen,
Stefan 
----------------------------------------------------------------------------
Diese E-Mail wurde mit GnuPG digital signiert:
Fingerabdruck: A602 F768 93F1 38B4 A8EF  DDD5 C2DC 916F 3575 1C24 
----------------------------------------------------------------------------
-------------- n�chster Teil --------------
Ein Dateianhang mit Bin�rdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigr��e  : 833 bytes
Beschreibung: nicht verf�gbar
URL         : <http://lists.notraces.net/pipermail/profanity/attachments/20200418/8a6a7494/attachment.sig>


More information about the profanity mailing list