A year ago, I fired up wire shark on my home network to check out the packet flow of the DHCP process. I closed all my browser windows and other chat/im services, and still noticed a lot of chatter on the network. One that got my particular attention was a packet that was related to the popular service dropbox. I had not updated/edited any files recently, so was surprised to see it. I then decided to dig a little more on wire shark and with some google search came to the conclusion that it was a dropbox feature to sync data changes within the local network.

Earlier today(yes 1 year later) I decided to spend some more time looking at the traces and try to figure out the details of the LAN sync protocol. After an hour or so I believe that the following steps are involved in Dropbox’s LAN syncing -

1. Discovery (LAN sync discovery protocol)

The dropnbox process running on your computer sends a UDP broadcast packet in the local network every 30 seconds. The source and destination port of the packet are set to 17500. This UDP packet has some payload attached to it for identify itself to the receiver. It seems like a dictionary.

"Text": {
    "host_int": 14xxxx52,
    "version": [1,8],
    "displayname": 14xxxx52,
    "port": 17500,
    "namespaces": [263xxxx, 152xxxxx, 152*****] 
}

The Macbook was sending every 30 seconds. However, on my Win7 laptop, it seemed like there was an initial rampup time where intervals started with 22 seconds and only after 5 mins they became 30 seconds.

2. Exchange Data (LAN sync protocol)

If all the dropbox clients have LAN sync enabled, then each of them should be able to understand and respond to the Discovery packet (assuming it’s able to distinguish between different user accounts. I believe it uses namespaces to identify them uniquely). This response packet called DB LAN sync (DB-LSP) is a TCP packet where the dropbox clients exchange data.

This first DB-LSP based TCP packet is destined to the other client on port 17500. The source port is an ephemeral port (say 49373) to which the receiver will send its reply. These are set to type 23. My guess is that these basically exchange information if there is data to be synced or not between the clients. If there is data to be synced, there will be some configurations that need to be exchanged to send them securely/encrypted across the local network. This is probably sent using DB-LSP packets set to type 22.


Dropbox LSP Sync Protocol

   0 - 7     8 - 31       32 - 63
+--------+-------------+--------------+
| TYPE   |    MAGIC    |   LENGTH     |
+--------+-------------+--------------+
|                                     |
|              DATA                   |
+-------------------------------------+

TYPE: 
    Decimal   Hex   Meaning
           20       14    <Unknown>
           22       16    Configuration
           23       17    Data
          128       80    <Uknown>

MAGIC:
    Decimal  Hex  
    769      0301

I quickly wrote this to share my notes on the analysis. Feel free to correct me in any of the assumptions. Also, pardon me for any spelling/grammar mistakes.

PS: If you would like to experiment this on your home network, you could use the following filter to get rid of the noise.

udp.port == 17500 or (ip.addr==mahcine1-ip and ip.addr==machine2-ip)