I have a CCR1009-7G-1C-1S+ with a fairly simple setup (DHCP, NAT, Firewall, a few VLANs). One of the VLANs is an IOT VLAN and I am trying to get TP Link Smart Plug Minis to work on my network. When I first boot up the plug, everything works fine, it joins to WiFi, local control and control of the plug over the internet works great. After almost exactly 5 minutes, the plug switches to “local only” control in the TP Link app and access to the plug over the internet doesn’t work at all, it shows the plug is offline. About 10 minutes later, the plug briefly drops off network completely it seems and then rejoins and now works fine again. This process of working, then not working, then working again repeats over and over.
At first I thought maybe it was PiHole blocking something with TP Link servers, but the plug does work fine at first and I changed DNS on router to use 8.8.8.8 and it still had same problem anyway. I brought the plug to another location (a mikrotik router with built in wifi) and the plug works fine there non-stop. I also tried a different temporary access point on my network in case the main AP had some weird issue with the TP Links. I also disabled 5GHz on the APs.
So obviously the plug doesn’t have a problem and it’s something with my setup causing it to not work. I am out of ideas… and I have no other issues with any other device on the network or any VLAN.
The only issues I have had with the TP-Link smart plugs have been due to the DNS server(s) being down. I don’t have them on their own IOT vlan though. They only connect to 2.4G wireless so 5G wireless should have no bearing.
I would configure the packet sniffer to forward traffic to wireshark on your desktop and capture any traffic from that IOT vlan. This should give you a good idea of what the plugs are doing.
The below sniff was set to only look at traffic to and from the MAC address of the one plug. IP of plug is 10.137.10.175, router is 10.137.10.1.
Here is part of the packet sniff. Up top is right before the plug stops working, so you see it working normally there. At 298 seconds, which is almost exactly 5 minutes as previously mentioned, you can see the plug initiates a DHCP request, which is acknowledged by the router. This is when I notice on the TP Link app, it goes to local control only. And, as you can see the packet sniff gets weird and seems to indicate no further requests from the plug except ARP broadcasts.
I just ran a sniffer trace on the plug right next to me and I don’t see the same results. You will need to look at the packet details/decodes in wireshark to see what request/response was made to help determine what the issue is. If you want to upload/post your packet capture then myself and perhaps others can take a look.
Thank you, yeah I can see how whole picture would be needed to analyze further. See attached. 0 seconds is plug being inserted into outlet. 298 seconds is where the app can’t connect to plug anymore, and about 1,000 seconds is when plug comes back online by itself, only to then stop again 5 minutes later. Reminder, all this time, local control still works, and plug shows up on access point so it isn’t actually loosing WiFi connection or anything like that. hs105 full trace.pcapng.gz (138 KB)
Your lease time is 10 minutes, so the plug is going to try and renew the least at the 50% time left mark - 5 minutes. Unless you have a lot of unique devices coming and going on that vlan/subnet you can dramatically increase the lease time for DHCP addresses. Perhaps there is a code issue with the plugs with such a short lease time. I would try at least a few hours or perhaps day(s). If you don’t have a LOT of unique devices entering and leaving your network and you are not making any changes to your dhcp config then setting a longer lease time is very safe.
OK, trying a higher lease time, like 30 minutes still made plug have same problem, upping to 24 hours seems to make the issue go away. BUT, I just checked the config on the other router at other site (also a mikrotik) and the lease time on that DHCP is 10 minutes (seems to be the default mikrotik setting, which is why it was at 10 min in first place). So, although the issue does seem to be DHCP related, and increasing the lease time makes the plug work longer, I am not convinced that is the real issue behind my problem since it works fine with 10 min lease time on other location. With a 24 lease time, and renewal attempt happening at 12 hours, it makes it hard to sit and watch the plug and what’s going on with it to see if it still fails at 12 hours now but I wouldn’t be surprised if it still is and increasing the lease time is just prolonging when the “failure” happens.
Think I found the issue here guys… I changed my IP scheme on the IOT vlan to 192.168.x.x instead of 10.x.x.x and the plugs stay online and work perfectly (so far) regardless of DHCP lease time. So issue definitely seems to be IP address related and it is triggered by the DHCP renewal taking place half way through whatever lease time is set. Unless I am missing something about networking, I would say it’s the result of a bug in the plug firmware. Can’t imagine why 10.x.x.x addresses shouldn’t work.
I also have the TP Link smart plug (branded Kasa) and ran into this issue. I found that it is dropping off the network exactly at the 1/2 way mark for the DHCP lease when it tries to renew.
I had my lease time on the network set to 30m. After extending the lease on this device to longer time like 2d the rapid disconnecting cycle has stopped but I do believe that it will disconnect at the half way mark of the lease again. Maybe will set this thing to 30d then to make the issue less annoying. Going to see if there are any other settings that will keep this device up longer. That is super interesting about the 192 address that it is happier with. My networks are on the 10.x.x.x networks. That would be a pain to have to set up a new VLAN just for this. Hoping to find another solution. Tried DHCP broadcast and that did not seem to help. So glad to find this thread and know I’m not the only one. I bought a 4 pack of these plugs and tested two of them , both have the exact same issue.
One great things about these plugs is they are fully programmable and can be automated for smart home with node-red, homeassistant, or the tplink api scripts. I’m using it with node-red with the node-red-contrib-tplink plugin to trigger the on off programmatically
This is a really important forum post for Kasa/TP Link smart plug/switch users. I had the same problem with KASA devices on a IoT VLAN with 10.0.16.0/22 subnet. The cloud based access would turn off periodically for a few random devices. changing the IP configuration of the IoT vlan to 192.168.16.0/24 has made them work. looks like a Kasa bug to me, still haunting us 2 years later.
I was unfairly blaming the Ubiquiti APs and tried changed a bunch of settings. Every time I’d change the settings the devices would reconnect and all work for a while. But after making the IP change they’ve all been up steadily for several hours.
I’m going file a report with Kasa/TP-link and what they say.
I contacted TP Link support and got through to higher level support, but no positive result yet.
I have noticed that certain firmware/hw revisions are afflicted and some are not. For instance the older HS200 works consistently but the newer HS200 (hw 3.0) doesn’t.
NOT WORKING
HS103, hw 2.1, fw 1.1.4
HS200, hw 3.0, fw 1.1.5
I can reliably reproduce the problem by changing nothing but the IP address, they fail exactly 50% through the DHCP lease time (I tried different lease times with the same result). I think at this point we’re at the mercy of the firmware developers at TP Link, or redo your IP addresses to work around the problem. with a 192.168.55.0/24 network they are working perfectly.
Not related to MIkrotik as such but I noticed certain TP- Link HS100 Smartplugs were declining DHCP ACKs from my OpenWRT 22.03.5 router.
Turns out some HS100s do arping check to check if the allocated address is unused and I had enabled 802.11v Proxy ARP (power saving optimization) on the wireless interface which then caused the issue. Disabling the ProxyARP solved the issue.
