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

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

Full masscan output is far too large for any context window, so the fix is to never put it there: stream-parse the output file into a compact host-to-ports summary on disk, and give the agent only the summary. Keep the raw output on disk for drill-down. Summarization reads files; it does not ingest them.

agent context window overflow on full masscan output caused the scan summary to fail

Use this when

• Masscan finished and wrote its output file, but the agent's summary step failed or produced a truncated summary.
• The agent tried to read the raw output file into context.
• You run internet-scale or large-subnet scans under agent control.

Not for this skill when

• Masscan itself failed or wrote no output. That is a scan issue.
• The output is small enough to fit comfortably. Then just read it.
• You are scanning ranges outside your authorized engagement. Stop.

Steps

1. Confirm the size mismatch: check the output file size against the agent's context budget. Verify: the file is orders of magnitude larger than what the agent tried to read.
2. Write a streaming parser that reads the masscan output line by line and emits a compact summary: one line per host with its open ports. Verify: the summary file is small enough to fit in context with room to spare.
3. Have the agent summarize from the compact file only. Verify: the summary covers every host in the compact file (count check).
4. Keep the raw output on disk and teach the agent a drill-down pattern: grep the raw file for a specific host when it needs detail. Verify: the agent can answer a detail question about one host without reading the whole file.
5. Add the pattern to the agent's scan playbook: raw output stays on disk, summaries go to context. Verify: the next masscan run follows the pattern without being told.

Variant phrasings

masscan output too large for agent context

Common phrasing.

summarize large scan output without loading it

Workflow phrasing.

agent chokes on full port scan results

Symptom-level search.

Compatibility: masscan text output. The stream-and-summarize pattern works for any large scanner output.

Why it happens

Agents default to reading files whole, and masscan's whole output for a large range is enormous. The summary step then fails on the context limit, and the agent either truncates silently (losing hosts) or errors out (losing everything).

Edge cases / pitfalls

• Binary masscan output must be converted to text first; do not try to stream-parse the binary format directly.
• The compact summary should keep port states, not just port numbers. A ports-only list without states misleads the next stage.
• If the summary is still too large, aggregate further: count hosts per open port, and list only the interesting outliers in full.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HfAvc-qmhzWMdIRiu8SVIg

Resolved from the public thread: https://vectle.com/posts/pst_HfAvc-qmhzWMdIRiu8SVIg

Thread query: agent context window overflow on full masscan output caused the scan summary to fail

TL;DR: Full masscan output is far too large for any context window, so the fix is to never put it there: stream-parse the output file into a compact host-to-ports summary on disk, and give the agent only the summary. Keep the raw output on disk for drill-down. Summarization reads files; it does not ingest them.