Partially working under local network.

[LEXUGE]

I have a computer which uses hostapd to host a Wi-Fi to Wi-Fi hotspot (in this way the computer is like a router). Also on this computer (192.168.12.1), I use docker to deploy the snapdrop server. Then, I have an iPad and an iPhone connected to my local network hosted by my computer.

Open the snapdrop on all these three devices:

1. if my computer is connected to the world Internet (which also means other two are then connected two), then all features in all direction between devices work.
2. if my computer is not connected to the Internet (which means only local communication is available), then iPad <-> iPhone transfer works, iPad/iPhone -> computer works, but NOT computer -> iPad/iPhone.

The console log on my computer (under scenario 2) says ICE gathering failed, and it advises me to add a TURN server.
Also, UI says that I am offline not surprisingly.

I am not sure why could other two devices transfer files but not my computer since all are under the same local network.

[LEXUGE]

It seems like to be a Firefox only issue. On chrome, there is no You are offline, and it transferred. I hope it can work on firefox as well.
BTW, for big files (300 Mb) that I tested, Safari on iPad encounters "internal error".

[LEXUGE]

Related issue on bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1659672

[najtin]

There may be some problems here.

1. Snapdrop puts you in a room with the clients having the same ip, which are usually clients that are behind the same NATed router. Client 1 connects to a publicly available snapdrop server with the IP of the router (see NAT). The snapdrop server puts it in a room for all clients with the ip of the NATing router. Client 2 connects to the snapdrop server and ends up in the same room. Now the devices can see each other in the UI. Now, if the snapdrop server runs in the same LAN, than the clients connect with different ips, and they end up in a different room. If you did not see this behavior with your snapdrop server, something is odd. It might work in your case, because of how the WIFI-Hotspot is implemented, i can't really tell.

2. The way snapdrop is setup right now, it uses a stun-server. The stun-server coordinates the clients and tells them their real ip (intended for NATed networks). What happens in an offline situations, is that both clients try to connect to googles stun server (which is the standard stun-server in snapdrop). Since they are offline, they fail, thus the ICE gathering failed. Theoretically, this should also work in LAN without a stun server, but i couldn't get it to work in Firefox. (see also https://stackoverflow.com/a/32186448)

The solution to 1) is to alter some lines in the server code. My solution to 2) is to run a stun server in the LAN. I use coturn. I will soon upload my LAN version of snapdrop and write a document for the necessary configuration steps.

[LEXUGE]

Would you like to put out the solution of how to alter the sever code? I believe that should be a proper one. Else getting server inside docker can somewhat be unfriendly to existing complicated networking settings (like ones on my machine).
Also, since it's running in docker, I think WiFi hotspot already masquerades the packets, resulting in no issue described in 1).

[najtin]

yes, it will be done today

[najtin]

https://github.com/najtin/snapdrop-lan
Beware that this setup requires a STUN server in the LAN
These are the changes i made to snapdrop:
najtin@ddd80eb#diff-0861d6d6b50d7d695344bf2d86d6e5e6
najtin@58a5cb1
there seem to be an issue with the Firefox for Windows, works fine in Chrome and on Linux

[jarylc]

For my use case, since my instance URL is going to be private, I have opted for a single room mode where all peers can see each other when pointed to the same server.

Just replacing all instances of peer.ip and sender.ip in server/index.js with the same value works just fine for me. Albeit maybe not security wise, but I can always protect it with some form of authentication. In shell, running the 2 lines below in the source directory does everything you need to achieve this.

sed -i 's/peer.ip/0/g' server/index.js
sed -i 's/sender.ip/0/g' server/index.js

I've also spun up a public Docker image that will be mirrored and built by GitLab CI/CD here:
https://hub.docker.com/r/jarylc/snapdrop (src: https://gitlab.com/jarylc/snapdrop-docker)

You can run it with SINGLE_ROOM=1 environment variable and it will run the above before starting the server.

Take note that if you wish to use my image, I have opted to remove Nginx as I already have it on the host, but you can mount the container's /home/node/client directory to somewhere like /var/www/snapdrop on the host and it will automatically overwrite with the latest client version on an update.

EDIT: note that I have taken the Docker image down as I cannot find time to continue supporting it.

[hursey013]

Similar to @jarylc, my instance is private and accessible only within my LAN. I was already running a reverse proxy (Caddy) for local services so I found that by proxying requests to Snapdop and modifying the X-Forwarded-For header to the same value achieves the same results as modifying the server code. For reference, here's what I'm using with Caddy:

  @snapdrop host snapdrop.lan.mydomain
  reverse_proxy @snapdrop snapdrop {
    header_up X-Forwarded-For {host}
  }

[laukeng]

https://github.com/najtin/snapdrop-lan Beware that this setup requires a STUN server in the LAN These are the changes i made to snapdrop: najtin@ddd80eb#diff-0861d6d6b50d7d695344bf2d86d6e5e6 najtin@58a5cb1 there seem to be an issue with the Firefox for Windows, works fine in Chrome and on Linux

I have fixed the bug with Firefox.
When Firefox receives files, if it loads the page befor the sender, the received packet type is Blob. If Firefox loads later than the sender, the received packet type becomes Arraybuffer.Other browsers don't have this problem，no matter who opens it first, the received packets are Arraybuffer type. I don't know why.
Edit network.js,goto _onChunkReceived()
Just modify it as follows:
_onChunkReceived(chunk) {
if(!(chunk.byteLength || chunk.size)) return;

[CqN]

I see this thread is not active for many months. Hope somebody would respond.

I have a different setup than described here. I have a plain router with two chromeos notebooks and an android phone. All got snapdrop installed from snapdrop.net. Because I have synced my browser settings thru google, whenever I have chromeos, the snapdrop automatically appears as an installed app.

My problem is very slow file transfer speed. My internet connection bandwidth is extremely low (I have no control over this.) Based on the file transfer speed I experience thru snapdrop between two chromeos, I have a feeling the transfer is going thru the WAN side (perhaps may be thru my isp).

Every notebook or Android phone which are on my LAN see all of the other snapdrop machines.

1. How can I speed up my transfer?

2. How can I test if my transfer is going thru the WAN side?