ovalseven8
commented
6 years ago And it consumes not much battery.
Sorry, but I had to laugh. :smile_cat:
Closed bziemons closed 5 years ago
ovalseven8
commented
6 years ago And it consumes not much battery.
Sorry, but I had to laugh. :smile_cat:
ontheair81
commented
6 years ago Sorry, but I had to laugh.
I am not working for Threema GmbH, I am just an average user, so its not my intention to make Threema Web look better than it is. But the truth is: I am using Threema Web every day for hours in the office. And battery consumption is really ok (on my phone using LineageOS / Android 7.1.2 with most current security patches).
I just shared my experience in a normal every-day use. Sorry if that makes you laugh...
ovalseven8
commented
6 years ago I'm so frustrated because the connection problems have been huge for so long now.
Currently, I cannot use Threema Web. And that's although I'm in my (stable) WIFI at home.
When the session reconnection is successful, then the connection bar is green for a few seconds, in the chat, however, there's only this circle:
But immediately, also the connection bar gets orange:
The problem is: Even after the connection establishment is done, I only can see the circle again and in few seconds the connection bar is orange again and so on.
Here some browser logs, I guess they could help:
Also, I got this error today already:
EugenMayer
commented
6 years ago Use Signal. Solved - Sorry to say. (i am a Threema user since day 1 .. i am neither jumping around messengers nor i dislike Threema - but its just too much).
lgrahl
commented
6 years ago @ovalseven8 The last error looks like a regression of the changed disconnect procedure. Can you take a look, @dbrgn?
@EugenMayer I think you have made your point earlier. We have told you that there are plans to solve them, they just take time. Looking at your profile, you seem to have profound experience with projects on GitHub. Ask yourself if you would like to see such a counter-productive comment in one of your projects.
lgrahl
commented
6 years ago @ovalseven8 Alright, I went through the connection failures one by one:
[SaltyRTC.Initiator] Signaling error: Protocol error (Invalid nonce: ValidationError: Received message after handshake with invalid sender address (3 != 2)). This looks like a bug to me, perhaps on the server side. Why was there a message from the dropped responder? And why does it affect the connection towards responder 0x02? Have we specified that? @dbrgn, any thoughts?The buffering problem mentioned in 1 can be fixed fairly easily. I'm bumping my personal priority for it. Thanks for the log - this took a couple of hours to analyse but has already helped in narrowing down a bunch of issues!
@dbrgn Very confusing... between buffering and sending the local candidates in the second connection, a lot of time (definitely a couple of RTTs, so much more than 5ms) elapses. Any idea what could be happening here? Perhaps long blocking of the main thread due to a lot of slow tasks enqueued before the timeout handler?
ovalseven8
commented
6 years ago Wow, very nice @lgrahl!
Glad to see my post had effect. :smile: This is one of some really annoying/important issues.
lgrahl
commented
6 years ago Before I forget: Regarding the problem with the loading indicator spinning for ages... that is another annoying bug (see #247) you can easily work around. Just open another conversation and switch back.
ovalseven8
commented
6 years ago @lgrahl In my case mentioned above this does not work. Probably because there is no real connection? Threema Web just tries to reconnect (orange bar), then it's green for about 5 seconds, then reconnection again (orange) and so on. But in general you're right, I've experienced #247 also in past and then it worked with changing conversations.
ovalseven8
commented
6 years ago @lgrahl @dbrgn As soon as the connection is built up, it is already lost it seems. Today, I did a test again and here you can find both the browser logs and app logs for this issue mentioned in https://github.com/threema-ch/threema-web/issues/184#issuecomment-408324795. Perhaps the addition of the app logs can help even more:
message_log.txt browser_logs.txt
What's interesting is that SOMETIMES it works, however. But usually when I scanned the QR code, the connection was built up and lost immediately, then built up and lost etc. So, not usable.
dbrgn
commented
6 years ago Perhaps long blocking of the main thread due to a lot of slow tasks enqueued before the timeout handler?
Yeah, that could be.
@ovalseven8 did anything change about your wifi? Does it make a difference if your phone is in the mobile network?
ovalseven8
commented
6 years ago On my WiFi nothing changed, also no router or smartphone updates.
ontheair81
commented
6 years ago Since around one week I have the same issues as @ovalseven8 . Tested on two computers, both with Linux Mint 19, Firefox, and VPN via PrivateInternetAccess.
The setup with Mint / Firefox / VPN worked very well before, but showing the same issues as mentioned above, making it impossible to use Threema Web. I would like to add that web.threema.ch/troubleshoot/ shows no problems at all. Also the web client of WhatsApp is still working fine.
The problem can be solved by deactivating the VPN service, then Threema Web is working stable as expected again. Im just wondering why this happens now all of a sudden; there was never a problem before when using Threema Web with VPN.
lgrahl
commented
6 years ago @ontheair81 @ovalseven8 We'll address the identified problems mentioned in https://github.com/threema-ch/threema-web/issues/184#issuecomment-408369691 first and let you know once they are fixed. If it still doesn't work for you after that, we can take a look at it again in detail. One step at a time. :smiley_cat:
mhoff
commented
6 years ago I can confirm occasional hick-ups, seemingly of the same kind. Threema Web does connect and then immediately closes the secure connection, such that no data can be loaded and the web app has to be restarted. However, the problem does (most often) disappear after a few minutes (and a few refreshs...). Also, troubleshoot does not indicate any problems either (checked while the problem was present). My internet connection is provided by UnityMedia, too. Plus, no VPN is active.
dbrgn
commented
6 years ago @mhoff and others: Regarding the general connectivity issues, as @lgrahl wrote, we're working on the issues mentioned in https://github.com/threema-ch/threema-web/issues/184#issuecomment-408369691. Until that is done, further "me too" comments don't help much.
To troubleshoot your individual case, it's best to contact support via https://threema.ch/en/support, or to send a message to the threema contact *SUPPORT. The support staff will try to help you with those cases.
Until the issues mentioned above are fixed, I will lock this issue to avoid unnecessary noise. We are aware of some problems with data channel stability and aim to fix them soon! Thanks for your patience.
lgrahl
commented
5 years ago IIRC we have filed issues for all of the mentioned problems that are fixable from our side and they are slowly being resolved - one by one. I'll unlock the thread in case we have missed a specific one that has already been raised in this thread.
Like @dbrgn said, to troubleshoot your individual case, contact the support via https://threema.ch/en/support, or send a message to the threema contact *SUPPORT.
Referencing to #151 and others: Although the bug with reconnecting is fixed (thanks a lot by the way), the reason for losing connection was not yet identified, I think.
Just to give my go at it: I know for a certain that my ISP (Unitymedia it is) does close TCP connections after two minutes of inactivity. Although I think that is hardly what an ISP should do to cleanup old connections, thats what they do. I do have the very same problem with SSH, IRC, VPN, you name it. I suspect the same problem could apply here.
My solution to that problem is to setup keepalive packets in the application. SSH and my VPN software do have those options. Sending a packet every 30 seconds or so (preferably configurable) does not hurt and is much better than a full TCP/TLS reconnect every two minutes.
I do suspect some ISP do that to free ports on shared IPs. Unitymedia does give a shared IPv4 address (for new contracts) and they call it DS Lite. That, of course, means all ports on that IP are shared as well and need to be routed correctly. At some point they actively close TCP connections that are inactive, because they want to free ports. I suspect mobile providers to do the very same, because phones often share a single IPv4 as well.
Just a little heads up, as I haven't known this existed before I was a customer of Unitymedia.