Descalon/connections fix#320
Open
daescalona wants to merge 3 commits into
Open
Conversation
…bor discovery During a Zigbee network scan, some connections between same-level radios (for example two routers that can hear each other directly) showed correct signal quality in one direction but -9999 / status -1 in the other. In some cases the connection was missing entirely. Two related causes were found in the neighbor-table processing path: 1. SIBLING relationships were excluded from the neighbor-based connection path. A sibling appears in a radio's neighbor table with a measured LQI even when the radio holds no active route to it (Zigbee route tables are directional). Because siblings were excluded, the measured LQI was thrown away and the reverse direction of an existing connection stayed UNKNOWN. 2. A role-check guard rejected any connection when the neighbor node's cached role was UNKNOWN. This guard has no equivalent in the XCTU Java implementation, which creates a connection for every neighbor entry regardless of the reported device type. The guard was too conservative: ZDO neighbor entries sometimes report device_type=3 (UNKNOWN), which leaves the cached role as UNKNOWN even for a fully functioning router, so valid LQI measurements were silently discarded. Removing the guard entirely matches the XCTU Java behavior; the separate check that decides whether to queue a node for its own neighbor-table query is unaffected. While on it, guard against a reserved (undefined) value in the relationship field of a neighbor entry. An undefined value previously caused a crash that silently dropped all remaining neighbor entries for that radio. XBPL-438 XBPL-439 Signed-off-by: David Escalona <david.escalona@digi.com>
…O settings During a DigiMesh network scan, discovering the neighbors of each radio was much slower than it should be, and in some cases connections were missed. The radio answers a neighbor request by sending one frame per neighbor and then one final empty frame to signal that the list is complete. The library was not recognizing that empty frame as the end-of-list signal, so it always waited until the full configured timeout expired before moving on. This made each radio take the maximum wait time regardless of how quickly it actually responded. Additionally, the empty frame was being passed into the data parser instead of being handled separately, which caused a crash. Because the crash happened inside the callback, it was ending silently and the scan appeared to work even though the end-of-list was never properly detected. While on it, fix an issue causing the discovery process to completely overwrite the NO setting of the radio. Before starting the scan, the library was setting a flag (0x04) on the local radio to include signal strength in neighbor responses. It was overwriting the entire setting instead of adding only that flag, which cleared any other options the user had configured. The fix now reads the current value and only adds the needed flag, leaving everything else untouched. XBPL-440 Signed-off-by: David Escalona <david.escalona@digi.com>
During a DigiMesh deep discovery, the library asks each node to list its neighbors with the 'FN' (find neighbors) command and waits 'N?' for the answer. If the answer does not arrive in time, the node is marked as non-reachable. 'N?' is the time the local node needs for its own neighbor discovery, and it was used as the wait time for every node, local and remote alike. A remote 'FN' needs more time than that: the request has to travel to the remote node, the remote then runs its own neighbor scan before it can answer, and the answer has to travel back. As a result, a remote node that was online but a little slow to answer could miss the deadline and be wrongly reported as non-reachable. Give remote requesters more time: wait the local timeout multiplied by _REMOTE_NEIGHBOR_TIMEOUT_FACTOR (2) instead of the plain local timeout. The local node is unaffected. The factor is a conservative upper bound (the remote does about the same work as the local node, ~'N?', plus the round trip, also bounded by ~'N?'), and using a multiplier rather than a fixed margin lets the extra time grow with network depth, since 'N?' is derived from the maximum hop count. See the constant's documentation for the full reasoning. XBPL-436 Signed-off-by: David Escalona <david.escalona@digi.com>
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
5 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.
No description provided.