Repository navigation
New firmware for HS103 blocking local access? #42
Description
Has anyone ever actually gotten this to work with an HS103? I'm trying it now, and just getting timeout errors with no response...
~> kasa --host 192.168.1.43 --plug --debug
DEBUG:kasa.smartdevice:Initializing 192.168.1.43
DEBUG:asyncio:Using selector: KqueueSelector
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/kasa/smartdevice.py", line 136, in _query_helper
response = await self.protocol.query(host=self.host, request=request)
File "/usr/local/lib/python3.7/site-packages/kasa/protocol.py", line 47, in query
reader, writer = await asyncio.wait_for(task, timeout=timeout)
File "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncio/tasks.py", line 449, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/bin/kasa", line 8, in <module>
sys.exit(cli())
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 1236, in invoke
return Command.invoke(self, ctx)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/click/decorators.py", line 21, in new_func
return f(get_current_context(), *args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/kasa/cli.py", line 81, in cli
ctx.invoke(state)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/click/decorators.py", line 73, in new_func
return ctx.invoke(f, obj, *args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/click/decorators.py", line 21, in new_func
return f(get_current_context(), *args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/kasa/cli.py", line 183, in state
asyncio.run(dev.update())
File "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncio/runners.py", line 43, in run
return loop.run_until_complete(main)
File "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncio/base_events.py", line 587, in run_until_complete
return future.result()
File "/usr/local/lib/python3.7/site-packages/kasa/smartdevice.py", line 184, in update
self._sys_info = await self.get_sys_info()
File "/usr/local/lib/python3.7/site-packages/kasa/smartdevice.py", line 177, in get_sys_info
return await self._query_helper("system", "get_sysinfo")
File "/usr/local/lib/python3.7/site-packages/kasa/smartdevice.py", line 138, in _query_helper
raise SmartDeviceException(f"Communication error on {target}:{cmd}") from ex
kasa.smartdevice.SmartDeviceException: Communication error on system:get_sysinfo
Activity
Yeraze commented on Apr 18, 2020
So, it seems there is a new firmware update available for these that completely breaks this function. They come in a 2-pack, and the first one I applied the firmware update during setup as instructed.
On the 2nd one, when I got to that stage I force-quit the app (there is no "Skip" or "Don't update" option).. and now everything works.
rytilahti commented on Apr 18, 2020
Is the one with a newer fw still discoverable using the discovery call? If so, maybe they have just changed the protocol a bit, but otherwise... :(
Yeraze commented on Apr 18, 2020
No it isn't.. In fact, the updated one doesn't even respond to Ping's. I've tried resetting and power cycling it at least 3 times, and no change. I think the new firmware is actively trying to prevent things like this.
New one is 192.168.1.43, stock one is 192.168.1.144:
I have confirmed that both units are online and functional within the Kasa app (iPhone) and I even took the new-firmware one and got it working with google home ("Hey google, tell kasa to turn the air filter on").
rytilahti commented on Apr 18, 2020
Ouch, that's not looking good then :-( can you check if other ports are accessible (i.e., nmap without defining the ports) just in case they changed the port for some reason.
Some potential solutions:
Yeraze commented on Apr 18, 2020
It doesn't look good...
Yeraze commented on Apr 18, 2020
Same for tddp, no response
~/D/t/tddp-client (master) [1]> ./tddp-client.py -t 192.168.1.43 -c 0E Request Data: Version 02 Type 03 Status 00 Length 00000000 ID 0001 Subtype 0E ^CTraceback (most recent call last): File "./tddp-client.py", line 207, in <module> response, addr = sock_receive.recvfrom(1024) KeyboardInterrupt === [17:55] ⚡ ▸▸▸▸▸▸▸▸▸▸ Took : 2 min, 33.8 sec ,rytilahti commented on Apr 18, 2020
Try nmap -sS -p 1-65535 to do tcp syn scan on all ports. But it's not looking good...
jgrills commented on Apr 18, 2020
Is the implication that we would need cloud connectivity to talk to the switches, as they won't listen to packets from the local network?
Yeraze commented on Apr 18, 2020
rytilahti commented on Apr 18, 2020
That's way too fast (0.5s for testing all the ports?):
@jgrills yes, that's the implication if we cannot find a way to revert it back to the factory defaults / old firmware.
@Yeraze, did you already try the instructions at https://www.tp-link.com/de/support/faq/1779/ ?
Yeraze commented on Apr 19, 2020
(Running the nmap again now, looks like it's doing something serious this time. I'll post results when done, says it will take 3 hours).
I did the 10s reset already, yes.. Twice.. Apparently the firmware update persists across factory resets., as I've not been prompted to do it again.
kirichkov commented on Apr 19, 2020
What happens if you connect the Plug to a Wi-Fi network that doesn't have internet connectivity? Can you still find it and set it up from the app, and find it afterwards in the app?
I think that's a good test to figure out whether the protocol is changed or local access is completely removed.
Yeraze commented on Apr 19, 2020
Nmap is showing all ports filtered, although does recognize the device is online and can convert the IP to MAC address..
I did set the device up once in "Local Only" mode, where you go through all the usual configuration steps but skip all the cloud login parts. In this mode, you can only control it with the app, and only when you're both on the same network. However, the Plugin still didn't work and the device failed to respond to things like Ping. I didn't do the full nmap scan in that configuration tho.
rytilahti commented on Apr 19, 2020
When using -Pn, nmap considers the host automatically being online, I think. Or maybe it does that as/when it has seen an ARP communication from the device.
Hm, so there is still some sort of local mode available, but it you cannot control it using python-kasa? If that's the case, it could be helpful if you'd record some traffic (wireshark, tcpdump, ..) between the device and the phone when that happens. At least you would see which ports are being used for communication, even if the tplink dissector (https://github.com/softScheck/tplink-smartplug#wireshark-dissector) is not working for you.
totarello91 commented on May 4, 2020
Are there news on this bug?
kaelancotter commented on May 16, 2020
Any Idea what the latest relevant firmware version is? I'm running
and didn't have any issues with a basic state check.
Additionally, the devices are on an isolated vlan without internet access, which may be relevant. App shows the devices as local only and nmap shows 9999/tcp open.
mikaelnelson commented on Jul 17, 2020
I just bought a HS103 for my 3D printer and ran into this issue where it couldnt be controlled locally. I did see this on the TPLink site and was able to get the plug set to local only and working with the Octoprint TPLink plugin: https://www.tp-link.com/us/support/faq/2707/
My HS103 is on firmware 1.1.2, not sure if this is the version people are having issues with or not. The app says my device is on the most recent software version.
rytilahti commented on Jul 17, 2020
Okay, so my understanding is that if the device is connected to the cloud, it disables the local access. Maybe it's worth adding that to the docs & add the API functionality to unbind from the cloud for those who prefer local only connection?
Since some time it is also possible to use the kasa tool (kasa wifi --help) to do the initial network configuration, so there is no need to use the app at all if one doesn't want to.
ladeak commented on Sep 7, 2020
Do you have any updates/findings on this issue?
rytilahti commented on Oct 4, 2021
Please do test if it works with the latest release that has changed several facets of the communication protocol. I'm closing this now as there has been no updates on the matter and it is impossible to debug without further input.
Prepare 0.4.1
Prepare 0.4.1 (#288)
Prepare 0.4.1 (python-kasa#288)