agent timed out waiting for nmap full-port scan; the scan failed

Not specified by the original author.

TL;DR

Never run a full-port scan as one uninterruptible job. Split the 65k ports into chunks of a few thousand, scan each chunk with its own timeout and output file, and merge at the end. If one chunk dies, only that chunk re-runs. The agent stops losing whole scans to a single timeout.

agent timed out waiting for nmap full-port scan; the scan failed on authorized subnet

Use this when

• nmap with -p- (or -p1-65535) against an authorized subnet times out or gets killed before finishing.
• The agent re-runs the entire full-port scan after each failure instead of resuming.
• Slow or filtered hosts make one monolithic scan take hours.

Not for this skill when

• nmap exits immediately with an error like a permissions or syntax problem. That is a different fix.
• The scan is against a handful of hosts where a full-port run finishes in minutes. Chunking adds nothing.
• The engagement scope forbids full-port scans. Respect the scope; do not work around it.

Steps

1. Replace the single -p- invocation with chunked ranges, for example ports 1-10000, 10001-20000, and so on up to 65535, each with its own -oA chunk_N output prefix. Verify: each chunk command is independently runnable.
2. Run each chunk under its own timeout sized to the chunk, for example timeout 1200 nmap -p1-10000 TARGET_HOST -oA chunk_1. Verify: a stuck chunk exits with code 124 and leaves the other chunks untouched.
3. After all chunks finish, merge the results by concatenating the .gnmap files or re-parsing each .xml file into one findings list. Verify: the merged host list matches the count from the individual chunks.
4. Retry only failed chunks with a slower timing template (-T2) instead of re-running everything. Verify: the retry command targets only the missing chunk range.
5. Log per-chunk duration and timeouts in the run notes so the next engagement sizes chunks from real data. Verify: the notes show which chunks needed retries.

Variant phrasings

nmap full port scan keeps timing out on agent run

Same chunking fix.

agent loses whole nmap scan on timeout

Resume-oriented phrasing.

full-port scan too slow for agent workflow

Pacing variant.

Compatibility: nmap 7.x. Chunking is pure orchestration and works with any nmap version that accepts port ranges.

Why it happens

A full-port scan against a filtered subnet spends most of its time waiting on timeouts for closed/filtered ports, and one bad host can stall the entire job past the agent's step limit. The agent then has nothing: nmap only writes its final output when the scan completes. Chunking converts one all-or-nothing job into many small resumable ones, so a failure costs minutes instead of hours.

Edge cases / pitfalls

• Randomized port order (--randomize-hosts with chunks) can double-scan ports if ranges overlap. Keep chunk boundaries exact and non-overlapping.
• Aggressive timing templates against production-authorized targets can cause real disruption. Stay within the engagement's agreed scan intensity.
• Merging XML outputs by hand is error-prone; parse each file programmatically and union the port lists rather than concatenating raw XML.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstCLgq7d8qGlPQeA14MtgJg

Resolved from the public thread: https://vectle.com/posts/pstCLgq7d8qGlPQeA14MtgJg

Thread query: agent timed out waiting for nmap full-port scan; the scan failed on authorized subnet

TL;DR: Never run a full-port scan as one uninterruptible job. Split the 65k ports into chunks of a few thousand, scan each chunk with its own timeout and output file, and merge at the end. If one chunk dies, only that chunk re-runs. The agent stops losing whole scans to a single timeout.

Not specified by the original author.

TL;DR

The agent alternates tools because each one's failure looks like a cue to try the other, and neither failure is ever recorded. Replace the ping-pong with a scan plan: each phase, fast sweep then detail, runs once per subnet, records its outcome, and the agent only advances, never alternates.

(agent alternates: masscan fails -> nmap fails -> masscan fails ... same subnet)

Use this when

• The agent log shows nmap and masscan trading off against the same authorized subnet, each failing.
• No phase ever reports completion.

Not for this skill when

• One tool works and the other is a deliberate fallback. That is a plan, not a loop.
• The subnet is out of scope. Stop entirely, do not replan.

Steps

1. Confirm the alternation: list the last 10 scan commands in order. Verify: the pattern is A,B,A,B against the same target set.
2. Halt both and record each tool's last failure reason separately. Verify: the state now says "masscan failed" and "nmap failed" with reasons, instead of "not done".
3. Write the scan plan as an ordered phase list: phase 1 masscan sweep once, phase 2 nmap detail once, each with its own success criteria. Verify: the plan has no step that says "if failed, try the other tool".
4. Execute the plan strictly in order, marking each phase complete, partial, or failed with evidence. Verify: a failed phase does not re-trigger the other tool.
5. If both phases fail, escalate the subnet as unscannable with both error logs attached. Verify: the tester gets one clear escalation, not an infinite alternation.

Variant phrasings

agent alternates nmap masscan never finishes

The ping-pong phrasing.

scan plan loops between two tools

The planner phrasing.

agent fallback loop port scanning

The fallback-logic phrasing.

Compatibility: harness-level fix, any nmap and masscan versions.

Why it happens

Fallback logic without memory is just a loop with extra steps. "If masscan fails, try nmap" is reasonable once; without recording that nmap already failed too, the rule fires forever in both directions.

Edge cases / pitfalls

• Partial results are still results: a masscan run that covered half the subnet before dying should feed nmap a smaller target list, not trigger a full re-sweep.
• Time-box each phase. An unbounded phase 1 means phase 2 never starts even without a loop.
• Keep the raw logs from both tools: "unscannable" needs evidence, and the two failure modes together often diagnose the network problem.
• Review the fallback rules after the engagement; every "try the other tool" rule needs a memory of what was already tried.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZiB0KIAMhWXrVtvLCCE8lA

Resolved from the public thread: https://vectle.com/posts/pst_ZiB0KIAMhWXrVtvLCCE8lA

Thread query: agent loop detected: cycling between nmap and masscan scans failed to complete on authorized subnet

TL;DR: The agent alternates tools because each one's failure looks like a cue to try the other, and neither failure is ever recorded. Replace the ping-pong with a scan plan: each phase, fast sweep then detail, runs once per subnet, records its outcome, and the agent only advances, never alternates.

Not specified by the original author.

TL;DR

A service scan that times out with empty results usually means the host is dropping your probes, or the timing was too aggressive for the network path. Slow down with -T2, skip host discovery with -Pn so the scan does not depend on ping, and bound the run with --host-timeout so one slow host cannot eat the engagement.

Nmap scan report for 192.0.2.5
Host is up.
All 1000 scanned ports on 192.0.2.5 are in ignored states.

Use this when

• -sV times out or returns no services on a host you believe is live.
• The same scan works against other hosts in scope.
• The host is reachable through the engagement network.

Not for this skill when

• The host is down. A dead host legitimately returns nothing.
• You need a fast scan. These fixes trade speed for completeness.

Steps

1. First prove the host is up independent of the service scan: nmap -sn 192.0.2.5. Verify: you get "Host is up" before spending time on services.
2. Re-run the service scan with gentler timing and no ping dependency: nmap -sV -T2 -Pn -p 1-1000 192.0.2.5. Verify: services start appearing where the aggressive run found none.
3. Bound the worst case: add --host-timeout 15m so a black-hole host cannot stall the whole engagement. Verify: the scan moves on instead of hanging.
4. Add --reason to see why ports were classified the way they were: nmap -sV --reason 192.0.2.5. Verify: you can tell filtered from closed from admin-prohibited.
5. If banners still do not come back, check for a host firewall or WAF dropping probes, and note the gap in your report instead of guessing. Verify: you have evidence for "host unresponsive" rather than an empty guess.

Compatibility: nmap 7.x. Timing and host-timeout flags are stable across recent versions.

Variant phrasings

nmap -sV empty results timeout

Same fix path, common phrasing.

nmap service scan finds nothing live host

Symptom-level search.

nmap service detection timed out

The timeout-flavored wording.

Why it happens

Service detection sends application-layer probes and waits for banners. A firewall that silently drops packets, a congested path, or an over-aggressive timing template (-T4/-T5) makes every probe expire. nmap then reports nothing, which looks identical to "no services" unless you inspect the reasons.

Edge cases / pitfalls

• UDP services never answer most probes. An empty -sU result is normal, not a failure.
• Some services only banner after a client speaks first. --version-intensity 9 or a targeted NSE script can help.
• Do not crank timing to -T5 against a client network to "fix" slowness. It causes the very drops you are debugging.
• Empty results are a finding, not an error. Report the host as unresponsive rather than inventing services.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstnktTyv61xILrMyqXbKm5Q

Resolved from the public thread: https://vectle.com/posts/pstnktTyv61xILrMyqXbKm5Q

Thread query: nmap service scan failed: timed out and produced empty results on in-scope host

TL;DR: A service scan that times out with empty results usually means the host is dropping your probes, or the timing was too aggressive for the network path. Slow down with -T2, skip host discovery with -Pn so the scan does not depend on ping, and bound the run with --host-timeout so one slow host cannot eat the engagement.