Stuck at 60% #43
Comments
|
has to be the corporate firewall... Will test again at home. Thank you! |
|
Stuck at 60% ...
Are there STUN or TURN servers available to traverse vpn/fw restrictions? |
Yes, they're at stun.threema.ch:443 and turn.threema.ch:443. Maybe the company firewall blocks the traffic because it's not real HTTPS. Does it work outside the VPN? |
|
@dbrgn I think it would be a good idea to log gatherered and exchanged candidates (censor IP addresses that are not from Threema) so this can be investigated easier. |
Yes
In VPN I can see an UDP connection to turn.threema.ch:443 with 14 packets exchanged, then handover to another port happens, but there only 7 packets are exchanged before it stops at 60% (according to SmartSniff tool) |
|
Same situation here.
btw. Slack, WhatsApp, etc. are working fine in both browsers. I tried out https://test.webrtc.org/ Any suggestions?
|
|
These are the last few lines of the log from FF console: Note the 10s gap between first and second line. Let me know if and how I shall provide the complete log. Btw, meanwhile the circle keeps turning in the app, but can be removed by hold+Remove session. |
|
Note also |
Ok, but this contains sensitive information like local IP adresses, I won't post this here. Let me know which parts in particular might be helpful. |
|
Some redacted info from ICE stats
Might there anything else be helpful from |
|
I've no idea. I just saw this panel and thought it might be nice. |
|
When ICE goes to failed every time you try it, you can be pretty certain that it is a network-related problem. |
AFAIK WebRTC is supposed to traverse firewalls, so there must be something missing in threema-web's way to use it or in the setup of the STUN/TURN servers. I checked at https://www.netscan.co/ , WebRTC tests are ok. Just have a look at the forums (threema-forum.de, heise), this bug bites many. |
|
I'm pretty sure it is not related to networking. Both my phone and the PC are on the same net, and the progress is steady. When reaching 99% it always stops when I have the error (once it actually worked), and when I then delete the session inside the app the browser is notified immediately. |
That's an other issue: #38 |
|
All I'm saying is that when ICE goes to failed... what I said above. This does not mean I'm ruling out a bug here. And I'm not talking about the 99% stuck case here, this is the 60% stuck case, so please only discuss problems related to the 60% case in this issue. |
|
So, to clarify: I was talking about the case that both app and browser have no unhandled exceptions and then ICE goes to failed. Indeed, exceptions raised in the app that tear down the WebRTC PeerConnection instance would also lead to ICE going to failed on the browser side. |
I didn't check that explicitly. Would this have caused a message in the app (which did not occcur) or do I need to gather logs? If logs from the app are helpful, let me know how to do this. |
|
Yeah, give it a try. Edit: You can turn it on in the settings. |
|
I am also having the 60% issue in a corporate network. |
|
+1 same here |
|
log from Threema app while trying to connect to the browser: |
|
STUN/TURN servers are listening on port 443. This was done in order to prevent company firewalls from blocking it. But since the traffic going through Port 443 is not actually HTTPS, some firewalls with packet inspection might still block it. |
|
@dbrgn We should be able to verify this if you configure both servers to respond on the default STUN port as well and add it to the list of ICE servers. |
|
My initial comment was completely misguided, so I decided to try again. It's not the PCs that prevent my connection to Threema (stuck at 60%). It is my phone. My cellular provider seems to be causing the issue. Connecting to Wi-Fi or turning on a VPN such as Opera VPN allows me to circumvent it. All the browsers I have tested have this issue. Originally I got the 60% error in Opera regardless, but I then noticed WebRTC is disabled on the Opera browsers I tested. Opera's content settings make enabling WebRTC simple enough. I think Threema may want to suggest this to beginners using their Web client. |
|
@echotest123 Can you tell us the name of the cellular provider? It is indeed a possibility that they do not allow STUN/TURN packets because they are usually used in relation with mobile calls which probably isn't in the interest of the cellular provider. @dbrgn It should be possible to circumvent this limitation by using TURN with TLS (but I'm not sure if WebRTC can cope with TURN over TLS). |
|
@lgrahl It's Cricket, an AT&T based provider if that matters. |
|
@echotest123 Thanks. I'm not asking to be able to blame the ISP, just to be able to google if this is a known limitation. :) |
|
I can get it to work in this case and the error disappears. As the problem does not seem to be connected with any of my installed addons, maybe this could be connected due to some customized values inside |
|
Yes that's true. What is the value of |
|
@rugk The connection could be established now after setting this value. |
|
Hi. I get the 60% problem, when my Phone is connected to my OpenVPN. When I deactivate the OpenVPN connection, everything´s fine. When I activate the OpenVPN connection after the session was successfully established, the connection to the web-client gets lost. |
|
Maybe OpenVPN blocks WebRTC? And if you're using Firefox did you check the setting I mentioned? |
Threema Web works fine for me through OpenVPN. @bruennlein is there a firewall on the other side of the tunnel?
If that were the case, it wouldn't have worked without OpenVPN. |
|
@bruennlein A browser log (to see the ICE candidates) would help in this case. Please let us know at which point in the log you activated the OpenVPN connection. |
|
@dbrgn Yes, there is a firewall, but it blocks incoming traffic only. The outgonig traffic is not limited. One special thing about my OpenVPN is, that is goes through port 443. But as far as I know, this shouldn´t be a problem. I was just testing this at home and there I can use Threema Web while my phone is connected to the VPN. When I encountered the problem, the browser I used was communicating through a SOCKS Proxy. @lgrahl By browser log, do you mean F12->Console? |
|
@bruennlein Yes. |
|
There is another strange behavior. The problem shows up in my companys network. When I use a Chrome portable (with or without SOCKS), it doesn´t work. If I use the installed Chrome (same version) on the same machine, it works from my companys network. But I have to deactivate VPN on my phone. When I´m at home, I can use everything while VPN is active on my phone...very strange.. All right, here is the log, when it´s stuck at 60%: |
|
Thanks! The app doesn't gather any server reflexive or relay candidates which means the app cannot reach the STUN/TURN servers. You might want to wait until the next app update where #83 will be added to the app. @dbrgn will probably post here when this has been deployed. (But I'm not certain that it will help in your case.) |
|
For everyone who has still problems with the connection, there is a test page now: |
|
Thanks. I´ve tired it and everything´s green. Thanks a lot and happy chatting. |
|
Yes, TURN-TLS is now deployed on both sides. If it still doesn't work, post in this issue. |
|
Can you try whether it works in an anonymous session in Chrome (ctrl+shift+n)? But it definitely looks like the issue is either your browser configuration (addons) or your firewall. |
|
Still having issues here with firefox 51.0.1, latest Threema update, and Threema web 1.0.5. All tests were done in a normal firefox session with all extensions disabled and an anonymous session. When looking at the troubleshooting page in any of the previously mentioned situation all tests are YES except for TURN - which is a shiny red No. |
|
@james56b your computer is apparently behind a firewall that blocks non-HTTPS TCP and UDP traffic to our TURN servers. Can you try the troubleshooting tool in a modern version of Chrome/Chromium/Opera instead? Firefox does not support TURN via TLS yet (it will be added in version 53). |
|
Used Chrome and the problem is solved. Thank you very much for the help! |
|
I think this can be closed for now. If you're still having problems, please follow the advice in the issue description. |
|
I ran into this problem, OpenVPN connection established, and no longer being able to get Threema Web to run. I think my VPN connection is taking traffic only for specific 192.168.0.0/16 addresses of my home network based on routes pushed by the server. It's not clear to me why the WebRTC connections suddenly time out. Anyway, I finally gave up and explicitly excluded Threema from VPN access in the VPN settings (Allowed Apps). With this, even with established OpenVPN connection on the Android device, Threema Web keeps working without problems. |
|
@axeluhl ThreemaWeb is working with my OpenVPN-Server, so it should be possible in generyl. Maybe you could post your server and client-configs, so we can have a look. |
|
Here goes the generated config from the phone: -------- SNIP -------- Config for OpenVPN 2.xEnables connection to GUImanagement /data/user/0/de.blinkt.openvpn/cache/mgmtsocket unix setenv IV_GUI_VER "de.blinkt.openvpn 0.7.22" And here goes the server config file, tun0.conf in my case: -------- SNIP -------- push 'route 192.168.101.0 255.255.255.0' I think that this config should not cause the phone to route any Threema traffic through the VPN. It's not the default route, and all routes pushed by the server are within 192.168.0.0/16. Even if DNS queries hit my own DNS server (which forwards requests for non-internal domains to another DNS server) then this shouldn't affect the routing of non-DNS requests. But maybe I'm missing something... I tested a large download from the phone's browser with VPN active, from some external web site. The fact that the VPN traffic count wasn't affected by this download suggests to me that regular HTTP/HTTPS requests don't route through the VPN which is the behavior I expect. Threema Web so far is the only service causing noticeable trouble in relation to the VPN. |
|
@axeluhl what happens, when you do an nslookup to web.threema.ch? Maybe this can give more information about the way, the request takes. You could try to change the push dhcp-option for testing. Seems like, we have to exclude possible causes one by one, unless someone has a solution. |
|
nslookup on a terminal opened on the phone uses the Google 8.8.8.8 server, find a few IPv6 addresses and then reports "Can't find web.threema.ch: no answer" which is a bit surprising, given the fact that IPv6 addresses were discovered. Trying a "ping", however, seems to retrieve the IPv4 address 185.88.236.108 properly, and the ping succeeds. Android's DNS resolution schemes drive me nuts.
|
|
Note that if that is Termux you are using, note that it does not use Android's DNS server, see termux/termux-packages#1174. The better way is to use the WebRTC troubleshooting tool included in the Threema app (in the settings). It checks most stuff. |
|
Yup, you can see chosen IP addresses and potentially debug your routes here: https://web.threema.ch/troubleshoot/ |
and others
If connecting is stuck at 60%, this means that you WebRTC PeerConnection cannot be established. We're working on fixes, but it's a complex issue with many possible causes.
Please go to https://web.threema.ch/troubleshoot/ to see if any problem is detected.
When using Firefox, please try whether it works with Chrome/Chromium/Opera, since current versions of Firefox don't yet support TURN via TLS, which can cause the traffic to be blocked by some firewalls.
When it doesn't work in Chrome, try running the Threema Web in an anonymous window (Ctrl+Shift+n). If it works there, a plugin is blocking the connection.
If that does not help, a firewall might be the problem, especially if the issue occurs in a company network. We're actively working on a fix to circumvent the firewalls, but it might take a few more days until everything is properly set up and tested.
The text was updated successfully, but these errors were encountered: