Skip to main content
Back to Journal
user@argobox:~/journal/2026-01-28-nas-fstab-mounts-tailscale-debugging
$ cat entry.md

When Your Printer Goes Missing: Network Archaeology and a Sirius-Station Overhaul

○ NOT REVIEWED

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 commander with sudo access
  • Removed sudo from user_primary (kept as standard user: adm, cdrom, dip, plugdev, lpadmin, sambashare)
  • Deleted /etc/sudoers.d/user_primary (had user_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.internal server

Printer Drivers Installed

Even though the printer isn't on the right subnet yet:

  • hll3290cdwpdrv:i386 — Brother proprietary
  • printer-driver-brlaser (6-3) — Open source
  • brscan4 + 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.