Smack 4.2.1-beta2-SNAPSHOT: No response received within reply timeout even when reply is received well within the specified PacketReplyTimeout

I decided to trace back previous aTalk releases to see when the reply timeout problem occurred

  1. aTalk 0.8.1 to 0.8.4 - (smack 4.2.1-SNAPSHOT) muc setup work correctly without problem

  2. aTalk 0.8.5 - (smack 4.2.1-beta2-SNAPSHOT) muc setup work correctly without problem

  3. aTalk 0.8.6 - (smack 4.2.1-beta2-SNAPSHOT) muc reply timeout started

Checking on the change log, I really cannot see anything changes that can cause this problem. However I also realize that this is also the time at which I have updated the AS SDK which also shown up in debug log when aTalk starts (v0.8.6). Since the new SDK, I begin to see weird behavior during aTalk debug as reported in

https://issuetracker.google.com/issues/64425255

I now wonder the problem that I see are actually due to new AS SDK built.

===== aTalk start up with new SDK compiled code =========

08-17 07:14:45.490 I/MultiDex: VM with version 1.6.0 does not have multidex support

08-17 07:14:45.490 I/MultiDex: install

08-17 07:14:45.490 I/MultiDex: MultiDexExtractor.load(/data/app/org.atalk.android-2.apk, false)

08-17 07:14:45.500 I/MultiDex: Detected that extraction must be performed.

========================

Version: 0.8.6 - change log

Author: cmeng

Upload Date: 08/05/2017

  • Fix implementation error in denying OTR session setup request from buddy while OMEMO session is in progress

  • Implement XEP-0084 User Avatar publishing with reflection patch for Smack PepManager.publish to support old server

  • Harmonize operations between XEP-0084 User Avatar and XEP-0153 VCardAvatar for co-existence

  • When XEP-0084 is enabled, omit avatar hash in presence stanza VCardTempXUpdate x-extension

  • Sync main menu avatar display with user selected picture

  • Delay the auto software update version check on application start up

  • Remove all unused smiley java files from built

  • Remove large screen landscape contactList and chatFragment side-by-side support

What you really want to do is taking a thread dump while the situation is happening: How to make Java Thread Dump in Android? - Stack Overflow

That would most likely show the culprit.

Finally, I have found the root cause.

aTalk has implemented XEP-0084: User Avatar; if the option is enabled, then the vcard-temp:x:update" (XEP-0153) will be sent as

.in all the stanza including the muc join room stanza i.e. without element.

However reply from server will be in short-form, and looks like smack does not like to see a single element without the attribute. This results to a reply timeout exception thrown by smack.

// ============ aTalk with XEP-0084 option enabled ==============

08-17 06:43:45.790 D/SMACK: SENT (0):

08-17 06:43:45.880 D/SMACK: RECV (0):

================== //

If I enabled the full vcard-temp:x:update" (XEP-0153) together with elements in stanza when joining room, then smack works correctly as captured in the log below.

On seeing muc with hash, aTalk tries to retrieve the avatar from MUC. However smack throws an exception again as shown in the log below.

Setting vCards / Avatars for MUC rooms | ejabberd Docs

aTalk has implemented catch, bus seems it is not captured???

try {
mVCard = vCardMgr.loadVCard((EntityBareJid) userId);
}
catch (SmackException.NoResponseException | XMPPException.XMPPErrorException
| SmackException.NotConnectedException | InterruptedException e) {
LOGGER.log(Level.WARNING, “Error while downloading VCard for: '” + userId

  • "’. Exception: " + e.getMessage());
    }

============= aTalk muc setup ================

08-17 17:35:51.418 D/SMACK: SENT (0): 186f39da130310dbc59002608c56d1bd26abd72d</ph oto>

08-17 17:35:51.468 D/SMACK: RECV (0): 186f39da130310dbc59002608c56d1bd26abd72d</ph oto>

08-17 17:35:51.468 D/SMACK: RECV (0):

08-17 17:35:51.478 D/SMACK: SENT (0):

08-17 17:35:51.478 D/SMACK: SENT (0):

08-17 17:35:51.488 D/SMACK: SENT (0): Group Chat

08-17 17:35:51.908 D/SMACK: RECV (0):

08-17 17:35:51.938 D/SMACK: RECV (0):

08-17 17:35:51.958 D/SMACK: RECV (0): Group Chat

08-17 17:35:52.008 E/αTalk: [15] util.UtilActivator.uncaughtException().95 An uncaught exception occurred in thread=Thread[Smack-Cached Executor 1 (0),5,main] and message was: XMPP error reply received from chatroom1234@conference.icrypto.com: XMPPError: item-not-found - cancel

                        org.jivesoftware.smack.XMPPException$XMPPErrorException: XMPP error reply received from chatroom1234@conference.icrypto.com: XMPPError: item-not-found - cancel

at org.jivesoftware.smack.StanzaCollector.nextResultOrThrow(StanzaCollector.java:2 56)

at org.jivesoftware.smack.StanzaCollector.nextResultOrThrow(StanzaCollector.java:2 08)

at org.jivesoftware.smackx.vcardtemp.VCardManager.loadVCard(VCardManager.java:133)

at org.jivesoftware.smackx.avatar.vcardavatar.VCardAvatarManager.downloadVCard(VCa rdAvatarManager.java:186)

at org.jivesoftware.smackx.avatar.vcardavatar.VCardAvatarManager.parseContactPhoto Presence(VCardAvatarManager.java:294)

at org.jivesoftware.smackx.avatar.vcardavatar.VCardAvatarManager.access$300(VCardA vatarManager.java:45)

at org.jivesoftware.smackx.avatar.vcardavatar.VCardAvatarManager$3.processStanza(V CardAvatarManager.java:163)

at org.jivesoftware.smack.AbstractXMPPConnection$4.run(AbstractXMPPConnection.java :1202)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1120)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)

at java.lang.Thread.run(Thread.java:820)

08-17 17:35:52.028 E/αTalk: [16] util.UtilActivator.uncaughtException().95 An uncaught exception occurred in thread=Thread[Smack-Single Threaded Executor 0 (0),5,main] and message was: Attempt to invoke interface method ‘boolean java.util.Iterator.hasNext()’ on a null object reference

java.lang.NullPointerException: Attempt to invoke interface method ‘boolean java.util.Iterator.hasNext()’ on a null object reference

at org.jivesoftware.smackx.muc.MultiUserChat$3.processStanza(MultiUserChat.java:25 2)

at org.jivesoftware.smack.AbstractXMPPConnection$5.run(AbstractXMPPConnection.java :1228)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1120)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)

at java.lang.Thread.run(Thread.java:820)

aTalk implements both the XEP-0084: User Avatar and XEP-0054: vcard-temp. aTalk still keeps XEP-0054 support so as to be able to receive avatar from client that only support XEP-0054. However I am not so sure what should I do with “vcard-temp:x:update” (cf. XEP-0153); so I just follow conversations implementation.

With the observed problem, I have changed aTalk to send when XEP-0084 is enabled. Not sure if this the correct implementation, or just completely remove XEP-0153 element when XEP-0084 is enabled. Any recommendation?

with the new implementation, no more reply timeout, but I still seeing smack throws exceptions as below. In aTalk version 0.8.5 I still received the event listener.joined(from); from MultiUserChat#presenceListener (need further investigation.)

08-17 21:51:42.849 E/αTalk: [15] util.UtilActivator.uncaughtException().95 An uncaught exception occurred in thread=Thread[Smack-Single Threaded Executor 0 (0),5,main] and message was: Attempt to invoke interface method ‘boolean java.util.Iterator.hasNext()’ on a null object reference

java.lang.NullPointerException: Attempt to invoke interface method ‘boolean java.util.Iterator.hasNext()’ on a null object reference

at org.jivesoftware.smackx.muc.MultiUserChat$3.processStanza(MultiUserChat.java:25 2)

at org.jivesoftware.smack.AbstractXMPPConnection$5.run(AbstractXMPPConnection.java :1228)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1120)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)

at java.lang.Thread.run(Thread.java:820)

After some thought, I decided to completely remove and not to send when XEP-0084 is enabled in aTalk implementation. Otherwise sending an empty element can cause some xmpp clients to remove the existing avatar; and may interfere with the normal XEP-0084 operation.

Just found out that ejabberd server will always send on user behalf in stanza if the user is not defined in XEP-0054. This causes jitsi-window to remove the avatar. So need to look again the optimized implementation. Look like has to go for full XEP-0153 implementation even when XEP-0084 is enabled.

Another instance where reply timeout happen even with correct reply was received within time.

While Sony XTS was in standby, it disconnected the xmpp connection.

Upon wake up and start up a chatSession. The chat session check for omemo support …, the logcat is catpured below:

Large amount of omemo data being processed before exception.

======= aTalk logcat on Sony Xeperia Tablet S (Sony XTS) ===========

08-25 12:39:42.460 D/SMACK: SENT (0):

08-25 12:39:42.470 W/αTalk: [16] org.jivesoftware.smack.AbstractXMPPConnection.callConnectionClosedOnErrorListen er()** Connection** XMPPTCPConnection[smith476@atalk.org/atalk] (0) closed with error

javax.net.ssl.SSLException: Write error: ssl=0x1f52ac0: I/O error during system call, Broken pipe

at org.apache.harmony.xnet.provider.jsse.NativeCrypto.SSL_write(Native Method)

at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl$SSLOutputStream.write(O penSSLSocketImpl.java:713)

08-25 12:39:51.510 D/SMACK: XMPPConnection (XMPPTCPConnection[smith476@atalk.org/atalk] (0)) will reconnect in 0

08-25 12:39:52.460 W/System.err: org.jivesoftware.smack.SmackException$NotConnectedException: The connection XMPPTCPConnection[smith476@atalk.org/atalk] (0) is no longer connected while waiting for response with IQReplyFilter: iqAndIdFilter (AndFilter: (OrFilter: (IQTypeFilter: type=error, IQTypeFilter: type=result), StanzaIdFilter: id=cZEjs-133)), : fromFilter (OrFilter: (FromMatchesFilter (full): cmeng@atalk.org))

08-25 12:40:12.980 D/SMACK: User logged (0): smith476@atalk.org:5222/atalk

08-25 12:40:13.020 D/SMACK: SENT (0): 08-25 12:40:13.010 D/SMACK: RECV (0):

08-25 12:40:13.020 D/SMACK: SENT (0): <iq id='cZEjs-144’ type=‘set’>

08-25 12:40:13.220 D/SMACK: RECV (0):

08-25 12:40:21.330 D/SMACK: SENT (0): BckyQ4ns69pHmGYCVndH3uG41d1r4l/sm8xngtt6GTtr</signedPreKeyPu blic>bxomkKsXqZstMjOSepmsgUp4iulcaCNDg0K5Y40NJtZLMi5fnCou mst3T4a5HMuV22DrtuTcePsQMLSSBQLojA==BaYfEh9 Rp5HJDsSROw4MIW84Ub1tkyEhEf1BFZ1pARtUBXg+g/MM8wAm/nf3JtRxz2i8Z29jfJFJFLUxgOpW++d2<preKey Public

preKeyId=‘42’>BYMYj8B0UQic6xwPqlEPdKgan3gRFmS6Yxvy+rrjMA4ABfBOWPLFT62aTCNlKE

08-25 12:40:23.020 E/αTalk: [19] impl.protocol.jabber.OperationSetBasicInstantMessagingJabberImpl.enableDisableC arbon().760 Failed to set carbon state for: smith476@atalk.org/atalk to true

org.jivesoftware.smack.SmackException$NoResponseException: No response received within reply timeout. Timeout was 10000ms (~10s). Waited for response using: IQReplyFilter: iqAndIdFilter (AndFilter: (OrFilter: (IQTypeFilter: type=error, IQTypeFilter: type=result), StanzaIdFilter: id=cZEjs-144)), : fromFilter (OrFilter: (FromMatchesFilter (full): null, FromMatchesFilter (ignoreResourcepart): smith476@atalk.org, FromMatchesFilter (full): atalk.org)).

at org.jivesoftware.smack.StanzaCollector.nextResultOrThrow(StanzaCollector.java:2 53)

at org.jivesoftware.smack.StanzaCollector.nextResultOrThrow(StanzaCollector.java:2 08)

Smack version 4.2.2 still throwing response timeout exception even the reply stanza was received within timeout period. The observation was on Note3 happen for aTalk while doing IBR account registration. It happens for both the carbon and omemo devicelist stanzas in a single test instance. As the test is not carried out at initial apk launch, I believe android inherited JIT compilation time does not contribute to the observed problem; also unlikely due to slow device long process time since the problem happen on Note3.

Another observation is carbon throws at 10s timeout (the default aTalk global setting) but message shows 50s timeout which was intentionly set for omemo devicelist request.

===== an extraction of the debug log showing only relevant stanza ===============
01-12 05:37:04.553 D/SMACK: SENT (3): <iq id='8NKO8-376' type='set'><enable xmlns='urn:xmpp:carbons:2'/></iq>
01-12 05:37:04.693 D/SMACK: RECV (3): <iq xml:lang='en' to='test2@atalk.org/atalk' from='test2@atalk.org' type='result' id='8NKO8-376'/>
01-12 05:37:06.253 D/SMACK: SENT (3): <iq to='test2@atalk.org' id='8NKO8-388' type='get'><query xmlns='http://jabber.org/protocol/disco#info' node='eu.siacs.conversations.axolotl.devicelist'></query></iq><r xmlns='urn:xmpp:sm:3'/>
01-12 05:37:06.273 D/SMACK: RECV (3): <iq xml:lang='en' to='test2@atalk.org/atalk' from='test2@atalk.org' type='result' id='8NKO8-388'><query node='eu.siacs.conversations.axolotl.devicelist' xmlns='http://jabber.org/protocol/disco#info'><identity type='registered' category='account'/></query></iq>
01-12 05:37:14.563 E/aTalk: [111] impl.protocol.jabber.OperationSetBasicInstantMessagingJabberImpl.enableDisableCarbon().796 Failed to set carbon state for: test2@atalk.org/atalk to true
                            org.jivesoftware.smack.SmackException$NoResponseException: No response received within reply timeout. Timeout was 50000ms (~50s). Waited for response using: IQReplyFilter: iqAndIdFilter (AndFilter: (OrFilter: (IQTypeFilter: type=error, IQTypeFilter: type=result), StanzaIdFilter: id=8NKO8-376)), : fromFilter (OrFilter: (FromMatchesFilter (full): null, FromMatchesFilter (ignoreResourcepart): test2@atalk.org, FromMatchesFilter (full): atalk.org)).
                                at org.jivesoftware.smack.StanzaCollector.nextResultOrThrow(StanzaCollector.java:253)
                                at org.jivesoftware.smack.StanzaCollector.nextResultOrThrow(StanzaCollector.java:208)
                                at org.jivesoftware.smackx.carbons.CarbonManager.setCarbonsEnabled(CarbonManager.java:311)
01-12 05:37:56.263 E/aTalk: [112] org.jivesoftware.smackx.omemo.OmemoManager.run() connectionListener.authenticated() failed to initialize OmemoManager: No response received within reply timeout. Timeout was 50000ms (~50s). Waited for response using: IQReplyFilter: iqAndIdFilter (AndFilter: (OrFilter: (IQTypeFilter: type=error, IQTypeFilter: type=result), StanzaIdFilter: id=8NKO8-388)), : fromFilter (OrFilter: (FromMatchesFilter (full): test2@atalk.org, FromMatchesFilter (full): null)).

Hm… I’ll try to take a look. What makes me wonder is, that I haven’t yet been able to reproduce this in the integration tests.

The rework of smack-omemo will soon be done. Maybe you want to give it a try? The API is unfortunately no longer the same, so you have to make some changes, but maybe it pays out?
In case you want to try it, you’ll have to compile Smack yourself from https://github.com/igniterealtime/Smack/pull/177 .

Maybe the new version solves your issue :slight_smile:

Yes, I would certainly integrated the new omemo library into aTalk but
will wait a week or two.
I just released aTalk into google playstore and need to do some final tidy
up.
By the way, do you have any omemo migration guide?

Below is a link to aTalk apk.
http://atalk.sytes.net

I am still fairy new in using git. By the way how do I pull in your source
into my local storage for compilation?

I’m working on it.

I’d recommend you to do the following in a working directory of your choice:

$ git clone https://github.com/igniterealtime/Smack.git
$ git remote add vanitasvitae https://github.com/vanitasvitae/Smack

That way you cloned the main smack repo and added my for as a remote.
Then you can checkout my branch and install it into your local maven repository:

$ cd Smack
$ git fetch vanitasvitae
$ git checkout vanitasvitae/storerework
$ gradle install

I’m not sure, which build system is used for building aTalk, but in gradle I included the mavenLocal repo like this:

repositories {
     mavenLocal()
}

If you need jar files, you can find those for example in ~/.m2/repository/org/igniterealtime/smack/smack-omemo/4.2.3-SNAPSHOT/

Thanks. Will take a look next week.

I have completed the initial porting to use the new omemo library and start
system testing.

Would appreciate for advice on the following:

  1. I see that you have obsoleted OmemoManager.regenerate(). Any reason?
    aTalk provides this option to user. User has used this to recovere from
    incomplete omemo database setup when connect to a slow server has timeout.

  2. Smack class FileBasedOmemoStore extends OmemoStore, whereas aTalk class
    SQLiteOmemoStore extends SignalOmemoStore
    It has been this way for aTalk. Do you see any problem with this?

  3. In aTalk earlier implementation, it uses the following method when
    encountered CorruptedOmemoKey in database so as to create new.
    OmemoService.getInstance().buildSessionFromOmemoBundle(omemoManager,
    omemoDevice, false);

I see that this is no more available. Do I need to do this with the new
implementation?

  1. I initi the OmemoManage with the following; is this correct?
    OmemoManager omemoManager = OmemoManager.getInstanceFor(connection);

  2. When a buddy added a new device, the previous OmemoManager seems to
    ignore published devicelist from this buddy. So any new message send to
    this buddy will not copy to the buddy new device? When and how OmemoManager
    will start cc omemo message to this new device?

aTalk has the following in AndroidOmemoService.java class to add new buddy
device. No sure if this correct?

private PEPListener buddyDeviceListUpdateListener = new PEPListener() {};

  1. How do you want me to feedback the test comment if any?
    Continue to use email or via forum - how do I name the new omemo if via
    forrum?

Regards,
CM ENg

Hi @cmeng!
Great to hear, that you are already testing :slight_smile:

  1. I find that the regenerate method is not really useful. There is no real use-case for it. Instead of throwing the whole identity away, I’d rather find a way to avoid sessions from breaking. If you really need a regenerate function, you can just manually delete all data associated to the old identity from the OmemoStore and then call OmemoManager.getInstanceFor(OmemoManager.randomDeviceId()).

  2. I dont fully understand the question, but it should be fine. Since you use a selfmade SQL store, extending SignalOmemoStore is he right choice to go. I advise you to wrap your SQL store in a SignalCachingOmemoStore in order to improve performance though (just call signalOmemoServiceInstance.setOmemoStoreBackend(new SignalCachingOmemoStore(yourSQLStoreInstance));.

  3. Yeah, I just realized, that a client dev doesn’t have access to such a function anymore. I’ll fix that by adding a method to the OmemoManager. In a perfect world, you wouldn’t need such function, but I agree that it is probably a good idea to expose this to the dev.

  4. By calling that code snippet you just get an instance of the OmemoManager. To initialize it, you’ll want to call either omemoManager.initialize(), or more suitable for older devices omemoManager.initializeAsync(initCallback). See the updated documentation.

  5. That should not have happened and shouldn’t happen anymore. As soon as a buddy adds a new device, you should get a deviceList update. If you then try to send a message, smack-omemo should instantly throw an UndecidedOmemoIdentityException due to that new device. If that doesn’t happen, please let me know!
    The code you have in your AndroidOmemoService should not be needed, as the OmemoManager already has a PEPListener (see these lines).

  6. I highly appreciate any form of feedback. The fastest way would be via XMPP (for example in the open_chat muc). If we have to exchange longer messages (eg. stanza logs), I think the forum is most suitable. You can use the naming scheme “smack-omemo (#177)” for issues :slight_smile:

Hi,

More questions:
7. Why localDeficeIdsOf() is requesting for SortedSet of deviceID. My
understanding is that each device is only associated with one deviceID.

/**

  • Returns a sorted set of all the deviceIds, the localUser has had
    data stored under in the store.
  • Basically this returns the deviceIds of all “accounts” of
    localUser, which are known to the store.
  • @param localUser BareJid of the user.
  • @return set of deviceIds with available data.
    */
    public abstract SortedSet localDeviceIdsOf(BareJid localUser);
  1. The return is date is not teddy with @return description text. I think
    it should be:
  • @return date if existent, otherwise null based on
    FileBaseOmemoStore.java implementation
    /**

  • Return the date in millis of the last message that was received
    from device ‘from’.

  1. It is possible (even though not very practical) to use multiple OmemoManagers on one device. Each OmemoManager then has its own deviceId. Therefore this method is needed. If you only ever use one OmemoManager on your device, this method can simply return a sorted set of just your one deviceId.

  2. You are right, I haven’t changed the javadoc. Thank you for the hint :slight_smile:

Edit: By the way if you include code in your comments/posts its better to put it in a block quote (ctrl + shift + 9).

I fixed the points you mentioned :slight_smile:

aTalk initialize the OmemoManager in two stages i.e.

  1. after xmpp connection connected
    OmemoManager omemoManager = OmemoManager.getInstanceFor(connection);

  2. on user authenticated - must only perform this upon user authenticated, other user not login exception.
    mOmemoManager.initializeAsync(this);

Then I receive the following error (attached below) in initializationFailed()
Look like aTalk cannot use OmemoManager.getInstanceFor(connection) without a deviceId being specified.

In the AndroidOmemoService.java I have to perform the following in order for OmemoManager initialization to work properly. Just wonder if omemoManager will include the below code, or leave to app to implement.

	XMPPTCPConnection connection = pps.getConnection();
        if (connection.getUser() != null) {
            user = connection.getUser().asBareJid();
        }
        else {
            user = pps.getAccountID().getFullJid().asBareJid();
        }

	int deviceId = (int) mOmemoStore.localDeviceIdsOf(user).first();
        OmemoManager omemoManager = OmemoManager.getInstanceFor(connection, deviceId);
========= debug log error message ==============
01-15 23:22:44.963 E/aTalk: [7] org.atalk.crypto.omemo.AndroidOmemoService.initializationFailed().116 Initialize OmemoManager failed: 
                            org.jivesoftware.smackx.omemo.exceptions.CorruptedOmemoKeyException: OMEMO Identity KeyPair is null for: leopard@atalk.org:-1
                                at org.atalk.crypto.omemo.SQLiteOmemoStore.loadOmemoIdentityKeyPair(SQLiteOmemoStore.java:371)
                                at org.atalk.crypto.omemo.SQLiteOmemoStore.loadOmemoIdentityKeyPair(SQLiteOmemoStore.java:66)
                                at org.jivesoftware.smackx.omemo.OmemoStore.replenishKeys(OmemoStore.java:199)
                                at org.jivesoftware.smackx.omemo.OmemoService.init(OmemoService.java:250)
                                at org.jivesoftware.smackx.omemo.OmemoManager.initialize(OmemoManager.java:244)
                                at org.jivesoftware.smackx.omemo.OmemoManager$2.run(OmemoManager.java:260)
                                at java.lang.Thread.run(Thread.java:818)
  1. You should get the instance of the OmemoManager before the connection gets connected.
  2. This is alright.

It looks like the exception gets thrown because your SQLiteOmemoStore is not correctly implemented.
Can you try to add your implementation to smack-omemo-signal’s SignalOmemoStoreTest in line 69?

The code snippet you provided to retrieve the BareJid will probably not be included in smack-omemo, but if it works for you, just use it.

  1. The parameter connection == null before connection is connected (before authenticated). Not sure if this is ok as pass in parameter connection is null.

Actually the error message is because OmemoManager device ID=UNKNOWN_DEVICE_ID for fetching; since I did not initialize the device ID. Should the OmemoManger take care of fetching it?

org.jivesoftware.smackx.omemo.exceptions.CorruptedOmemoKeyException: OMEMO Identity KeyPair is null for: leopard@atalk.org:-1

After the new implementation, the similar error message is still thrown this time for correct deviceID. On checking the sql database, it is really missing from DB. Not sure if this is due to my early testing with the half cooked code.
2. Any suggestion how to recover from this type of error i.e. corrupted or missing IdentityPreKeyPair beside doing the OmemoManager.regenerate?

  1. By the way, when and how is OmemoManager knows to initialize a new omemo data for a freshly installed device, as the following method has been obsoleted.

public boolean isFreshInstallation(OmemoManager omemoManager)

4, Testing on Note3, I still seeing the smack still throwing response timeout, but I think it is correct because of defaultPacketReplyTimeout of 5sec in SmackConfiguration. Even for Note8, it takes about 4.5s to publish the prekeys and receive the reply from my home server. I believe many of the free servers on network will failed to meet this timeout period of 5s. Actually the reply timeout also happen for enableDisableCarbon in the same test. On a safe side, aTalk I will change the global default timeout to 10sec. Possibly to also include the patch to ignore publish prekey timeout that I did for Smack v4.2.2.

  1. Following is a capture of the aTalk while testing on Note3. Do not quite understand why it throws reply timeout for id=FGapr-175 which is OK; shouldn’t the reply timeout is for id=‘FGapr-168’ i.e. publishing prekeys?
    Is my observation correct because of some race condition in smack?
============ Debug Log ==================
01-16 08:47:59.852 D/SMACK: SENT (1): <iq to='test2@atalk.org' id='FGapr-168' type='set'><pubsub xmlns='http://jabber.org/protocol/pubsub'><publish node='eu.siacs.conversations.axolotl.bundles:430747565'><item><bundle xmlns='eu.siacs.conversations.axolotl'><signedPreKeyPublic signedPreKeyId='1'>BRPO3WTznMiVhikIs+wJ9jUMFqHcqUsotYjgXwxB1wAJ</signedPreKeyPublic><signedPreKeySignature>2VGYV8+FlU9he6W6wbE7soKQAGWZZB/29Vtz+bYCOQTU92XTKeiKRPpTzJAJlbB5Nl4LfM7ScNe8j1cv+gFBCQ==</signedPreKeySignature><identityKey>BRH6nZPaSd1HQ6fn1LsfeHKkbloZxwIOHphZ0Gv7BTAr</identityKey><prekeys><preKeyPublic
01-16 08:48:04.272 D/SMACK: RECV (1): <iq xml:lang='en' to='test2@atalk.org/atalk' from='test2@atalk.org' type='result' id='FGapr-168'><pubsub xmlns='http://jabber.org/protocol/pubsub'><publish node=

01-16 08:48:04.292 D/SMACK: SENT (1): <iq to='test2@atalk.org' id='FGapr-175' type='get'><query xmlns='http://jabber.org/protocol/disco#info' node='eu.siacs.conversations.axolotl.devicelist'></query></iq>
01-16 08:48:05.702 D/SMACK: RECV (1): <iq xml:lang='en' to='test2@atalk.org/atalk' from='test2@atalk.org' type='result' id='FGapr-175'><query node='eu.siacs.conversations.axolotl.devicelist' xmlns='http://jabber.org/protocol/disco#info'><identity type='registered' category='account'/></query></iq>
01-16 08:48:09.293 E/aTalk: [17] org.atalk.crypto.omemo.AndroidOmemoService.initializationFailed().123 Initialize OmemoManager failed: 
                            org.jivesoftware.smack.SmackException$NoResponseException: 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=FGapr-175)), : fromFilter (OrFilter: (FromMatchesFilter (full): test2@atalk.org, FromMatchesFilter (full): null)).