Tech Log-Migrating a Printer from USB to Network (Ethernet)

Tech Log-Migrating a Printer from USB to Network (Ethernet)

(or, How a Canon imageCLASS MF269dw Got Onto the Managed Switch — and Why It Fought Back the Whole Way)


Background and Context

After relocating equipment and introducing a managed switch (TP-Link TL-SG108E, 8-port gigabit "Easy Smart" switch) into my LAN segment, the printer needed to move off its old USB-B → USB-A connection to the desktop and onto the network instead. Goal: the Canon imageCLASS MF269dw reachable over Ethernet by any machine on the segment, not tethered to one host PC.

The topology at the time was unusual and turned out to matter a great deal. My segment is not directly cabled to the house's main router (a Hitron CODA-4582). Instead, the desktop pulls internet over Wi-Fi from a Netgear Orbi mesh (RBR750 router + RBS750P satellite), and I intended the managed switch to distribute connectivity to the printer, two laptops, and a UPS. Critically, at the start of troubleshooting the switch had no uplink to the rest of the network — it was an isolated island.

  • LLM used: Claude Opus 4.8

  • Printer: Canon imageCLASS MF269dw (10/100 Fast Ethernet NIC, MAC 74-BF-C0-8C-C2-9A)

  • Switch: TP-Link TL-SG108E v6.0 (802.1Q VLAN, port mirroring, cable diagnostics, IGMP snooping, LAG)

  • Static IP assigned to printer: 192.168.1.200

CompTIA Network+ (N10-009) relevance: This entire exercise is a walk through Domain 5.0 (Network Troubleshooting) methodology — establish a theory, test it, escalate, verify — plus Domain 1.0 (OSI model, addressing) and Domain 2.0 (switching, duplex, VLANs). Nearly every layer of the stack showed up as a distinct sub-problem, which made it quite the case study and worthy of documenting.


The Problem and Proposed Solution

Problem: Before the network "modernization" upgrade (or migration) from USB to network, the printer sent successful print jobs.  However, after the network migration, print jobs would not print once the printer was on Ethernet-on-the-switch (managed switch). Setting the printer to Wired LAN and reinstalling the driver did nothing.

Initial (wrong) theory: the printer wasn't linking. The proposed approach was a bottom-up OSI walk — confirm physical link, get the printer's IP, ping it, then fix Windows — on the assumption the fault was somewhere obvious in that chain. That framing was right; the specific culprit turned out to be several layers deep and had multiple independent faults stacked on top of each other.


Steps to Resolve (roughly in order)

  1. Physical layer check. Switch port showed an amber LED. Learned (and this bit me twice) that on the TL-SG108E amber = 10/100 Mbps link, green = gigabit. Since the MF269dw is a 10/100 NIC, amber was correct, not a fault. The printer's RJ-45 jack has no link LED at all — its absence was meaningless.

  2. Get the printer's IP. The printer's own menu structure buries this under Network Settings → TCP/IP Settings → IPv4 Settings → IP Address Settings → Check Settings. It reported 169.254.247.229 — an APIPA address (Automatic Private IP Addressing).

  3. Recognize APIPA. A 169.254.x.x address means the device tried DHCP, got no response, and self-assigned. Since the desktop on the same switch got a normal lease, the printer specifically wasn't getting a DHCP OFFER back.

  4. Diagnose the isolated switch. ipconfig /all on the desktop revealed the real root of this stage: the desktop's wired Ethernet adapter was manually set to a static 192.168.2.1 with no default gateway and no DHCP server, and its actual internet came over Wi-Fi. The switch segment had no path to any DHCP server. Everything on it was stranded.

  5. Provide an uplink. Cabled the Orbi RBS750P satellite's LAN port into the switch (port 1). Confirmed via Netgear's own docs that satellite LAN ports are meant exactly for this. arp -a then showed the desktop resolving the Orbi router's MAC through the wired adapter — proof the bridge worked at Layer 2.

  6. Force DHCP on the desktop. ipconfig /release "Ethernet" then ipconfig /renew "Ethernet" pulled a real lease: 192.168.1.23, gateway 192.168.1.1, DHCP server 192.168.1.1. The desktop's wired half was now correct.

  7. Static-IP the printer. The printer still refused DHCP even with the network live, so I assigned it a static address manually: 192.168.1.200 / 255.255.255.0 / gateway 192.168.1.1. arp -a confirmed the printer answered ARP at that address — Layers 2 and 3 were now correct.

  8. Fix the duplex mismatch. Despite ARP working, ping and Test-NetConnection ... -Port 9100 failed. The TL-SG108E port statistics told the story: TxBadPkt 0, but RxBadPkt climbing to ~75% of received frames — the classic asymmetric error signature of a duplex mismatch. The printer had been forced to 100/Full while the switch port auto-negotiated to 100/Half. Set the printer's Ethernet Driver Settings back to Auto Detect: On, which let both ends negotiate to 100M Full.

  9. Swap the cable. The port's cable-diagnostic test bounced wildly (fault distance reading 3–49 m on repeated tests) and errors persisted. Replaced the Cat6 patch cable and moved the printer to a clean port (port 3). Cable test then read a stable ~4 m, link came up 100M Full, and RxBadPkt dropped to a trickle. Test-NetConnection 192.168.1.200 -Port 9100 finally returned TcpTestSucceeded : True.

  10. Rebuild the Windows printer object. Even with the network path confirmed good, jobs sat at "unknown status" and the printer showed Offline with device error code 45 ("not connected"). The fix was to delete every stale Canon printer object, clear the spooler, and create a fresh TCP/IP printer.  (An online check showed the driver was already updated.)


New Problems and Complications

  • APIPA masked the real cause. The identical 169.254.247.229 on every power cycle looked like a stuck static IP but was normal APIPA behavior (the address is seeded from the unchanging MAC). The actual fault was upstream: no DHCP reachability, then a duplex mismatch preventing the handshake.

  • The switch itself showed gateway 0.0.0.0. A red herring — the switch's management interface failing to lease an address does not stop it forwarding Layer 2 traffic. Set aside deliberately.

  • The Orbi satellite has no separate admin login. Orbi satellites are managed entirely through the main router (orbilogin.com / 192.168.1.1) or the Orbi phone app. The credentials on the satellite's sticker are backhaul/sync info, not a web login — which is why they never worked. Never needed it in the end.

  • The laptops "failed" too — but for a different reason. Both Linux Mint laptops couldn't reach the internet over wired Ethernet. ip addr show revealed noprefixroute static addresses in the dead 192.168.2.x range — leftover config from when the switch was an isolated island. ProtonVPN's kill-switch interface (pvpnksintrf1) further hijacked the default route, masking the real state. Not a network fault at all; stale host config.

  • Duplex mismatch was the single most time-consuming fault. Because ARP (tiny, aggressively retried single frames) squeaks through a half-duplex-collision link while TCP and ICMP do not, the printer looked reachable (arp -a succeeded) while every actual connection failed. This is a genuinely deceptive failure mode.

  • The Windows printer object was welded to a dead USB stack. Re-pointing the old object's port to the network address did not work because its underlying plumbing still tried to deliver to a USB device that no longer existed (error code 45). Repeated driver reinstalls had also spawned "copy 2/3/4" ghosts and an "Unknown USB Device (Port Reset Failed)" entry.


Final Resolution and Underlying Cause(s)

There was no single cause; this was a stack of independent faults stemming from or predating the migration from unmanaged switch and USB connections to a managed switch with ethernet connections.  Each cause was hidden behind the one above it:

  1. No DHCP reachability — the switch segment was an isolated island with no uplink. (Fixed: cabled the Orbi satellite LAN port into the switch.)

  2. Duplex mismatch — printer forced 100/Full vs. switch port at 100/Half, causing massive receive errors that let ARP through but blocked TCP/ICMP. (Fixed: set printer NIC back to Auto Detect; both ends negotiated 100M Full.)

  3. Marginal cable / port — unstable cable diagnostics on the original run. (Fixed: new Cat6 cable, clean port.)

  4. Corrupt Windows printer object — the print target was a network-ported object still bound to a dead USB device stack (error code 45), so jobs never left the spooler. This was the true final cause of "won't print" once the network was genuinely good. (Fixed: deleted all stale Canon objects, cleared the spooler, created a fresh TCP/IP printer bound to a RAW/9100 port at 192.168.1.200.)

The fresh printer object — added via Add manually → TCP/IP Device → 192.168.1.200 → RAW port 9100 — printed a test page on the first try.


Lessons Learned

  • Amber ≠ error. On a switch, link-LED color usually indicates speed (amber = 10/100, green = gigabit), not a fault. Know your specific switch's convention before treating a color as a problem.

  • 169.254.x.x = APIPA = "DHCP failed." It always means the device couldn't reach a DHCP server. The same address on every reboot is normal (seeded from MAC), not evidence of a stuck static.

  • ARP success does not mean the link is healthy. ARP is tiny and aggressively retried, so it survives a half-duplex-collision link that kills every TCP connection. If arp -a resolves a device but ping/Test-NetConnection fail, suspect a duplex mismatch and check the switch's per-port RxBadPkt/TxBadPkt counters.

  • Asymmetric packet errors (TxBadPkt 0, RxBadPkt high) are the fingerprint of a duplex mismatch. Both ends must agree — the safest fix is auto-negotiation on both sides, not forcing one.

  • Test-NetConnection <ip> -Port 9100 is the reachability test that actually matters for a network printer — not ping. Printers frequently drop ICMP by default (and via inbound IP filters), so ping failing is not diagnostic; a successful TCP handshake on 9100 is.

  • When converting a printer from USB to network, build a NEW printer object. Re-pointing an existing USB-born object's port often leaves it welded to a dead USB device stack (Windows error code 45 = "not connected"), so jobs silently never send. Delete the old objects entirely and add fresh as a TCP/IP device.

  • Don't let stale device objects accumulate in Windows. Repeated driver reinstalls spawn "copy 2/3/4" duplicates that fight over jobs. Remove old copies before/after installing a new one.

  • Static IPs above the DHCP pool are correct for printers. A fixed address means the Windows port never breaks the way it would when a DHCP lease changes.

  • noprefixroute static addresses are a trap after a topology change. Devices configured for an old isolated subnet won't request DHCP on the new network — they just assert the dead address. Switch the interface to DHCP (nmcli connection modify ... ipv4.method auto).

  • Kill the VPN before diagnosing LAN routing. ProtonVPN's kill-switch interface hijacks the default route and masks the real state of wired connectivity.


Things to Watch Out For (Future)

  • Keep the printer's USB cable unplugged. The entire clean setup depends on the printer being network-only. Plugging in USB re-triggers Windows' USB-printer detection and can rebuild the exact "copy N" / error-code-45 mess. Cable is accordingly labeled and stays in a drawer.

  • The printer's static IP lives on the printer itself. A factory-reset of the printer wipes 192.168.1.200 and it'll fall back to APIPA again. Re-enter the static config after any network-settings initialization.

  • Confirm 192.168.1.200 sits above the Orbi's DHCP pool if/when admin access to the Orbi is obtained, so nothing else is ever leased that address. Conflict is unlikely at .200 but worth locking in.

  • Duplex/cable faults are silent until you look at port counters. If printing (or any device on the switch) gets flaky, check the TL-SG108E's Monitoring → Port Statistics for climbing bad-packet counts and run the built-in cable diagnostic before assuming a config problem.

  • Windows "Let Windows manage my default printer" was turned off so the network printer stays the default; leave it off.


Next Steps / To-Do

  • Add the printer to the two Linux Mint laptops via CUPS (Menu → Printers → Add → AppSocket/HP JetDirect → host 192.168.1.200, port 9100). Verify with nc -zv 192.168.1.200 9100 first. May need Canon's official UFR II Linux driver if the built-in/driverless options don't cover the MF260 series. (Starting with laptop #2.)

  • Fix laptop #1’s wired connection — still stuck on a 192.168.2.2 static; switch the wired profile to DHCP and quit ProtonVPN while testing.

  • Chase the recurring "Unknown USB Device (Port Reset Failed)" on the desktop — unrelated to the printer (a different faulty USB peripheral); find it by unplugging USB devices one at a time.

  • Resolve the original stuck .crdownload files and the OneDrive "5 files in use" sync hang from before this work began.

  • Turn off Windows printer sharing if not already off; every device reaches 192.168.1.200 directly, so host-based sharing is unnecessary and ties availability to the desktop being on. (Currently done.)

Comments

Post a Comment

Popular posts from this blog

Tech Log-Linux Learning Progress Synopsis

  Linux Learning Progress Synopsis Personal Study: Linux Mint → Linux Tails → Linux Kali  Date: May and June, 2026 Background & Starting Point Actively learning Linux Mint for several months, achieving basic comfort with terminal navigation, filesystem structure, and standard Linux commands (ls, cd, mkdir, rm, cat, grep, man, etc.). The goal is a structured progression: Linux Mint for general familiarity → Linux Tails for privacy/anonymity concepts → Linux Kali for cybersecurity offense/defense studies. Linux Tails — Concepts Covered What Tails Is. Tails (The Amnesic Incognito Live System) is a Debian-based, privacy-focused Linux distribution that boots entirely from a USB stick, routes all traffic through the Tor anonymity network, and leaves zero trace on the host machine at shutdown. It is now maintained under the Tor Project umbrella. Current version: 7.8. Key Concepts Learned: Amnesia vs. Persistence: The core Tails principle. Everything outside the Persistent fold...
Read more

Tech Log-Browser Image Agent project

Tech Log Entry — Browser Image Agent:  An AI-Powered Image Tagger and Saver Category: AI / Computer Vision / Browser Automation / Local LLM / Python Initial Goal I wanted a tool to automatically save images from open browser tabs to a local folder, with descriptive, search-friendly filenames and tags generated by an AI vision model — replacing manual save-and-rename workflows. All processing to be fully local: no cloud APIs, no subscriptions, no data leaving the machine. The tool should use only free open-source software, run on my Windows 11 desktop, and leverage my RTX 3060 GPU for local AI inference. Two operating modes: fully automatic (save all qualifying images without interruption) and human-in-the-loop review (confirm each image before saving). Hardware Used Desktop: Windows 11 Home, NVIDIA GeForce RTX 3060 (12 GB VRAM) No additional hardware required — everything runs locally on the desktop Software Stack Python 3.12 Ollama 0.17.7 (local AI runtime) Vision mode...
Read more

Telling Rocks What To Think

Image
Telling Rocks What To Think First post on this new blog format.  I'm establishing this medium for "recoding" and recording my professional tech studies, experiences, impressions, plans, problems, and solutions. Erin Spiceland said "Coding is the art of telling rocks what to think."  It's metaphorical, but not by much.  Digital computing mostly relies on silicon working its logic and magic.  You talk to it in painfully specific code.  You need all the material, semantic, and verbal components just right.  If you get it right, then it talks back.  Get it wrong, and you have just found a "bug". I named my blog "Debug and Rebug" to indicate two key principles of my approach to coding.  First, "debug": When you write your code, it will never work perfectly, as you envision it.  Perfect running never happens; it's an inevitable consequence of entropy, human lateral thinking, and logic's inexorable conflict with our wants.  Tho...
Read more