When Your Printer Goes Missing: A Network Archaeology Expedition

Got a call from mom - her printer stopped working. Should be simple, right? Just SSH into her Zorin laptop (Sirius-Station at 10.42.0.174) and fix the CUPS drivers.

Famous last words.

The Setup (Or What I Thought It Was)

My home network runs OPNsense at 10.42.0.1, with an ASUS RT-AX56U acting as the WiFi access point for “House LANister.” Mom’s laptop connects via WiFi, and her Brother HL-L3290CDW 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.

Network Scan Reveals Nothing

Full nmap scan of 10.42.0.0/24 - no Brother printer (MAC 30:C9:AB:*). Not at its configured mDNS address, not anywhere. Avahi daemon running but finding nothing.

Then I noticed something weird: the ASUS was advertising itself via mDNS as 192.168.0.108. But my network is 10.42.0.0/24. What?

Down the Rabbit Hole

Scanning deeper, I found:

OPNsense at 10.42.0.1 ✓
MikroTik RouterOS at 10.42.0.3 (the managed switch)
Another ASUS device at 10.42.0.152 (no web GUI - probably AiMesh node)
No printer anywhere

Mom mentioned there was a power surge recently. Maybe the printer just needed to reconnect to WiFi? But wait - if the ASUS is advertising 192.168.0.108, maybe the printer connected there and I can’t see it?

The TP-Link Plot Twist

WiFi scan from Sirius-Station showed all my ASUS SSIDs (House LANister, “404 Network Unavailable”, “I Believe I Can Fi”), but also… TP-Link_1D90.

I don’t have a TP-Link router. Or do I?

Tracked it to MAC 14:EB:B6:13:XX:XX, getting strong signal from Sirius-Station’s location. Running its own network at 192.168.0.1. This was getting weird.

The Subnet Problem

Here’s where it got interesting. Sirius-Station was connected to “House LANister” and getting IP 10.42.0.174 from OPNsense just fine. But I couldn’t reach the ASUS management interface. It was stuck on 192.168.0.108 - a completely different subnet.

The ASUS label showed MAC D4:5D:64:C6:XX:XX. Sirius-Station’s WiFi showed connected to AP D4:5D:64:C6:XX:XX. Same router (routers use sequential MACs for different radios), but the management interface was unreachable.

The Clever Trick

I needed to reach 192.168.0.108 from Sirius-Station without breaking the SSH session or internet connectivity. Here’s what I did:

Added a secondary IP to Sirius-Station’s WiFi interface:

ip addr add 192.168.0.50/24 dev wlx5ce931608890

This gave the interface TWO IPs simultaneously:

10.42.0.174/24 - original (SSH still works)
192.168.0.50/24 - added (can now talk to 192.168.0.x)

Then created an SSH tunnel from my desktop through Sirius-Station to the ASUS:

ssh -L 8080:192.168.0.108:80 [email protected]

Opened http://localhost:8080 - boom, ASUS login page!

What Actually Happened

After logging into the ASUS (password wasn’t the default - good), I saw the client list:

TP-Link at 192.168.0.1 (wait, it’s connected TO my ASUS?)
Sirius-Station at 192.168.0.50 (my secondary IP, working!)
Some Liteon device at 192.168.0.101

The ASUS was set to DHCP. Best guess: after the power surge, it booted before OPNsense came back online. DHCP timeout → fell back to its default static IP of 192.168.0.108. OPNsense eventually came up, but the ASUS already had its fallback IP and stuck with it.

WiFi kept working because it was bridging clients to 10.42.0.x just fine. Only the management interface was stranded on 192.168.0.x.

The Fix

Changed the ASUS LAN IP from 192.168.0.108 to 10.42.0.2 (static, not DHCP). Set gateway to 10.42.0.1, disabled its DHCP server since OPNsense handles that.

Router rebooted, came back at 10.42.0.2. Perfect.

Cleaned up the secondary IP and tunnel:

ip addr del 192.168.0.50/24 dev wlx5ce931608890
pkill -f "8080:192.168.0.108"

The Mystery TP-Link

That TP-Link device (14:EB:B6:13:XX:XX) is still out there somewhere, running its own 192.168.0.x network. Probably an old range extender someone plugged in and forgot about. It’s on my list to hunt down physically.

Found it by setting up another tunnel to 192.168.0.1:8081, but the web GUI was stuck on “Opening…” (heavy JavaScript, old device). SSH worked but used ancient SSH-DSS encryption. Definitely old hardware.

Next Steps

Still need to:

Power cycle the Brother printer so it reconnects to “House LANister” and gets a proper 10.42.0.x IP
Install the correct Brother drivers on Sirius-Station (it’s using Generic PCL - wrong)
Clear the stuck print jobs in CUPS
Find that TP-Link physically and decide if it’s useful or just unplugging it

Also considering putting the IoT devices and printer on a separate VLAN for security (compromised smart plug shouldn’t be able to attack my servers), but that’s a project for another day.

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 - DHCP fallbacks are unpredictable
mDNS announcements can be stale/misleading
Sometimes the “simple printer problem” turns into network archaeology

The printer? Still not back yet when this session ended, but at least the network topology makes sense again. I’ll call it progress.