Back to blog
FILE 0xBB·WHEN A THINKPAD DISAPPEARS FROM THE LAN AFTER A NIC SWAP

When a ThinkPad disappears from the LAN after a NIC swap

May 12, 2026 · windows, networking, homelab

Swapped a USB-to-Ethernet adapter on a ThinkPad to fix a flaky link. After the swap, the laptop dropped off the network entirely. No reservation hit in the router. No ARP entry anywhere on the LAN. The cable LED was on, so it wasn't dead-dead, but nothing could see it.

What was happening

My deploy runner was trying to push an update to the box every two minutes and timing out. The router's DHCP log showed no requests from the new NIC's MAC. The old NIC's MAC was still in the lease table but obviously unresponsive.

$ arp -a | grep -i <expected MAC suffix>
# nothing

The Wi-Fi adapter was also disabled, because Windows had switched to Ethernet when the new NIC came up and turned off the wireless. So the laptop was on a wire that wasn't getting a lease, with no wireless fallback, and effectively isolated.

What I found

Three things happen when Windows sees a new network adapter come online while another adapter is active:

  1. If the new adapter is Ethernet and the existing one is Wi-Fi, Windows treats Ethernet as preferred and may disable Wi-Fi.
  2. The new adapter doesn't always come up with a DHCP-enabled profile; if the previous profile on a same-vendor adapter had a static IP, sometimes Windows binds the static config to the new MAC.
  3. Many of the cheap USB-to-Ethernet adapters present multiple ports of the same logical device, and "WAN" vs "LAN" labeling on the switch I plug into matters.

In my case it was the third one. The switch port I'd grabbed during the swap was actually a WAN uplink (a small UDM Pro setup with one of the front ports configured as WAN). The cable carried link, but DHCP requests went out the WAN side and got dropped.

The fix

Moved the cable two ports over to a LAN port. DHCP request went out, lease came back within about three seconds, and the deploy runner picked the laptop up on its next poll.

If it had actually been a Windows-side issue, the recovery sequence would have been:

# enable wireless as a fallback
netsh interface set interface "Wi-Fi" admin=enable

# release/renew on the new ethernet
ipconfig /release "Ethernet"
ipconfig /renew "Ethernet"

# verify
Get-NetIPAddress -InterfaceAlias "Ethernet"

But since the cable was in the wrong port, none of that would have helped.

What I'd do differently

When a device "drops off the LAN" after a hardware change, the right first check isn't on the device — it's on the switch. Does the upstream port show a link? Is the port assigned to the right VLAN? Is it a LAN port at all? You'd be surprised how often the answer to that last one is no. I now label the WAN ports on the UDM Pro with bright orange tape so I can't accidentally plug a workstation into one in a hurry.

The other small fix: keep Wi-Fi enabled as a backup on any box that I might lose physical access to. The cost is negligible. The benefit is "I can SSH in to recover" instead of "I have to walk over to the device."