powered by Jive Software

Omemo message session with second new omemoDevice of same user failed

In my previous omemo message testing, After few attempts, I am able to setup omemo sessions between the following two clients without problem.

  1. aTalk (leopard@atalk.org) installed on Note3

  2. conversions (swan@atalk.org) installed on S3

Note: aTalk implements "Blind Trust on First Use: .

After that, I shut down conversions client; then installed a new aTalk client on S3 but with the same user account swan@atalk.org; I am facing the following problems: I found that the new omemDevice created on S3 for swan@talk.org is not being detected by leopard@atalk.org. Omemo session always failed and the encrypted messages sent from either party contains no for the recipient to decrypt the message

07-16 22:14:10.377 D/SMACK: SENT (0): I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo7b1b20ee-d17a-492d-bda7-af000665730734VVCnDGEZ3KlWsXUwr94Q==XMGZWQ==</p ayload>

The try/catch loop for

mOmemoManager.encrypt(bareJid, “Hi buddy!”);

always return success since it only tests for bareJid instead of new omemoDevice for swan@atalk.org.

fingerPrints = mOmemoManager.getActiveFingerprints(bareJid);

always returns only one fingerprint i.e. the previously created omemoDevice when conversations client is first installed. I checked the database, and found there is NO new omemoDevice created for the new aTalk-swan account.

Appreciate if someone can clarify the following:

I see that when S3-atalk startup, it does publish its omemoDevice information to the server. However there is no publish notification get sent to leopard@atalk.org Note3.

a. Is there some missing entityCapability feature that needs to be advertised by atalk client, before the new omemDevice notification is relayed to it.

Not sure if it is necessary, but I have added the feature to the aTalk entityCapability i.e. OmemoConstants.PEP_NODE_BUNDLES + NOTIFY

b. Or omemo protocol uses a different method to fetch the new identify, and what is the process?

c. Or the same user account can have only one omemoDevice defined?

d. Is there some routines that aTalk needs to implement to resolve this issue?

Continue the testing where I left off. Based on aTalk SQLite database and xmpp ejabberd server (XES) database information, I redefined the omemoDevices and named each as below for ease of discussion.

  1. NA36: aTalk (leopard@atalk.org) installed on Note3; omemoDevice (leopard@atalk.org, 1011347036)

  2. SC37: conversions (swan@atalk.org) installed on S3; omemoDevice (swan@atalk.org, 816614937)

  3. SA35: aTalk (swan@atalk.org) installed on S3; omemoDevice (swan@atalk.org, 1711246335)

With SA35 active, I found that the publish_item on XES db deviceList contains only the SA35 own omemDevice ID.

I do not know why SC37 omemoDevice ID is missing. Some how SA35 overwritten the deviceList on XEP with only its own ID.

Exit SA35 and restart SC37 client:

Observed the following was received by NA36.

07-17 16:56:16.275 D/SMACK: RECV (0):

However I checked and see that there is no change to the NA36 identities table; It still contains only SC37 single entry. No sure why NA36 does not fetch and save the SA35 omemoDevice info in its identities table on received the event. XEP database already has all the SA35 defined in the database.

Check on XEP, its publish_item deviceList now contains both the omemDevices i.e. SC37 and SA35:

Exit SC37 and restart SA35:

SA35 sent the omemo bundle data but with response timeout

============ SA35 log ==============

07-17 17:12:28.560 D/SMACK: SENT (0): BSnb5U5LfsRclhInPggIBSkDzzXKGN4KR53pHaS1BxkC</signedPreKeyPu blic>d588c51cjsjBYnvHFERfdcH+ehm2LvCdUH266mM9C1dB1H8cDjR8 Siz75Y5huPTAyDG1Ja/xpUlWCLyHD5plDQ==BUwtBjE W56yMH+2NuWD861F8QxoGJIR3zGCIzjAFDesEBRMihW/mUsxJ9wVK0CnY7ex6CJlFLpWT7Pe7AEi/ElYnBWksRfURixEDVmovfOU3ZGvF8RDXZpgs74kEfCG9wIofBTtdxBtETfVvAaU1uMx7uyAkm83GGT3Fr5/oH55SSL9ZBY+e0mGHPd1GuURjh/1y3f09ZsYUY4WZHbzxQmyVw6M8Bfny1WcC8UeuQHZ1HgPTWVFWN9lGETSL9XjeXUx8fDo2Baj6PslEyRa86NbZYC5Ui

07-17 17:12:28.560 D/SMACK: SENT (0):

07-17 17:12:30.725 E/αTalk: [4] org.jivesoftware.smackx.omemo.OmemoManager.authenticated() connectionListener.authenticated() failed to initialize OmemoManager: No response received within reply timeout. Timeout was 5000ms (~5s). Waited for response using: IQReplyFilter: iqAndIdFilter (AndFilter: (OrFilter: (IQTypeFilter: type=error, IQTypeFilter: type=result), StanzaIdFilter: id=FQLaH-132)), : fromFilter (OrFilter: (FromMatchesFilter (full): swan@atalk.org, FromMatchesFilter (full): null)).

07-17 17:12:30.735 D/SMACK: XMPPConnection authenticated (XMPPTCPConnection[swan@atalk.org/atalk] (0))

07-17 17:12:38.340 D/SMACK: RECV (0):

==== End of log ===========

Following message deviceList was received by SA35 from XEP

On NA36:

There is no …

being received.

So SA35 behaves different as compare to SC37 in this respect. Not sure if this due to response timeout for id=FQLaH-132?

=== new findings =====

Look like the response timeout is not the cause of the problem. I set the smack setDefaultReplyTimeout to 20 seconds globally


Although the reply timeout is temporary fixed, but still experiencing the exact same problem as before while setting up omemoSession between NA36 and SA35,

There is no change to the stored data on all Omem0Device devices and XEP. Also there is no deviceList event message being sent to NA36.

On XEP database, one thing I observed in the publish_item table, the publisher is specified as swan@atalk.org/phone i.e. resource ‘phone’. Whereas the resource for SA35 is swan@atalk.org/atalk. Just wonder what is the effect of the differences in resources for SA35 and SC37.

OR because SA35 did not ‘update’ the device list hence no event message is sent to NA36 by XEP?

Need further testing and investigation

See comments on

Smack OmemoService#subscribeToDeviceLists & #registerDeviceListListener happen too late to listen for PEPEvent to take actions