lkeng.org

I have several TP-Link / Kasa smart home products, including a few model EP10 smart plugs and wall switches like the H100 and HS220.

I’ve noticed the devices using a prodigious amount of data over the internet which I found quite odd. Afterall, it’s a switch, what could it possibly be doing sending 218 MB and receiving 63 MB over 8 days?

I decided to try to figure this out, so I setup a debian machine (a VM within Proxmox) as a NAT router, and installed Wireshark so I can spy on the device. There are other ways of doing this but this is the method I thought would be the easiest.

I have a local Omada controller so I was able to spin up a new WLAN SSID (called iot) and have it point to the new Wireshark VM via a new VLAN(10).

So anything that connects to the iot SSID will now be filtered through my debian VM, and subsequently Wireshark will be able to see it.

What did I find?

Well I found a huge bot net!

No.. I thought it might be that, but it was much less exciting.

The Kasa devices are spamming the NTP server pools: time.nist.gov and pool.ntp.org. I believe these services have blocked the Kasa devices, and they are repeatedly looking up those names via DNS, trying to contact them, and just going nuts doing that over and over. (see screenshots). You can see that the client devices (192.168.10.11) is trying to contact the server (whose IP varies, but for example is: 198.137.202.32 – but it never replies!

The Fix (Sort of)

I had already setup dnsmasq on my debian VM to act as the DHCP server for my test VLAN and also the DNS resolver/forwarder. So I added a few lines to the dnsmasq.conf to make time.nist.gov and pool.ntp.org resolve to my own VM.

address=/time.nist.gov/192.168.10.1
address=/pool.ntp.org/192.168.10.1

You can see from the log file that dnsmasq is telling my EP10 plug (192.168.10.113) to hassle the NTP server at my local server now (192.168.10.1)

Jan 15 11:16:01 deborah dnsmasq[9334]: query[A] time.nist.gov from 192.168.10.113
Jan 15 11:16:01 deborah dnsmasq[9334]: config time.nist.gov is 192.168.10.1

And in Wireshark:

5635	2026-01-15 11:16:01.375559605	192.168.10.113	192.168.10.1	DNS	73	Standard query 0x089a A time.nist.gov
5636	2026-01-15 11:16:01.375714667	192.168.10.1	192.168.10.113	DNS	89	Standard query response 0x089a A time.nist.gov A 192.168.10.1
5637	2026-01-15 11:16:01.377797273	192.168.10.113	192.168.10.1	NTP	90	NTP Version 4, client
5638	2026-01-15 11:16:01.377842157	192.168.10.1	192.168.10.113	NTP	90	NTP Version 4, server

I setup chrony to be the NTP server on my local VM (aka “deborah”). I installed chrony with apt and then just had to add the following line to /etc/chrony/chrony.conf:

allow 192.168.10.0/24

The EP10 client took the diversion, queried my local server, and the server replied:

After the server replied, the EP10 stopped repeatedly trying to query it and stopped looking up time.nist.gov / pool.ntp.org

The device is no longer continuously sending packets, and so far the only internet connections I have seen are to tplinkcloud.com, which is less worrisome than I think many of us imagined.

Conclusion

I’m not the only person to complain about Kasa devices using a stupid amount of data for no reason. I’m not a network engineer but I’ve done some work almost 20 years ago with Wireshark — capturing USB traffic when debugging a homemade USB device in Windows 2000. I decided to dig in and try to figure this out.

The fix: creating your own NTP server and setting up your own DNS forwarder is a little overkill for the layperson: I think many well-featured home routers have these options. I use TP-Link Omada (yes I see the irony!) but I think Ubiquiti and OpenWRT / DD-WRT etc. would give you the same capability.

Primary Ref: AD9361 Reference Manual

Some notes on research I was doing on the AD9361.

The Main PLL block generates a frequency, locked to the external clock reference, from 6 GHz to 12 GHz. This then goes to a divider chain.

The result of the divider chain is an I/Q clock that becomes the output center frequency.

The synthesizer is configured by registers 0x270 through 0x290

The code

The AD9361 frequencies/clocks/PLLs are configured using the (no-os) function:

https://github.com/analogdevicesinc/no-OS/blob/cfe610d403b4f6bc988bc2ee1dd7e7e221b0795e/drivers/rf-transceiver/ad9361/ad9361_util.c#L119

This is a very simple 433 MHz Temperature & Humidity transmitter. It has an STM32 MCU and an SHTC3 sensor onboard.

The 433 MHz transmitter is realized by using the WL4456 IC.

WL4456 is made by: “Shenzhen Welles Technology Co., LTD” and costs about US $0.14 at LCSC. Unfortunately their datasheet is sparse (and only in Chinese). There is no block diagram of how the chip works, but we can surmise it has an x32 PLL to generate 433.92 MHz from the attached 13.56 MHz crystal.

From there, we can assume there is basically some power management circuitry and an output buffer to gate the RF output depending on the ASK modulation pin. The rated output power is 12dBm. I haven’t yet attempted to confirm that.

The MCU

The MCU in this device is the STM32F042G6U6

The board has a vertical type-C USB connector. The intention is that you can plug this board into a wall-wart type C power supply and it will transmit the temperature and RH to your rtl_433 instance somewhere else. For example I have these going to Home Assistant.

I wrote source code for the MCU to modulate the carrier to emulate an “Oregon SL109H” sensor. This way, these sensors work with the RTL-433 receiver without modifying the receiver source code. They are auto-detected by rtl-433.

I have a limited quantity of these boards. Let me know if you want one and I’ll put them up for sale.

Antenna

One of the drawbacks of 433 MHz devices is that they definitely require an offboard antenna. The ideal wire antenna length is 6.8 inches. If you’re only going a very short distance you can probably get away with just a short piece of wire inside an enclosure, or a “spring” type antenna.