Sudden OMEMO errors

Support
1

A few weeks ago, I migrated all of my users from OTR to OMEMO. Everything went smoothly but today suddenly I began to get

There was an error decrypting an OMEMO message addressed to this device. See the debug log for details.

from one client that is getting my messages fine. This is in the debug window (numbers masked with # and text masked with periods):

(18:17:45) xmlnode: XML parser error for xmlnode 0x55a5fec21c90: Domain 3, code 100, level 1: xmlns: URI eu.siacs.conversations.axolotl is not absolute
(18:17:45) jabber: Sending (ssl) (~~~~~~@domain.com/PidginLinuxPC): 
<message type='chat' id='purple3bd8fc4e' to='^^^^^@domain.com'>
<active xmlns='http://jabber.org/protocol/chatstates'/>
<encrypted xmlns='eu.siacs.conversations.axolotl'>
<header sid='116#####42'>
<key rid='743671112'>Mw......sQXg1.......2Dm/rR.....2Nm/R.....d.........a........g.......Q.zedA5ji7/qC.R............................................................................................................HsMFMG/SIcP3....................................EMAA=</key>
<key rid='12######12'>MwhKE....................................................................A5ji7/qCm...........................................................................................hqorP/3wnc.............................XIN/Lvs....................EMAA=</key>
<key rid='627####00'>M....e/w...T/ZKi.........................................................................................bLfQ/1yv...............6h4=</key>
<key rid='160#####48'>MwgdEiEF............................................IQUMJ5x4gf6JUEWIQ9zedA5ji7/qCmR.............................................................................1kE/Ih...n/1F.................................................................QwAA==</key>
<key rid='185#####79'>MwohBT................................................................TO8l/jZj.........Zs/6j/Dq........N//Go...................gGfk=</key>
<iv>5fl..........WOQ</iv>
</header>
<payload>z5FDaw==</payload>
</encrypted>
<encryption xmlns='urn:xmpp:eme:0' namespace='eu.siacs.conversations.axolotl' name='OMEMO'/>
<store xmlns='urn:xmpp:hints'/>
</message>

I tested with other clients and it works fine in both directions.

The only change was that my machine was reimaged from backup after a few hours of downtime due to hardware migration.

2

What should I change in Pidgin/Lurch to restore service with that user?

3

Any ideas as to why out of many Pidgins of the same version only one fails to communicate?

4

I wish I had some suggestions for you, but unfortunately I don’t.

When it comes to same versions not and one not working, that would usually suggest a configuration issue, but I’m not well versed enough with lurch to make any guesses.

5

Lurch does not have configuration

6

Well there has to be some soft of device management. I think it’s done via commands but I’m not sure. Is it possible a device key cycled or something between the time your backup happened and you restored it?

7

I have no way of knowing any of that.
Are you totally opposed to an idea of adding Lurch, enabling it and checking out how it works?

8

I looked at the code, it’s configured via the commands in the conversations.

As for me “checking out how it works” I’d need to find someone else to test it with which is harder to arrange.

Even then I’m willing to bet I’m not going to be able to reproduce your problem of having a working config going bad.

But at any rate, best I can tell is that you provide the debug log for a working setup and not from the one that failed. As the message stated, there is most likely more information in the debug log where a message failed. Just remember to open the debug log before sending a message.

9

Usually a VM is used for such testing.

10

Sure that could be an option too, but you’re asking me to do a ton of work to solve your issue when you haven’t even provided the debug logs for your failure case. So excuse me if I’m a bit hesitant to sink any more time into this then I already have…

11

Both not true:
Debug logs are above, scroll up.
I am not asking you anything.

12

OMEMO is crap.
Another device broke down today, in the same exact fashion.
At least, with OTR, sessions could be restored, even though it required micro-management. This next best thing OMEMO just does not work, no matter what, and there seems to be no way to restore BAU. This is the definition of crap.

13

One after another, users with OMEMO report breakdown of communication.
Random intervals of time later, since they had enabled OMEMO, it stops working. Either OMEMO is malware or its programming is junk. Reverting to OTR.