mirror/NetAlertX
1
0
Fork 0
mirror of https://github.com/jokob-sk/NetAlertX.git synced 2026-02-06 21:11:24 -05:00
Code Issues Packages Projects Releases Wiki Activity

DOCS: WiFi extenders and ping vs arp-scan clarification

Browse Source 
Signed-off-by: jokob-sk <jokob.sk@gmail.com>
This commit is contained in:
jokob-sk
2026-02-03 21:04:56 +11:00
parent 5081767b6e
commit 0f0a09fb28
1 changed files with 10 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/REMOTE_NETWORKS.md
View File

@@ -13,9 +13,17 @@ The following network setups might make some devices undetectable with `ARPSCAN`
### Wi-Fi Extenders
Wi-Fi extenders typically create a separate network or subnet, which can prevent network scanning tools like `arp-scan` from detecting devices behind the extender.
Wi-Fi extenders often **block or proxy Layer-2 broadcast traffic**, which can prevent network scanning tools like `arp-scan` from detecting devices behind the extender. This can happen **even when the extender uses the same SSID and the same IP subnet** as the main network.
> **Possible workaround**: Scan the specific subnet that the extender uses, if it is separate from the main network.
Please note that being able to `ping` a device does **not** mean it is discoverable via `arp-scan`.
* `arp-scan` relies on **Layer 2 (ARP broadcast)**
* ICMP (`ping`) operates at **Layer 3 (routed traffic)**
That’s why devices behind extenders may respond to ping but remain undiscoverable via `arp-scan`.
> **Possible workaround**:
> If the extender uses a separate subnet, scan that subnet directly. Otherwise, use DHCP-based discovery plugins or router integration instead of ARP. See the **Other Workarounds** section below for more details.
### VPNs