Problem
AsyncClient currently resembles the synchronous TLS path but lacks V1 SessionKey authentication, legacy HMAC framing, session activation, post-auth legitimation, key renewal and a password argument on connect().
Package documentation broadly claims V1/V2/V3 support without making this async limitation clear. Maintaining two copied protocol state machines is also causing correctness drift.
Scope
First decide and document one explicit support boundary:
- Bring async legacy authentication to parity, preferably by sharing protocol codecs/state transitions with the sync connection; or
- Deliberately support TLS-only async operation and fail early with a clear error on legacy SessionKey PLCs.
In either case:
- Share authentication/frame parsing logic where practical.
- Align connection/session-ready semantics with the sync client.
- Add an explicit compatibility matrix to API documentation.
- Prevent unsupported firmware from yielding a misleading connected client.
Acceptance criteria
- Async behavior for V1, V2 and V3 is explicitly documented and enforced.
- Supported paths have end-to-end setup/authentication tests.
- Unsupported paths fail during connect with an actionable message.
- Common framing and authentication rules are not independently reimplemented without parity tests.
- Future sync authentication fixes have an obvious shared or mirrored async test location.
Problem
AsyncClientcurrently resembles the synchronous TLS path but lacks V1 SessionKey authentication, legacy HMAC framing, session activation, post-auth legitimation, key renewal and a password argument onconnect().Package documentation broadly claims V1/V2/V3 support without making this async limitation clear. Maintaining two copied protocol state machines is also causing correctness drift.
Scope
First decide and document one explicit support boundary:
In either case:
Acceptance criteria