search

mozilla-mobile / mozilla-vpn-client

A fast, secure and easy to use VPN. Built by the makers of Firefox.
https://vpn.mozilla.org
Other
453 stars 108 forks source link

Unable to set up TP-Link Kasa IOT devices (which use temporary wireless network), when connected to Mozilla VPN #3683

Open dholbert opened 2 years ago

dholbert commented 2 years ago

STR:

  1. Have a TP-Link K115 Smart Switch, e.g. Amazon link here
  2. If the switch isn't already in "initial setup" mode, then hold down its power button for ~5 seconds so that it enters this mode. (Eventually it will flash orange and blue)
  3. On your Android phone, with Mozilla VPN turned on, open the TP-Link Kasa app and follow its "add a new device" flow. (Tap "+" icon in top right corner, then "Device", and then "Smart Plugs", and then "Smart Plug Lite / Mini")

ACTUAL RESULTS:

EXPECTED RESULTS No such interference; I'd like my smart switch to get set up properly.

Note, I'm using Mozilla VPN with "Local network access" checkbox checked in Network Settings, and with "default" selected in Advanced DNS Settings. ("Automatically use Mozilla VPN-protected DNS") As a guess/shot-in-the-dark, I also tried choosing "Custom" as my DNS provider and I entered in the smart-switch temporary-wifi-network's "default gateway" IP address, 192.168.0.1, in case it's e.g. trying to resolve some special domain via DNS on the smart-switch -- but that didn't change my outcome at all.)

┆Issue is synchronized with this Jira Bug

dholbert commented 2 years ago

Also notable, my carrier is Google Fi which also provides a VPN.

If I have that VPN active in my Android settings (instead of Mozilla VPN), then I get "EXPECTED RESULTS"; the smart switch sets up just fine.

dholbert commented 2 years ago

Here's a portion of my logcat when this issue is happening (when the Kasa app is just spinning while showing "Connecting to Smart Plug", doomed to never finish connecting): logcat-snippet.txt

Here's the most-relevant (I think?) piece of the snippet, showing Kasa trying and failing to connect to some network service:



06-06 12:09:07.381 27025  1678 W System.err: java.net.SocketException: Binding socket to network 143 failed: EPERM (Operation not permitted)
06-06 12:09:07.381 27025  1678 W System.err:    at android.net.Network.bindSocket(Network.java:442)
06-06 12:09:07.381 27025  1678 W System.err:    at android.net.Network.bindSocket(Network.java:391)
06-06 12:09:07.381 27025  1678 W System.err:    at com.tplink.sdk_shim.net.KasaTDPSocketProvider.bindSocketToNetwork(KasaTDPSocketProvider.java:59)
06-06 12:09:07.381 27025  1678 W System.err:    at java.lang.reflect.Method.invoke(Native Method)
06-06 12:09:07.381 27025  1678 W System.err:    at com.tplinkra.tpcommon.discovery.TDPClient.bindDatagramSocket(TDPClient.java:354)
06-06 12:09:07.381 27025  1678 W System.err:    at com.tplinkra.tpcommon.discovery.TDPClient.openTDPDataChannel(TDPClient.java:166)
06-06 12:09:07.381 27025  1678 W System.err:    at com.tplinkra.tpcommon.discovery.TDPClient.access$800(TDPClient.java:42)
06-06 12:09:07.381 27025  1678 W System.err:    at com.tplinkra.tpcommon.discovery.TDPClient$12.accept(TDPClient.java:130)
06-06 12:09:07.381 27025  1678 W System.err:    at com.tplinkra.tpcommon.discovery.TDPClient$12.accept(TDPClient.java:126)
06-06 12:09:07.381 27025  1678 W System.err:    at io.reactivex.internal.observers.c.onSubscribe(DisposableLambdaObserver.java:42)
data-sync-user commented 1 year ago

➤ Sarah Bird commented:

Santiago Andrigo good to get your take on priority here. Eng take is low (workarounds exist - turn off vpn while doing initial setup).

data-sync-user commented 1 year ago

➤ Santiago Andrigo commented:

Do we understand why this is happening? If LAN bypass is enabled, why wouldn’t the client be able to talk to the device?

birdsarah commented 1 year ago

@dholbert sorry for the delays getting back to you.

Can you try enabling Local Network Access under the Network settings:

Hopefully this works, we've decided to remove this setting and turn Local Network Access on by default in an upcoming release to help prevent user issues like this.

If this doesn't work, please let us know.

birdsarah commented 1 year ago

@dholbert sorry I just re-read your initial message and you had already tried that.

We would be interested to hear if you're still having this on 2.11or 2.12 (2.12 is coming out next week)...but off the top of our heads we're not sure what's causing this if you've already tried LAN Bypass.

dholbert commented 1 year ago

Hi @birdsarah ! Sure, I'll retry with 2.12 next week or so.

For what it's worth: I did try with whatever the current version was ~2 weeks ago (maybe that was 2.11?) when setting up some Christmas lights on a new smart-plug, and I did confirm that I was still seeing this issue at that point. (Though there's now one minor mitigation: now the Kasa app has a note suggesting to disable any VPN apps when it fails to find the smart plug. So hopefully affected users won't get blocked by this for too long, with Kasa devices at least.)

birdsarah commented 1 year ago

Thank you for the update @dholbert.

If you're able to get logs (https://support.mozilla.org/en-US/kb/debugging-mozilla-vpn#w_how-to-export-logs-on-mozilla-vpn) and post them here when you try again that would be amazing....I'll be honest this isn't super high on our todo list but having the logs will give us the most info possible when someone comes to pick this up.

If you uninstall and reinstall the app before doing the 2.12 test that will delete the old logs and give us a clearer picture of what happened just for the test...it might also help by giving a fresh start with all your settings...but no obligation.

Thanks for your engagement.

dholbert commented 1 year ago

I can still reproduce in version 2.12.0 (installed today; I uninstalled + reinstalled as-suggested, and enabled local network access in the Network Settings area).

I exported a log from the Mozilla VPN app, but nothing interesting appeared around the time when I performed the STR, so I'm not bothering to attach it. In particular: I went through the STR, reaching the doomed-to-fail searching-for-devices part of the Kasa app flow at timestamp 12:02 PM, right on the dot, with the Kasa "EPERM" system error logging (noted above appearing right around then as well.

The next line in the Mozilla VPN log had a timestamp about a minute later. Here are the two adjacent entries in my log that straddle the issue (the first one seems to be from me switching apps from Mozilla VPN over to Kasa):

[19.12.2022 12:01:38.218] Debug: (android - AndroidGlean) App Going in the Background, trigger sending due pings
[19.12.2022 12:02:58.158] Debug: (networking - ConnectionHealth) Resuming connection check from Suspension

So, Mozilla VPN doesn't seem to have any interesting log output that's triggered by this issue, unfortunately.

dholbert commented 1 year ago

Totally fine-by-me that this isn't high-priority and might not get looked at soon. :) Having said that: I have spare devices and live in the SF bay area, if any of our Mozilla VPN devs who might-be-interested-to-investigate happen to live nearby. Alternately/also, they can be had for $10-20 on Amazon depending on sales/etc; the device linked in my initial post is currently $13 USD.

I also did a websearch for the EPERM error that Kasa is failing with, and I found some mentions of an allowBypass API that VPN apps can use to allow devices to access the local network. References: https://stackoverflow.com/a/59073918 https://github.com/schwabe/ics-openvpn/issues/1058

Not sure what our local-network-access APIs are, but I did notice that I don't see any calls to this allowBypass API in our code: https://github.com/search?q=repo%3Amozilla-mobile%2Fmozilla-vpn-client%20allowBypass&type=code ...though I do see a call in e.g. ics-openvpn, the app whose issue I linked above: https://github.com/schwabe/ics-openvpn/blob/f07066d047562f1fae9618ffc5af1f940d733967/main/src/main/java/de/blinkt/openvpn/core/OpenVPNService.java#L1070