PARITY.md

Feature parity: pure-Rust replacements for nmap, zmap and masscan

The nmap, zmap and masscan tool wrappers were removed from this server: it no longer executes a scanning binary. Their features live in the built-in engine (crates/zscan), reached through the net_scan MCP tool and the zscan CLI.

Everything marked "yes" below is implemented in Rust here and covered by a test. Everything under Out of scope is absent on purpose, with the reason stated — no flag is accepted and then ignored.

Scan types

nmap	what it does	here
-sS	TCP SYN	yes (tcp_syn)
-sT	TCP connect, via the kernel	yes (--connect-scan), no privileges needed
-sA	TCP ACK, maps firewall state	yes (tcp_ack)
-sF	TCP FIN	yes (tcp_fin)
-sN	TCP NULL	yes (tcp_null)
-sX	TCP XMAS	yes (tcp_xmas)
-sM	TCP Maimon (FIN+ACK)	yes (tcp_maimon)
-sW	TCP window (RST window size)	yes (tcp_window)
-sU	UDP	yes (udp, plus dns/mdns/snmp/ntp/ssdp/memcached payload modules, and udp_empty)
-sO	IP protocol scan	yes (ip_proto; the port field carries protocol numbers)
-PE, -PP, -PM	ICMP echo / timestamp / address-mask discovery	yes
-PR	ARP scan	yes (--arp-scan), authoritative on-link
-PS/-PA/-PU	TCP SYN/ACK/UDP ping	yes — those are the same probes as tcp_syn/tcp_ack/udp
--traceroute	path discovery	yes (--traceroute)
-sV	service/version detection	yes (versionDetect), probes over the kernel TCP stack
-O	OS detection	partial: TTL-derived stack hint (osDetect). A real fingerprint match needs a signature database; see gaps
-A	-sV -O --reason	yes (-A)
--reason	why a port got its verdict	yes (reason)

Why the flag-based scans report different things

This is nmap's semantics, implemented as such and unit-tested:

• SYN: SYN-ACK -> open, RST -> closed.
• FIN/NULL/XMAS/Maimon: RFC 793 makes a closed port answer RST and an open port stay silent, so RST -> closed and silence is simply unreported (it cannot be distinguished from filtered).
• ACK: cannot tell open from closed; RST proves the host is reachable and unfiltered, reported as up rather than a false open.
• Window: same probe as ACK, but the RST's window field decides: non-zero -> open, zero -> closed.

Port selection

Feature	Status
-p 80, 22,80, 1-1024, -1000, 1024-, *, all 65535	yes
T: / U: / S: / P: protocol prefixes, nmap's "prefix lasts until the next prefix" rule	yes
--top-ports N	yes, over nmap's published frequency data (1000 TCP / 200 UDP)
--port-ratio R	yes, a true prefix of the same table
-p - (all ports)	yes

Target handling

Feature	Status
CIDR, ranges, single hosts, commas, hostnames	yes
--exclude, --excludefile (-b)	yes, file errors name the offending line
--allowlist-file (-w), -I list-of-ips file	yes
-n / -R (no DNS / reverse DNS)	yes; a PTR client in zscan::dns, default is -n
-Pn semantics	inherent: the engine never pings before scanning
--randomize-hosts	inherent: the traversal is always seed-randomised (see zscan::addr::Permutation)
-n/--max-targets, -t/--max-runtime, -N/--max-results	yes

Pacing, evasion and output

Feature	Status
-r/--max-rate, -B/--bandwidth	yes
--min-rate	yes
-T0..-T5 timing templates	yes (rate ceiling + worker count)
--scan-delay	yes, and a test proves it actually paces the engine
-C/-P (numProbes/probesPerTarget)	yes
--source-port, --source-ip, --source-mac, --router-mac, -i	yes
--probe-ttl	yes, verified on the wire for every probe kind
-f / --mtu	yes; fragments are reassemblable (IP id, MF, offsets, DF cleared)
--data-length	yes, padded probes keep valid checksums and IP lengths
--badsum	yes; a host that answers an invalid checksum is not verifying
--shards N / --shard n (--seed)	yes; shards partition the space exactly
--dryrun (-d)	yes
--banners, --banner-hello	yes
Output: -oN normal, -oX XML, -oG grepable, JSON, CSV, list	yes
--output-fields, --output-filter (stateFilter)	yes
--dedup-method (one line per host)	yes (dedupHosts)
--metadata-file / --notes	yes (notes echoed in the response)

Quotas and multi-node (not an nmap feature)

The shell tools had none of this, and it is the reason the server exists:

• per-credential and per-tool rate, concurrency, cooldown, daily caps
• cluster quota profiles in MongoDB with priority queueing, sliding minute/hour/day/week windows for requests and bytes, CPU share
• editable in the web admin panel; changes propagate over the Redis bus

Out of scope

Each of these is a deliberate omission, not an oversight:

Feature	Why it is absent
-sC / --script (NSE)	A scripting language plus ~600 bundled scripts. The plugin tool registry ([[tools.custom]] and in-process ToolHandler impls) is the supported way to add a custom check, and it runs under the same quotas and timeouts.
-sY / -sZ (SCTP)	Requires SCTP support and is vanishingly rare; the raw engine speaks IPv4 only.
-sI (idle/zombie)	Needs a third-party host with predictable IP-ID behaviour; unusable on modern networks.
-b (FTP bounce)	Abuses an FTP server as a relay; obsolete and generally a hostile act.
-O full fingerprint DB	nmap's database is a large body of closed research. TTL hints are provided instead, and the limitation is stated in the output.
IPv6 in the raw engine	The AF_PACKET engine is IPv4 only (net_scan rejects IPv6 with a clear message). The connect scan (-sT) works over IPv6 through the kernel.
-D decoys, --proxies, --spoof-mac	Evasion features that require sending traffic attributable to third parties. --source-mac (your own NIC) and --probe-ttl are supported.
--netmap-wait-ping, --disable-syslog, --sender-threads, --batch, --iplayer	Properties of zmap's own implementation. This engine uses per-worker AF_PACKET rings with 4096-probe batches, speaks L3 already, and logs through the server's tracing.
--list-probe-modules, --list-output-fields and friends	Introspection of zmap's config system; here the tool schema and --help serve that purpose.

Measured performance

See PERFORMANCE.md. Summary: on this VM, against the same 1M-probe workload, zscan finishes in 5.0-5.6 s versus zmap's 5.3-5.8 s and masscan's 27.3 s, and the rate limiter holds a 40 000 pps cap to within 0.15 %.