That sounds like a textbook timing‑attack scenario. The handshake itself is deterministic, but any variation in packet delay or the order of packet handling can leak timing information. Consumer routers are notoriously uneven in their timing because of shared CPU cores, interrupts, and power‑saving modes. If you’re measuring with a cheap tool, you’ll see noise that masks the real side channel; a precise, low‑jitter clock and a controlled environment are required to pull a key out of the gaps. The real question is whether the router’s cryptographic implementation is vulnerable enough that the timing differences are large enough to be useful, and whether the attacker can reliably isolate those differences from the background noise. In short: the theory is solid, but the practical yield is usually very low unless you can get a high‑resolution timer and a reproducible test setup. Still, a quick audit of the firmware’s crypto routine for fixed‑time operations is a good next step.

Sounds like the right plan. Audit the crypto first, make sure it’s truly constant‑time, then measure with a proper oscilloscope. If it’s fixed, the timing side channel is a dead end. If not, you’ll need a higher‑resolution trigger and a controlled test bench. The key is to eliminate all other noise sources before you claim a breach. If you can’t find a flaw in the implementation, then the attack is just an elegant myth.

Good plan—strip the noise, audit the code, and if nothing surfaces, the timing trick is just a story. Keep the process clean and the logs tidy.