Read the Windows neighbor table directly, and stop reporting the broadcast address as a host - #495
Merged
Merged
Conversation
…dcast address as a host Discovery and sweep ran `arp -a` and parsed its text on Windows. They now read the table with GetIpNetTable2, keeping only live neighbor states with a unicast MAC. Discover also drops the subnet's network and broadcast addresses (except on /31 and /32) and any broadcast or multicast MAC, on every platform: the Windows table lists x.x.x.255 as ff:ff:ff:ff:ff:ff, and discover reported it as a host that a sweep then scanned. Timing: arp -a took 65 ms idle and about 4 s under heavy CPU load on the same Windows 11 machine. On an idle machine a /24 discover measured 1.72 s before and 1.71 s after (10 interleaved runs), so this is not a speed change in the normal case.
|
Site preview: https://pr-495.netscli-site-preview.pages.dev Built from f9961ef 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.
From the R&D pass on discovery.
Bug fixed. On Windows the neighbor table lists
192.168.1.255with MACff:ff:ff:ff:ff:ff(a static entry), anddiscoverreported it as an ICMP-silent host, whichsweepthen scanned. Seen in 10 of 10 runs on a home /24 before, 0 of 10 after.Change.
GetIpNetTable2(IPv4 only, as before) instead of runningarp -aand parsing it. Only live neighbor states (reachable, stale, delay, probe, permanent) with a unicast MAC are kept, so thearpcommand also stops listing broadcast and multicast entries (57 → 23 rows here, all of the dropped onesff:ff…or01:00:5e…).Speed: no change in the normal case, stated plainly. My first measurement said discover was 40% faster. That was taken while other builds were saturating the CPU, when
arp -atook about 4 s. On an idle machinearp -atakes 65 ms, and a /24 discover measured 1.72 s before and 1.71 s after (10 interleaved runs each). What remains is one fewer program start per discover, which matters only under load.Dropped from the prototype: shortening the mDNS window from 1.5 s to 1 s. It looked faster under load, but names were lost (
linux.localnamed in 5 of 8 runs).Tests: the neighbor filter and the host-address filter, plus a live read of the table asserting no broadcast entry. Breaking either filter fails 3 of the 6. Clippy clean.
Not verified: macOS and Linux behaviour (the discover filter applies there too; their table readers are unchanged).