Stuck at 60% about threema-web

[dbrgn]

After scanning QR code, progress in browser starts immedeately, stays stuck at 60%, when I then disable Threema Web on phone browser goes directly to expected "Server connection closed" state, so there is some kind of communication,

Yes, there is a WebSocket connection for the signaling information, but that is not used for the message content itself. You get the "server connection closed" warning because the signaling server drops the connection if the session is deleted in the app.

We're actively working on a fix related to the problems with firewalls. It might take a few more days until everything is properly set up and tested.

[lgrahl]

Note that the issue will still remain in case the Android device is in such a restricted environment. Resolving this requires an app update.

[dbrgn]

Threema Web 1.0.3 was just published. ✨ This should fix a lot of the "stuck at 60%" problems.

Thanks @lgrahl for the research and pull request.

[Gegh]

Threema Web 1.0.3 was just published
Fix confirmed, no more stuck at 60% for me (web client behind corporate fw) 👍

also confirmed. Well done :)

[jakunar]

I am also having the 60% issue in a corporate network.
about:webrtc result is equal #43 (comment)

[lgrahl]

@MarcR2000 There are no relay candidates gathered by the browser. You are probably one of the 1% left that need TURN-TLS. Give the Threema team a little time. :)

[rugk]

Yes that's true. What is the value of media.peerconnection.enabled in about:config?
If set to false, this disables WebRTC. Please set it to true in this case.

[dbrgn]

Maybe OpenVPN blocks WebRTC?

Threema Web works fine for me through OpenVPN. @bruennlein is there a firewall on the other side of the tunnel?

And if you're using Firefox did you check the setting I mentioned?

If that were the case, it wouldn't have worked without OpenVPN.

[dbrgn]

@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).

[dbrgn]

I think this can be closed for now.

If you're still having problems, please follow the advice in the issue description.

[CptHermi]

has to be the corporate firewall...

Will test again at home.

Thank you!

[fichtennadel]

Stuck at 60% ...

• browser FF 51.0.1 and Chrome 56.0.2924.87 (also tried in anon window), both on Win7 64bit
• no plugin
• disabled ad blocker
• corporate VPN, don't know about deep packet inspection fw

Are there STUN or TURN servers available to traverse vpn/fw restrictions?

[dbrgn]

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?

[lgrahl]

@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.

[fichtennadel]

Does it work outside the VPN?

Yes

Yes, they're at stun.threema.ch:443 and turn.threema.ch:443

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)

[Ka-Hen]

Same situation here.
Tried browsers

• Chromium 56.0.2924.87 (64-bit) with WebRTC and w/o any plug-ins etc.
• Firefox 51.0.1 (32-Bit) with and w/o plug-ins

btw. Slack, WhatsApp, etc. are working fine in both browsers.
Android phone connected via WiFi or 4G. Same behaviour.
The message_log.txt reports nothings interesting AFAICS (attached below)

I tried out https://test.webrtc.org/
in Chromium the network part is green (TURN) but the Connectivity part is yellow at the "Reflexive connectivity"
in FF the network part is red "[ FAILED ] TURN request failed". No idea why atm.

Any suggestions?

Thu Feb 16 15:38:47 MEZ 2017 releaseConnectionLinger: source = activityPaused, timeout = 60000 Thu Feb 16 15:38:47 MEZ 2017 releaseConnection: source = activityPaused, refCount = 0 Thu Feb 16 15:38:47 MEZ 2017 acquireConnection: source = activityResumed, refCount = 1 Thu Feb 16 15:38:49 MEZ 2017 releaseConnectionLinger: source = activityPaused, timeout = 60000 Thu Feb 16 15:38:49 MEZ 2017 releaseConnection: source = activityPaused, refCount = 0 Thu Feb 16 15:38:49 MEZ 2017 acquireConnection: source = activityResumed, refCount = 1 Thu Feb 16 15:38:51 MEZ 2017 releaseConnectionLinger: source = activityPaused, timeout = 60000 Thu Feb 16 15:38:51 MEZ 2017 releaseConnection: source = activityPaused, refCount = 0 Thu Feb 16 15:38:51 MEZ 2017 acquireConnection: source = activityResumed, refCount = 1 Thu Feb 16 15:38:51 MEZ 2017 releaseConnectionLinger: source = activityPaused, timeout = 60000 Thu Feb 16 15:38:51 MEZ 2017 releaseConnection: source = activityPaused, refCount = 0 Thu Feb 16 15:38:51 MEZ 2017 acquireConnection: source = activityResumed, refCount = 1 Thu Feb 16 15:39:01 MEZ 2017 releaseConnectionLinger: source = activityPaused, timeout = 60000 Thu Feb 16 15:39:01 MEZ 2017 releaseConnection: source = activityPaused, refCount = 0 Thu Feb 16 15:39:02 MEZ 2017 onTrimMemory: 20 Thu Feb 16 15:39:06 MEZ 2017 acquireConnection: source = activityResumed, refCount = 1 Thu Feb 16 15:41:39 MEZ 2017 releaseConnectionLinger: source = activityPaused, timeout = 60000 Thu Feb 16 15:41:39 MEZ 2017 releaseConnection: source = activityPaused, refCount = 0 Thu Feb 16 15:41:39 MEZ 2017 acquireConnection: source = activityResumed, refCount = 1 Thu Feb 16 15:41:43 MEZ 2017 releaseConnectionLinger: source = activityPaused, timeout = 60000 Thu Feb 16 15:41:43 MEZ 2017 releaseConnection: source = activityPaused, refCount = 0 Thu Feb 16 15:41:43 MEZ 2017 onTrimMemory: 20

[fichtennadel]

These are the last few lines of the log from FF console:

19:02:01.743 [SaltyRTC.WebRTC.initiator] New event: candidates  saltyrtc-task-webrtc.es5.js:1051:13
19:02:12.854 [PeerConnectionHelper] ICE connection state change: failed  angular.js:14199:18
19:02:12.863 [StateService] RTC connection state: connecting => disconnected  angular.js:14199:18

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.

[rugk]

Note also about:webrtc may contain some useful debug information in Firefox.

[fichtennadel]

Note also about:webrtc may contain some useful debug information in Firefox.

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.

[fichtennadel]

Some redacted info from about:webrtc

ICE stats

Local Candidate	Remote Candidate	ICE State	Priority
(web client IP VPN):58350/udp(host)	(app IP LAN):53677/udp(host)	failed	9xxxx
(web client IP VPN):58350/udp(host)	(LAN gateway public IP):53677/udp(serverreflexive)	failed	7xxxx
(web client IP VPN):58350/udp(host)	5.148.175.222:62236/udp(relayed)	failed	1xxxx
	::1:38781/udp(host)
	127.0.0.1:36203/udp(host)
	(app IP LAN):59211/tcp(host)
	::1:49132/tcp(host)
	127.0.0.1:48222/tcp(host)

Might there anything else be helpful from about:webrtc?

[rugk]

I've no idea. I just saw this panel and thought it might be nice.
But "ICE State = failed" does not look good…

[lgrahl]

When ICE goes to failed every time you try it, you can be pretty certain that it is a network-related problem.

[fichtennadel]

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.

[DerDakon]

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.

[fichtennadel]

... When reaching 99% it always stops ...

That's an other issue: #38

[lgrahl]

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.

[lgrahl]

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.

[fichtennadel]

... exceptions raised in the app that tear down the WebRTC PeerConnection ...

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.

[lgrahl]

Yeah, give it a try. Edit: You can turn it on in the settings.

[Gegh]

+1 same here

[fichtennadel]

log from Threema app while trying to connect to the browser:

Fri Feb 17 13:14:49 CET 2017	acquireConnection: source = activityResumed, refCount = 1
Fri Feb 17 13:14:49 CET 2017	startConnection
Fri Feb 17 13:14:49 CET 2017	ThreemaConnection state changed: CONNECTING Port: 5222 IPv6: false
Fri Feb 17 13:14:49 CET 2017	ThreemaConnection state changed: CONNECTED Port: 5222 IPv6: false
Fri Feb 17 13:14:49 CET 2017	ThreemaConnection state changed: LOGGEDIN Port: 5222 IPv6: false
Fri Feb 17 13:14:55 CET 2017	[type: WIFI[], state: CONNECTED/CONNECTED, reason: (unspecified), extra: "SSID", roaming: false, failover: false, isAvailable: true, isConnectedToProvisioningNetwork: false]
Fri Feb 17 13:14:59 CET 2017	releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri Feb 17 13:14:59 CET 2017	releaseConnection: source = activityPaused, refCount = 0
Fri Feb 17 13:14:59 CET 2017	onTrimMemory: 20
Fri Feb 17 13:15:59 CET 2017	stopConnection
Fri Feb 17 13:15:59 CET 2017	ThreemaConnection state changed: DISCONNECTED Port: 5222 IPv6: false

[dbrgn]

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.

[lgrahl]

@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.

[lgrahl]

@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.

[lgrahl]

@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. :)

[jakunar]

@echotest123
Have you tried using https://web.telegram.org
Or can anybody clarify for me, how they might use webrtc differently? I can use it from our corporate network, but can't use Threema..

[lgrahl]

@jakunar Telegram does not use WebRTC at all. They can avoid this issue because their traffic probably looks like TLS and that pretty much always works (because we expect websites to work). WebRTC traffic does not look like TLS.

[jakunar]

@lgrahl ah..okay thank you.
Well then, even with @echotest123 possibly having problems with his/her ISP, which I do not exclude myself from (might test it tomorrow morning), mine and I bet others problem still persist.

To give more precise information:
my phone is on a rather public WiFi where any devices from co-workers are allowed and my workstation, where the web-interface is running on, is in a different vpn-secured network.

[rugk]

Which is your ISP?

@jakunar I hope that my discovery of this issue can be tested, especially if it is more common and doesn't simply affect the web clients! For me, my assumption that my work ISP caused the problem misdirected me. (But it does affect many others.)

It's an easy enough thing to test. On your phone, turn on a VPN like Opera's. Then see if your browser works.

Out of curiosity, do you use AT&T, Cricket, etc? Or another prepaid carrier based off a major one?

[fichtennadel]

Just to clarify: my variant of the issue is related to the network connection of the browser, I tried with the app both in mobile/umts/lte network and LAN/WiFi.

TURN with TLS and/or TCP seems to be a promising approach, this could get through firewalls blocking non-TLS traffic on 443 and/or blocking UDP.

[theiltho]

Same here. Thanks to the suggestion from @echotest123 I got the web client working.

Initial setup (stucks at 60%): Chrome connected to internet, no corporate network, phone connected via LTE (ISP is O2).

Workaround: Chrome connected to internet, no corporate network, phone connected via VPN with my home network. As soon as I stop the VPN connection on the phone the web client stops immediately.

[lgrahl]

@dbrgn Looked it up, WebRTC should support TURN over TLS. Looks like you should try using the default port (3478) for STUN/TURN traffic and turns (TURN over TLS) for fallback using port 443. This should fix this issue here. I can help you testing it out if the Fritzbox setup (mentioned here (German)) turns out to be a reliable test case.

[Gegh]

angular.js?v=1.0.1:14199 [StateService] Reset
angular.js?v=1.0.1:14199 Detected browser: Chrome 56
angular.js?v=1.0.1:14199 Initialize session by scanning QR code...
angular.js?v=1.0.1:14199 [StateService] Reset
saltyrtc-client.es5.js?v=1.0.1:467 [SaltyRTC.KeyStore] New public key: 3f06cb8dff4e8228745abe4f714e59e8a5ae7885ff087656e6dad1e0f6fdf252
saltyrtc-client.es5.js?v=1.0.1:526 [SaltyRTC.AuthToken] Generated auth token
angular.js?v=1.0.1:14199 Starting WebClientService...
saltyrtc-client.es5.js?v=1.0.1:2934 [SaltyRTC.Client] New event: state-change
saltyrtc-client.es5.js?v=1.0.1:2934 [SaltyRTC.Client] New event: state-change:new
saltyrtc-client.es5.js?v=1.0.1:2934 [SaltyRTC.Client] New event: state-change
saltyrtc-client.es5.js?v=1.0.1:2934 [SaltyRTC.Client] New event: state-change:ws-connecting
saltyrtc-client.es5.js?v=1.0.1:1172 [SaltyRTC.Initiator] Opening WebSocket connection to wss://saltyrtc-3f.threema.ch:443/3f06cb8dff4e8228745abe4f714e59e8a5ae7885ff087656e6dad1e0f6fdf252
angular.js?v=1.0.1:14199 [StateService] Signaling connection state: new => new
angular.js?v=1.0.1:14199 [StateService] Signaling connection state: new => ws-connecting
saltyrtc-client.es5.js?v=1.0.1:984 [SaltyRTC.Initiator] Opened connection
saltyrtc-client.es5.js?v=1.0.1:2934 [SaltyRTC.Client] New event: state-change
saltyrtc-client.es5.js?v=1.0.1:2934 [SaltyRTC.Client] New event: state-change:server-handshake
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (81 bytes)
saltyrtc-client.es5.js?v=1.0.1:1189 [SaltyRTC.Initiator] Received server-hello
saltyrtc-client.es5.js?v=1.0.1:1273 [SaltyRTC.Initiator] Sending client-auth
angular.js?v=1.0.1:14199 [StateService] Signaling connection state: ws-connecting => server-handshake
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (194 bytes)
saltyrtc-client.es5.js?v=1.0.1:1200 [SaltyRTC.Initiator] Received server-auth
saltyrtc-client.es5.js?v=1.0.1:1435 [SaltyRTC.Initiator] Expected server public permanent key is b1337fc8402f7db8ea639e05ed05d65463e24809792f91eca29e88101b4a2171
saltyrtc-client.es5.js?v=1.0.1:1436 [SaltyRTC.Initiator] Server public session key is 3a9253a27236e66701056a7084514a34ddfe9a84e29e2ef5e3cb79d87886bd4e
saltyrtc-client.es5.js?v=1.0.1:1928 [SaltyRTC.Initiator] 0 responders connected
saltyrtc-client.es5.js?v=1.0.1:2934 [SaltyRTC.Client] New event: state-change
saltyrtc-client.es5.js?v=1.0.1:2934 [SaltyRTC.Client] New event: state-change:peer-handshake
saltyrtc-client.es5.js?v=1.0.1:1210 [SaltyRTC.Initiator] Server handshake done
angular.js?v=1.0.1:14199 [StateService] Connection buildup state: connecting => waiting
angular.js?v=1.0.1:14199 [StateService] Signaling connection state: server-handshake => peer-handshake
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (64 bytes)
saltyrtc-client.es5.js?v=1.0.1:1809 [SaltyRTC.Initiator] Received new-responder 0x02
saltyrtc-client.es5.js?v=1.0.1:467 [SaltyRTC.KeyStore] New public key: dc683a6f52bb4b6c0ddec14cec74909ef0a764b9a1d4f2acf2b3e8e646c87e68
saltyrtc-client.es5.js?v=1.0.1:2934 [SaltyRTC.Client] New event: new-responder
angular.js?v=1.0.1:14199 [StateService] Connection buildup state: waiting => peer_handshake
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (90 bytes)
saltyrtc-client.es5.js?v=1.0.1:1838 [SaltyRTC.Initiator] Received token
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (88 bytes)
saltyrtc-client.es5.js?v=1.0.1:1854 [SaltyRTC.Initiator] Received key
saltyrtc-client.es5.js?v=1.0.1:1962 [SaltyRTC.Initiator] Sending key
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (193 bytes)
saltyrtc-client.es5.js?v=1.0.1:1861 [SaltyRTC.Initiator] Received auth
saltyrtc-client.es5.js?v=1.0.1:2001 [SaltyRTC.Initiator] Task v0.webrtc.tasks.saltyrtc.org has been selected
saltyrtc-task-webrtc.es5.js?v=1.0.1:706 [SaltyRTC.WebRTC] Max packet size: We requested 65536 bytes, peer requested 65536 bytes. Using 65536.
saltyrtc-client.es5.js?v=1.0.1:2004 [SaltyRTC.Initiator] Responder 0x02 authenticated
saltyrtc-client.es5.js?v=1.0.1:1981 [SaltyRTC.Initiator] Sending auth
saltyrtc-client.es5.js?v=1.0.1:2038 [SaltyRTC.Initiator] Dropping 0 other responders.
saltyrtc-client.es5.js?v=1.0.1:2934 [SaltyRTC.Client] New event: state-change
saltyrtc-client.es5.js?v=1.0.1:2934 [SaltyRTC.Client] New event: state-change:task
angular.js?v=1.0.1:14199 Initialize WebRTC PeerConnection
angular.js?v=1.0.1:14199 [PeerConnectionHelper] Setting up ICE candidate handling
saltyrtc-task-webrtc.es5.js?v=1.0.1:948 [SaltyRTC.WebRTC.initiator] Initiate handover
saltyrtc-client.es5.js?v=1.0.1:1869 [SaltyRTC.Initiator] Peer handshake done
angular.js?v=1.0.1:14199 [StateService] Signaling connection state: peer-handshake => task
angular.js?v=1.0.1:14199 [PeerConnectionHelper] RTCPeerConnection: negotiation needed
angular.js?v=1.0.1:14199 [PeerConnectionHelper] Signaling state change: have-local-offer
angular.js?v=1.0.1:14199 [PeerConnectionHelper] Created offer, set local description
saltyrtc-task-webrtc.es5.js?v=1.0.1:874 [SaltyRTC.WebRTC.initiator] Sending offer
saltyrtc-client.es5.js?v=1.0.1:1592 [SaltyRTC.Initiator] Sending task message through ws
saltyrtc-task-webrtc.es5.js?v=1.0.1:920 [SaltyRTC.WebRTC.initiator] Buffering 1 candidate(s)
saltyrtc-task-webrtc.es5.js?v=1.0.1:924 [SaltyRTC.WebRTC.initiator] Sending 1 candidate(s)
saltyrtc-client.es5.js?v=1.0.1:1592 [SaltyRTC.Initiator] Sending task message through ws
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (512 bytes)
saltyrtc-client.es5.js?v=1.0.1:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.1:1246 [SaltyRTC.Initiator] Received answer [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.1:721 [SaltyRTC.WebRTC.initiator] New task message arrived: answer
saltyrtc-task-webrtc.es5.js?v=1.0.1:1051 [SaltyRTC.WebRTC.initiator] New event: answer
angular.js?v=1.0.1:14199 [PeerConnectionHelper] Signaling state change: stable
angular.js?v=1.0.1:14199 [PeerConnectionHelper] Received answer, set remote description
angular.js?v=1.0.1:14199 [PeerConnectionHelper] Initiator flow done
angular.js?v=1.0.1:14199 [PeerConnectionHelper] ICE connection state change: checking
angular.js?v=1.0.1:14199 [StateService] RTC connection state: new => connecting
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (228 bytes)
saltyrtc-client.es5.js?v=1.0.1:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.1:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.1:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.1:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (201 bytes)
saltyrtc-client.es5.js?v=1.0.1:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.1:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.1:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.1:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (208 bytes)
saltyrtc-client.es5.js?v=1.0.1:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.1:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.1:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.1:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (245 bytes)
saltyrtc-client.es5.js?v=1.0.1:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.1:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.1:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.1:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (218 bytes)
saltyrtc-client.es5.js?v=1.0.1:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.1:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.1:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.1:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (223 bytes)
saltyrtc-client.es5.js?v=1.0.1:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.1:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.1:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.1:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (261 bytes)
saltyrtc-client.es5.js?v=1.0.1:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.1:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.1:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.1:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
saltyrtc-client.es5.js?v=1.0.1:1027 [SaltyRTC.Initiator] New ws message (259 bytes)
saltyrtc-client.es5.js?v=1.0.1:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.1:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.1:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.1:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
angular.js?v=1.0.1:14199 [PeerConnectionHelper] ICE connection state change: failed
angular.js?v=1.0.1:14199 [StateService] RTC connection state: connecting => disconnected

Chrome Version 56.0.2924.87 (Behind corporate firewall)
Android Behind ISP (Vodafone Germany)

[jkrwdf]

My browser is behind corporate firewall. No plugins that block something installed. Also tried incognito mode without any plugins. Chrome and Firefox.

Stuck at 60% regardless of how the phone is connected to the internet. Via mobile data, via Opera VPN or direct (non firewalled) internet access (available at my corporation for private devices) does not matter.

After scanning QR code, progress in browser starts immedeately, stays stuck at 60%, when I then disable Threema Web on phone browser goes directly to expected "Server connection closed" state, so there is some kind of communication,

Is in my case only related to how the big browser connects to the Internet.

[Gegh]

Same with Release 1.0.2
web.threema.ch-1487753632500.txt

[fichtennadel]

Same with Release 1.0.2

same for me, still no connection when behind corporate fw

[fichtennadel]

Add TURN-TCP to ICE server configuration ...

Tried in Chrome debugger by adding ?transport=tcp to turn URL --> successfully connected!!

Looking forward to see this in next release!

Great work, thanks 🎉

[lgrahl]

@fichtennadel You're welcome. ;)

[fichtennadel]

Threema Web 1.0.3 was just published

Fix confirmed, no more stuck at 60% for me (web client behind corporate fw) 👍

[theiltho]

Same, thanks guys!

[MarcR2000]

Unfortunately cannot confirm. STILL STUCK behind corporate Firewall. Same Browser / PC works as soon as I leave corporate environment.

[jakunar]

Mine is solved too, as long as my phone does not use the corporate wifi.

@MarcR2000 Is your phone in that same network? Or are you using your mobile data?

[MarcR2000]

Using mobile data. And again - same setup on phone side works as soon as I leave corporate environment with the PC.

[lgrahl]

@MarcR2000 Make sure your browser hasn't cached any data (CTRL+F5). If it still doesn't work, please attach your browser console log, so this can be investigated.

[MarcR2000]

Hi,

Cache is clean... Still the same. I'm attaching the log.

[StateService] Reset
Detected browser: Chrome 53
Initialize session by scanning QR code...
[StateService] Reset
[SaltyRTC.KeyStore] New public key: 2e8100ede2166b2dc68df8658c8682bbd5eb40957ef859cbfb87b37876d0345b
[SaltyRTC.AuthToken] Generated auth token
Starting WebClientService...
[SaltyRTC.Client] New event: state-change
[SaltyRTC.Client] New event: state-change:new
[SaltyRTC.Client] New event: state-change
[SaltyRTC.Client] New event: state-change:ws-connecting
[SaltyRTC.Initiator] Opening WebSocket connection to wss://saltyrtc-2e.threema.ch:443/2e8100ede2166b2dc68df8658c8682bbd5eb40957ef859cbfb87b37876d0345b
[StateService] Signaling connection state: new => new
[StateService] Signaling connection state: new => ws-connecting
[SaltyRTC.Initiator] Opened connection
[SaltyRTC.Client] New event: state-change
[SaltyRTC.Client] New event: state-change:server-handshake
[SaltyRTC.Initiator] New ws message (81 bytes)
[SaltyRTC.Initiator] Received server-hello
[SaltyRTC.Initiator] Sending client-auth
[StateService] Signaling connection state: ws-connecting => server-handshake
[SaltyRTC.Initiator] New ws message (194 bytes)
[SaltyRTC.Initiator] Received server-auth
[SaltyRTC.Initiator] Expected server public permanent key is b1337fc8402f7db8ea639e05ed05d65463e24809792f91eca29e88101b4a2171
[SaltyRTC.Initiator] Server public session key is 2b5073948690a1d2a1e47b2f34c9baa6c372d229a0e17f5206e068b77322e26b
[SaltyRTC.Initiator] 0 responders connected
[SaltyRTC.Client] New event: state-change
[SaltyRTC.Client] New event: state-change:peer-handshake
[SaltyRTC.Initiator] Server handshake done
[StateService] Connection buildup state: connecting => waiting
[StateService] Signaling connection state: server-handshake => peer-handshake
[SaltyRTC.Initiator] New ws message (64 bytes)
[SaltyRTC.Initiator] Received new-responder 0x02
[SaltyRTC.KeyStore] New public key: 994708d9a0eaeb76f5262f7ff54c82cb16376e0f2be83cdf1e6eb050c2537a4c
[SaltyRTC.Client] New event: new-responder
[StateService] Connection buildup state: waiting => peer_handshake
[SaltyRTC.Initiator] New ws message (90 bytes)
[SaltyRTC.Initiator] Received token
[SaltyRTC.Initiator] New ws message (88 bytes)
[SaltyRTC.Initiator] Received key
[SaltyRTC.Initiator] Sending key
[SaltyRTC.Initiator] New ws message (193 bytes)
[SaltyRTC.Initiator] Received auth
[SaltyRTC.Initiator] Task v0.webrtc.tasks.saltyrtc.org has been selected
[SaltyRTC.WebRTC] Max packet size: We requested 65536 bytes, peer requested 65536 bytes. Using 65536.
[SaltyRTC.Initiator] Responder 0x02 authenticated
[SaltyRTC.Initiator] Sending auth
[SaltyRTC.Initiator] Dropping 0 other responders.
[SaltyRTC.Client] New event: state-change
[SaltyRTC.Client] New event: state-change:task
Initialize WebRTC PeerConnection
[PeerConnectionHelper] Setting up ICE candidate handling
[SaltyRTC.WebRTC.initiator] Initiate handover
[SaltyRTC.Initiator] Peer handshake done
[StateService] Signaling connection state: peer-handshake => task
[PeerConnectionHelper] RTCPeerConnection: negotiation needed
[PeerConnectionHelper] Signaling state change: have-local-offer
[PeerConnectionHelper] Created offer, set local description
[SaltyRTC.WebRTC.initiator] Sending offer
[SaltyRTC.Initiator] Sending task message through ws
[PeerConnectionHelper] Gathered local ICE candidate: candidate:4245267258 1 UDP 2113937151 *** 1 typ host
[SaltyRTC.WebRTC.initiator] Buffering 1 candidate(s)
[SaltyRTC.WebRTC.initiator] Sending 1 candidate(s)
[SaltyRTC.Initiator] Sending task message through ws
[SaltyRTC.Initiator] New ws message (491 bytes)
[SaltyRTC.Initiator] Message received
[SaltyRTC.Initiator] Received answer [v0.webrtc.tasks.saltyrtc.org]
[SaltyRTC.WebRTC.initiator] New task message arrived: answer
[SaltyRTC.WebRTC.initiator] New event: answer
[SaltyRTC.Initiator] New ws message (248 bytes)
[SaltyRTC.Initiator] Message received
[SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
[SaltyRTC.WebRTC.initiator] New task message arrived: candidates
[SaltyRTC.WebRTC.initiator] New event: candidates
[PeerConnectionHelper] Adding remote ICE candidate: candidate:3153415652 1 UDP 2122262783 *** 1 typ host
[SaltyRTC.Initiator] New ws message (230 bytes)
[SaltyRTC.Initiator] Message received
[SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
[SaltyRTC.WebRTC.initiator] New task message arrived: candidates
[SaltyRTC.WebRTC.initiator] New event: candidates
[PeerConnectionHelper] Adding remote ICE candidate: candidate:2812961067 1 UDP 2122194687 *** 1 typ host
[SaltyRTC.Initiator] New ws message (201 bytes)
[SaltyRTC.Initiator] Message received
[SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
[SaltyRTC.WebRTC.initiator] New task message arrived: candidates
[SaltyRTC.WebRTC.initiator] New event: candidates
[PeerConnectionHelper] Adding remote ICE candidate: candidate:559267639 1 UDP 2122136831 *** 1 typ host
[SaltyRTC.Initiator] New ws message (208 bytes)
[SaltyRTC.Initiator] Message received
[SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
[SaltyRTC.WebRTC.initiator] New task message arrived: candidates
[SaltyRTC.WebRTC.initiator] New event: candidates
[PeerConnectionHelper] Adding remote ICE candidate: candidate:1510613869 1 UDP 2122063615 *** 1 typ host
[SaltyRTC.Initiator] New ws message (262 bytes)
[SaltyRTC.Initiator] Message received
[SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
[SaltyRTC.WebRTC.initiator] New task message arrived: candidates
[SaltyRTC.WebRTC.initiator] New event: candidates
[PeerConnectionHelper] Adding remote ICE candidate: candidate:1797742264 1 UDP 1685987071 *** 1 typ srflx raddr *** rport 2
[SaltyRTC.Initiator] New ws message (262 bytes)
[SaltyRTC.Initiator] Message received
[SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
[SaltyRTC.WebRTC.initiator] New task message arrived: candidates
[SaltyRTC.WebRTC.initiator] New event: candidates
[PeerConnectionHelper] Adding remote ICE candidate: candidate:1797742264 1 UDP 1685987071 *** 1 typ srflx raddr *** rport 2
[PeerConnectionHelper] Received answer, set remote description
[PeerConnectionHelper] Initiator flow done
[SaltyRTC.Initiator] New ws message (264 bytes)
[SaltyRTC.Initiator] Message received
[SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
[SaltyRTC.WebRTC.initiator] New task message arrived: candidates
[SaltyRTC.WebRTC.initiator] New event: candidates
[PeerConnectionHelper] Adding remote ICE candidate: candidate:4118196500 1 TCP 1518283007 *** 1 typ host tcptype passive
[PeerConnectionHelper] Signaling state change: stable
[PeerConnectionHelper] ICE connection state change: checking
[StateService] RTC connection state: new => connecting
[SaltyRTC.Initiator] New ws message (246 bytes)
[SaltyRTC.Initiator] Message received
[SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
[SaltyRTC.WebRTC.initiator] New task message arrived: candidates
[SaltyRTC.WebRTC.initiator] New event: candidates
[PeerConnectionHelper] Adding remote ICE candidate: candidate:3911818715 1 TCP 1518214911 *** 1 typ host tcptype passive
[SaltyRTC.Initiator] New ws message (218 bytes)
[SaltyRTC.Initiator] Message received
[SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
[SaltyRTC.WebRTC.initiator] New task message arrived: candidates
[SaltyRTC.WebRTC.initiator] New event: candidates
[PeerConnectionHelper] Adding remote ICE candidate: candidate:1876313031 1 TCP 1518157055 *** 1 typ host tcptype passive
[SaltyRTC.Initiator] New ws message (223 bytes)
[SaltyRTC.Initiator] Message received
[SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
[SaltyRTC.WebRTC.initiator] New task message arrived: candidates
[SaltyRTC.WebRTC.initiator] New event: candidates
[PeerConnectionHelper] Adding remote ICE candidate: candidate:344579997 1 TCP 1518083839 *** 1 typ host tcptype passive
[SaltyRTC.Initiator] New ws message (259 bytes)
[SaltyRTC.Initiator] Message received
[SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
[SaltyRTC.WebRTC.initiator] New task message arrived: candidates
[SaltyRTC.WebRTC.initiator] New event: candidates
[PeerConnectionHelper] Adding remote ICE candidate: candidate:4146655061 1 UDP 41819903 5.148.189.199 53875 typ relay raddr *** rport 2
[PeerConnectionHelper] No more local ICE candidates
[PeerConnectionHelper] ICE connection state change: failed
[StateService] RTC connection state: connecting => disconnected

[MarcR2000]

Too bad :-(

[lgrahl]

@MarcR2000 Are you using a proxy in the corporate network?

[MarcR2000]

Yes, there is a proxy in the autoconfiguration. I don't think it can be deleted...

[lgrahl]

Do you have knowledge about how restrictive the proxy is? Does it filter HTTP requests? Can you browse HTTPS sites normally? Anything that does not work? What type of proxy is it (SOCKS/HTTP)? The more we know, the better, so we can reproduce it. Any sensitive information you don't want to post publicly can be sent to Threema directly. :)

[MarcR2000]

I have experienced it to be not at all restrictive. Anything else works extensively. HTTPS, Whatsapp and all other services I have ever tried to use work like a charm. The only thing that does not work is Teamviewer.

[dbrgn]

Proxies should probably work once we have TURN-TLS, unless the proxies intercept/break TLS traffic. If that's the case, bad luck. (But I don't think that's the case for @MarcR2000)

Note that Firefox <53 does not yet support TURN-TLS, so users behind firewalls doing deep packet inspection will have to use Chrome/Chromium.

[lgrahl]

I also believe that the proxy looks at the STUN packets and throws them away because they don't look like TLS. As @dbrgn said, this should be fixed once TURN-TLS has been deployed (and you're using a browser that supports it).

[FriedrichFroebel]

I have the same problem running FF 51.0.1 (Windows only, on Ubuntu connection can be established; NoScript and Adblocker disabled).

I get an Unhandled Exception error after I have scanned the QR code. (Do not know if this is connected to this issue.)

...
[SaltyRTC.Client] New event: new-responder  saltyrtc-client.es5.js:2934:13
[StateService] Connection buildup state: waiting => peer_handshake  angular.js:14199:18
[SaltyRTC.Initiator] New ws message (90 bytes)  saltyrtc-client.es5.js:1027:13
[SaltyRTC.Initiator] Received token  saltyrtc-client.es5.js:1838:25
[SaltyRTC.Initiator] New ws message (88 bytes)  saltyrtc-client.es5.js:1027:13
[SaltyRTC.Initiator] Received key  saltyrtc-client.es5.js:1854:25
[SaltyRTC.Initiator] Sending key  saltyrtc-client.es5.js:1962:13
[SaltyRTC.Initiator] New ws message (193 bytes)  saltyrtc-client.es5.js:1027:13
[SaltyRTC.Initiator] Received auth  saltyrtc-client.es5.js:1861:25
[SaltyRTC.Initiator] Task v0.webrtc.tasks.saltyrtc.org has been selected  saltyrtc-client.es5.js:2001:17
[SaltyRTC.WebRTC] Max packet size: We requested 16384 bytes, peer requested 65536 bytes. Using 16384.  saltyrtc-task-webrtc.es5.js:706:13
[SaltyRTC.Initiator] Responder 0x02 authenticated  saltyrtc-client.es5.js:2004:13
[SaltyRTC.Initiator] Sending auth  saltyrtc-client.es5.js:1981:13
[SaltyRTC.Initiator] Dropping 0 other responders.  saltyrtc-client.es5.js:2038:13
[SaltyRTC.Client] New event: state-change  saltyrtc-client.es5.js:2934:13
[SaltyRTC.Client] New event: state-change:task  saltyrtc-client.es5.js:2934:13
Initialize WebRTC PeerConnection  angular.js:14199:18
[SaltyRTC.Client] Unhandled exception in state-change:task handler: ReferenceError: RTCPeerConnection is not defined
Stack-Trace:
PeerConnectionHelper@https://web.threema.ch/dist/app.js?v=1.0.3:12708:9
init/<@https://web.threema.ch/dist/app.js?v=1.0.3:13593:34
onceHandler@https://web.threema.ch/node_modules/saltyrtc-client/dist/saltyrtc-client.es5.js?v=1.0.3:2917:21
callHandler@https://web.threema.ch/node_modules/saltyrtc-client/dist/saltyrtc-client.es5.js?v=1.0.3:2976:28
emit@https://web.threema.ch/node_modules/saltyrtc-client/dist/saltyrtc-client.es5.js?v=1.0.3:2945:25
setState@https://web.threema.ch/node_modules/saltyrtc-client/dist/saltyrtc-client.es5.js?v=1.0.3:1118:13
onPeerHandshakeMessage@https://web.threema.ch/node_modules/saltyrtc-client/dist/saltyrtc-client.es5.js?v=1.0.3:1868:25
Signaling/this.onMessage@https://web.threema.ch/node_modules/saltyrtc-client/dist/saltyrtc-client.es5.js?v=1.0.3:1051:25
  saltyrtc-client.es5.js:2947:25
[SaltyRTC.Initiator] Peer handshake done  saltyrtc-client.es5.js:1869:25
[StateService] Signaling connection state: peer-handshake => task  angular.js:14199:18
...

[dbrgn]

@FriedrichFroebel You seem to be blocking WebRTC:

[SaltyRTC.Client] Unhandled exception in state-change:task handler: ReferenceError: RTCPeerConnection is not defined

Any plugins installed?

[FriedrichFroebel]

Just tried to start Firefox in Safe Mode which disables all addons. The error remains.

[dbrgn]

@FriedrichFroebel you could try to create a new Firefox profile to test whether it works there: https://support.mozilla.org/t5/Install-and-Update/Use-the-Profile-Manager-to-create-and-remove-Firefox-profiles/ta-p/2914

[FriedrichFroebel]

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 about:config.

[FriedrichFroebel]

@rugk The connection could be established now after setting this value.

[bruennlein]

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.

[rugk]

Maybe OpenVPN blocks WebRTC? And if you're using Firefox did you check the setting I mentioned?

[lgrahl]

@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.

[bruennlein]

@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.
Maybe it´s the combination of SOCKS and OpenVPN. I´ll try it again tomorrow.

@lgrahl By browser log, do you mean F12->Console?

[lgrahl]

@bruennlein Yes.

[bruennlein]

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%:
angular.js?v=1.0.3:14199 [StateService] Reset
angular.js?v=1.0.3:14199 Detected browser: Chrome 56
angular.js?v=1.0.3:14199 Initialize session by scanning QR code...
angular.js?v=1.0.3:14199 [StateService] Reset
saltyrtc-client.es5.js?v=1.0.3:467 [SaltyRTC.KeyStore] New public key: 1f94411217ff0135de41c3e4bf714c6eeaae3c0b1e8465ae41116cb3f13fb817
saltyrtc-client.es5.js?v=1.0.3:526 [SaltyRTC.AuthToken] Generated auth token
angular.js?v=1.0.3:14199 Starting WebClientService...
saltyrtc-client.es5.js?v=1.0.3:2934 [SaltyRTC.Client] New event: state-change
saltyrtc-client.es5.js?v=1.0.3:2934 [SaltyRTC.Client] New event: state-change:new
saltyrtc-client.es5.js?v=1.0.3:2934 [SaltyRTC.Client] New event: state-change
saltyrtc-client.es5.js?v=1.0.3:2934 [SaltyRTC.Client] New event: state-change:ws-connecting
saltyrtc-client.es5.js?v=1.0.3:1172 [SaltyRTC.Initiator] Opening WebSocket connection to wss://saltyrtc-1f.threema.ch:443/1f94411217ff0135de41c3e4bf714c6eeaae3c0b1e8465ae41116cb3f13fb817
angular.js?v=1.0.3:14199 [StateService] Signaling connection state: new => new
angular.js?v=1.0.3:14199 [StateService] Signaling connection state: new => ws-connecting
saltyrtc-client.es5.js?v=1.0.3:984 [SaltyRTC.Initiator] Opened connection
saltyrtc-client.es5.js?v=1.0.3:2934 [SaltyRTC.Client] New event: state-change
saltyrtc-client.es5.js?v=1.0.3:2934 [SaltyRTC.Client] New event: state-change:server-handshake
angular.js?v=1.0.3:14199 [StateService] Signaling connection state: ws-connecting => server-handshake
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (81 bytes)
saltyrtc-client.es5.js?v=1.0.3:1189 [SaltyRTC.Initiator] Received server-hello
saltyrtc-client.es5.js?v=1.0.3:1273 [SaltyRTC.Initiator] Sending client-auth
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (194 bytes)
saltyrtc-client.es5.js?v=1.0.3:1200 [SaltyRTC.Initiator] Received server-auth
saltyrtc-client.es5.js?v=1.0.3:1435 [SaltyRTC.Initiator] Expected server public permanent key is b1337fc8402f7db8ea639e05ed05d65463e24809792f91eca29e88101b4a2171
saltyrtc-client.es5.js?v=1.0.3:1436 [SaltyRTC.Initiator] Server public session key is b90f088cde27ac1b80c50fa39ea429396169b40864e9f3bc8e89558560ea4307
saltyrtc-client.es5.js?v=1.0.3:1928 [SaltyRTC.Initiator] 0 responders connected
saltyrtc-client.es5.js?v=1.0.3:2934 [SaltyRTC.Client] New event: state-change
saltyrtc-client.es5.js?v=1.0.3:2934 [SaltyRTC.Client] New event: state-change:peer-handshake
saltyrtc-client.es5.js?v=1.0.3:1210 [SaltyRTC.Initiator] Server handshake done
angular.js?v=1.0.3:14199 [StateService] Connection buildup state: connecting => waiting
angular.js?v=1.0.3:14199 [StateService] Signaling connection state: server-handshake => peer-handshake
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (64 bytes)
saltyrtc-client.es5.js?v=1.0.3:1809 [SaltyRTC.Initiator] Received new-responder 0x02
saltyrtc-client.es5.js?v=1.0.3:467 [SaltyRTC.KeyStore] New public key: b0bbb3064f9a975266a84b73e21d075d9ff287a7eebd615e18dcc91724a82408
saltyrtc-client.es5.js?v=1.0.3:2934 [SaltyRTC.Client] New event: new-responder
angular.js?v=1.0.3:14199 [StateService] Connection buildup state: waiting => peer_handshake
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (90 bytes)
saltyrtc-client.es5.js?v=1.0.3:1838 [SaltyRTC.Initiator] Received token
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (88 bytes)
saltyrtc-client.es5.js?v=1.0.3:1854 [SaltyRTC.Initiator] Received key
saltyrtc-client.es5.js?v=1.0.3:1962 [SaltyRTC.Initiator] Sending key
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (193 bytes)
saltyrtc-client.es5.js?v=1.0.3:1861 [SaltyRTC.Initiator] Received auth
saltyrtc-client.es5.js?v=1.0.3:2001 [SaltyRTC.Initiator] Task v0.webrtc.tasks.saltyrtc.org has been selected
saltyrtc-task-webrtc.es5.js?v=1.0.3:706 [SaltyRTC.WebRTC] Max packet size: We requested 65536 bytes, peer requested 65536 bytes. Using 65536.
saltyrtc-client.es5.js?v=1.0.3:2004 [SaltyRTC.Initiator] Responder 0x02 authenticated
saltyrtc-client.es5.js?v=1.0.3:1981 [SaltyRTC.Initiator] Sending auth
saltyrtc-client.es5.js?v=1.0.3:2038 [SaltyRTC.Initiator] Dropping 0 other responders.
saltyrtc-client.es5.js?v=1.0.3:2934 [SaltyRTC.Client] New event: state-change
saltyrtc-client.es5.js?v=1.0.3:2934 [SaltyRTC.Client] New event: state-change:task
angular.js?v=1.0.3:14199 Initialize WebRTC PeerConnection
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Setting up ICE candidate handling
saltyrtc-task-webrtc.es5.js?v=1.0.3:948 [SaltyRTC.WebRTC.initiator] Initiate handover
saltyrtc-client.es5.js?v=1.0.3:1869 [SaltyRTC.Initiator] Peer handshake done
angular.js?v=1.0.3:14199 [StateService] Signaling connection state: peer-handshake => task
angular.js?v=1.0.3:14199 [PeerConnectionHelper] RTCPeerConnection: negotiation needed
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Signaling state change: have-local-offer
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Created offer, set local description
saltyrtc-task-webrtc.es5.js?v=1.0.3:874 [SaltyRTC.WebRTC.initiator] Sending offer
saltyrtc-client.es5.js?v=1.0.3:1592 [SaltyRTC.Initiator] Sending task message through ws
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Gathered local ICE candidate: candidate:839781666 1 UDP 2113937151 *** 1 typ host
saltyrtc-task-webrtc.es5.js?v=1.0.3:920 [SaltyRTC.WebRTC.initiator] Buffering 1 candidate(s)
saltyrtc-task-webrtc.es5.js?v=1.0.3:924 [SaltyRTC.WebRTC.initiator] Sending 1 candidate(s)
saltyrtc-client.es5.js?v=1.0.3:1592 [SaltyRTC.Initiator] Sending task message through ws
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Gathered local ICE candidate: candidate:2434426190 1 UDP 16785151 5.148.175.197 51111 typ relay raddr *** rport 2
saltyrtc-task-webrtc.es5.js?v=1.0.3:920 [SaltyRTC.WebRTC.initiator] Buffering 1 candidate(s)
saltyrtc-task-webrtc.es5.js?v=1.0.3:924 [SaltyRTC.WebRTC.initiator] Sending 1 candidate(s)
saltyrtc-client.es5.js?v=1.0.3:1592 [SaltyRTC.Initiator] Sending task message through ws
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (512 bytes)
saltyrtc-client.es5.js?v=1.0.3:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.3:1246 [SaltyRTC.Initiator] Received answer [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.3:721 [SaltyRTC.WebRTC.initiator] New task message arrived: answer
saltyrtc-task-webrtc.es5.js?v=1.0.3:1051 [SaltyRTC.WebRTC.initiator] New event: answer
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Signaling state change: stable
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Received answer, set remote description
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Initiator flow done
angular.js?v=1.0.3:14199 [PeerConnectionHelper] ICE connection state change: checking
angular.js?v=1.0.3:14199 [StateService] RTC connection state: new => connecting
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (229 bytes)
saltyrtc-client.es5.js?v=1.0.3:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.3:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.3:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.3:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Adding remote ICE candidate: candidate:221074828 1 UDP 2122260223 *** 1 typ host
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (222 bytes)
saltyrtc-client.es5.js?v=1.0.3:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.3:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.3:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.3:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Adding remote ICE candidate: candidate:257476908 1 UDP 2122194687 *** 1 typ host
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (201 bytes)
saltyrtc-client.es5.js?v=1.0.3:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.3:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.3:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.3:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Adding remote ICE candidate: candidate:559267639 1 UDP 2122136831 *** 1 typ host
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (208 bytes)
saltyrtc-client.es5.js?v=1.0.3:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.3:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.3:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.3:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Adding remote ICE candidate: candidate:1510613869 1 UDP 2122063615 *** 1 typ host
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (246 bytes)
saltyrtc-client.es5.js?v=1.0.3:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.3:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.3:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.3:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Adding remote ICE candidate: candidate:1135520124 1 TCP 1518280447 *** 1 typ host tcptype passive
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (239 bytes)
saltyrtc-client.es5.js?v=1.0.3:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.3:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.3:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.3:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Adding remote ICE candidate: candidate:1104885212 1 TCP 1518214911 *** 1 typ host tcptype passive
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (218 bytes)
saltyrtc-client.es5.js?v=1.0.3:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.3:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.3:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.3:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Adding remote ICE candidate: candidate:1876313031 1 TCP 1518157055 *** 1 typ host tcptype passive
saltyrtc-client.es5.js?v=1.0.3:1027 [SaltyRTC.Initiator] New ws message (223 bytes)
saltyrtc-client.es5.js?v=1.0.3:1217 [SaltyRTC.Initiator] Message received
saltyrtc-client.es5.js?v=1.0.3:1246 [SaltyRTC.Initiator] Received candidates [v0.webrtc.tasks.saltyrtc.org]
saltyrtc-task-webrtc.es5.js?v=1.0.3:721 [SaltyRTC.WebRTC.initiator] New task message arrived: candidates
saltyrtc-task-webrtc.es5.js?v=1.0.3:1051 [SaltyRTC.WebRTC.initiator] New event: candidates
angular.js?v=1.0.3:14199 [PeerConnectionHelper] Adding remote ICE candidate: candidate:344579997 1 TCP 1518083839 *** 1 typ host tcptype passive
angular.js?v=1.0.3:14199 [PeerConnectionHelper] No more local ICE candidates
angular.js?v=1.0.3:14199 [PeerConnectionHelper] ICE connection state change: failed
angular.js?v=1.0.3:14199 [StateService] RTC connection state: connecting => disconnected

[lgrahl]

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.)

[ovalseven8]

For everyone who has still problems with the connection, there is a test page now:
https://web.threema.ch/troubleshoot

[bruennlein]

Thanks. I´ve tired it and everything´s green.
For some reason it is working now with all my extra-stuff (portable Chrome, SOCKS, Phone connected to OpenVPN).
I don´t know if the Threema-Guys have changed anything, because I haven´t.
But I think an update came in today. My current version is 3.1.2000343. So if anyone has the same problem, try updating to this version.

Thanks a lot and happy chatting.

[lgrahl]

Yes, TURN-TLS is now deployed on both sides. If it still doesn't work, post in this issue.

[dbrgn]

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.

[james56b]

Still having issues here with firefox 51.0.1, latest Threema update, and Threema web 1.0.5.
I've tested with my phone behind a Carrier Grade NAT (CGN) and also in a situation without. And also tested with my laptop on either the office network behind a proxy or behind a PFSense with basic NAT44. Additionally, having the laptop tethered to the phone via wifi also does not help even if the phone is connected to a APN with or without CGN.

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]

Used Chrome and the problem is solved. Thank you very much for the help!

[axeluhl]

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.

[bruennlein]

@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.

[axeluhl]

Here goes the generated config from the phone:

-------- SNIP --------

Config for OpenVPN 2.x

Enables connection to GUI

management /data/user/0/de.blinkt.openvpn/cache/mgmtsocket unix
management-client
management-query-passwords
management-hold

setenv IV_GUI_VER "de.blinkt.openvpn 0.7.22"
setenv IV_SSO openurl,crtext
setenv IV_PLAT_VER "25 7.1.1 armeabi-v7a bq msm8952 Aquaris X5 Plus"
machine-readable-output
allow-recursive-routing
ifconfig-nowarn
client
verb 4
connect-retry 2 30
resolv-retry 60
dev tun
remote {my-hostname} 1194 udp
connect-timeout 10

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

-----BEGIN PRIVATE KEY----- ... -----END PRIVATE KEY----- ... -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- remote-cert-tls server data-ciphers AES-256-GCM auth SHA256 float -------- SNIP --------

And here goes the server config file, tun0.conf in my case:

-------- SNIP --------
dev tun0
topology subnet
server 192.168.105.0 255.255.255.0
keepalive 10 60
dh /etc/openvpn/openvpn-ca/keys/dh2048.pem
ca /etc/openvpn/openvpn-ca/keys/ca.crt
cert /etc/openvpn/openvpn-ca/keys/klo.crt
key /etc/openvpn/openvpn-ca/keys/klo.key
cipher AES-256-GCM
auth SHA1
reneg-sec 6000

push 'route 192.168.101.0 255.255.255.0'
push 'route 192.168.102.0 255.255.255.0'
push 'route 192.168.104.0 255.255.255.0'
push 'route 192.168.105.0 255.255.255.0'
push 'dhcp-option DOMAIN {my-internal-domain-name}'
push 'dhcp-option DNS 192.168.101.1'
push 'dhcp-option DNS 8.8.8.8'
-------- SNIP --------

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.

[bruennlein]

@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.

[axeluhl]

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.

[rugk]

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.

[lgrahl]

Yup, you can see chosen IP addresses and potentially debug your routes here: https://web.threema.ch/troubleshoot/
WebRTC can have some... surprising mechanics in which address/interface combination it chooses. If you're familiar with Wireshark, it's the best tool I know to debug that. Use stun or dtls for filtering.