Network scan fails without -n flag due to DNS resolution timeout

[KafCaf]

Of course. Here is a complete, professionally written GitHub issue based on our entire troubleshooting process. You can copy and paste this directly into a new issue on the UpSnap GitHub page.

---

Issue Title: Network Scan Fails Due to DNS Timeout, Works with nmap -n Flag

Environment

• UpSnap Image: ghcr.io/seriousm4x/upsnap:latest

Problem Description

The UpSnap web interface does not display any discovered devices on the local network. The application starts correctly, and the web server is accessible.Devices can be added manually,but the primary network scanning feature appears to be non-functional, resulting in an empty device list.

Detailed Troubleshooting Steps & Logs

A systematic diagnosis was performed, which successfully isolated the issue to the way nmap is being called by the application. The underlying network connectivity from the container to the LAN is fully functional.

1. Verified L2 Network Connectivity with arp-scan

I entered the running container and confirmed that basic Layer 2 ARP scanning works correctly.

Command:

docker exec -it upsnap /bin/sh
apk add --no-cache arp-scan
arp-scan --localnet

Result: (Success)
arp-scan successfully and quickly discovered multiple hosts on the LAN (192.168.31.0/24), proving the macvlan network is correctly configured and the container has L2 visibility.

Interface: enx68da73ae50e2, type: EN10MB, MAC: 68:da:73:ae:50:e2, IPv4: 192.168.31.250
Starting arp-scan 1.10.0 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.31.1    58:ea:1f:9d:96:1c       (Unknown)
192.168.31.2    b0:25:aa:54:73:52       Private
192.168.31.7    e8:6b:ea:9a:8f:44       (Unknown)
...
Ending arp-scan 1.10.0: 256 hosts scanned in 2.052 seconds (124.76 hosts/sec). 5 responded

2. Tested nmap without disabling DNS resolution

Next, I tested nmap with the same parameters UpSnap likely uses (-sn). This command failed by hanging indefinitely.

Command:

# Inside the container
nmap -sn 192.168.31.0/24

Result: (Failure)
The scan got stuck on DNS resolution and eventually would have timed out without finding any hosts.

Starting Nmap 7.97 ( https://nmap.org ) at 2025-07-07 04:41 +0000
Stats: 0:00:06 elapsed; 0 hosts completed (0 up), 254 undergoing ARP Ping Scan
Parallel DNS resolution of 254 hosts. Timing: About 1.97% done; ETC: 04:44 (0:02:29 remaining)
... (hangs here)

3. Tested nmap WITH DNS resolution disabled (-n flag)

This is the definitive test. By adding the -n flag to disable DNS resolution, nmap works perfectly.

Command:

# Inside the container
nmap -sn -n 192.168.31.0/24

Result: (Success)
The scan completed quickly and successfully discovered all online hosts, matching the arp-scan result.

Starting Nmap 7.97 ( https://nmap.org ) at 2025-07-07 04:43 +0000
Nmap scan report for 192.168.31.1
Host is up (0.0019s latency).
MAC Address: 58:EA:1F:9D:96:1C (Beijing Xiaomi Mobile Software)
Nmap scan report for 192.168.31.2
Host is up (0.0028s latency).
MAC Address: B0:25:AA:54:73:52 (Private)
Nmap scan report for 192.168.31.7
Host is up (0.038s latency).
MAC Address: E8:6B:EA:9A:8F:44 (Espressif)
...
Nmap done: 256 IP addresses (5 hosts up) scanned in 2.11 seconds

Conclusion & Suggested Solution

The root cause of the network scan failure is that nmap is being called without the -n flag. In typical LAN environments without a local DNS server configured for reverse lookups, this causes nmap to hang on DNS resolution timeouts, preventing the scan from ever completing successfully.

It is highly recommended that UpSnap's internal call to nmap for network scanning should use the -n flag by default to ensure reliable performance on all local networks. Alternatively, this could be exposed as a user-configurable option in the settings.

Thank you for your work on this great tool.