# Mouse Slowness Network Path

## Symptom

Mouse movement felt slow even though the user expected the Macs to be connected over Thunderbolt.

## Findings

On this Mac, the live OpenMouse process had an established socket on Wi-Fi:

```text
192.168.86.249:5873 -> 192.168.86.21:56146
```

Thunderbolt was not active:

```text
bridge0 status: inactive
```

Direct health checks failed:

```text
ping 192.168.86.21: 100% packet loss
ping 169.254.148.79: 100% packet loss
nc 192.168.86.21 5873: No route to host
nc 169.254.148.79 5873: No route to host
```

The internet path still worked, so the issue was local peer/LAN/Thunderbolt reachability rather than general network outage. OpenMouse CPU was low during sampling.

## Root Cause

The current connection was not actually on Thunderbolt; it was an old Wi-Fi TCP socket while both fresh peer routes were failing. OpenMouse also did not close stale sockets after missed RTT probes, so mouse events could continue to queue into a degraded/dead socket and feel laggy.

## Fix

Added consecutive latency miss tracking. After 3 missed app-level RTT probes, OpenMouse logs `LATENCY_STALE` and destroys the stale peer socket so it can reconnect or show disconnected instead of continuing to send input into a bad path.

## Evidence

Verification run:

```text
node --check app.js
node --check app-ui/renderer.js
git diff --check
npm run package:mac
```

## Status

DONE_WITH_CONCERNS: root cause identified and stale-socket handling packaged. The physical/network issue still requires restoring Thunderbolt bridge or LAN reachability on the Macs.
