Whatsminer – Ethernet Auto-Negotiation Failed

Read the link LED colour first. Green = `1000BASE-T`, amber/orange = `100BASE-TX` on virtually every Whatsminer M-series controller jack. A gigabit-capable miner showing amber is your diagnosis: the link came up at 100 Mbit instead of 1000, which is the auto-negotiation failure symptom. Note the colour, take a photo for documentation, move on to Tier 2.

Replace the Ethernet cable with a known-tested Cat6 patch cable that you have personally verified on a laptop in the last week. Don't reuse the cable from the box on a secondhand miner. Cable failures are silent — link LED stays on, frames corrupt, auto-neg drops to a lower speed. About 25% of `auto-neg fail` intakes on D-Central's bench resolve at cable swap alone.

Move the miner to a different switch port — pick the simplest port on your simplest switch, or borrow the router's LAN-side ports for the test. Goal: bypass every `smart` / `managed` / `PoE` / `VLAN-aware` switch in the current path so you can rule out switch-side configuration as the cause.

Power-cycle the miner cleanly for 60 seconds at the breaker — not via WhatsMinerTool, an actual power-off cycle. Wait the full 60 seconds so PSU rails drop and the controller's PHY state machine fully resets. On power-up the PHY renegotiates from a clean state. About 8% of transient auto-neg failures clear with a real cold boot.

Plug a second device — laptop, phone via USB-Ethernet, another miner — into the exact same cable and switch port. Watch its link LED colour and check whether it gets a DHCP lease in under 30 seconds. If the second device comes up green with DHCP, the LAN path is healthy and the Whatsminer is the problem. If the second device also comes up amber or fails DHCP, the LAN side is the problem.

Pull the switch port config. Cisco IOS: `show running-config interface gi0/X`. Aruba: `show interface X config`. Ubiquiti UniFi / MikroTik / TP-Link Smart: open the web UI port settings. Look specifically for `speed 100` / `speed 1000` / `duplex full` / `duplex half`. Any speed or duplex setting other than `auto` is suspect.

Set the switch port to `auto/auto`. Cisco: `interface gi0/X` → `speed auto` → `duplex auto` → `end` → `write memory`. Other switches: same logical change in the UI, then save the running config so it persists across reboot. Retest the miner — if it comes up green with DHCP, the forced port was the cause. Document the change so the next admin doesn't re-pin the port.

Pull port-error counters. Cisco: `show interface gi0/X counters errors`. Look at `late-collisions` (the duplex-mismatch smoking gun), `runts`, `CRC errors`, `align errors`. Any non-zero `late-collisions` after a clean reset confirms duplex mismatch. Clear counters (`clear counters interface gi0/X`), let traffic flow 5 minutes, recount. If they climb again, you still have a mismatch — re-check both ends.

Disable Energy-Efficient Ethernet (`EEE` / `802.3az`) on the switch port. Cisco: `interface gi0/X` → `no power efficient-ethernet`. Aruba: `eee disable` per-port. Ubiquiti / MikroTik / TP-Link: per-port toggle in UI. Save config, retest. `EEE` misnegotiation between Whatsminer PHYs and certain switch firmwares causes link instability that mimics auto-neg failure. Long-term: leave `EEE` disabled on every miner-facing port.

Replace the switch with a known-good unmanaged gigabit unit as a diagnostic step. A $25 TP-Link or NETGEAR 5-port gigabit unmanaged switch removes every smart-switch variable from the loop in 60 seconds. If the miner negotiates green on the unmanaged switch but amber on the managed switch, the managed switch firmware or config is the cause — work upstream of the miner.

Update the managed switch's firmware to the latest stable build if you've isolated it as the cause. NETGEAR ProSafe and several no-name managed switches shipped with broken auto-neg implementations across multiple firmware generations. Vendor release notes will frequently call out `auto-negotiation fixes` — read the changelog and update if there's a relevant fix.

Capture the controller UART boot log. Open the chassis. Find the four-pin UART header silkscreened `TX RX GND VCC`, 0.1" pitch, near the SoC. Connect a 3.3 V USB-to-UART adapter — ground first, crossover RX to controller TX and TX to controller RX, do NOT connect VCC. Open a serial terminal at `115200 8N1`. Power-cycle and capture the boot log. Look for kernel `eth0` link-state lines like `eth0: Link is Up - 100Mbps/Half - flow control off` — that line is the authoritative answer.

Run `ethtool eth0` from the BTMiner shell once you have UART or SSH access. The output shows current speed, duplex, auto-negotiation state, and the modes the PHY is advertising. Compare advertised modes against what the switch port advertises (most managed switches expose this in the port detail UI). Mismatched advertisements explain the failed negotiation directly.

Force the controller side to a fixed speed/duplex via UART or SSH: `ethtool -s eth0 speed 100 duplex full autoneg off`. Verify with a second `ethtool eth0`. Set the upstream switch port to the same `100/full` forced config (both ends forced is the only correct alternative to both ends auto). This is a workaround that gets the miner reachable while you fix the switch properly. Persist the forced config across reboots by adding the `ethtool` command to BTMiner network init scripts.

Disable `EEE` controller-side via `ethtool --set-eee eth0 eee off` if disabling on the switch alone didn't stabilise the link. Both ends of an `EEE` link participate; either side can fail the handshake. Verify with `ethtool --show-eee eth0`. Persist via the same network init script path used for the forced speed/duplex.

Reflow the controller's Ethernet PHY chip and magnetics if all software workarounds fail and the UART log shows persistent `link is not ready` or `phy not found` even with a known-good cable on a known-good port. Bottom preheat 150 °C, top-side hot air 300-320 °C for 30-45 seconds, cool naturally, retest. Hail-Mary on a controller otherwise headed for the bin — works ~30% of the time.

Stop DIY and book D-Central ASIC Repair when (a) UART log shows persistent `eth0: link is not ready` even with `auto/auto` and a known-good cable, (b) you've tried every switch-side fix and the controller still won't negotiate gigabit, (c) you've reflowed the PHY and the symptom returned within 30 days, or (d) you see visible damage on the controller — burnt component, lifted trace, or brown stain near the Ethernet jack. Ship in an anti-static bag, double-boxed with foam, with a note describing symptom history, firmware version, switch model, and your contact info. Turnaround 5-10 business days.