guardianproject
OTR failing intermittently
I'm experiencing crippling issues on 4.4.4 with 14.0.1 OTR against a server that had been previously working fine. Occasionally OTR will refuse to work with specific contacts even after rebooting the phone and repeatedly ending/starting new chats. The icon just spins forever and never responds
This is happening for others, as well, and we will have a fix in the next update this week.
One question - do you or any of these contacts use any other OTR chat programs like Pidgin or Adium?
No, they only use ChatSecure. One thing I've noticed is that after recovering from this bug (for seemingly no reason) it appears to show an unverified OTR fingerprint with the contact in question which seems to indicate that the OTR fingerprints have been corrupted in some way.
I would be willing to offer financial compensation if you could fix this bug within the next day.
We've push an update to Google Play, or you can grab the latest release here: https://guardianproject.info/releases/ChatSecure-v14.0.3.apk
I have forked your project from GIT. Facing same problem. I am working on Master branch. On which branch you have fixed the bug?
Pushing another update today. I think the problem relates to using the wrong JID. If we are [email protected]/blah but the server actually sets us to [email protected]/blah123 we were not getting that info and setting the setFrom() in the XMPP Message properly. This made OTR sessions not connect.
I think there is some problem in initialization of OTR. When you set it to fore and restart mobile It works but if you enable it in the middle then it's like taking forever. So I think there is something missing in the flow. Still you know far better than me.. but this is also a possibility.
We've pushed changes that affect this bug, and have released 14.0.4 official as well: https://guardianproject.info/releases/ChatSecure-v14.0.4.apk
Just set it to forced, restart your mobile. Everything will work fine :)
This issue appears to be fixed with 14.0.4 and I haven't noticed any problems so far
EDIT: Further testing reveals that this has not been fixed! I'm intermittently unable to send OTRd chat to ANY of my contacts, this includes across between new versions of chatsecure, between new and old and between chatsecure and pidgin. Encryption is set to "automatically attempt". Force-stopping the app appears to fix the issue temporarily. PLEASE FIX THIS ISSUE AS SOON AS POSSIBLE
The issue appears not to be fixed :-/ ... I've testet it with ChatSecure 14.0.4 on Android 4.1.2, 4.2.2 and 4.4.4 on different devices. If I enable chat encryption the wheel is endless spinning and no encryption is enabled. All tricks named here are testet. I use OpenFire as XMPP-Server. With Xabber the OTR-Encryption works fine, so I think, it's not the server setup. Does anyone has other experiences with this constellation?
I have reverted everyone I know to <13 versions earlier to avoid this issue which is why I haven't noticed, but now that I've switched back this bug is definitely still here... this makes the app essentially unuseable as it's constantly failing to initiate OTR with contacts and nothing (rebooting, closing the app, etc) short of force stopping the app fixes this issue
@n8fr8 says: "one source of OTR failing seems to be corruption of the keystore props file we use. a) not sure why the corruption happens and b) we have no good way to recover from it"
Perhaps it's realated to this bug: https://github.com/guardianproject/ChatSecureAndroid/issues/545
The OTR failing seems to happen nearly every time I use it within less than a minute. Easiest way to reproduce has been start an OTRd chat, end the chat, then start a chat again. This occurs between v14 and v14, v13 and v14 and v14 and pidgin.
BTW the setup: CS 14.0.4 (any version 14+ seems to be affected) Nexus 5 Android 4.4.4 WiFi or Cellular data connection
The keystore file corruption is not related to the DB closing. The fact that you can establish an OTR session at means your keystore is intact. The OTR issues you are experiencing are more likely addressed by fixes in the SessionID instance management I have fixed in another pull request and will likely merge.
Awesome! Thank you so much! Let me know whenever you have a new build out and I will be happy to test it for you
I've been testing the latest builds (Oct 19th) among several people throughout the day and this issue is still present about 50% of the time OTR is attempted. Others who initially had some success reported not receiving many encrypted messages (despite delivery receipts on the senders end) during conversations and after resetting the database and logging back in OTR no longer worked at all (even after multiple attempts, force stops, etc). Rebooting the phone seemed to clear the issue. Others reported problems initializing OTR with anyone running v13 builds until force stopping. Please explain any steps you'd need to help further diagnosing this problem and I would be glad to assist
I reproduced this using the latest code in git between ChatSecure and Gajim. OTR would not start at all, then I Force Quit ChatSecure, then it started working. Trying to reproduce again...
I can reproduce it now:
- uninstall ChatSecure
- install ChatSecure
- setup existing XMPP account (e.g. [email protected])
- attempt to start OTR conversation from Gajim (signed into [email protected])
It looks like ChatSecure is trying to decrypt the initial OTR request, I don't know if that is the appropriate behavior or not:
OtrChatListener V onIncomingMessage: [email protected] has r
OtrChatManager V decryptMessage: [email protected]/ChatSecure [email protected]/Gajim [email protected] has r
Glad you can repro, hc. I think a few issues are being conflated here though.
v13 and existing v14 code definitely has issue with OTR and XMPP resources that could be causing this. If you are testing, knoy, please just test between the latest builds on both ends, and not an old build on one end.
2nd, the issue of delivery receipts showing, even if OTR fails, is that we are showing the delivery receipt which means we did receive the message, but decryption fails, so the user does not see it. Perhaps we should only send the receipt for OTR sessions if decryption succeeds? That would be tricky because delivery receipts right now are a the XMPP layer. I think what you want is a "read receipt" in fact.
Otherwise, hc, we always call "decryptMessage" in all cases, because that is how we detect whitespace characters to trigger OTR session to start in "as requested" mode. If it is not an OTR message, the engine will just pass the plain text along.
I do think, hc, that what you reproduced relates to the issue I have seen of this problem mostly happening on first-time use/setup. Once it stops happening, then it is fine from there on out. So it may be related to OTR key generation?
Key generation can take a VERY long time on mobile devices, especially older ones. There was a bug in libotr that we had to work around related to async key generation causing the handshake to fail. Perhaps otr4j has a similar issue.
On Thu, Oct 23, 2014 at 5:10 PM, n8fr8 [email protected] wrote:
I do think, hc, that what you reproduced relates to the issue I have seen of this problem mostly happening on first-time use/setup. Once it stops happening, then it is fine from there on out. So it may be related to OTR key generation?
— Reply to this email directly or view it on GitHub https://github.com/guardianproject/ChatSecureAndroid/issues/520#issuecomment-60328281 .
I've been doing most of the testing on v14, the v14->v13 testing was just to ensure edge cases. In any event this does NOT appear to be a v13 bug as the OTR always works flawlessly on v13, it seems to be clearly a result of something added in < 14.0.1
This also does NOT appear to be a key generation bug as I have waited upwards of 8 minutes for the problem to resolve without success, and then immediately after force stopping and relaunching the application OTR initiates instantaneously.
The message receipts happened after I initiated an OTRed conversation, received several encrypted messages I could read and then sent several which were delivered but unreadable to my recipient, not sure if this is unrelated
This issue is still really crippling any use of chatsecure. I'm having troubles understanding why you are having problems reproducing this bug as it's affected every person I know who's updated to v14. Anytime the app is updated to a new version (i.e: a new debug build) all the active chats become instantly affected and reboots and force stops do not fix.
@n8fr8 ok, following up on the XMPP resources, have OTR Instance Tags been implemented in v14? or is there something else happening with XMPP resources? I just had a session where ChatSecure was not receiving messages at all, and it seemed to be related to different XMPP Resources.
While you say "works flawlessly on v13" others did not say that, so you see it is a matter of perspective. Absolute statements about what does or does not work are not helpful.
OTR instance tags are not implemented, as we are not using OTR v3.
XMPP resources could be a cause of this, specifically how the OTR Session object instances are tied to a SessionID instance, and how new sessions are instantiated when the resource changes.
As a side note, since 14.0.8.1 I have not had any problems init'ing OTR sessions with any of the non-technical users I communicate with using ChatSecure on a daily basis.
@n8fr8 I only see v14.0.4 in git, where is the code for the newer releases?