Added information for debugging mesh connects#45
Closed
kendelmccarley wants to merge 0 commit into
Closed
Conversation
KMX415
added a commit
to kendelmccarley/meshpoint_mod
that referenced
this pull request
May 4, 2026
Bundled additions on top of the relay_node tracking work in PR KMX415#45: - tests/test_relay_node_header.py: locks the Meshtastic header byte 15 read into Packet.relay_node. Covers the static parser in isolation (extracts nonzero byte, treats zero as direct, full-byte-range round-trip, no bleed from byte 14) and the full decode() path (Packet.relay_node populated, defaults to 0, included in to_dict() for the WebSocket payload). - tests/test_database_migration.py: adds TestRelayNodeMigration with four cases for the packets.relay_node ALTER TABLE migration: fresh-install schema already includes the column, pre-PR-45 databases get it added on next connect(), the migration is idempotent across restarts (no duplicate column, no data loss), and rows that predated the column read back with relay_node=0 by default. Module docstring updated to cover both migrations. - frontend/css/dashboard.css: .relay-hop now uses var(--accent-amber) instead of var(--accent-yellow, #f0c040). The dashboard does not define an --accent-yellow token, so the hex fallback would have fired everywhere; --accent-amber (#f59e0b) is the canonical token already used by the position packet type, mid-band RSSI, and other amber accents on the page. - src/transmit/tx_service.py: renamed NODEINFO_HOP_LIMIT to DEFAULT_HOP_LIMIT and used it in both fallback expressions, so the text-message fallback no longer relies on a bare literal 3 while the NodeInfo fallback uses a named constant. The constant has no importers outside this file. Behavior unchanged (still 3). All 280 tests pass. ruff clean. No edge-runtime behavior changes.
Owner
|
Really useful change. Pushed a few additions to your branch:
Take a look when you have a minute. Happy to revert any of it if you'd rather take it in a different direction. Want to leave room for you to keep iterating on the relay debugging idea you mentioned. Multi-Meshpoint correlation is on our roadmap too, so this lays useful groundwork. |
Owner
|
Did you mean to close this? |
Contributor
Author
|
Nope. I need to learn Git |
Owner
|
All good, shit happens. |
9 tasks
Owner
|
FYI — your two commits from this branch (the Sorry about the close — totally understand the force-push mishap. The work is good and it's shipping. Will hardware-validate on the test RAK before bumping |
KMX415
added a commit
that referenced
this pull request
May 5, 2026
iceice400
pushed a commit
to iceice400/meshpoint
that referenced
this pull request
May 6, 2026
Bundled additions on top of the relay_node tracking work in PR KMX415#45: - tests/test_relay_node_header.py: locks the Meshtastic header byte 15 read into Packet.relay_node. Covers the static parser in isolation (extracts nonzero byte, treats zero as direct, full-byte-range round-trip, no bleed from byte 14) and the full decode() path (Packet.relay_node populated, defaults to 0, included in to_dict() for the WebSocket payload). - tests/test_database_migration.py: adds TestRelayNodeMigration with four cases for the packets.relay_node ALTER TABLE migration: fresh-install schema already includes the column, pre-PR-45 databases get it added on next connect(), the migration is idempotent across restarts (no duplicate column, no data loss), and rows that predated the column read back with relay_node=0 by default. Module docstring updated to cover both migrations. - frontend/css/dashboard.css: .relay-hop now uses var(--accent-amber) instead of var(--accent-yellow, #f0c040). The dashboard does not define an --accent-yellow token, so the hex fallback would have fired everywhere; --accent-amber (#f59e0b) is the canonical token already used by the position packet type, mid-band RSSI, and other amber accents on the page. - src/transmit/tx_service.py: renamed NODEINFO_HOP_LIMIT to DEFAULT_HOP_LIMIT and used it in both fallback expressions, so the text-message fallback no longer relies on a bare literal 3 while the NodeInfo fallback uses a named constant. The constant has no importers outside this file. Behavior unchanged (still 3). All 280 tests pass. ruff clean. No edge-runtime behavior changes.
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.
Summary
This was a first step towards exploring how to use the packet list on the dashboard to debug networking issues. In my case, it helped me find that the ERP from my rooftop node was crap. Exposed the ID byte from the retransmitting node. Added the capability to draw a line between nodes when focus shifted to its line in the packet list.
Why
Relayed packets arrive with no visibility into which node retransmitted them. Without that, diagnosing hop-chain issues — weak relay nodes, misconfigured ERP, unexpected relay paths — requires external tools. Surfacing the relay node inline in the packet list makes it possible to spot these issues directly from the dashboard.
Ultimately, I'd like to see the capability to analyze the meshpoint logged data, maybe from multiple meshpoints, to find networking issues (can't get there from here kind of things). I want to find out what other traceroute information I can log. For now, it was sufficient to see the packet source (me) and who retransmitted it.
Pushing this just to get the discussion going and something to build from.
Type
Testing
How tested?
Used it to figure out my hardware issue keeping Meshpoint packets from reaching the local net (was my rooftop node).
Hardware:
Impact
Adds relay_node (header byte 15) to the packet model, database, and WebSocket feed. Existing rows default to 0. No changes to decode logic, relay policy, or TX path.
AI-assisted?
Claude Code — root-caused the relay behavior, identified the header byte, and implemented the full stack change (decoder → model → DB migration → frontend display + map interaction).