PSPLink Hardware Research: Transport Qualification, HostFS, and Failure Modes

Wave 4 structured record

Stable ID: FIND-PSPLINK-TRANSPORT-001

Evidence class: MEASURED / ENVIRONMENT-SCOPED. This is a transport-methodology finding from the same PSP/package tested through two host paths, not a universal Windows or Linux compatibility claim.

Scope: Native Windows enumerated, opened, and claimed Sony 054c:01c9, then timed out on the EP2 HostFS magic; the same PSP/package through usbipd → WSL2/Linux returned 4, produced EP81 traffic, and reached a real host0:/> prompt. The A/B result isolates host/backend/path differences for this fixture.

Reproduction confidence: REPEATED SAME DEVICE for the reported A/B route; a second PSP and a second host are still needed. Qualification requires handshake, remote-shell round trip, smoke test, and capture-integrity checks.

Novelty/support: N2 transport isolation and N3 reproducibility criteria. It supports EXP-PSPLINK-TRANSPORT-20260806-A.

Status: HARDWARE MEASURED / METHODOLOGY · Scope: tested Windows 11 native path versus WSL2/usbipd with a PSP Type B device · Last reviewed: 2026-08-11

Qualify the transport before the semantics

PSPLink research has two separable questions: can the host open and claim the USB device, and can a real HostFS operation complete? A shell that opens successfully is only a transport precondition. The semantic gate is a remote operation such as pwd or ls, with capture integrity checked before interpreting the result.

Observed path

In the tested native Windows session, device open, configuration, and interface claim succeeded, but the first four-byte HOSTFS_MAGIC bulk OUT transfer on endpoint 0x02 timed out. Responses are expected on bulk IN endpoint 0x81. The same PSP package and device, attached to WSL/Linux through usbipd, completed the HostFS exchange and a real remote operation.

The responsible conclusion is narrow: the result localizes a difference to the tested Windows-side libusb/backend/path combination. It does not show that PSPLink “doesn’t work on Windows.” Re-test with a named driver/backend and device state before comparing implementations.

Hardware traceability

Directly observed: device open/configure/claim, the endpoint-0x02 magic write, endpoint-0x81 response behavior, and the bounded native-Windows versus WSL2/usbipd comparison. Interpretation: localization to the tested Windows-side backend/path. Repeatability: this is a bounded session comparison; other host drivers/backends, device states, and PSP revisions remain untested.

Recovery and integrity controls

resetonexit=0 matters when repeating probes; otherwise a session can reset the device before the next observation. Reset storms, stale tails, and large output can make a capture look like a protocol failure. Classify those conditions explicitly as RESET_STORM, CAPTURE_MISSING, or CAPTURE_CORRUPT before calling a semantic test pass or fail.

Public sources

The PSPDEV debugging guide and the pinned psplinkusb HostFS client path and its HOSTFS_MAGIC definition document the public transport/tooling context. The hardware observations above are a bounded source-owned record; the public transport setup and probe provenance are available for review, and no private game files, keys, captures, or derived bytes are needed or published.

Use the Hardware Oracle Methodology to separate setup, transport, and semantic evidence, and the Evidence Standard to report an unavailable or corrupt capture honestly. Related reading: Open Research Questions.

Contradiction/replication: Track the environment difference in CONFLICT-PSPLINK-TRANSPORT-001 and the REG-HARDWARE-FINDINGS-001. Report backend versions and clean capture integrity without exposing private routes, keys, captures, or game assets.

Current source anchor — Wave 4

The public qualification guidance was refreshed against docs/HARDWARE_ORACLE.md at main 04daf156. The transport result remains environment-scoped; no universal host compatibility claim is made.