3 june 2026

I spent today tightening up my HomeLab notes and automation around regaining access to a WiFi router when the admin creds (or even the WiFi password) are unknown. I also paid attention to how much system resources these workflows can chew through by keeping an eye on temps/power while I iterated.

What I learned

• Turning “router recovery” into a repeatable workflow is mostly about sequencing and decision points: identify the gateway/device, enumerate access paths, try the least invasive options first, and only escalate when you’ve confirmed you’re working against equipment you own and are authorized to test.
• WiFi recovery techniques and tooling can be risky/abusable. For public documentation, it’s better to focus on defensive, owner-authorized recovery (hardware reset/physical access, vendor recovery modes, backup configs, credential rotation) and avoid publishing step-by-step attack instructions.

What I built

• Cleaned up and organized my markdown runbooks for router discovery and access recovery.
• Refactored shell scripts that automate the early stages: basic network discovery, extracting likely gateway/router info, and guiding a “try these next” flow for recovering access.

Experimenting with

• A structured recovery playbook that distinguishes:
• Admin access recovery (physical reset, default creds, vendor recovery, config restore)
• Client WiFi access recovery (rotate PSK, re-provision devices, auditing)
• Monitoring system temperature/power while running network tooling to understand practical limits and when to pause/adjust workloads.