Bitaxe – NTP Sync Failure / Clock Drift Breaking Stratum

Confirm the clock is actually wrong before fixing anything else. Open the AxeOS dashboard at `http://<bitaxe-ip>/`. Locate the system-time display in the System or Status section. Compare to your wall clock. Also check the OLED on the front of the Bitaxe. If the time matches reality within 5 seconds, NTP is working and you are chasing the wrong problem; back out to a different troubleshooting page. If the time reads `1970-01-01`, `00:00:00`, or some clearly wrong year/date, you have confirmed an NTP failure and can proceed.

Cold power-cycle the Bitaxe for 30 full seconds and watch what happens on first boot. Pull the barrel jack or XT30. Wait 30 full seconds — capacitors drain and the SNTP client state in SRAM clears completely. Reconnect power. Within 60 seconds of WiFi joining, the dashboard time should update from `1970-01-01` to the current time. If it does, the previous SNTP attempt was wedged after a transient network hiccup — common after router reboots — and a clean restart fixed it.

Change the AxeOS NTP server from `pool.ntp.org` to `time.cloudflare.com`. In AxeOS, navigate to System or Network settings. Locate the NTP server field. Replace with `time.cloudflare.com`. Save. Cold-cycle the Bitaxe again for 30 seconds. Watch the dashboard. Cloudflare's NTP service is geographically anycast, returns clean responses, and is rarely blocked on filter lists. If `pool.ntp.org` was failing because the round-robin landed on a misbehaving community NTP server, Cloudflare bypasses that.

Try a different NTP hostname if Cloudflare does not work either. AxeOS accepts any hostname or IPv4 in the NTP field. Try in this order: `time.google.com`, `time.nist.gov`, `time.windows.com`. Each is run by a different operator with different network paths and filter exposure. If any of them syncs, you have narrowed the problem to the specific hostname previously configured — either DNS for it is broken or a filter is blocking it.

Verify the time syncs after each change. After saving the NTP server in AxeOS and cold-cycling, wait a full 90 seconds before judging success or failure. Some networks are slow on first NTP packet; the SNTP client retries with backoff, and a quick read of the dashboard at 30 seconds may show `1970-01-01` even when sync is about to happen at 60 seconds. Refresh at 30, 60, and 90 seconds — if it does not sync within 90 seconds, the change did not help and you need Tier 2.

Test outbound UDP `123` from a desktop on the same LAN. Linux/macOS terminal: `nc -u -v pool.ntp.org 123` then any character + Enter. If `nc` returns `Connection refused` or hangs forever, UDP `123` is blocked. Windows: `Test-NetConnection -ComputerName pool.ntp.org -Port 123 -InformationLevel Detailed` (limited UDP support; use Wireshark for definitive). Linux/macOS alternative: `sudo ntpdate -q pool.ntp.org`. If the desktop cannot reach NTP either, the network is the problem, not the Bitaxe.

Configure your router as a local NTP relay/server. UniFi: Settings → Services → NTP. ASUS: Administration → System → Time Settings. OpenWrt: install `chrony` or `ntpd`. pfSense / OPNsense: Services → NTP. Set upstream to `time.cloudflare.com` or `pool.ntp.org`. Make sure UDP `123` egress is allowed for the router itself (egress for the router can be different from egress for clients). In AxeOS, change the NTP server field to your router's LAN IP (typically `192.168.1.1`). Save, cold-cycle the Bitaxe.

Set DHCP option `42` (NTP servers) to push your router's NTP server to all LAN clients automatically. Most routers expose this in advanced DHCP settings. Set it to your router's LAN IP. The Bitaxe does not consume DHCP option 42 directly today, but setting it standardizes the network's time discipline and means the router's NTP relay sees consistent traffic patterns from every other LAN device.

Check your router's firewall logs for blocked NTP traffic. UniFi: Settings → Internet Security → Logs. pfSense / OPNsense: System Logs → Firewall. Look for `block` entries on UDP destination port `123` or sourced from your Bitaxe's IP. If you see blocks, you have found the rule responsible — usually a default-deny outbound rule that does not have an explicit allow for NTP. Add a rule allowing UDP `123` outbound for the Bitaxe's IP or LAN VLAN.

Verify WiFi signal strength and stability at the Bitaxe location. Flaky WiFi can cause NTP packets to drop in transit even when the firewall allows them. Check RSSI on the AxeOS dashboard — anything weaker than `-65 dBm` causes packet loss that hits NTP harder than TCP because there is no retransmit at the application layer for SNTP. Move the Bitaxe closer to the AP, drop a 2.4 GHz repeater, or run Ethernet via a USB-Ethernet dongle (where supported). The ESP32-S3 is 2.4 GHz only — force a dedicated 2.4 GHz SSID if your AP is band-steering.

Capture a serial boot log at `115200 baud` and trace the SNTP sequence. USB-C **data** cable (charge-only cables will not enumerate). PuTTY (Windows), `screen /dev/ttyACM0 115200` (Linux/macOS), or Arduino Serial Monitor. Reboot the Bitaxe. Save 90 seconds. Look for: `wifi: connected, IP:`, `sntp: server: <hostname>`, `sntp: time synchronized` (success), or `sntp: failed to receive response` / `sntp: timeout` (failure). Cross-reference Espressif's ESP-IDF system-time docs for the exact message sequence.

Run a packet capture on your router to verify NTP traffic is leaving the network. Wireshark on a desktop with port mirror, or `tcpdump -i any -n udp port 123` on the router (if it runs OpenWrt, pfSense, OPNsense, or any Linux-based firmware). Reboot the Bitaxe. You should see outbound packets from the Bitaxe's IP to the NTP server's IP within 5 seconds of WiFi-up. If they leave but no response comes back, upstream is blocking responses. If they do not leave at all, the Bitaxe is not sending — DNS or SNTP-client issue.

Reflash the latest stable AxeOS via the USB-C web-flasher with Erase Flash. Some older builds had SNTP-client regressions where the initial query timed out and never retried. Reflash via `https://bitaxeorg.github.io/bitaxe-web-flasher/` in Chrome or Edge. Choose 'Erase Flash' before reflashing to wipe NVS and any wedged SNTP state. Select the correct `.bin` for your variant: `BM1366` = Ultra, `BM1368` = Supra, `BM1370` = Gamma and GT, `BM1397` = Max. Hex / UltraHex use the `ESP-Miner-multichip` fork. Wrong `.bin` bricks the board.

Run a dedicated NTP server on a Raspberry Pi or NAS as a LAN-side time source. A Raspberry Pi running `chrony` synced against four upstream NTP servers (Cloudflare, Google, NIST, Quad9) and serving the LAN as the canonical time source. Cost ~$20 in hardware + 30 minutes of setup. Configure `chrony.conf` with upstream pool, `allow 192.168.1.0/24` for LAN clients. Point every Bitaxe at the Pi's LAN IP. Eliminates per-client UDP `123` egress issues forever.

Audit any DNS-blocking layer for NTP-hostname blocks. Pi-hole admin → Query Log; AdGuard Home → Filtering → Logs; NextDNS → Logs. Search for `pool.ntp.org`, `time.cloudflare.com`, and whatever NTP server you have configured. If they show as blocked (red), check which list flagged them — some over-eager privacy blocklists treat NTP traffic as 'tracking' and block hostnames. Allow-list explicitly. Also check for wildcard rules (`*.ntp.org`, `*.cloudflare.com`) in custom block lists.

Stop DIY and contact D-Central support when (a) you have reflashed the latest stable AxeOS twice with 'Erase Flash', configured three different NTP servers, set up a router-side relay, and the clock still will not sync; (b) router packet capture confirms NTP responses are returning but the firmware is not accepting them — firmware regression; (c) the Bitaxe syncs but drifts >5 seconds per hour with steady network access — possible failing internal oscillator; (d) multiple Bitaxes on the same network all fail NTP simultaneously while desktops sync cleanly. The D-Central Bitaxe Troubleshooting Guide and Discord are the right escalation channels.

What D-Central does at this point: bench-side reproduction with identical Bitaxe variant, identical AxeOS build, controlled network with known-good NTP egress, full serial trace including `CONFIG_LWIP_DEBUG` and `CONFIG_SNTP_DEBUG` if needed. We isolate firmware-vs-network-vs-hardware. If we reproduce a firmware-level failure, we file a GitHub issue against `bitaxeorg/ESP-Miner` with the trace and a reproducer. D-Central contributes to the Bitaxe ecosystem and maintainers triage our reports because they come with hardware-grade reproduction notes.

Ship to D-Central if you want bench-grade diagnosis. Anti-static bag, double-box with 3 cm+ foam every side. Include a note: Bitaxe variant, AxeOS firmware version, NTP server configured, router make/model, screenshot of the AxeOS System page showing the time, and what you have already tried. We test on a controlled bench network, isolate firmware-vs-network-vs-hardware, return with a full report. Most NTP-fail tickets close without hardware repair because the issue is upstream — but bench reproduction proves it definitively. Turnaround typically 3–7 business days for diagnostic-only tickets.