Unable to transfer file or send message, when devices are visible to each other

[terrytw]

I have discovered that when using Adguard (an adblocker working as a VPN that does not change public IP address, or tunnel network traffic at all for that matter) on my android phone, my desktop computer's browser and the mobile browser on my Android phone will be able to see each other, but I won't be able to send messages or files across.

I have also tried using openvpn to connect to my home network when using mobile data, normally per my setup, my phone would be considered in the same subnet as other devices on my home network, I would be able to connect to local smb files on my NAS, I would get the same public IP address as my other home devices, but I would not be able to send anything through snapdrop at all, I can see other device on the webpage and vice versa, but won't be able to send files.

Can the dev please kindly point me the right direction as to why this happens and if there is any potential fix from my side?

[nogarcia]

I've yet to test this out myself (I might get to it today, certainly this weekend,) but I've found a few bits of documentation and one forum post online that lead me to believe that Adguard may be blocking WebRTC (which Snapdrop uses) as a method of discouraging IP leaks. It may also block Websockets too, which would make more sense with your problem: peer discovery working but not transfer.

As far as I can tell from first glance as a non-Adguard user, there's no way to let Snapdrop past this short of disabling WebRTC blocking altogether, but I'll look into it soon. TL;DR: Adguard blocks WebRTC; disabling this may fix your problem.

[terrytw]

Thanks for the response! Much appreciated!

I was aware of the WebRTC blocking function, I did disable it in Adguard, but problem persists. In fact I disabled every single blocking function in Adguard, leaving only the VPN itself, but problem still persists.

However a little update on OpenVPN, I did some poking around, and manage to make it work. So it is not all VPN functions, it's just Adguard's VPN fucntion somehow interfering with snapdrop.

[nogarcia]

I'll see if I can get reproduce the problem and get a logcat this weekend to track down what exactly's being blocked.

[iaeiou]

Thanks for the hint @terrytw , I had the same issue and disabled NetGuard - everything works fine now

[gene1wood]

I had the same issue with uBlock Origin, disabled it on snapdrop.net on both devices and the problem was solved.

[terrytw]

Thank you guys, for you input. Glad to know that I am not alone on this.

I think Netguard and Adguard are quite similar, a VPN working on Android phones that routes traffic through itself.

Not quite so sure about uBlock Origin though, because I have it on both my desktop PC's chrome and Android phone's Firefox browser, it does not seem to cripple snapdrop.

[TheBlackRoom]

I just discovered this issue myself and wondering if anyone found a fix?

I have Adguard installed on Windows and Android and I'm finding my Windows desktop is unable to receive or transmit, but the Android phone does work to/from another person's Android phone (it may be irrelevant but the other phone did not have Adguard installed). Obviously the Adguard settings and config are slightly different between computer and phone platforms but it makes me wonder why the phone can manage to do Snapdrop.

I opened three browsers on the Win10 computer and even though all devices/browsers can see and show each other with Snapdrop, the sending/receiving part does not work (except phone to phone).

I do have uBlock Origin installed in my browsers but I don't think that is the issue whether enabled or not. Tried disabling Adguard in the browser and also WebRTC via the Windows Adguard App but it made no difference.

Is that it for Snapdrop then on my Windows desktop, will it never work with Adguard installed?

[BeecherNetworks]

Same problem here, Adguard disabled, uBlock disabled, no go on Firefox.

[Bellisario]

I've sometimes the same problem... The problem is in WebRTC called in a "wrong" state: stable (?!).
I don't know what is the problem!

[iaeiou]

I've tried again today, it's working fine with

• on the computer: Firefox 86.0.1 on Debian 10 - Ublock origin is turned on, Noscript is turned off
• on the smartphone: Fennec F-droid 84.1.0

Thx!

[terrytw]

I have done some investigation, and come up with my assumption, which was confirmed by Adguard devs.

I believe this is a problem between Adguard and ICE services like TURN and STUN. When using these services, clients need to report their local IP addresses for the possibility of a direct connection. However when using Adguard in VPN mode, it creates an IP adress of 172.18.11.218. Client would report this IP to TURN or STUN servers, other peers would try to connect to client using 172.18.11.218 instead of the actual private IP address that the client has (like 192.168.1.100)

If snapdrop could detect the real local IP address instead of the fake IP, this issue could be resolved.

Adguard devs said there was nothing they can do about it. AdguardTeam/AdguardForAndroid#3778

[Fabian665]

This issue hasn't been updated in a while but maybe I can add something to it.

I am using the android client installed from f-droid on my phone and my tablet, on my phone I also have NetGaurd enabled.

these are the results trying to send between devices:

to\from	Brave on PC	Firefox on PC	Chrome on PC	Android client on phone	Android client on tablet
Brave on PC	irrelevant	X	X	X	X
Firefox on PC	X	irrelevant	V	X	V
Chrome on PC	X	V	irrelevant	V	V
Android client on phone	X	V	V	irrelevant	V
Android client on tablet	X	V	V	V	irrelevant

A few notes:

1. All devices discovered all the other devices.
2. On Brave I have webRTC disabled for non proxied UDP so the results are not surprising.
3. I have NetGaurd enabled on my Phone but not on my tablet.

I hope this helps

[vmiheer]

I was facing similar issue with Windows + Firefox laptop <-> Safari + iPhone. Disabling adguard on both devices and in safari clicking on "aA" symbol in the url bar and choosing "show ip" option helped.