agent masscan run timed out and the agent failed parsing partial output

Not specified by the original author.

TL;DR

masscan can be resumed and its partial output is usable, but only if the agent asks for both. Run masscan with --resume support via its conf file, write results incrementally, and parse whatever landed before the timeout instead of treating a killed run as zero data.

agent masscan run timed out and the agent failed parsing partial output

Use this when

• masscan is killed by timeout or the agent step limit and the agent reports no findings.
• The agent discards the run because the output file looks incomplete.
• A previous masscan run on the same authorized range exists and could be resumed.

Not for this skill when

• masscan fails immediately with a permissions error (raw sockets need elevated privileges). That is a setup problem.
• masscan completes normally but the agent misreads the output. That is a parsing bug, not a timeout.
• The engagement scope does not permit masscan's speed. Respect the scope.

Steps

1. Launch masscan with a conf file (--conf scan.conf) so the --resume state (paused.conf) is written automatically; run it under an explicit timeout. Verify: interrupting the scan leaves a paused.conf file behind.
2. Choose an incremental output format (-oJ for JSON or -oX for XML) rather than the default human-readable list. Verify: the output file grows while the scan runs.
3. After a timeout kill, parse the partial output file as-is: read every complete record and ignore the truncated tail. Verify: the parsed host count is greater than zero even though the scan did not finish.
4. Resume with the same command plus --resume; masscan picks up where paused.conf says it stopped. Verify: the resumed run's first output lines cover unscanned ranges, not repeats.
5. Merge partial parses from each attempt into one findings list, deduplicating by host and port. Verify: the final list has no duplicate host/port pairs.

Variant phrasings

masscan timeout left agent with no results

Same resume pattern.

agent cannot read partial masscan output

Parsing-focused variant.

resume masscan after agent step timeout

Resume-focused phrasing.

Compatibility: masscan 1.3.x. The --resume/paused.conf mechanism is built into masscan and needs no extra tooling.

Why it happens

Agents treat a killed process as a failed process, and masscan's default output gives them nothing until the end. The --resume machinery exists precisely for interrupted scans, but agents rarely invoke it because it is not part of the default command they were shown. Partial output plus resume converts a timeout from total loss into a pause.

Edge cases / pitfalls

• paused.conf is written on clean interrupts (SIGINT); a hard SIGKILL may skip it. Prefer interruptible timeouts where the harness allows signal choice.
• masscan's speed can overwhelm small authorized targets. Keep the --max-rate within the engagement's agreed limits; resume does not excuse over-aggressive scanning.
• Partial output from a timed-out run is a coverage statement: report which ranges were actually scanned, not just what was found.

Provenance

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

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

Thread query: agent masscan run timed out and the agent failed parsing partial output

TL;DR: masscan can be resumed and its partial output is usable, but only if the agent asks for both. Run masscan with --resume support via its conf file, write results incrementally, and parse whatever landed before the timeout instead of treating a killed run as zero data.

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.

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.