You should probably avoid TP-Link products if you’re on a tight bandwidth budget. By design, TP-Link firmware sends six DNS requests and one NTP query every 5 seconds, for a total of 715,4 MB per month.
The firmware of some TP-Link repeaters — but not routers — including all 2017 models are very talkative on NTP, to a total of 715,4 MB per month. NTP is the network time protocol used to synchronize clocks across the web. To put this number in context: an always-on Windows device will use around 1,6 KB per month on NTP.
TP-Link’s firmware doesn’t have any sort of DNS caching, and they query DNS about 6 NTP server pool addresses every 5 seconds followed by an NTP request to one of them. An always-on Windows client sends 1 DNS and 1 NTP request once a week. (If you power cycle or suspend your device, it will send one additional request.)
This means your TP-Link product is using about 1,38 KB every 5 seconds — or 23,85 MBs per day — on timekeeping. For comparison, a 5-minute check would be considered a pretty aggressive checking interval, and would only consume 11,92 MB per month.
Update (): TP-Link have issued firmware updates to address this issue.
This behavior isn’t a bug from TP-Link’s perspective. They misuse DNS and NTP as a stand-in for an internet connectivity test feature. These types of tests are normally implemented over HTTP and only check against remote servers every 5–45 minutes.
The feature as TP-Link has implemented it’s overly aggressive, and they don’t even have the decency to direct the traffic at their own servers. Instead, they misuse public infrastructure provided by volunteers (like the NTP project pool servers), universities, and the US government.
TP-Link repeaters don’t seem to modify their behavior based on whether there’s a working internet connection or not. (Except for providing a DHCP server when they fail to detect another DHCP server, but that’s irrelevant for this discussion.) I may be mistaken, but as far as I’ve been able to observe by studying the network traffic and behaviors of my TP-Link RE650 – it only controls the string “Internet Status: Connected”. Wasting 715,4 MB per month for a single string on a web administration interface that the customer is only likely to visit once a year is outright stupid.
TP-Link has hardcoded the following non-configurable NTP servers and server pools in their firmware:
- time.nist.gov, time-a.nist.gov, time-b.nist.gov, time-nw.nist.gov
- au.pool.ntp.org, nz.pool.ntp.org
- 188.8.131.52, 184.108.40.206, 220.127.116.11
The first sets of servers are operated by the US National Institute of Standards and Technology (NIST). The second is the Australian and New Zealand public NTP project time server pools. The IP addresses are owned by universities in Japan, Colorado; US, and Sweden respectively.
The NTP Pool project asks device manufacturers and vendors to register (and optionally sponsor) their own pools through the service (e.g. tplink.pool.ntp.org), and emphasize that they “must absolutely not use the default pool.ntp.org zone names”. They also request that vendors don’t check more often than every 5 minutes at the most. I find it interesting that TP-Link chose to use the Australia and New Zealand server pools in their firmware globally.
The six DNS requests add up to about 75 bytes each with a median response size of 125 bytes. An NTP request is another 90 bytes plus a 90 byte response. Multiply this by one request per 5 seconds throughout the day, and then finally add up the monthly figure and you’ll end up at 715,4 MB.
The number can be reduced by about 15 % if your router has a caching DNS server and you’re extremely lucky with request timings. The NTP pool addresses have very short caching lifespans, and they may even have expired before they reach your router.
You can avoid buying TP-Link products to avoid this problem.
You can’t turn this behavior off in TP-Link’s web administration interface nor in their management app for mobile. You can’t change the NTP server addresses it targets either.
You can set up firewall rules rate-limiting your TP-Link product to one outgoing connection on UDP to port 123 (NTP) to limit the NTP traffic (which makes up for 93,31 MB out of the month total data usage).
You can likewise rate limit connections to the three hardcoded IP addresses. If your TP-Link product is running in access point mode, you can also safely limit its DNS queries (UDP out to port 53). Please note that this will also prevent you from checking for firmware updates on the device, and you’ll have to rely on TP-Link’s unreliable website to find firmware updates instead.
Your home router may not have the features required to configure firewall rules that meet these requirements. It’s not uncommon for network routers aimed at the home market only to have configurable incoming and not outgoing firewalls.
You should also complain to TP-Link Support. This is a broken feature that generates a ton of unnecessary data and they should fix it. To save everyone a bit of time, you may refer them to this article. (Send them the one linked above while you’re at it!)
715,4 MB isn’t trivial when you’re paying by the megabyte or you’ve a tight monthly data quota. This bug can run up a significant monthly cost for TP-Link customers who are on mobile, satellite, or other expensive internet connection options. Customers are also unlikely to be aware that it’s their TP-Link products that are secretly eating up their data quotas.
This is a small amount of data for a high-speed uncapped broadband consumer. However, let us wildly speculate that TP-Link has sold 100 million of these devices. That is 2,385 PB (petabytes) or 2385 TB (terabytes) per day transmitted to public DNS and NTP infrastructure. It’s starting to resemble a small distributed denial of service (DDoS) botnet attack by this point.
TP-Link sold 161 million devices in 2016, but it’s unspecified what type of devices were sold.
I hope TP-Link will update their firmware to address this issue soon! These devices don’t have automated firmware update checks, notifications, and even TP-Links websites do a poor job with firmware updates. They should address this problem with a firmware update regardless of the distribution difficulties — which they themselves have also created.