revolution-irc
revolution-irc copied to clipboard
MCMrARM
Does not traverse VPNs
Maybe someone else can verify this? It's a bit peculiar, but I can't get it to work with any VPN app. It works fine with proxy apps and apps that use the Android VPN service for things that are not VPN, like Tor VPN mode and firewall apps that use the VPN service to analyze and filter traffic but don't establish an actual VPN, but it always bypasses actual VPN apps, like OpenVPN, SSTP, etc. I have verified the VPNs work with various other apps, but just not this one for some reason.
The only time I can stop it from leaking outside of a VPN is by using Android's VPN options for "Always-on VPN" and "Block connections without VPN", but it just ends up blocking it and it still does not want to traverse the VPN.
I have it working correctly with WireGuard VPN.
@foxcpp What Android version ? Are you using an IRC bouncer ?
Revolution isn't working on Android 9. Only get messages if "force stop" the app, then on restart, receive the ZNC bouncer buffer. Then no more messages until "force stop" and restart the app again.
Think HoloIRC doesn't work either. So wonder if a lot of clients are using the same bad IRC library in their source.
I use Android 9 and a bouncer. I'm not sure exactly if I lose any messages - never noticed it being the case. I do not keep it always running though.
A point worth considering is that (unlike most mobile apps) IRC uses a single continuous TCP stream, so connection changes are visible to the IRC client, and can't be hidden from the user.
This means that:
- switching from WiFi to UMTS or vice versa;
- changing WiFi AP;
- any upsteam NAT change; and
- connecting or disconnecting a VPN
will all disrupt an in-flight IRC session.
Moreover, some changes will result in "silent" failure, where both ends believe the connection is still "up" but no traffic can be exchanged. Timeouts in that case range from minutes to hours.
A VPN that isn't always-on, especially if it is triggered by a connection attempt, may disrupt the connection.
That might not apply if the connection can be brought up fast enough, which may explain why Wireguard is seemingly less affected than other VPN types.
In addition Android on some versions of the platform actually keeps the mobile connection up for a while longer when switching to wifi as far as I am aware. (re to reconnects on connection changes)
Buried in the developer options, one can elect to have the UMTS module remain turned on even while WiFi is connected, with the intention that "switching" is much faster (at some battery cost).
The UMTS connection is hidden from apps so they are not aware that the device is concurrently multi-homed. (I've tried to prevent session breakage by using iproute2 policy routing to ensure that an IRC session "sticks" to the mobile connection even when WiFi or USB data is up, but so far to no avail.)