chore(core): increase retransmission timeout [no changelog]
What changed, and why it matters
This commit simply doubles the initial wait time between retries when sending data over the Trezor's THP (Trezor Host Protocol) channel and slightly adjusts the maximum timeout. It is a routine tuning change with no visible security implications.
No security action required; treat as normal maintenance.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch modifies the retransmission timeout curve in core/src/trezor/wire/thp/channel.py. The formula changes from round(10200 - 1010000 / (100 + i)) to round(10300 - 1010000 / (100 + i)). At iteration i=0 the timeout increases from 100 ms to 200 ms; the asymptotic maximum rises marginally from about 3.42 s to about 3.52 s. No logic, bounds checks, cryptographic operations, or trust assumptions are altered.
Changed components
core/src/trezor/wire/thp/channel.pyInspect captured patch +2 / −2
diff --git a/core/src/trezor/wire/thp/channel.py b/core/src/trezor/wire/thp/channel.py
index 690ca253d..1f95065ba 100644
--- a/core/src/trezor/wire/thp/channel.py
+++ b/core/src/trezor/wire/thp/channel.py
@@ -435,8 +435,8 @@ class Channel:
log.error(__name__, "Sending is stuck for %d ms", _WRITE_TIMEOUT_MS)
break
- # starting from 100ms till ~3.42s
- timeout_ms = round(10200 - 1010000 / (100 + i))
+ # starting from 200ms till ~3.52s
+ timeout_ms = round(10300 - 1010000 / (100 + i))
try:
# wait and return after receiving an ACK, or raise in case of an unexpected message.
await self.recv_payload(expected_ctrl_byte=None, timeout_ms=timeout_ms)
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.