[hnw]

Summary

Fix TLS connection error handling in the RTL8720DN driver.

Previously, Connect() only treated -1 as a failure. However, the RTL8720DN firmware can return other negative values, including mbedTLS error codes. These were incorrectly treated as successful connections.

The firmware can also return 0 after a certificate verification failure, making the return value alone insufficient to determine whether the connection succeeded.

Changes

• Treat all negative TLS connection results as errors.
• Check the underlying SSL socket state after a non-negative result to detect connections that were closed during the handshake or certificate verification.
• Propagate UART and RPC transport errors during TLS connection setup.
• Validate RPC response framing, CRC, message type, and request identifiers.
• Handle non-blocking UART reads while waiting for RPC responses.
• Add host-based regression tests without modifying the generated RPC code.

Testing

• Host-based TLS/RPC regression tests.
• Wio Terminal hardware:
  • Successfully established 12 consecutive TLS connections to httpbin.org:443.
  • Confirmed that a failed TLS connection to example.com:443 returns error code -29312 (MBEDTLS_ERR_SSL_CONN_EOF).
  • Confirmed the same error code when connecting to apple.com:443.

With the previous driver implementation, connecting to example.com:443 incorrectly reported Connected! after approximately 120 seconds. The example then proceeded to send an HTTP request and stalled while waiting for a response.

With this fix, the same connection attempt correctly fails with error code -29312 (MBEDTLS_ERR_SSL_CONN_EOF) instead of reporting success.

Notes

The firmware retries TLS handshake errors until its handshake timeout, potentially replacing the original failure code with a later error. This PR does not change firmware behavior; it ensures that errors returned by the firmware are correctly propagated by the TinyGo driver.

Certificate verification failure handling is covered by host-based tests but has not been verified on hardware with a configured CA certificate.

[deadprogram]

Do we really want to exclude the tests here?

[deadprogram]

Thanks for tracking this down. The fix to Connect() looks right and the hardware testing is very helpful.

A few things before we merge:

1. With rtl8720dn in EXCLUDE_TESTS and nothing calling testdata/test-host.sh, these tests never run in CI. Can you hook the script into make unit-test? If that's not practical, I'd rather drop the fake machine module and keep the change smaller. Also test-host.sh is not marked executable.

2. The new read path in read() drops the r.debug hex dumps that the old path prints. Please keep those so TLS connect can still be debugged the same way as other RPC calls.

3. Go error strings should start lowercase. Also these checks apply to any RPC frame, not only TLS, so something like invalid RPC frame length %d would be clearer than Invalid TLS RPC frame length %d.

Optional. Using rpcErr *error as both the on/off switch and the error holder is a bit hard to follow. A plain rpcErr error plus a bool would be clearer. Sharing more code between the two read paths would also help, but I understand wanting to keep the generated RPC code untouched.

[hnw]

Thanks for the review! I've pushed a follow-up commit addressing your comments:

• Added the RTL8720DN host tests to make unit-test and marked the test script executable.
• Restored the RPC receive-side debug hex dumps, using a small shared helper for both read paths.
• Updated the error messages to follow Go conventions and removed the TLS-specific wording.
• Replaced rpcErr *error with separate error-capture state and error value.