Replace old waitForTunnelUp function

[Rawa]

After invoking VpnService.establish() we will get a tunnel file descriptor that corresponds to the interface that was created. However, this has no guarantee of the routing table beeing up to date, and we might thus send traffic outside the tunnel. Previously this was done through looking at the tunFd to see that traffic is sent to verify that the routing table has changed. If no traffic is seen some traffic is induced to a random IP address to ensure traffic can be seen. This new implementation is slower but won't risk sending UDP traffic to a random public address at the internet.

---

This change is 

[Pururun]

Reviewed 9 of 9 files at r1, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @Rawa)

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 145 at r1 (raw file):

        // send traffic before the routes are set up. Otherwise we might send traffic
        // through the wrong interface
        runBlocking { waitForRoutesWithTimeout(config) }.bind()

Is this main/ui thread blocking?

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 184 at r1 (raw file):

                connectivityListener.currentNetworkState
                    .map { it?.linkProperties }
                    .distinctUntilChanged()

Is distinct until change required if we have first?

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 210 at r1 (raw file):

    companion object {
        const val FALLBACK_DUMMY_DNS_SERVER = "192.0.2.1"
        private val ROUTES_SETUP_TIMEOUT = 5000.milliseconds

What is the motivation for this timeout length?

[Rawa]

Reviewable status: 8 of 9 files reviewed, 3 unresolved discussions (waiting on @Pururun)

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 145 at r1 (raw file):

Previously, Pururun (Jonatan Rhodin) wrote…

Is this main/ui thread blocking?

Previously this function has also been blocking (with wait_for_tunnel_up in Rust), I believe the tunnel is opening from daemon with runs on a separate thread, but we should ensure and verify this so we don't block UI.

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 184 at r1 (raw file):

Previously, Pururun (Jonatan Rhodin) wrote…

Is distinct until change required if we have first?

Correct, this was lingering since how it worked in the previous implementation.

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 210 at r1 (raw file):

Previously, Pururun (Jonatan Rhodin) wrote…

What is the motivation for this timeout length?

Generally it should be a timeout for how long we reasonable think a system should take until it's routes are setup, previously there was a timeout of 60 seconds. However, that timeout was based on the expected time to able to send a single udp packet successfully.

[Rawa]

Reviewable status: 8 of 9 files reviewed, 3 unresolved discussions (waiting on @Pururun)

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 145 at r1 (raw file):

Previously, Rawa (David Göransson) wrote…

Previously this function has also been blocking (with wait_for_tunnel_up in Rust), I believe the tunnel is opening from daemon with runs on a separate thread, but we should ensure and verify this so we don't block UI.

Verified by adding a sleep, it does not block UI.

[Rawa]

Reviewable status: 8 of 9 files reviewed, 3 unresolved discussions (waiting on @Pururun)

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 210 at r1 (raw file):

Previously, Rawa (David Göransson) wrote…

Generally it should be a timeout for how long we reasonable think a system should take until it's routes are setup, previously there was a timeout of 60 seconds. However, that timeout was based on the expected time to able to send a single udp packet successfully.

If we reach this timeout I believe we should consider the tunnel broken, and enter error state.

[kl]

Reviewable status: 8 of 9 files reviewed, 4 unresolved discussions (waiting on @Pururun and @Rawa)

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 158 at r2 (raw file):

        }

    private fun Builder.addDnsServerE(dnsServer: InetAddress) =

Personal preference, but I think it's clearer to write out the return type explicitly for all functions. Also maybe call this function addDnsServerEither would be clearer?

[Pururun]

Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Rawa)

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 145 at r1 (raw file):

Previously, Rawa (David Göransson) wrote…

Verified by adding a sleep, it does not block UI.

⭐

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 210 at r1 (raw file):

Previously, Rawa (David Göransson) wrote…

If we reach this timeout I believe we should consider the tunnel broken, and enter error state.

Agree on the error state if timed out. Since it "should" be fast I think it is ok with a rather short timeout, but some phones are still very slow so a good idea to test this on multiple devices.

[Rawa]

Reviewable status: 8 of 9 files reviewed, 1 unresolved discussion (waiting on @kl and @Pururun)

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 210 at r1 (raw file):

Previously, Pururun (Jonatan Rhodin) wrote…

Agree on the error state if timed out. Since it "should" be fast I think it is ok with a rather short timeout, but some phones are still very slow so a good idea to test this on multiple devices.

Agree, it should be tested on multiple devices. Along with leak tests. Once reviewed by us I'll go through it with @pinkisemils as well.

---

android/lib/talpid/src/main/kotlin/net/mullvad/talpid/TalpidVpnService.kt line 158 at r2 (raw file):

Previously, kl (Kalle Lindström) wrote…

Personal preference, but I think it's clearer to write out the return type explicitly for all functions. Also maybe call this function addDnsServerEither would be clearer?

Renamed it to addDnsServerSafe to align with prepareVpnSafe and establishSafe. Would like to avoid the Safe-part and just let the signature speak for it self unfortunately it can't distinguish between the functions then. :(

[kl]

Reviewed 8 of 9 files at r1, 1 of 1 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved