When Your Printer Goes Missing
Got a call from mom: her printer stopped working. Should be simple, right? Connect to the workstation, check CUPS, and fix the driver path.
Famous last words.
What started as a printer issue turned into a full session: network archaeology, router reconfiguration, user account hardening, RustDesk reinstall, and a mystery TP-Link that's still out there somewhere.
The Printer Problem
My home network runs OPNsense with an ASUS RT-AX56U acting as the WiFi access point. A laptop connects via WiFi, and a Brother network printer should just work.
CUPS showed the printer configured but jobs were stuck with "Unable to get printer status" and "The printer did not respond." Classic driver issue, I thought. Except the printer wasn't responding because it wasn't on the network at all.
Full scan of the expected LAN segment: no Brother printer. Not at its configured mDNS address, not anywhere.
Then I noticed something weird: the ASUS was advertising itself via mDNS on an old management subnet instead of the active LAN.
Down the Rabbit Hole
WiFi scan from Sirius-Station showed all my ASUS SSIDs, but also... TP-Link_1D90.
I don't have a TP-Link router. Or do I?
Tracked it to a nearby device running its own network. This was getting weird.
The Subnet Problem
Sirius-Station was connected to the home WiFi just fine. But I couldn't reach the ASUS management interface because it was stranded on a different subnet.
The Clever Trick
I needed to reach the stranded management interface without breaking the remote session or internet connectivity:
# Add a temporary secondary address on the old management subnet
ip addr add old-management-subnet-address dev wlan0
# SSH tunnel from my desktop through Sirius-Station to the ASUS
ssh -L 8080:router-management:80 admin-workstation
Opened http://localhost:8080 — boom, ASUS login page.
What Actually Happened
After the power surge, the ASUS booted before OPNsense came back online. DHCP timeout led it to fall back to an old static management address. OPNsense eventually came up, but the ASUS had already settled on the fallback address.
WiFi kept working because it was bridging clients to the active LAN. Only the management interface was stranded on the old subnet.
The Fix
Changed the ASUS LAN IP to a static address on the active management range. Set the gateway correctly and kept DHCP disabled because OPNsense handles that.
The printer was still stuck on the old subnet and needed a physical power cycle plus DHCP reconfiguration. That's a next-visit fix.
The Sirius-Station Overhaul
While I had SSH access, I addressed several other issues:
User Account Hardening
User user_primary was the only account with full sudo access including NOPASSWD. Root was locked. No other admin.
- Created user
commanderwith sudo access - Removed sudo from
user_primary(kept as standard user: adm, cdrom, dip, plugdev, lpadmin, sambashare) - Deleted
/etc/sudoers.d/user_primary(haduser_primary ALL=(ALL) NOPASSWD: ALL) - Kept privileged access explicit and key-based for administrative recovery
- Added SSH keys to the dedicated admin account
RustDesk Reinstall
RustDesk was installed but connection failing because of a config mismatch between machines.
- Uninstalled the old package, removed all configs
- Installed the current package via apt
- Configured for
remote.lab.internalserver
Printer Drivers Installed
Even though the printer isn't on the right subnet yet:
hll3290cdwpdrv:i386— Brother proprietaryprinter-driver-brlaser(6-3) — Open sourcebrscan4+brscan-skey— Scanner drivers
Pending Items
- Power cycle Brother printer → set to DHCP → get an address on the active LAN
- Reconfigure CUPS with new printer IP
- Find that mystery TP-Link physically and decide its fate
- Zorin 17 → 18 upgrade (official upgrade in early testing)
- Consider putting IoT/printer on separate VLAN
Lessons Learned
- Secondary IPs on a single interface are incredibly useful for reaching misconfigured devices
- Power surge + boot order can cause weird fallback behavior — always set static IPs on infrastructure devices
- mDNS announcements can be stale/misleading
- Single admin account with NOPASSWD sudo is a security risk — always have a separate admin user
- Sometimes the "simple printer problem" turns into network archaeology
The printer? Still pending a physical visit. But the network topology makes sense again, the ASUS has a proper management address, user accounts are hardened, and RustDesk works. I'll call it progress.