fix(ota): align nRF DFU MAC increment to nrf-ota no-carry convention + add discovery fallback#121
Merged
g4bri3lDev merged 3 commits intoJul 6, 2026
Conversation
…+ add discovery fallback Two DFU-rediscovery issues in the nRF OTA path: - `_increment_mac` used a full 48-bit carry, disagreeing with the Nordic-reference convention (a uint8 increment of the last octet: wrap 0xFF -> 0x00, no carry) that the standalone nrf-ota scanner uses. Align py-opendisplay to the no-carry convention so both implementations agree. - `find_nrf_dfu_device` matched only the MAC+1 address, so a wrong guess meant a silent scan miss. Add a fallback that also matches the Legacy DFU service UUID or a DFU-style advertised name. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012g2e8mr132vcizx92WsgiR
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
…-ota OpenDisplay#7) Selecting a DFU target by a name merely containing "DFU"/"DfuTarg" picks the wrong tag when two devices are in bootloader mode at once — the core of finding MJ-23. Align with nrf-ota OpenDisplay#7: select only by MAC+1 OR the Legacy DFU service UUID. Replace `_is_dfu_advertisement` with `_advertises_dfu_service` (UUID-only) and update the fallback test to assert a DfuTarg-named advert with no matching UUID/MAC is NOT selected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012g2e8mr132vcizx92WsgiR
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012g2e8mr132vcizx92WsgiR
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
2 participants
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.
Fixes finding MJ-23 (py-opendisplay side): two DFU-rediscovery issues in
src/opendisplay/ota.py.1. MAC+1: align to the Nordic / nrf-ota no-carry convention
_increment_macincremented the address as a full 48-bit integer, so…:EE:FFcarried into the previous octet (…:EF:00). The standalonenrf-otascanner (nrf_ota/scan.py) instead increments only the last octet as a uint8 — it wraps0xFF → 0x00with no carry (…:EE:FF → …:EE:00), matching documented Nordic bootloader behaviour. This aligns py-opendisplay to that convention so both implementations agree.Note: the exact bootloader wrap behaviour isn't captured in the repos, so this should be validated on real hardware. The discovery fallback below keeps rediscovery robust regardless of the exact MAC guess.
2. Discovery fallback by DFU service UUID (no name-based selection)
find_nrf_dfu_devicepreviously matched only the MAC+1 (and, after 10 s, the original) address, so a wrong MAC guess meant a silent 30 s scan miss. It now also selects a device advertising the Legacy DFU service UUID (00001530-…). The scan switches todiscover(return_adv=True)to read advertisement service UUIDs.Selection deliberately does not match on device name. A name that merely contains "DFU"/"DfuTarg" would pick the wrong tag when two devices are in bootloader mode at once — which is the core of finding MJ-23. This matches the discriminator chosen in nrf-ota #7 (
MAC+1 OR service-UUID, name-based selection dropped). The UUID fallback is safe to return before the 10 s mark because the stale app-mode entry does not expose the DFU service.Tests
_increment_macnow asserts the no-carry wrap (…:FF → …:00, previous octets untouched).find_nrf_dfu_devicecase matching by service UUID when the MAC doesn't match, and a case asserting aDfuTarg-named advert with no matching UUID/MAC is not selected.501 passed.Companion change on the nrf-ota side is tracked in its own PR (#7); both now use the same no-carry MAC+1 convention and the same
MAC+1 OR service-UUIDselection discriminator.🤖 Generated with Claude Code
https://claude.ai/code/session_012g2e8mr132vcizx92WsgiR
Companion PR: OpenDisplay/nrf-ota#7 (standalone tool — same MAC+1 no-carry + UUID-only device selection). Both now select by MAC+1 OR Legacy DFU service UUID, never by name.