Crashplan on Synology Diskstation – successfully setting QoS DSCP values to de-prioritize upload traffic

Way back in June 2012 I wrote about how you could set QoS (Quality of Service) DSCP values on Crashplan traffic on Windows, not by using the ineffective settings within Crashplan, but by using the group policy tool to tag traffic coming from the CrashplanService.exe process itself. In other words, I never found a way to make the Crashplan setting work, but the work around was pretty solid.

Earlier this year I acquired a Synology DS415Play diskstation, a decent NAS which could store the constant accumulation of photos, video clips and music, but I also installed the excellent Crashplan package from PCLoadLetter on it in ‘headless’ fashion using Scott Hanselman’s guide. Shortly afterwards I again needed to tag the crashplan traffic with a DSCP value so that the bulk upload traffic could be deprioritized to prevent it crippling my internet connection for other contending devices.

This post explores how to work around a serious bug (again!) in the Crashplan QoS settings, monitor the traffic via ssh and finally being able to successfully set the Differentiated Services Code Point (DSCP) values for upload traffic for QoS. This then allows you de-prioritize Crashplan traffic at your router and so leave you internet connection fast and responsive for other clients and applications. See previous post of how to do this with a Draytek SOHO router.

Setting QoS values

This should be straightforward – configure the Crashplan desktop client to connect to our headless NAS, and change the QoS settings:


I’ll skip the predefined options for now, and select the DSCP option. From previous experience with Crashplan on windows, I tried an DSCP decimal value of 10. Note that the prompt says ‘DSCP decimal value’.


After making this change you must restart the service for it take effect. Within the Synology interface, open the package manager, select the Crashplan package, then stop and restart the service. You’ll need to reconnect any connected Crashplan desktop clients as they will immediately disconnect when the service is stopped.

I then tried to selectively monitor this tagged traffic using my Draytek router as described in a previous post but without success. The traffic wasn’t showing up in my QoS filter, instead it appeared untagged with everything else.

Viewing TCP packet headers

Previously with windows I used NetMon to catch and view TCP packets within windows itself. Seeing packets coming from the NAS device headed for Crashplan central required a different approach.

If we enable SSH within the Synology control panel, we can use a Telnet/SSH client such as Putty to get to the NAS command prompt. I’m a complete Linux novice, but I found that when prompted by Putty I had to login with the user ‘root’ using the password I’d set for the ‘admin’ account.  If I logged in as admin I’d reach the command prompt but with insufficient permissions for the following commands.


From the command line we can use tcpdump to output packet information from crashplan’s upload.

DiskStation> tcpdump -i eth0 tcp dst port 443 -c 3 -vvv

This will capture packets on ethernet interface ‘eth0’, TCP packets (ignore UDP), to the destination port 443 only, capturing just three packets, output verbose level 3 (more detail than -vv or -v  etc)


The nearest thing we can look at is the tos bytes but unfortunately no matter how you look at it,  0x0 is zero, and not what we’re expecting.  This excellent table of QoS and DSCP correlations is very useful.

Qos Tos DSCP binary hex decimal coversion chart

Qos Tos DSCP binary hex decimal conversion chart. Credit:

The workaround – set ToS decimal not DSCP decimal value

Based on a tip in the comments of my previous post, I tried setting the ToS decimal value that correlates to the desired DSCP value rather than the decimal DSCP value itself. Hey presto, setting a value of ’40’ in crashplan gives us this :


So setting ’40’ gives us a tos hex value 0x28. Which looking at the linked table correlates to a decimal DSCP value of  10. This was then successfully picked up by the router.

Trying other values also works as expected. Crashplan on my laptop was already generating DSCP 10 tagged traffic (AF11 or AF1 Low drop). In order to differentiate the NAS I set it to ’48’ which correlates to DSCP value of 12 (AF12 or AF1 medium drop). This also worked as expected. Note that between any of these changes I had to stop and restart the package service within the Synology web interface, then reconnect the disconnect Crashplan client, then wait for the upload to start again. At this point we can run the tcpdump again.

So it seem there is a flat-out bug in the Crashplan GUI setting in that it specifically asks for the DSCP decimal value, but treats it as the TOS decimal value.

What about the predefined values ‘low, ‘normal’, ‘throughput, reliability’ ?

While I was at it, I explored what those predefined QoS labels actually did :

NAS Crashplan value of ‘low’ = tos 0x00
NAS Crashplan value of ‘normal’ = tos 0x00
NAS Crashplan value of ‘reliability’ = tos 0x4 (DSCP decimal 1)
NAS Crashplan value of ‘throughput’ = tos 0x8 (DSCP decimal 2)

In DSCP terms, values of 1 or 2 are not really meaningful.

The ideal DSCP value for Crashplan upload traffic is perhaps a value of 8 (use 38 to get this) as this is described as a scavenger class that uses unused bandwidth but has no priority over anything else. See the table below


In my case I previously used a DSCP value of 10 rather than 8 because the quirky Draytek interface doesn’t have any selectable option for ‘CS’, only ‘AF’ variants or ‘EF’ are selectable. AF11 (Draytek described this as ‘AF1 low drop’ is DSCP 10.

I hope this helps others in a similar situation to get QoS DSCP working on their NAS working, and perhaps explain what appears to be a crashplan GUI bug

Leave a Reply

Your email address will not be published. Required fields are marked *