client: identify persistent clients via IPv6 NDP neighbor table#8248
Open
AndyHazz wants to merge 1 commit intoAdguardTeam:masterfrom
Open
client: identify persistent clients via IPv6 NDP neighbor table#8248AndyHazz wants to merge 1 commit intoAdguardTeam:masterfrom
AndyHazz wants to merge 1 commit intoAdguardTeam:masterfrom
Conversation
|
I ran into an unexpected issue while reviewing this PR. Please try again later. |
AndyHazz
force-pushed
the
ndp-client-identification
branch
from
e5f42d6 to
757928e
Compare
Currently, persistent clients configured with a MAC address can only be identified when they query over IPv4 (via DHCP lease lookup). When the same device queries over IPv6, AGH cannot resolve the source IPv6 address back to a MAC address, so the client appears unidentified and per-client filtering rules don't apply. Add an NDP (Neighbor Discovery Protocol) cache to Storage that periodically reads the kernel's IPv6 neighbor table (`ip -6 neigh`) and maps IPv6 addresses to MAC addresses. The cache is refreshed alongside ARP updates and on-demand when an address is not found and the cache is stale (>30s). The NDP lookup is used as a fallback in findByIP, FindLoose, and ApplyClientFiltering when the DHCP lease lookup returns no result. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
AndyHazz
force-pushed
the
ndp-client-identification
branch
from
757928e to
26f2f8c
Compare
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.
Summary
MACByIP()only checks DHCPv4 leasesfindByIP(),FindLoose(), andApplyClientFiltering()Motivation
On home networks where AdGuard Home acts as the DNS server and DHCP server, per-client filtering rules (e.g. blocking YouTube on children's devices) rely on identifying clients by MAC address. When IPv6 is enabled, devices send DNS queries from auto-generated IPv6 addresses (SLAAC + privacy extensions) that have no corresponding DHCPv4 lease. These queries appear as unidentified clients, bypassing per-client rules.
The NDP neighbor table already contains the IPv6→MAC mapping (populated by the kernel when processing incoming packets), but AGH doesn't consult it. The existing
arpdbinfrastructure only reads/proc/net/arp(IPv4) and doesn't reach theip neighfallback that includes IPv6.Implementation
map[netip.Addr]net.HardwareAddr) toclient.Storage, populated by runningip -6 neighReloadARP()parseNDPNeigh()for testabilityStorageConfig.NDPData(defaults to exec, overridden in tests)findByIP(),FindLoose(), andApplyClientFiltering()after the DHCP MAC lookup failsTest plan
parseNDPNeigh()— 8 cases covering typical output, missing lladdr, short lines, bad IP/MAC, router flag, empty input, mixed valid/invalidStorage.Find()andStorage.FindLoose()— IPv6 client found via NDP, unknown IPv4/IPv6 not found, graceful handling when NDP command failsinternal/clienttest suite passes🤖 Generated with Claude Code