Skip to main content
How Can We Help?
< All Topics
Print

Conflict: PSPLink Native Windows vs WSL2 Transport

Posted
Updated
ByJstar269

Conflict ID: CONFLICT-PSPLINK-TRANSPORT-001 · Status: RESOLVED AS SCOPE DIFFERENCE

Question

Does a detected PSP Type B device prove that a PSPLink semantic session is healthy on modern Windows?

Claims in conflict

  • A — native Windows leg: the device enumerated, opened, configured, and claimed, but the first four-byte HostFS EP2 write timed out with libusb -7.
  • B — WSL2/usbipd Linux leg: the same physical PSP/package returned four bytes, completed EP81 traffic, and reached a real host0:/> shell.

Why they appeared incompatible

“Connected” and a local shell process can look healthy even when the remote PSP protocol has not completed. The A/B comparison isolates host/backend/path behavior without proving a universal Windows failure.

Smallest supported conclusion

In the tested environment, native Windows transport failed at the initial HostFS handshake while WSL2/Linux succeeded. Transport qualification must be explicit before semantic results are classified.

What was resolved

USB presence, local TCP shell behavior, remote HostFS handshake, smoke qualification, and semantic acceptance are separate states. Stale-tail, truncated, or reset-storm captures are invalid evidence.

Resolving experiment: EXP-PSPLINK-TRANSPORT-20260806-A. Related finding: FIND-PSPLINK-TRANSPORT-001 · Last reviewed: 2026-08-11.

Current source anchor — Wave 4

The qualification context was refreshed against docs/HARDWARE_ORACLE.md at main 04daf156; this conflict remains an environment-scoped transport difference.

Table of Contents