Thanks, and multiple questions: access control, discovery not working, access by hostname vs IP

[egburr]

1. Thanks!!! For a few years now, I've been using a shell script I've cobbled together using curl to access my plugs and switches through the cloud interface. I just stumbled across this and it is so much better, and seems like it will work even when I lose the external internet. But it brings up a question...

2. There does not appear to be any access control! Anyone who gets onto my network can access my devices? And I can access whatever Kasa devices I find on any network I happen to connect to? Has anyone discussed this with Kasa or TP-Link? (not a problem with python-kasa, but with the devices themselves!)

3. The discovery function does not appear to work. It finds none of my devices. But it has no trouble checking their state and turning them on and off when I specify them directly by their IP address. Am I missing something? The instructions seem pretty clear. I am on the same class C (192.168.1.x) network as the devices. A tcpdump trace shows the UDP 9999 broadcast and all the devices responding to the broadcast.

02:30:42.359686   B fc:aa:14:7e:eb:f7 ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 50046, offset 0, flags [DF], proto UDP (17), length 61)
    192.168.1.250.37086 > 192.168.1.255.9999: [udp sum ok] UDP, length 33
02:30:42.381291  In b0:4e:26:35:ec:b0 ethertype IPv4 (0x0800), length 643: (tos 0x0, ttl 64, id 29290, offset 0, flags [none], proto UDP (17), length 627)
    192.168.1.122.9999 > 192.168.1.250.37086: [udp sum ok] UDP, length 599

And yet:

(02:29:19)egburr:~/bin # kasa --target 192.168.1.255
No host name given, trying discovery..
Discovering devices on 192.168.1.255 for 3 seconds
Found 0 devices

4. I can't specify the devices by DNS hostname, only by IP address. The help text suggests using the hostname should work.

(02:40:08)egburr:~/bin # kasa --host lib-lt-1
No --type defined, discovering..
Got error: SmartDeviceException('Unable to get discovery response for lib-lt-1')
(02:40:27)egburr:~/bin # host lib-lt-1
lib-lt-1.burr.cc has address 192.168.1.126
(02:40:51)egburr:~/bin # kasa --host 192.168.1.126
No --type defined, discovering..
== Library Light 1 - HS105(US) ==
        Host: 192.168.1.126
        Port: 9999
        Device state: False
        == Generic information ==
        Time:         2023-11-02 01:41:05 (tz: {'index': 18, 'err_code': 0}
        Hardware:     1.0
        Software:     1.5.6 Build 191114 Rel.104204

After reading into that a little more and adding "--type plug", it works! So, apparently only discovery fails for using the hostname.

(02:49:41)egburr:~/bin # kasa --type plug --host lib-lt-1
== Library Light 1 - HS105(US) ==
        Host: lib-lt-1
        Port: None
        Device state: False

# kasa --version
kasa, version 0.5.4

[rytilahti]

Hi there,

just some brief answers to your questions:

1. You're welcome, and yes, this library and the cli tool all work only locally. There are some cloud-specific functionalities exposed via the cloud module but they are not currently used anywhere in the cli, see Support for disabling Remote Access #519 and get cloudinfo #370 (comment)
2. Yes, there are no access controls when using the 9999/tcp based protocol, some devices use a different protocol which derives the encryption keys from the cloud credentials.
3. No clue why this would not be working, especially as the discovery replies are
4. Lastly, Update discover single to handle hostnames #539 fixes the discovery when using hostnames.

[egburr]

Thanks for the response. A few comments on each of the questions...

1. Other than the lack of access control when on my local network (though I do control who can get on my local network, so not a huge issue, more the principle of it really), I like not having to go out to the internet to activate local functions. I've already modified some of my scripts to drop all the curl commands (and API token handling) in favor of the python-kasa cli.
2. nothing more to say...
3. I'm curious about this, too. Feel like pursuing it? I'm happy to capture and provide data if you want. (I'm sure you've got other things to do; I'm just offering to collect test data if you want to pursue this, not trying to talk you into pursuing it.)
4. Nice! Guess I'm a little late to the party. :)
5. (new question) Is there any information about the "raw command" option? Reading through some of the other discussions on here, I see a few of those raw commands mentioned. But I can't find anything about the commands themselves.

[rytilahti]

3. No, not really, I don't currently have time to dig into such. As it is working for most of the people afaik, it must be something in your local network setup. You could try to add --debug to the cli tool to see if it receives the responses, and if not, maybe they are dropped by the kernel/firewall?
4. They are scattered all around on the Internet, in the issues & pull request comments etc. But the README links to some of those, and I just created Add some more external links to README #541 to add one more link to the mix.

[egburr]

Again, thanks!

After looking into this a little more, I've learned something new... tcpdump sees the packets BEFORE firewalld drops them. I hadn't realized that. And yes, the firewall is dropping the responses. Off to fix that now. :)