GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||
GeezerVison is showing github.com — feat(klaptransport): auto-detect KLAP v2 for IOT devices by adamjacobmuller · Pull Request #1625 · python-kasa/python-kasa ConversationSummarySome IOT devices (e.g., HS300 with newer firmware) use KLAP v2 authentication (sha256/sha1 hashing) despite being classified as IOT devices. Previously, ChangesThis PR modifies The v2 fallback tries:
Affected devices
TestingTested on HS300 that was previously failing authentication. After this change, the device authenticates successfully using KLAP v2 while still being correctly classified as an IOT device.
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page. All reactionsSome IOT devices (e.g., HS300 with newer firmware) use KLAP v2 authentication (sha256/sha1 hashing) despite being classified as IOT devices. This modifies KlapTransport to try v2 hashing as a fallback when v1 doesn't match.
|
There was an error while loading. Please reload this page.
|
@adamjacobmuller Appreciate the great work here. The newer firmwares have a new flag in the device discovery process called new_klap. I created a PR already that uses this flag to determine the correct transport to use during the discovery process instead of modifying the transports themselves, PR#1580. Your method, while it works, mixes the authentication process between the two different KLAP transports and it doesn't keep a clean line of separation between them. I just finished it recently, had to handle some issues with the CLI and making sure that all of the other devices and tests worked correctly. Just waiting on merging and a new version to get it going. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Confirmed Working ✅Just tested this PR on two HS300 power strips that were previously failing with the "Device response did not match our challenge" error. Environment:
Before this PR: Authentication failed with KLAP v1 (md5) Test Results: The auto-detection of KLAP v2 worked seamlessly. Really appreciate this fix - these strips have been unusable with Home Assistant since the October firmware update. Hope this helps get the PR merged! 🎉 |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
HS300 was exactly what I built this for (nice little gadget). Hoping it gets merged too, but, it works fine for me either way :) |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
This doesn't seem working for my HS300s; connection succeeds, but the device class is wrongly set as model: HS300(US) My test script: import asyncio import kasa async def main(): dev = await kasa.Device.connect( config=kasa.DeviceConfig( host=input("host? "), credentials=kasa.Credentials( username="[email protected]", password="xxx", ), connection_type=kasa.DeviceConnectionParameters( device_family=kasa.DeviceFamily.IotSmartPlugSwitch, encryption_type=kasa.DeviceEncryptionType.Klap, ), ) ) await dev.update() print(f"children: {dev.children}") await dev.disconnect() if __name__ == "__main__": asyncio.run(main()) Please let me know if I can provide any more information or am doing something wrong; I'm not very familiar with python-kasa and am just looking to get this working for a larger project. I've created a fork that patches the issue for me by detecting device type through sys_info for KLAP connections (where this was only previously done on connections using the XOR transport). I don't expect this to be an accepted solution, but it solved the issue for me and may be of some use: |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Hey @adamjacobmuller — appreciate the work here, this was one of the first PRs to tackle the IOT KLAPv2 auth issue and confirmed it's a real problem affecting many users. 🙏 That said, #1692 takes a cleaner approach — it selects upfront in based on rather than falling back at runtime inside the handshake. This avoids mixing v1/v2 auth logic inside and keeps the transport boundary clean (as @ZeliardM also noted). #1692 also fixes the device class misdetection that @2myaus reported here — HS300 strips wrongly instantiated as with empty . That fix requires the sysinfo query path change in which this PR doesn't cover. Would you be open to closing this in favor of #1692? Both solve the core auth problem, but 1692 handles the broader set of regressions with tests included. 🤝 |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
There is already an existing, extensively tested PR that handles all of the CLI and API changes, #1580, we are working to get this implemented and a new version released soon. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.