Lost communication with TP Link Kasa Plugs after firmware update

WORKAROUND

https://www.tp-link.com/us/support/faq/2707/

The problem

Lost communication with all TP Link Smart Plugs. Smart Lightbulbs still working as expected. However all works fine on TP Link Kasa App, so I know it’s on the network and working correctly.

Environment

• Home Assistant Core release with the issue: 0.117.5
• Last working Home Assistant Core release (if known): 0.117.5
• Operating environment (OS/Container/Supervised/Core): Container
• Integration causing this issue: TP Link Kasa
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/tplink/

Problem-relevant configuration.yaml

tplink:
  discovery: false
  light:
    - host: 192.168.1.188
  switch:
    - host: 192.168.1.181
    - host: 192.168.1.176

Traceback/Error logs

2020-11-11 10:18:36 WARNING (SyncWorker_0) [homeassistant.components.tplink.common] Unable to communicate with device 192.168.1.181: Communication error
2020-11-11 10:18:36 WARNING (SyncWorker_0) [homeassistant.components.tplink.common] Unable to communicate with device 192.168.1.176: Communication error

Additional information

[SimonWilkinson]

Based on @chriswheeldon work here - https://gist.github.com/chriswheeldon/3b17d974db3817613c69191c0480fe55 and some earlier protocol sniffing I had been doing, I’ve extended python-kasa to support the new protocol. I’ve contributed it as their pull request 117.

With this, Home Assistant should just work with plugs that are set up in “Local” mode (where you configure them from an app without a cloud account connected) and auto discovered. Plugs that are connected to an authenticated cloud account, or those which are configured statically, will need some changes in Home Assistant to support passing a username and password into the Discover.discover call, or the SmartPlug constructor.

Of course, if they’re now downgrading devices, I could have saved myself the effort!

[chriswheeldon]

I also suffered from this firmware update breaking my home automation setup last week. Over the weekend I have managed to make some progress on reverse engineering the updated protocol in order to restore interoperability. I can now handshake with my HS110 and issue an encrypted request to get info. Summary:

1. UDP broadcast with fixed payload on port 20002 to discover devices.
2. Requests are plaintext HTTP on TCP port 80 with encrypted contents
3. Two step handshake to determine encryption key and base IV to use for later requests.
4. Key and IV seem to be derived from the device email and password. Presumably this is for the account registered for TP-Link cloud functionality. I haven’t registered and so the email and password are empty strings.
5. AES-128-CBC for request and response body encryption.
6. HTTP requests include an incrementing sequence number as a query parameter. This is used to determine the per-request IV.
7. Encrypted request and response bodies are prefixed with a HMAC.
8. Pre-documented requests seem to work e.g. {“system”:{“get_sysinfo”:null}}

Here is a proof of concept showing how to handshake and send a request to the device. FWIW It seems fairly unreliable: I get a 403 response to the request for system info about 50% of the time. Would be interesting to try and determine why that is…

https://gist.github.com/chriswheeldon/3b17d974db3817613c69191c0480fe55

@plasticrake would be wonderful to get this integrated into tplink-smarthome-api