IceRiver Not Showing on Network / Detect IP Button Guide

Wait a full 90 seconds after miner boot before declaring discovery failed. IceRiver firmware brings up the Ethernet interface late in the boot sequence - after the kHeavyHash hashboards have initialized and the fans have throttled down from their startup full-tilt spin. If you ran `Detect IP` in the first 30 seconds you ran it before the network stack was ready. Boot, wait for the fans to settle into their normal cooling-curve cadence, then run discovery. This single rule clears a meaningful slice of stranded-IceRiver tickets before any other troubleshooting begins.

Read the router's DHCP client table directly. Log into your gateway's web admin (typically `192.168.1.1`, `192.168.0.1`, or `10.0.0.1`), find the page labelled DHCP Clients, Active Leases, Connected Devices, or Network Map. Match the MAC sticker on the back of the IceRiver chassis to a line in that table. If a lease exists you have an IP - ping it, then `http://<that-ip>` in a browser. The Detect IP tool was wrong, not the miner. Bookmark the IP, set a DHCP reservation, and never run Detect IP on this miner again.

Disable every active VPN client on the discovery PC. WireGuard, Tailscale, GlobalProtect, Pulse Secure, NordVPN, ExpressVPN, corporate VPNs - any of these route all your traffic through the tunnel by default and the LAN broadcast never reaches the miner. Disconnect every VPN, including any quietly-running Tailscale exit node. Re-run Detect IP. This is the single most-overlooked Tier 1 cause.

Disable Windows Defender Firewall on the Private profile temporarily. Settings -> Privacy & Security -> Windows Security -> Firewall & network protection -> Private network -> Off. Re-run `Detect IP`. If the miner now appears, the firewall was eating the inbound UDP discovery reply. Re-enable the firewall and add a permanent inbound exception for the IceRiver Detect IP utility's executable path - do NOT leave the firewall off as a long-term fix.

Plug the discovery PC into the same wired switch as the miner. Wi-Fi-to-LAN bridges are unreliable for LAN broadcast traffic on most consumer routers. Wired-to-wired on the same unmanaged or dumb switch eliminates the bridge variable in 30 seconds. If you are on UniFi or Aruba Wi-Fi, also check whether multicast filtering or AP isolation is enabled - both are common defaults that strip broadcast traffic from wireless clients.

Try `http://192.168.1.100` directly in a browser. IceRiver's documented behavior is to fall back to `192.168.1.100` static when DHCP fails. If your LAN is on `192.168.1.0/24`, just type that IP into a browser - done. If your LAN is on `192.168.0.0/24` or `10.0.0.0/24`, set your laptop NIC to a temporary `192.168.1.50/24` static (no gateway, no DNS), point-to-point cable to the miner via a small unmanaged switch, and try `192.168.1.100` from there. This factory-default fallback path saves a UART session more often than expected.

Run `arp -a` on the discovery PC after a discovery attempt. Windows command prompt or PowerShell: `arp -a` lists every MAC the host has seen recently. The IceRiver MAC will be there with its IP if the miner replied to the broadcast at all - even if the GUI tool failed to display it. Match the chassis sticker MAC to the `arp -a` output and you have the IP. Two-line CLI workaround for a broken GUI.

Set a DHCP reservation in the router for the IceRiver MAC. Once you have the MAC (from the chassis sticker), pre-create a DHCP reservation in the router web UI for a known IP - e.g. `192.168.1.50`. Reboot the miner. It pulls that exact IP every time and you stop relying on the discovery utility entirely. Standard practice on any farm above 5 miners.

Reduce DHCP lease time on the router from default 24 h+ to 4-8 h. If you operate a mining farm and the DHCP scope is choked with stale leases from rebooted miners, shorter lease times let the scope recycle faster and prevent scope-exhaustion. Mining-farm-scale advice: never run a default 24-hour lease on a `/24` with more than 100 miners. Verify-flag: target lease times are directional - tune to your reboot cadence.

Flush the router's ARP and DHCP tables, then power-cycle the miner. Most consumer routers expose a Restart or Renew Leases option in the LAN admin page; some require a full router reboot to clear stuck table entries. Force the router to re-learn the LAN, then power-cycle the miner. The miner re-DHCPs cleanly into a fresh table and either gets a lease or the failure mode becomes much clearer.

Disable IGMP snooping and multicast filtering on the managed switch for the mining VLAN. UniFi: Settings -> Networks -> [Mining VLAN] -> Advanced -> IGMP Snooping = off. MikroTik: `/interface bridge settings set use-ip-firewall=no` and confirm `igmp-snooping=no` on the relevant bridge. Cisco: `no ip igmp snooping` on the relevant VLAN. Re-run Detect IP. Some managed switches with IGMP snooping aggressively strip what they think is unrequested multicast traffic, including IceRiver's discovery reply.

Verify the discovery PC and miner are on the same VLAN. LAN broadcasts do not cross VLAN boundaries. Either temporarily move the discovery PC to the mining VLAN, or configure the router/firewall to permit the discovery broadcast across VLAN boundaries - typically a UDP-helper / IP-helper rule pointing at the mining-VLAN broadcast address. Even simpler: just read the router's DHCP client table from any VLAN and skip Detect IP entirely.

Force the managed-switch port to `100 Mbps full-duplex` for the IceRiver. IceRiver controllers ship with `10/100` Ethernet PHYs that do not negotiate gigabit. A managed switch port set to auto-negotiate, gigabit-preferred can fail to come up cleanly with these PHYs. Hard-set the port speed and re-test. UniFi: Devices -> Switch -> Port -> Link Speed = 100 Mbps Full Duplex. Same on Aruba / Cisco / MikroTik via vendor-specific port config.

UART-console into the miner and force a static IP. Open the chassis (kill power at the rear rocker first, wait 60 seconds for caps to bleed). Locate the UART debug header on the IceRiver controller - typically a 3- or 4-pin TTL serial header labelled `UART`, `DEBUG`, `J3`, or `J5` depending on revision. Connect a USB-to-TTL adapter (`GND` to `GND`, host `RX` to miner `TX`, host `TX` to miner `RX`, leave `VCC` unconnected - the miner is already powered). Open a serial terminal at `115200 8N1`. Wait for the boot console. Configure a static IP from the console as documented in the IceRiver service manual for your model. Verify-flag: pinout varies by controller revision - confirm pinout against a salvaged reference unit before powering up TX/RX.

Re-flash IceRiver firmware via SD card recovery if the network stack is genuinely broken (DHCP client never sends a request, link comes up but no traffic). Pull a fresh firmware image from https://www.iceriver.io/firmware-download/ matching your model exactly (KS0 / KS0 Pro / KS0 Ultra / KS1 / KS2 / KS3 / KS3L / KS3M / KS5 / KS5L / KS5M - wrong-model image bricks the controller). Write to a microSD with BalenaEtcher, insert into the controller's SD slot, power-cycle, watch for the recovery LED pattern (varies by model). After re-flash, the miner DHCPs cleanly and `Detect IP` finds it. DCENT_OS is NOT applicable here - IceRiver runs `1004LV100`-class kHeavyHash silicon, completely different from Bitmain hardware.

Stop DIY and book a D-Central repair slot when any of these are true: Ethernet link LEDs are completely dead with a known-good cable on a known-good switch port (physical-layer fault), UART console returns no characters at any baud rate (`9600`, `38400`, `115200`), a firmware re-flash attempt left the controller non-POSTing, visible burn / discoloration / cracked solder around the RJ-45 magnetics or the PHY chip, or two or more KS-series units in the same shipment exhibit identical DHCP-fails-no-fallback behavior. Book at https://d-central.tech/services/asic-repair/. Western English-language IceRiver authority - Canadian / US / international welcomed.

What D-Central does at the bench for IceRiver network failures. Network-stack diagnosis against a known-good KS-series reference rig, RJ-45 magnetics package replacement, controller re-flash with a verified-clean firmware image, full DHCP/static-IP regression test on the bench LAN, and 24-hour reachability burn-in (continuous ping, hashrate verification at `~6 TH/s` KS3M / `~12 TH/s` KS5L / `~15 TH/s` KS5M depending on SKU) before we ship the unit back. Verify-flag: hashrate values are directional - confirm exact SKU spec sheet before quoting customer ROI on a repair.

Ship the miner safely. Pack the IceRiver in its original foam if you have it, or double-box with at least 5 cm of foam on every side. Wrap the controller separately in anti-static if you are shipping a controller-only after a chassis-level diagnosis. Include a printed note with: model SKU, serial, observed symptoms (Detect IP empty / pings fail / link LED state / which Tier 1-3 steps you tried), firmware version if known, and LAN environment (consumer router / managed switch / VLAN config / DHCP scope size). The note saves us 30-60 minutes of bench diagnostic time, which directly saves you repair dollars.