Wire-desktop: VPN activation prevents messages arriving, while sending is OK

[robertnurnberg]

Wire version: 3.0.2816
Wire for web version: 2017.11.10.1041
Operating system: Kubuntu 16.04
Which antivirus software do you have installed: None.

What steps will reproduce the problem:

1. Log in to wire desktop, with a standard internet connection active.
2. Activate a VPN connection.
3. Send messages in a chat in wire desktop.
4. The chat partner will see the messages and replies.
5. The replies will not arrive. They do arrive in a separate device, a mobile phone, say.

What is the expected result?
Either wire recognises a problem and refuses to send or receive messages. Or both sending and receiving should work.

What is the actual result?
Messages cannot be received.

Please provide any additional information below. Attach a screenshot if
possible.
Workaround: Log out from wire and log in again, while VPN is active.

[Fluffkin]

But you just changed your IP address when you activated the VPN. Lots of software doesn't like this behaviour, especially constantly connected services. Try it with pretty much any online game and you'll get disconnected.

[maximbaz]

Wire doesn't show "No internet" in such case, it is _seemingly_ online and I can even send a message, but incoming messages do not arrive. In my case VPN is connected automatically in background, so by looking at Wire I don't know if it is truly online or in such a broken state.

I personally would prefer either that Wire can both send and receive after VPN connection, or that it shows "No internet" message so that I know I have to restart the app.

[Fluffkin]

I'm not sure there's a solution without security and / or increasing network use implications (bad for mobile phone use). Generally this is something you have to get used to because you are using a VPN.

Virtually all software works on the assumption you either have an internet connection, or you don't. Wire works as expected in this situation. VPN connections change your internet settings (IP end point and probably routing), without dropping the network connection, so there's no easy way for user space software to be aware of the change.

You can still send messages because the other user end point still has the same IP. You can't receive messages because you just changed your IP. As far as your Wire connection is concerned, it can still see the other user end point, it can still access the internet, so it looks like everything is fine. The other user can't tell your end that it can't talk to you .. because it doesn't know where you are any more. You have to renegotiate the connect.

Have you got a theoretically viable way of solving this situation that doesn't have security or constant data use issues?

[maximbaz]

Sure - today Wire sends PING requests via websocket every 30 seconds:

However there is either no PONG response build on the server side yet, or server does send PONG back, but lack of it doesn't trigger client reconnection today.

Wire should reconnect if there is no PONG response from the server.

[Fluffkin]

But ... you are getting a PONG .. otherwise it would reconnect. You're saying you want a PONG that doesn't work if the originating IP address of the PING changed since the last PING. That's not how ping works.

[maximbaz]

Then I don't understand something, why am I supposedly receiving a packet "PONG", but not receiving another packet from the same server with a text message from my friend?

[Fluffkin]

"End to end encryption"

[maximbaz]

Sorry but I don't understand how encryption can prevent delivery of certain network packages 🙂

Are you saying that due to IP address change I am able to receive message "PONG", but am not able to receive message "x8%ds!35g", because the latter one is an encrypted version of string "PONG"?

[Fluffkin]

In very simple terms. Yes.

[robertnurnberg]

It is my impression that the mobile app already does this: it seems to work seamlessly across different network providers and/or different wireless networks. So it is hard to see why this cannot also be achieved for the desktop version.

[Fluffkin]

Androids have notification systems for network changes. Windows & Linux don't (I don't know about Apple)

[robertnurnberg]

I am not claiming it is straightforward, but it is possible to detect network changes or IP address changes in Windows and Linux. A quick google search shows how it can be done, see for example here.

[bennycode]

@robertnurnberg The main difference between sending and receiving messages on Wire is that receiving works through a WebSocket connecting and sending works through a REST call. It looks like your VPN is not forwarding WebSocket events, can this be true?

[maximbaz]

@bennyn I'll answer because I also struggle from this issue. VPN is able to forward websocket data, but only after the app is restarted. It's just that Wire doesn't notice that websocket connection is dead and doesn't reinitialize it.

[maximbaz]

@bennyn I looked into the code and debugged this exact scenario, so here's what I see after I connect or disconnect VPN:

• WebSocketService#sendPing is still being called every now and then, as expected
• socket.readyState is 1
• socket.send() does not crash, it's return value is exactly the same both when it manages to deliver a message and when it doesn't
• none of socket.on* methods are being called after sending "undelivered" pings.

So in the end, the app is trying to send "Wire is so much nicer with internet!" every now and then and it simply doesn't know that its messages are not being delivered.

The only thing you can actually do is to make Wire server respond to "Wire is so much nicer with internet!" with "Indeed it is", and on the client adapt your checks to look not at lastPingTime, but at lastPongTime — the time of receiving "Indeed it is" from the server.

Due to how Websockets work, until it's one-way communication, you won't be able to detect network failures 🙁