test(integration): cover MCUboot serial-recovery MCUmgr params negotiation#121
Merged
Merged
Conversation
…ation Re-vendor serial_recovery + serial_recovery_raw (mps2) from smp-server-fixtures 27c54835 -- the first release built with CONFIG_BOOT_MGMT_MCUMGR_PARAMS (mcu-tools/mcuboot#2746, intercreate/smp-server-fixtures#10). The bootloader's recovery SMP server now advertises {buf_size: 1024, buf_count: 1}, surfaced in the manifest as recovery_buf_size / recovery_buf_count (distinct from the app netbuf). The serial_recovery_buf<N> matrix stays on 0eae053d (app-mode only). Cover the negotiation path against a real recovery server: - encoded: Auto reads buf_size and fills buf_size - 4 = 1020 B, which base64 + 128-byte line framing expands to ~1400 B on the wire (the server decodes it incrementally back into its 1024 B buffer); an explicit BufferSize override is also exercised. - raw: the cap is the advertised buf_size itself -- 1024 B per message verbatim, no base64/length/CRC framing. Each asserts the advertised params (buf_count == 1, buf_size == recovery_buf_size) and that the upload fills the negotiated buffer. The fixed-mtu raw legs are dropped: against a params-advertising server SMPClient.connect() always negotiates (the raw transport adopts buf_size unconditionally), so a "fixed mtu honored" leg no longer reflects real client behavior. Factor the reboot-into-recovery boilerplate into conftest.reboot_into_recovery, and give recovery uploads a more generous per-chunk timeout (recovery erases flash as it writes, slower than app-mode netbuf writes under emulation/load). Update the now-outdated "recovery does not advertise params" wording in the encoded BufferSize docstring. Closes #120. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KKXy7L2Udjw929nie2c363
…ry probes reboot_into_recovery's "retry until the server answers" loop duplicated the structure of _wait_until_answering -- the poll every connected() test already relies on. Extract _poll_until_answering(client, probe), so both share one retry/except/sleep implementation and each call site supplies only its probe (echo round-trip vs image-list) and failure handling. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KKXy7L2Udjw929nie2c363
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #120. Unblocked by intercreate/smp-server-fixtures#11 (merged) → release
27c54835.MCUboot serial recovery now advertises the MCUmgr params command (mcu-tools/mcuboot#2746), so a client can negotiate the recovery buffer instead of being told it out of band. This covers that path against a real recovery server and verifies the negotiated packet sizes end to end.
Re-vendor
serial_recovery+serial_recovery_raw(mps2) are re-vendored from release27c54835(the first built withCONFIG_BOOT_MGMT_MCUMGR_PARAMS). The recovery server advertises{buf_size: 1024, buf_count: 1}, surfaced inmanifest.jsonas the newrecovery_buf_size/recovery_buf_countfields (distinct from the app netbufbuf_size/buf_count, which the recovery image reports in app mode). Theserial_recovery_buf<N>matrix stays on0eae053d— it's exercised in app mode, where recovery params don't apply.Coverage
Each test reboots into recovery, asserts the advertised params (
buf_count == 1,buf_size == recovery_buf_size), and uploads filling the negotiated buffer:Autoreadsbuf_sizeand fillsbuf_size − 4= 1020 B decoded, which base64 + 128-byte line framing expands to ~1404 B on the wire (12 line packets ≤128 B each — matching the bootloader'sBOOT_MAX_LINE_INPUT_LEN=128); the server decodes it incrementally back into its 1024 B buffer. An explicitBufferSizeoverride is also exercised.buf_sizeitself: 1024 B per message verbatim (no base64/length/CRC framing).Verified against real QEMU (mps2/an385); the DEBUG log shows the recovery server returning
buf_size=1024 buf_count=1and the client auto-configuringmax_unencoded_size=1020(encoded) / sending1024-byte messages (raw).Notes
mturaw legs are dropped: against a params-advertising serverSMPClient.connect()always negotiates (the raw transport adoptsbuf_sizeunconditionally via the baseinitialize), so a "fixed mtu honored" leg no longer reflects real client behavior. The transport's pre-negotiationmtufallback remains unit-tested.conftest.reboot_into_recovery.RECOVERY_UPLOAD_TIMEOUT_S) — recovery erases flash as it writes, slower than app-mode netbuf writes under emulation/load (a tight 5 s timeout flaked once under a loaded full-suite run).BufferSizedocstring.ruff/pydoclint/mypy --strict/ unit tests green; the recovery integration tests (encoded + raw, app-mode + recovery-mode) pass against QEMU.🤖 Generated with Claude Code
https://claude.ai/code/session_01KKXy7L2Udjw929nie2c363