Tapo Two way Audio: API has changed

[adyanth]

Describe the bug
Tapo two way audio plugin does not work with Tapo C210 camera.

To Reproduce
Steps to reproduce the behavior:

1. Add and enable Tapo two way audio
2. Pressing talk

Expected behavior
Two way audio should work.

Screenshots
N/A

Server (please complete the following information):

• OS: Proxmox/Ubuntu
• Installation Method: LXC

Hardware Model (please complete the following information):

• Device: Tapo C210

Client (please complete the following information, if applicable):

• Software: Home

Additional context
Logs:

[HomeKit]: intercom failed to start RPCResultError: http response statusCode 401
[HomeKit]:     at checkStatus (/server/src/fetch/index.ts:45:15)
[HomeKit]:     at t.httpFetch (/server/src/fetch/http-fetch.ts:128:108)
[HomeKit]:     at process.response2 (node:internal/process/task_queues:95:5)
[HomeKit]:     at Function.client [as connect] (/src/tapo-api.ts:50:15)
[HomeKit]:     at l.startIntercom (/src/main.ts:36:15)
[HomeKit]:     at RpcPeer.handleMessageInternal (/root/.scrypted/node_modules/@scrypted/server/src/rpc.ts:759:37)

The way it is currently implemented here expects a 401 response from a http endpoint (I am not sure what port options.address points to). I tried to port scan (see output below) and tried sending post requests to open ports.

adyanth@shipwreck:~$ nmap -sT IP
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-04 00:39 UTC
Nmap scan report for IP
Host is up (0.0053s latency).
Not shown: 995 closed tcp ports (conn-refused)
PORT     STATE SERVICE
443/tcp  open  https
554/tcp  open  rtsp
1025/tcp open  NFS-or-IIS
2020/tcp open  xinupageserver
8800/tcp open  sunwebadmin

Nmap done: 1 IP address (1 host up) scanned in 0.22 seconds

Only one of them, the https 443 one, responded in a way that related to the Tapo API implementation. It even has the nonce, error code of (-40)401 and encrypt type 3. I am on the latest firmware fyi Version 1.3.11 Build 231115 Rel. 85532n(5553). So, this makes me think the API has changed to use https with self signed certs and use the json body for the nonce and key (?).

❯ curl -lk -X POST https://IP/stream -H "Content-Type=multipart/mixed; boundary=--client-stream-boundary--" -v
*   Trying IP:443...
* Connected to IP (IP) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / AES256-GCM-SHA384 / [blank] / UNDEF
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: C=CN; CN=TP-Link
*  start date: Nov 15 15:44:55 2023 GMT
*  expire date: Sep 23 15:44:55 2033 GMT
*  issuer: C=CN; CN=TP-Link
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* using HTTP/1.x
> POST /stream HTTP/1.1
> Host: IP
> User-Agent: curl/8.6.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Cache-Control: no-cache
< Expires: 0
* TLSv1.2 (IN), TLS alert, close notify (256):
< Transfer-Encoding: chunked
< 
* Leftovers after chunking: 12 bytes
* Closing connection
* TLSv1.2 (OUT), TLS alert, close notify (256):
{"error_code": -40401, "result" : { "data": {"code": -40407, "encrypt_type": ["3"], "key": "227 char base64 key?", "nonce": "17 char hex nonce"}}}

[adyanth]

Luckily I have two, did not update the firmware on the second one, can confirm that the plugin works as expected on Version 1.3.7 Build 230823 Rel. 55314n(5553). What stumped me is that I cannot find which port accepts the http request. The port scan looks the same, but the API response on the https port is different (different encryption type):

❯ curl -lk -X POST https://IP/stream -H "Content-Type=multipart/mixed; boundary=--client-stream-boundary--" -v
*   Trying IP:443...
* Connected to IP (IP) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / AES256-GCM-SHA384 / [blank] / UNDEF
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: C=CN; CN=TP-Link
*  start date: Aug 23 07:21:51 2023 GMT
*  expire date: Jul  1 07:21:51 2033 GMT
*  issuer: C=CN; CN=TP-Link
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* using HTTP/1.x
> POST /stream HTTP/1.1
> Host: IP
> User-Agent: curl/8.6.0
> Accept: */*
> 
* TLSv1.2 (IN), TLS alert, close notify (256):
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Cache-Control: no-cache
< Expires: 0
< Transfer-Encoding: chunked
< 
* Leftovers after chunking: 12 bytes
* Closing connection
* TLSv1.2 (OUT), TLS alert, close notify (256):
{"error_code": -40401, "result" : { "data": {"code": -40407, "encrypt_type": ["1", "2"], "key": "231 char base64 key?", "nonce": "8 char base64? nonce"}}}%                                               

[koush]

JurajNyiri/HomeAssistant-Tapo-Control#551

[koush]

not a bug so much as tp link not allowing this anymore. not something I want to reverse engineer. if the other HA maintainer wants to release their code I will reevaluate.