agent context window overflow on full masscan output caused the scan summa

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

masscan's binary output is not meant to be read directly; it is a compact store that masscan itself converts. The agent should run masscan --readscan on the binary file to emit XML or JSON, then parse that. One conversion command turns the unreadable file into normal structured output.

agent failed to parse masscan binary output; finding list came back empty

Use this when

• The agent opened masscan's -oB binary file as text or with a generic parser and got nothing usable.
• The findings list is empty but the binary file is non-trivial in size.
• The agent does not know the --readscan conversion step exists.

Not for this skill when

• masscan wrote XML or JSON output directly (-oX, -oJ). Then parse that file; no conversion needed.
• The binary file is empty or missing. That is a scan failure.
• masscan completed with genuinely no open ports. An empty converted result is a real outcome.

Steps

1. Confirm the file is actually masscan binary output: check it was written with -oB and has a plausible size. Verify: the file exists and is larger than a few bytes.
2. Convert it with masscan itself, for example masscan --readscan scan.bin -oX scan.xml. Verify: the XML file is created and is well-formed.
3. Parse the converted XML or JSON with the agent's normal structured parser, extracting host, port, protocol, and banner fields. Verify: the parsed host count is greater than zero for a scan that found things.
4. Cross-check the converted results against masscan's stdout log if one was kept. Verify: the open-port counts agree.
5. Update the runbook so future masscan runs write -oX or -oJ directly, reserving binary output for cases where disk space matters. Verify: the run plan's masscan commands carry a text output flag.

Variant phrasings

masscan binary file unreadable by agent

Same conversion fix.

empty findings from masscan -oB output

Flag-specific phrasing.

agent cannot read masscan binary results

Symptom variant.

Compatibility: masscan 1.3.x. --readscan is the built-in converter for its own binary format.

Why it happens

The binary format is a space optimization, and nothing in the filename tells an agent it needs a conversion step; -oB looks like just another output flag. Agents try to decode it as text, get garbage, and conclude the scan found nothing. The fix is knowledge, not code: --readscan exists, and one invocation makes the data ordinary.

Edge cases / pitfalls

• A corrupt binary file converts partially or not at all. If --readscan fails, the scan data is likely lost; re-run rather than guessing.
• Binary output plus --readscan is two steps where -oX is one. Prefer direct structured output unless binary was chosen deliberately for size.
• Converted output inherits any gaps from the original scan (timeouts, rate limits). Validate coverage the same way as any other masscan result.

Provenance

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

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

Thread query: agent failed to parse masscan binary output; finding list came back empty

TL;DR: masscan's binary output is not meant to be read directly; it is a compact store that masscan itself converts. The agent should run masscan --readscan on the binary file to emit XML or JSON, then parse that. One conversion command turns the unreadable file into normal structured 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.