Avalon – AUC Controller Network Loss

Power-cycle the miner at the PSU switch (not the router — you will mask the real fault). Wait 60 seconds for the controller SBC to fully shut down and the network equipment to forget stale ARP entries. Power up and wait 3 full minutes for the controller to finish booting before you declare success or failure. This clears ~30% of NET_ERR tickets D-Central sees: transient DHCP-lease hangs, stuck cgminer processes, and SBC kernel hiccups. If the miner reappears on the network, set a 24-hour watch and move to prevention. If it does not, proceed to Step 2.

Visually inspect the RJ45 at both the miner side and the switch / router side. Check for a broken retention tab, a bent pin, a cable kinked through a rack bracket, or a plug seated loose. Look at the link LED on the AUC3 / chassis port and at the matching switch port. Solid or blinking green on both sides = physical link is up. Dark LED on either side = physical layer fault. Re-seat both plugs firmly. If the LEDs come to life, watch for 10 minutes to confirm the link is stable under vibration from PSU fans.

Swap the patch cable end-to-end with a known-good `CAT5e` or `CAT6` cable — one that has not been coiled tight, stapled, or run across a PSU fan inlet. Don't trust a cable tester at the crimps only — use a full end-to-end continuity tester (Klein VDV526-100 or Fluke equivalent). In home mining environments, jacket degradation from heat and vibration is a leading cause of intermittent `NET_ERR`. If the new cable restores connectivity, schedule the rest of the rack's cables for inspection — they age as a cohort.

Check the router's DHCP lease table for the miner's MAC address (`7C:BF:B1:xx:xx:xx` on most Canaan Avalons; older units may be `C8:3A:35:xx:xx:xx`). If the miner has a lease, note the IP and move to Step 6. If the miner is missing from the lease table, either DHCP is exhausted or the miner's Ethernet PHY never negotiated. On 721 / 841 / 1047 Avalons, hold `FUNC` for 3 seconds to print the current IP to the OLED — this confirms what the miner thinks its IP is versus what the router handed it.

Move the miner's cable to a different port on the same switch. If that fails, bypass the switch entirely and plug the miner directly into the router (or into a second switch / laptop-to-router direct). Unmanaged 5-port switches fail silently under 24/7 load — a port that has worked for 2 years can stop negotiating auto-MDIX overnight. If the miner comes back on a different port, the original port or switch is dying; replace it before other miners drop off the same unit. Label the bad port before you forget.

From a wired laptop on the same subnet, run `ping <miner-ip>`. Ping succeeds but the browser times out = the web service is down but the SBC is alive (Step 7). Ping fails but the router shows a lease = the SBC is wedged (Step 9). Ping fails and no lease = DHCP layer (Step 8). This branch is the single most important diagnostic in the whole flow — skipping it sends you down dead ends. Expect a healthy reply of `<1 ms` on LAN, under `5 ms` over a switch hop.

`ssh root@<miner-ip>` into the controller. Default credentials on most stock Avalons are `root` / `root` (change them after recovery if you haven't already). Run `cgminer-api -o stats`, `uptime`, and `dmesg | tail -50` to see what the controller has been doing. Restart the web service (`/etc/init.d/uhttpd restart` on OpenWrt-based controllers) or reboot cleanly (`reboot`). This is faster than a cold power-cycle and gives you a root-cause fingerprint for the log. Note the firmware version reported — you will need it in Step 10.

Reboot the router and wait 2 full minutes. Confirm the router's DHCP pool size is large enough — on a consumer router, the default `192.168.1.100–192.168.1.199` pool of 100 addresses is not enough once you have a dozen miners plus IoT plus laptops plus phones plus a VPN client. Expand the pool or, better, assign a static DHCP reservation to every miner keyed on MAC. Reservations survive router reboots and eliminate pool-exhaustion hangs permanently. This is the single fix that prevents 80% of `NET_ERR` reoccurrence in a farm of 10+ devices.

If the SBC is wedged (lease present, ping dead, ssh dead), power-cycle at the PSU and watch the boot sequence on the OLED / LEDs. If the miner boots clean and stays up 24 hours, log the event and watch for recurrence. If it drops off the network again within a week, the SBC is failing or the firmware has a regression. Do not leave a wedged controller in this state — the hashboards *will* keep mining on the last pool config via the AUC, which is great until the pool fails over, at which point you cannot point the miner at a backup.

Flash current stable Avalon firmware from `avalonminer.org/firmware-document/` for your exact model. Back up your config first — cgminer.conf, pool credentials, any custom stratum settings. On AUC3-connected Avalons, the flash is via USB stick on the AUC3. On SBC-based Avalons, use the web UI's flash page. Do not flash a development or community build blind; those have bricked units. If current stable firmware resolves the drop-off, you were on a bad build — don't roll back. If it still drops, proceed to Tier 4.

Check for VPN / DNS interference. If you run a Pi-hole, a custom DNS server, or a LAN-wide VPN client, temporarily disable it or whitelist your pool's stratum domain and `avalonminer.org`. Pi-hole blocklists have been known to silently include telemetry and stratum domains, taking miners off pool without any obvious error. Verify pool URL resolves from the miner (`ssh` + `nslookup <pool>` or `ping <pool>`). This is the single most-overlooked failure mode in home-miner setups — a $0 fix that nobody documents.

If the Ethernet link LED never lights on any cable + any switch port combination, the SBC's Ethernet PHY is dead or the magnetics on the RJ45 jack have failed. This is a board-level repair. You can source a replacement controller board from D-Central or from Canaan's support portal; swapping it is Phillips-screwdriver work once the miner is open and unplugged. If you don't have experience working inside a powered-off miner with the lid removed, skip to Tier 4 and ship it. Never open a powered miner — the PSU primary side sits at 400 V DC.

If the AUC3 itself shows no LED activity at all (no power LED, no data LED) even with a known-good USB cable from the controller SBC, the AUC3 has failed. D-Central stocks AUC3 replacements. Swap it out — unplug the old unit from USB and I²C, plug the new one in the same orientation, boot, and the miner will re-enumerate the hashboards automatically. No firmware changes required. This is ~15 minutes of work if the replacement is on hand.

When to stop DIY: if Tier 1–3 have not recovered the miner, if the SBC's Ethernet PHY is confirmed dead, if the AUC3 has failed, or if you are not comfortable with low-voltage board-level work near a live PSU primary side, ship the unit (or just the controller board + AUC3) to D-Central. Our bench has schematics, JTAG access to the AUC3, spare SBCs, and Ethernet PHY reflow capability. Typical turnaround 5-10 business days. Full burn-in on every unit before it ships back.

Post-repair prevention: set static DHCP reservations for every miner, upgrade to a managed switch with per-port statistics if you have more than 4 miners, segment miners onto their own VLAN if you have more than 6, label every chassis with its MAC address, stock 2-3 spare `CAT5e` or `CAT6` patch cables, and flash current stable Avalon firmware at least once per year. These six steps cut `NET_ERR` reoccurrence to near zero in D-Central's own lab and in customer farms we have audited.