KLAP v2 Authentication Failure on TP-Link HS300 (US) — Hardware Version 2.0

Summary

I'm testing several TP-Link HS300 (US) power strips (Hardware Version 2.0) using the latest feature/tpap branch of python-kasa. Discovery succeeds and the initial handshake completes, but all devices fail authentication with the message:

Device response did not match our challenge ... check that your e-mail and password (both case-sensitive) are correct.

All three devices are reachable and respond to /app/handshake1, but the returned server hash never matches the client challenge, causing the session to abort.

Environment

Observed Behavior

Trimmed kasa --debug discover output:

DEBUG:kasa.transports.klaptransport:Starting handshake with 192.168.0.98
DEBUG:kasa.httpclient:Posting to [http://192.168.0.98/app/handshake1](http://192.168.0.98/app/handshake1)
DEBUG:kasa.transports.klaptransport:Handshake1 success ... Server remote_seed is ...
DEBUG:kasa.transports.klaptransport:Device response did not match our challenge on ip 192.168.0.98,
check that your e-mail and password (both case-sensitive) are correct.
DEBUG:kasa.protocols.iotprotocol:Unable to authenticate with 192.168.0.98, not retrying
== Authentication failed for device ==

Each device reports the following discovery payload (sanitized):

{
  "device_type": "IOT.SMARTPLUGSWITCH",
  "device_model": "HS300(US)",
  "hw_ver": "2.0",
  "mgt_encrypt_schm": {
    "encrypt_type": "KLAP",
    "lv": 2,
    "new_klap": 1,
    "http_port": 80,
    "is_support_https": false
  },
  "login_version": 2
}

Network Connectivity

• ICMP ping ✅

• TCP 80 ✅

• UDP 9999 (now deprecated) ❌ Closed

Expected Behavior

Older HS300 firmware (KLAP v1) authenticated successfully with email + password and allowed full local control via UDP 9999 or HTTP port 80. Under the new firmware (KLAP v2 / Login Version 2), the initial handshake completes but authentication fails even with correct credentials.

Hypothesis

The new HS300 firmware likely implements KLAP v2 using a token- or certificate-based challenge hash, similar to TPAP / SPAKE2+ used in newer Tapo devices.

The current library still derives the challenge hash from plain credentials, so the computed client hash never matches the device’s expected value.

• /app/handshake1 → works ✅

• /app/handshake2 → validation fails ❌

Reproduction Steps

1. Connect HS300 (US v2.0) to local LAN.

2. Run:

   kasa --debug discover
   

3. Observe handshake success followed by:

   Device response did not match our challenge
   

Additional Notes

• Occurs on all three HS300 v2.0 units tested.

• Confirmed not a network or firewall issue (UPike IoT VLAN, unrestricted inter-VLAN traffic).

• /app/handshake1 returns 200 OK with remote_seed and server_hash.

• Likely related to:

  • Issue Missing support for TPAP encryption type #1590 (TPAP encryption)

  • PR TPAP Implementation #1592 (SPAKE2+/TPAP implementation)

• These devices may require new KLAP v2 handling logic parallel to the TPAP branch.

Request

Please confirm whether KLAP v2 / Login Version 2 devices (HS300 v2.0) still use credential-derived hashing or require cloud-issued tokens for the second handshake stage.

If a new derivation scheme is known, I can provide full --debug logs or packet captures of the /app/handshake1 → /app/handshake2 exchange for implementation testing.

Example Device IDs (Sanitized)

Device Id (hash): eff8dcab310ffac89b042df8a35da5c1
Owner (hash):     44D82453FD26F2F462DA5F77E58808FC

Thank you for maintaining python-kasa — happy to run any extra debugging or packet captures needed to help finish KLAP v2 support.