[GH-ISSUE #4176] [Bug] extract_firmware's fixed 120 s deadline covers publication, so a 7 MB OpenWrt image times out on a Docker Desktop bind mount #1634

New issue

Closed

opened 2026-10-16 21:08:15 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:08:15 +00:00

Owner

Originally created by @Rinkia on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4176

Before submitting

I searched the open and closed issues for a related report (extract_firmware timeout, firmware deadline, publication slow): none found.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

Same image, same container, same command. Only the output directory's filesystem differs:

`output_directory`	Result	Wall time
container `/tmp/rea-extract` (overlayfs)	success: 1,101 files, 34 MB published	18 s
bind-mounted host directory (`/work/...`, Docker Desktop on Windows)	`provider_timeout`, `timeout_ms: 120000`, nothing published	2 min 13 s

For comparison, a plain cp -r of the same 1,101-file tree into that bind mount takes 20 s.

{"code":"provider_timeout","category":"timeout",
 "message":"Analysis took too long. Try a smaller request, then run `rea doctor` if it continues.",
 "retryable":true,"details":{"operation":"extract_firmware","timeout_ms":120000}}

So almost all of the time went into REA's publication step (exclusive, symlink-resistant writes with durable digest readback, per the docs), not into Unblob. The deadline is the fixed FIRMWARE_LIMITS.timeoutMs = 120_000 (src/firmware/FirmwareRelease.ts). In FirmwareProvider.#execute, a single AbortSignal.timeout(FIRMWARE_LIMITS.timeoutMs) (line ~230) is passed to the snapshot, the Unblob run, the output inventory and publishFirmwareExtraction (line ~380), and it has no override. The remediation ("Try a smaller request") doesn't apply: the image is small, and only the destination filesystem matters.

Reproduction

Image: OpenWrt 24.10.8 openwrt-24.10.8-ath79-generic-tplink_archer-c7-v5-squashfs-sysupgrade.bin, sha256 feeab4e3142feb865450ab044a42e198af9510d263e4b0f6d1cdcc701d296003 (release sha256sums with a good GPG signature from the OpenWrt Build System key).

docker run … -v C:\...\work:/work rea-fw …
rea extract-firmware /targets/openwrt-…-sysupgrade.bin /work/fw-out/extract --json   # provider_timeout after ~133 s
rea extract-firmware /targets/openwrt-…-sysupgrade.bin /tmp/rea-extract --json       # OK in 18 s

Expected behavior

A deadline that scales with, or is configurable for, the publication phase (e.g. an environment variable like the other providers' limits, or a separate publication budget), so slow but working filesystems can be used.
When the deadline expires during publication, an error that says so (phase, files published so far) and suggests a local destination, rather than "try a smaller request".

Impact and scope

Affects Docker Desktop bind mounts on Windows and macOS, and plausibly network or FUSE filesystems. With REA running in a container, writing results to the host is the natural workflow.
Larger firmware (100+ MB root filesystems) would hit the deadline sooner. I haven't measured that on native filesystems.
Rollback worked correctly: no partial tree was left behind.

REA version

Executed on rea-agents@6.5.0. The constant is unchanged on main @ e9a71efa3 (source-derived).

Runtime and platform

Windows 11, Docker Desktop (WSL2 backend), bind mount of an NTFS directory. Linux x64 container from the rea image plus Binwalk 3.1.0 and Unblob 26.6.4.

Target and artifact context

Public, signed OpenWrt release image (GPL).

Interface

CLI.

Originally created by @Rinkia on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4176 ### Before submitting - [x] I searched the open and closed issues for a related report (extract_firmware timeout, firmware deadline, publication slow): none found. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior Same image, same container, same command. Only the output directory's filesystem differs: | `output_directory` | Result | Wall time | | --- | --- | --- | | container `/tmp/rea-extract` (overlayfs) | success: 1,101 files, 34 MB published | 18 s | | bind-mounted host directory (`/work/...`, Docker Desktop on Windows) | `provider_timeout`, `timeout_ms: 120000`, nothing published | 2 min 13 s | For comparison, a plain `cp -r` of the same 1,101-file tree into that bind mount takes 20 s. ```json {"code":"provider_timeout","category":"timeout", "message":"Analysis took too long. Try a smaller request, then run `rea doctor` if it continues.", "retryable":true,"details":{"operation":"extract_firmware","timeout_ms":120000}} ``` So almost all of the time went into REA's publication step (exclusive, symlink-resistant writes with durable digest readback, per the docs), not into Unblob. The deadline is the fixed `FIRMWARE_LIMITS.timeoutMs = 120_000` (`src/firmware/FirmwareRelease.ts`). In `FirmwareProvider.#execute`, a single `AbortSignal.timeout(FIRMWARE_LIMITS.timeoutMs)` (line ~230) is passed to the snapshot, the Unblob run, the output inventory and `publishFirmwareExtraction` (line ~380), and it has no override. The remediation ("Try a smaller request") doesn't apply: the image is small, and only the destination filesystem matters. ### Reproduction Image: OpenWrt 24.10.8 `openwrt-24.10.8-ath79-generic-tplink_archer-c7-v5-squashfs-sysupgrade.bin`, sha256 `feeab4e3142feb865450ab044a42e198af9510d263e4b0f6d1cdcc701d296003` (release `sha256sums` with a good GPG signature from the OpenWrt Build System key). ```sh docker run … -v C:\...\work:/work rea-fw … rea extract-firmware /targets/openwrt-…-sysupgrade.bin /work/fw-out/extract --json # provider_timeout after ~133 s rea extract-firmware /targets/openwrt-…-sysupgrade.bin /tmp/rea-extract --json # OK in 18 s ``` ### Expected behavior - A deadline that scales with, or is configurable for, the publication phase (e.g. an environment variable like the other providers' limits, or a separate publication budget), so slow but working filesystems can be used. - When the deadline expires during publication, an error that says so (phase, files published so far) and suggests a local destination, rather than "try a smaller request". ### Impact and scope - Affects Docker Desktop bind mounts on Windows and macOS, and plausibly network or FUSE filesystems. With REA running in a container, writing results to the host is the natural workflow. - Larger firmware (100+ MB root filesystems) would hit the deadline sooner. I haven't measured that on native filesystems. - Rollback worked correctly: no partial tree was left behind. ### REA version Executed on `rea-agents@6.5.0`. The constant is unchanged on `main` @ `e9a71efa3` (source-derived). ### Runtime and platform Windows 11, Docker Desktop (WSL2 backend), bind mount of an NTFS directory. Linux x64 container from the `rea` image plus Binwalk 3.1.0 and Unblob 26.6.4. ### Target and artifact context Public, signed OpenWrt release image (GPL). ### Interface CLI.

bsakaguchi closed this issue

2026-10-31 00:31:53 +00:00

bsakaguchi referenced this issue

2026-10-31 00:44:30 +00:00

[GH-ISSUE #6405] [Feature] Ghidra: export analyst names and comments from a session and re-apply them when the target is reopened #3835

bsakaguchi referenced this issue

2026-10-31 00:44:30 +00:00

[GH-ISSUE #6404] [Feature] Ghidra: admit comment / inline_comment / set_comment / set_inline_comment at any mapped address #3837

bsakaguchi referenced this issue

2026-10-31 00:54:15 +00:00

[PR #1635] [MERGED] feat(ghidra): admit set_address_name and set_addresses_names #4714

bsakaguchi referenced this issue