I would turn it off for both radios, on all 3 APs. You’re likely using the 5Ghz radio for communication between the APs. Don’t want QoS there either. Unless you have a specific need, QoS should be disabled. Kinda strange to see it enabled by default.
I’ll have to research that a bit more. The Orbi does NOT use the normal 5GHz radio for communication between the Satellites. There is a third dedicated 5GHz backhaul radio. It’s unclear if QoS is on or off on that or even controlled by the 5GHz on/off switch.
Also all settings affect the entire system router and whatever number of satellites you have. It is a true mesh, acting as one system. There are no separate settings for each box.
I should note that the Sense/KP115 issue happened with two previous WIFI systems in the house. A three AP wired Apple Airport Extreme system and just using the Sense and KP115’s alone on the FIOS router’s singe 2.4GHz WIFI. So as fun as finding all these Orbi settings is, I’m skeptical that this will make any difference to the original issue.
Okay. Perhaps I didn’t understand the manual. They list different factory default settings for the satellites so I assumed they were separately configurable.
Some configuration items, like channels, snmp, etc. really need to be separate for each AP. Again, I’m not a mesh guy or even a Netgear guy (for many years), but I don’t see how a mesh implementation would scale if they had shared channel configuration and the like. Perhaps the folk at Netgear have some magic solution that I simply don’t understand…
Well they all turned off simultaneously again tonight. So those QOS changes did nothing.
1 Like
@Offthewall, one question. I think you were explicit - the smartplugs in the Device list for the the KP115s go to ‘off’, not ‘n/a’ right ? And is the devices icon showing in green (color) or in gray ? There are subtle hints in that as well.
The KP115’s go to n/a, IF I had the on/off button enabled in Sense - which I currently do no, They are not green. It is obvious when they go offline to Sense since three of them have constant significant power draws on them 24/7. Look at “Server Rack” in the screenshot. It draws about 350 watts 24/7. It went offline last night at 10:44PM with all the other KP115’s. I have not manually unplugged/replugged it yet.
1 Like
Thanks for clarifying. You reminded me that there is one more dimension to what one might see for smartplugs in the Device list, depending on whether the on/off button is enabled.
If you’ve disabled QoS on all the wifi APs, assigned static IPs for both Sense and the plugs and rebooted all of them, then I’m out of easy ideas. Next steps from an existing networking perspective are sniffing or going to Netgear support.
Btw, did you try the script for rebooting the plugs?
I did disable the QOS on all radios 5 and 2.4GHz. I have not had a chance to assign static IP’s - that’s up next.
I’m not sure what you mean by the script to reboot the plugs. The only solution so far has been to physically unplug the replug them. Then all is well for a week or so.
Script referenced earlier in this topic (post #47). It should allow you to send a command
instead of having to unplug and replug. Like so:
tplink_smartplug.py -t plugaddress -c reboot
1 Like
Ah, thanks. Missed that in all my own noise. 
BTW, I just put the KP115’s and the Sense on static IP’s. We’ll see what that does.
1 Like
Fingers crossed…
1 Like
I am interested in using that script, but only if the load remains on while the plug reboots. I looked at it yesterday but I’m not sure how to run a python script on windows.
I haven’t explicitly tested, but I expect that the load is bounced briefly when the plug is rebooted.
A day after setting static IP’s for the Sense and all 5 KP115’s, I observed a new behavior. At 6:12AM all KP115s went offline simultaneously. Five minutes later, at 6:17AM, they all simultaneously came back online by themselves. That’s new.
Interesting. I don’t know much about FIOS or the router used on the output of the ONT, but I have always bridged my ISP-supplied router+, to use my own router for two reasons.
- Better, more predictable control (lots of undocumented constraints, like no spaces in client names, etc.)
- DHCP issues - out of 5, I have never had an ISP-supplied router combo that doesn’t eventually hose up DHCP, either by refusing to provide IP addresses when it should have plenty left in the pool, or arbitrarily changing one that ends up causing a pile-up of knock-on changes.
I would replace the FIOS router in a heartbeat if I didn’t also have FIOS TV. Those boxes are hooked up to the router MoCA. If I switched to my own router, I’d have to add some sort of MoCA adaptor and I’m not sure what type of Pandora’s Box that would open.
2 Likes
I was able to run the script using a raspberry pi and can confirm that a KP115 will ‘blink’ the load when it reboots. Haven’t decided whether that would be an issue for the devices on my plugs. I will continue to investigate the script.
2 Likes
Very understandable caution. Sounds like @dennypage ‘s suggestion is helping. Did you notice any swapping of IP addresses when you were experiencing earlier disruptions ? I can see the Sense monitor getting confused if responses from the smart plugs suddenly start coming back from a different set of IP addresses than from the previous broadcast request.
1 Like
This thread makes my head explode… There’s a lot of theories here without any concrete knowledge or evidence (sense engineers or docs) supporting the assertions made. I feel sorry for @Offthewall as he’s spending a ton of time on things that wouldn’t really change much. That being said, and as a network engineer, let’s clear some things up.
Here are the most common issues for devices not communicating on a vlan that I experience:
- Layer 3 roaming
- DMZ Isolation (blocked layer 2 discovery protocols)
- IOT Devices that don’t support non-native VLANs
- No AP Support for low density bitrate
- Band Steering
- No support for 2.4 GHz
The above are things that I would look at, but not necessary say are guaranteed to be problematic. They are just on my list of most common issues that I run into on a daily basis. Manufacturers are different as well and a Ubiquiti device won’t always have the same issues that a Meraki does, and vise versa.
I was going to go into a lengthy post about why it’s not the firewall, static ips (less hostname), QoS etc etc… I’ll digress on that to avoid the appearance that I would be offending someone. The likelihood of those things causing a problem are very low. Normally those things can accentuate issues such as network flooding, buffer allocations etc, but just not likely in a home environment. The KP115 does use UDP broadcast packets on a random SSID TP-LINK_Smart Plug_XXXX but only for initial device discovery and configuration by the Kasa app. It then shuts off the internal access point once it’s connected to WiFi and converts itself to a client.
The KP115 devices communicate on port 9999 locally. It also appears that for local device discovery they use hostnames instead of known IP addresses or multicast discovery. When a device has to renew (or get) it’s lease it informs the DHCP server of it’s hostname and the server assigns it a lease as part of the registration process. I see lots of speculation as to how Sense communicates with the TP Link plugs, but I haven’t been able to find anything from an engineer or a blog post confirming that. I don’t have one either so I can’t wireshark my network to figure it out. I ordered one and it will be here tomorrow so I can look into it further.
If you unplug the device and plug it back in, for example, it would get a renewed lease from the DHCP server. Sometimes in poorly coded devices short lease times can cause issues. If your lease renewal is set to 30 minutes, this could be problematic for some devices. This would also explain why different WiFi networks don’t solve the problem, because the DHCP lease is being assigned by the router, switch or other device on the network. This could also explain why the device can still communicate with the Kasa cloud.
My guess is that it has to do with the DHCP lease. If I were you I would look to see if there’s a correlation between the lease renewal and the loss of connectivity. For example, half way through the lease time. I would check what your lease time is set to. If it were me I would increase it to 12 or 24 hours if it’s really short. If you are setting the static IP as a reservation on your DHCP server and you’re able to associate a hostname with it, then that may work. If you can’t set a hostname the device will still have to provide it.
Once I get my hands on one of these devices tomorrow I’ll connect it to Sense and see if I experience the same issues and if I’m able to replicate the problem. I can then packet capture and analyze.
Edit: I saw where Kasa devices had an issue with 10.0.x.x subnets late last year. Don’t see a fix for that in the firmware either (tbf “fixed bugs” in the logs doesn’t help much).
3 Likes