Avalon 1566 – Stratum Authentication Failed

Open the A1566 control panel in a browser at the miner's LAN IP. Navigate to the pool / mining configuration page. Locate the Worker / Username field for pool 0. Delete everything in it. Open your Bitcoin wallet (Sparrow, Electrum, Blue Wallet, or a hardware wallet — not a Lightning-first wallet like Wallet of Satoshi or Phoenix), generate a fresh mainnet receive address that starts with `bc1`, `3`, or `1`. Paste it into the Worker field as the complete value with no suffix. Set Password to `x`. Save. Reboot. Watch the controller log; `mining.authorize` should return `result: true` within 30 seconds.

If Step 1 didn't fix it, verify the Stratum URL field contains the bare hostname and port your firmware build expects. For Canaan A1566 stock firmware, `solo.ckpool.org:3333` works on most builds, with or without the `stratum+tcp://` prefix depending on revision. Remove duplicated prefixes, trailing slashes, `https://`, and stray whitespace. Save, reboot. Watch the log for a clean `mining.authorize` round-trip.

Switch to the cleanest control pool. Set Stratum URL to `solo.ckpool.org:3333`, Worker to your validated mainnet BTC address (no suffix), Password to `x`. Save, reboot. ckpool's address-auth is the simplest auth scheme in solo mining — if you can't authorize there, the problem is your address, not the pool. This single substitution resolves a large fraction of A1566 auth tickets in D-Central's queue.

Add a worker suffix only after basic auth works. Edit Worker to `<address>.A1566-01`. One literal dot. Lowercase alphanumerics and hyphens only — `[a-z0-9-]`. Maximum 16 characters in the suffix. No emojis, no spaces, no underscores in the suffix, no consecutive dots. Save, reboot. The pool dashboard will now show `A1566-01` as a separate worker tile under your address.

Factory reset the A1566's network and pool config from the control panel, then re-enter every field manually from a master plaintext file you keep on your workstation — not from a PDF, a screenshot, or a chat message. Verify the controller's date/time is correct after reset (some pool implementations reject auth from clients with clock skew greater than a few minutes).

SSH into the A1566 controller. Default credentials: Canaan publishes them per-batch — change them immediately after first verification. Tail `/var/log/cgminer.log` in real time: `tail -f /var/log/cgminer.log | grep -E "authorize|pool|stratum"`. Reboot the cgminer process (`/etc/init.d/cgminer restart` on the Canaan-stock controller image), and watch the literal stratum exchange. You see exactly what your A1566 is sending and exactly what the pool replies — no UI middleware in the way.

From a laptop on the same LAN, run the stratum handshake manually to confirm pool reachability and behaviour. `nc solo.ckpool.org 3333`, paste `{"id":1,"method":"mining.subscribe","params":["A1566-Test"]}` then a newline, then `{"id":2,"method":"mining.authorize","params":["YOUR_BTC_ADDRESS","x"]}` and a newline. Watch the response JSON. The error is usually human-readable at the raw protocol level, where Canaan's UI sometimes truncates it.

Validate your BTC address against `mempool.space` via API: `curl https://mempool.space/api/address/<YOUR_BTC_ADDRESS>`. A valid address returns a JSON object with `chain_stats` and `mempool_stats` keys. A malformed address returns a 404 with `Bad Request` in the body. No mining until this returns valid JSON. This is the cheapest sanity check available — 30 seconds prevents an overnight zero-share session.

Tcpdump the controller's WAN interface to capture the actual stratum exchange. From the controller (or a router that mirrors traffic): `tcpdump -i eth0 -A -s 0 'tcp port 3333'`. Reproduce the auth failure. The capture shows you every byte going out and coming back, including any TLS interception, ISP-level packet rewriting, or corporate-firewall stratum throttling — all of which have been documented in real Canadian and US residential ISP setups.

If the rig is on a residential IP, verify against a known-good IP. Tether the controller's WAN to a phone hotspot for 5 minutes. If auth succeeds via cellular but fails via residential, the residential IP is on a pool-side blocklist. Switch pools (regional D-Central pool for North American operators, alternate ckpool replica for Europeans) or contact the original pool's operator with the abuse history showing your IP isn't responsible.

Build a patched cgminer with verbose stratum logging and side-load it onto the A1566 controller. Clone the cgminer source tree, enable `--enable-debug`, modify `stratum.c` to log every byte of `mining.authorize` and the response at the DEBUG level, cross-compile for the A1566's controller architecture (typically ARM-based on Canaan stock controllers), `scp` the binary in, replace the stock cgminer, restart. You now see character-level fidelity on the auth exchange. This catches encoding issues (UTF-8 vs ASCII), whitespace, and parser bugs in your username that the stock UI hides.

Flash the previous-known-good Canaan firmware for your A1566 hardware revision from `avalonminer.org/firmware-document/`. Verify hardware revision on the control board sticker before flashing — A1566 firmware is signed and a wrong-revision flash is a bench event. If Canaan's signed bootloader refuses the downgrade (the default observed pattern on every A1566 batch as of 2026-Q2), document the build version, flag the unit for bench recovery, and proceed to Step 17. Do not attempt unsigned firmware flashes — bricking via signature mismatch is a ship-to-D-Central event.

Patch the controller's pool config in `/etc/config/cgminer.conf` directly via SSH. The control panel UI sometimes silently corrupts pool entries when rapid edits are saved out of order; editing the JSON directly bypasses the UI's validation layer. Make a backup first (`cp /etc/config/cgminer.conf /etc/config/cgminer.conf.bak`), edit the `pools` array, validate JSON syntax with `python3 -m json.tool < /etc/config/cgminer.conf`, restart cgminer.

Run Wireshark or `tshark` on a router that's mirror-port-spanning the A1566's traffic. Capture 5 minutes across multiple reconnect attempts. Decode the TCP stream as JSON. This is the nuclear diagnostic — you see everything, including TLS interception by your router, corporate firewall rewriting, ISP-level stratum throttling, NAT helper interference, and any DNS hijacking re-routing your stratum connection.

Verify DNS resolution. SSH into the controller, run `nslookup solo.ckpool.org`. Stock Canaan firmware defaults to DNS `114.114.114.114` (Chinese public DNS, resolves unreliably outside China). Change to `1.1.1.1` or `8.8.8.8` via the control panel. Reboot. If the pool DNS now resolves to the correct IP and auth succeeds, DNS was the cause and your rig was likely connecting to the wrong host entirely (or timing out before connecting at all).

Stop DIY when any of these are true: address validates on mempool.space, worker simplified to bare address, alternate pool (`solo.ckpool.org`) also rejects, fresh wallet address also rejects, Wireshark shows well-formed `mining.authorize` going out — and every pool still refuses. That's not config; it's network-layer interference, IP blocklist, or controller-side state corruption. Or: A1566 stopped authorizing after a Canaan firmware flash and the signed bootloader refuses rollback. Or: `cgminer.conf` edits via SSH don't persist across reboot. Book a D-Central ASIC Repair slot.

What D-Central does on the bench. Boot the A1566 on isolated network on the bench. SSH into the controller, capture the stratum exchange against our internal test pool that logs every parser-level reject reason. Diff the rejected username against a regex that catches every documented A1566 auth failure mode (Lightning addresses, encoded spaces, smart quotes, registered-username pattern on address-pool, regressed-firmware truncation). Patch the controller config or, if the firmware is the regressed build and rollback is signed-blocked, side-load a known-good cgminer binary from D-Central's A1566 firmware library — keeping the Canaan stock OS otherwise intact. Burn-in test against a real solo pool for 24 hours to confirm the fix sticks.

Ship safely. The A1566 controller failure is rarely a chassis problem — for `A1566_AUTH_FAIL` cases that escalate to bench, you can usually ship just the control board in a small anti-static padded mailer, leaving the hashboards racked and powered down at home. Include a note: observed `mining.authorize` rejection signature, firmware version string, the literal username and pool URL you configured, and any controller log captures. Saves us diagnostic time, which saves you money. Canadian turnaround on A1566 controller-only repairs: 3-7 business days. US and international accepted.