First let me make it clear this post is on dropbox as used in a Linux environment, specifically for this post Fedora (Fedora 32). Dropbax clients may behave differently in different environments.
What is lansync
The dropbox reference pages promote lansync as a way of saving external bandwidth, in that if a file is updated it can be replicated to other machines replicating that folder across the local subnet/network without each local client needing to retrieve the changed file from the dropbox servers.
Ports lansync and dropbox use
A DuckDuckGo search of “dropbox lansync port numbers” returns the following pages.
The description of lansync is that it wants port 17500 on both udp and tcp.
(reference https://help.dropbox.com/installs-integrations/sync-uploads/lan-sync-overview)
Or 17500 only on tcp (reference https://dropbox.tech/infrastructure/inside-lan-sync)
From observation it uses port 17500 on udp, tcp, and tcp6
[mark@hawk bin]$ netstat -an | grep 17500 [mark@hawk bin]$ dropbox lansync y [mark@hawk bin]$ netstat -an | grep 17500 tcp 0 0 0.0.0.0:17500 0.0.0.0:* LISTEN tcp6 0 0 :::17500 :::* LISTEN udp 0 0 0.0.0.0:17500 0.0.0.0:*
However, due to the extensive logging on run on one of my servers, a server which does not run dropbox, only udp appears to be used. Worse, dropbox never tops trying, two machines run dropbox and each are retying a server that will never respond at thirty second intervals
Sep 17 14:49:24 mdickinson kernel: DROPPED IN=ens3 OUT= MAC=ff:ff:ff:ff:ff:ff:50:b7:c3:20:19:8f:08:00 SRC=192.168.1.9 DST=255.255.255.255 LEN=161 TOS=0x00 PREC=0x00 TTL=64 ID=34187 DF PROTO=UDP SPT=17500 DPT=17500 LEN=141 Sep 17 14:49:33 mdickinson kernel: DROPPED IN=ens3 OUT= MAC=ff:ff:ff:ff:ff:ff:74:d0:2b:92:f4:f7:08:00 SRC=192.168.1.187 DST=255.255.255.255 LEN=161 TOS=0x00 PREC=0x00 TTL=64 ID=7163 DF PROTO=UDP SPT=17500 DPT=17500 LEN=141 Sep 17 14:49:54 mdickinson kernel: DROPPED IN=ens3 OUT= MAC=ff:ff:ff:ff:ff:ff:50:b7:c3:20:19:8f:08:00 SRC=192.168.1.9 DST=255.255.255.255 LEN=161 TOS=0x00 PREC=0x00 TTL=64 ID=54938 DF PROTO=UDP SPT=17500 DPT=17500 LEN=141 Sep 17 14:50:03 mdickinson kernel: DROPPED IN=ens3 OUT= MAC=ff:ff:ff:ff:ff:ff:74:d0:2b:92:f4:f7:08:00 SRC=192.168.1.187 DST=255.255.255.255 LEN=161 TOS=0x00 PREC=0x00 TTL=64 ID=21945 DF PROTO=UDP SPT=17500 DPT=17500 LEN=141 Sep 17 14:50:24 mdickinson kernel: DROPPED IN=ens3 OUT= MAC=ff:ff:ff:ff:ff:ff:50:b7:c3:20:19:8f:08:00 SRC=192.168.1.9 DST=255.255.255.255 LEN=161 TOS=0x00 PREC=0x00 TTL=64 ID=2628 DF PROTO=UDP SPT=17500 DPT=17500 LEN=141 Sep 17 14:50:33 mdickinson kernel: DROPPED IN=ens3 OUT= MAC=ff:ff:ff:ff:ff:ff:74:d0:2b:92:f4:f7:08:00 SRC=192.168.1.187 DST=255.255.255.255 LEN=161 TOS=0x00 PREC=0x00 TTL=64 ID=26919 DF PROTO=UDP SPT=17500 DPT=17500 LEN=141
Note: when dropbox is running it also uses ports 17600 and 17603, although these are bound to localhost so not a risk as long as you have those ports open for access from localhost (yes I do have some firewall rules that prevent access to services from localhost). That is documented at https://help.dropbox.com/installs-integrations/desktop/configuring-firewall
root@hawk ~]# netstat -an | grep 176 tcp 0 0 127.0.0.1:17600 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:17603 0.0.0.0:* LISTEN
Nowhere can I find documentation on when and why dropbox will use port 17601/tcp. However on multiple occasions on multiple machines I have seen port 17601 tcp in use by /home/mark/.dropbox-dist/dropbox-lnx.x86_64-105.4.651/dropbox (identified by ‘netstat -anp’ and querying the pid; note also seen on earlier versions of dropbox), although only on localhost (only listening on 127.0.0.1). And it appears to stop listening immediately when lansync is turned off ?.
The same cannot be said for the udp port 17500, turning off lansync stops the 30 second polling but leaves the local udp port open until dropbox is restarted.
[mark@hawk bin]$ dropbox lansync n [mark@hawk bin]$ netstat -an | grep 17500 udp 0 0 0.0.0.0:17500 0.0.0.0:* [mark@hawk bin]$ dropbox stop Dropbox daemon stopped. [mark@hawk bin]$ dropbox start [mark@hawk bin]$ netstat -an | grep 17500 [mark@hawk bin]$ dropbox status Up to date [mark@hawk bin]$
It is probable that it uses udp to find machines, and tcp to transfer data.
Why not to use lansync, and when it may be ok
In a small replication environment where there may be only two or three machines replicating a folder if the file changes are small it is probably going to generate less network traffic by having all machines use the dropbox servers as the source for the changed file; especially as whichever machine changes the file will push it to the dropbox servers anyway.
Also in a small replication environment where there may be only a few users replicating the directory contents having those few users running lansync to poll every machine in the local subnet every thirty seconds is a large overhead (there may be hundreds of machines on the local subnet having to put up with all the polling).
Then of course there may be other small groups all doing the same thing causing a lot of needless broadcast udp traffic.
In environments such as this the preferred solution would be to do something like have an ownCloud or nextCloud server for each small group, all that needs is a single http server and each group could be assigned its own unique url to their own copy of it. Yes both of those two file sync software products also have clients that perform extensive polling, but only to the ownCloud/nextCloud server they are configured to use if they are doing file syncronisation rather than to every server and desktop in the local subnet/network. And if the files should be on dropbox, that one server can push them there; with maybe one ‘manager’ interacting with dropbox to manage conflicts.
In a large environment lansync would make sense if the majority of users on the same subnet were all interesting in replicating the same set of files. However I would think such a situation would be the exception rather than the norm.
It would also make sense in an environment where internet bandwidth is constrained or chargeable as while generating a lot of additional traffic on the local subnet it should cut down on external internet traffic, although one copy would always be uodated on the dropbox servers.
The main issue with lansync
The main issue with lansync is that is enabled by default. For home users with a small local network of a few PCs, maybe a TV, possible a couple of cell phones and maybe a laptop or tablet, connected to your default home router; having all those devices spammed with UDP traffic every thirty seconds simply because one device may have had dropbox installed on it is a pretty bad default.
In a large commercial environment even where lansync may make sense having it spam from install time before admins get around to setting up routing/firewalls/filtering also seems like a bad default; it should default to off in both large and small environments and turned on if needed.
However as toggling it is as sinple as using the commands ‘dropbox lansync n’ and ‘dropbox lansync y’ it is only an issue if users do not know that is is enabled by default. I only discovered it was the default when the firewall logs on one of my servers starting dropping traffic on port 17500 and I investigated where it was coming from.
Disclaimer
I do use dropbox for personal use, there are some files I want to guarantee a copy of should all my servers suddenly die, as it is only on a desktop and laptop (laptop normally powered off) I have disabled lansync.
A second desktop is just manually kept in sync by copying changes to important files in the dropbox folder to an ownCloud folder syncing across all my desktop machines; and of course bacula does daily backups of both.
For important files do not rely on one solution. An if you are syncronising files across multiple desktops use a solution that does not broadcast udp traffic to servers, TVs, cell phones etc as that is a needless overhead that you do not want; if you use dropbox at home disable lansync.
