Repository navigation
Discovery on Windows: ask table-only neighbours again before listing them - #535
Merged
Merged
Conversation
…them Discovery lists neighbour-table entries that did not answer ping, so that devices ignoring ICMP are still found. On Windows the table also keeps entries for devices that have left (Stale, Delay, Probe), and those were reported as present: 4 of 26 hosts on one LAN on 2026-10-06, each failing three SendARP lookups afterwards. Each table-only candidate is now asked with SendARP, in the background while names resolve, and kept only if it answers within 2.5 s. The slowest real answer measured was 2.2 s (a device answering Windows' third ARP retry). Linux and macOS are unchanged; not measured there. A/B against main, 6 interleaved runs each, scored against an ARP ground truth: both found all 23 devices with no extras; median 1.76 s versus 1.77 s, with one run at 3.9 s when a candidate had to time out. The ghost entries had aged out by the time of the A/B, so the 4-of-26 case is the earlier observation, not this run. A test asks an unassigned TEST-NET address and requires it to be dropped; it fails if candidates are kept.
Contributor
|
Site preview: https://pr-535.netscli-site-preview.pages.dev Built from fda75d0 with Production is unaffected: netscli.com is served from GitHub Pages via |
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
1 participant
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.
What I found
"Devices that ignore ping" turned out not to be a gap: discover already lists neighbour-table entries that didn't answer ping, and the ping sweep itself makes Windows ARP every address, so a silent device ends up in the table. Against an ARP ground truth (SendARP to every address in the /24) discover missed none of 22 devices, 5 of which only answer ARP.
The real problem was the opposite: devices that had left were listed as present. On 2026-10-06 discover returned 26 hosts; 4 of them (two Tuya plugs and two others) were stale table entries (
Stale/Delay/Probe), failed three SendARP lookups in a row afterwards, and Windows then marked themUnreachable.Fix
On Windows each table-only candidate is asked again with
SendARP, in the background while names resolve, and kept only if it answers within 2.5 s. Answers from present devices took 0 to 2,163 ms (one device answered Windows' third ARP retry); a lookup with nothing behind it takes about 4.2 s. Linux and macOS are unchanged, since nothing there has been measured.Measured (6 interleaved runs each, scored against ARP ground truth taken afterwards)
The stale entries had aged out before the A/B ran, so both builds were clean on it; the 4-of-26 case is the earlier observation. The A/B shows the change costs nothing when there is nothing to drop and loses no real device.
Test
a_neighbour_that_does_not_answer_arp_is_droppedasks an unassigned TEST-NET address and requires it to be dropped. With the filter replaced by "keep every candidate", it fails.