DHCP Reservation / Static IP for Bitaxe on Bitmern Solo
If DHCP lease churn or a router reboot changed your Bitaxe LAN IP on Bitmern Solo — miner “offline” after reboot because the old address moved, AxeOS bookmark…

Your Bitaxe kept hashing on Bitmern Solo — then the router rebooted, the DHCP lease renewed, and the LAN IP changed. AxeOS bookmarks break. Home dashboards that scrape the old address go dark. You assume the pool died, even though outbound stratum should still work if WiFi and DNS are fine.
If DHCP lease churn or a router reboot changed your Bitaxe LAN IP on Bitmern Solo — miner “offline” after reboot because the old address moved, AxeOS bookmark broken, static IP Bitaxe needed, or DHCP reservation mining setup — run an ordered checklist: confirm BTC easy-start bare host btc.bitmernsolo.com with port :3132 (never treat :3102 as the Bitaxe / home default), username WALLET.worker, password x, prove the stratum session still holds, then lock a DHCP reservation (or careful static IP) so local access stops chasing a moving address. This post is not the wifi-drops-stratum lane, the dns-resolve-fix lane, the guest-wifi-ap-isolation lane, the ethernet-vs-wifi lane, or the workers-not-appearing lane — and Current Effort is not a find guarantee.
This is the DHCP-reservation / static-IP lane. Radio flaps without a lease story: WiFi drops killing stratum. DNS-only failures: DNS resolve fix. Guest / AP isolation: guest WiFi / AP isolation. Wired vs wireless choice: ethernet vs WiFi. Dashboard identity / missing workers: workers not appearing.
Bitmern Solo is solo infrastructure: flat 1% fee on finds only, you keep 99%. Fee context stays light here — the job is stable LAN addressing so you can still open AxeOS while stratum to Bitmern Solo keeps using outbound TCP.
DHCP churn ≠ WiFi drops ≠ DNS ≠ guest isolation ≠ ethernet choice ≠ missing workers
Six patterns get mixed up:
- DHCP reservation / static IP — the Bitaxe got a new LAN IP after lease renew or router reboot, so local habits break even when outbound stratum can still reach Bitmern Solo. That is this post.
- WiFi drops — the radio flaps without a lease/IP story. Use WiFi drops killing stratum.
- DNS resolve fix — name resolution only. Use DNS resolve fix.
- Guest WiFi / AP isolation — isolation/VLAN policy blocks the path. Use guest WiFi / AP isolation.
- Ethernet vs WiFi — choosing wired media. Use ethernet vs WiFi.
- Workers not appearing — dashboard identity / attribution, not LAN IP. Use workers not appearing.
Do not invent Bitmern Solo “DHCP SLA” product guarantees, reserved-IP cloud sync, or a claim that Current Effort predicts finds. Product facts that matter for retest: BTC host btc.bitmernsolo.com, easy-start port :3132, username WALLET.worker, password x. Router DHCP UIs vary — follow your AP’s docs; Bitmern Solo does not publish a DHCP reservation compatibility matrix.
Critical clarify: stratum from the Bitaxe to Bitmern Solo is outbound TCP. A new LAN IP alone should not kill pool auth if WiFi association and DNS still work. What usually breaks is your local bookmark, home scraper, or “open AxeOS at 192.168.x.y” habit — not the pool endpoint itself.
What DHCP / IP churn usually looks like on a Bitaxe desk
Common desks:
- Router reboot overnight; old AxeOS URL 404s — lease renewed to a new address.
- Phone still opens the miner; laptop bookmark does not — one device cached mDNS / ARP; the bookmark did not.
- Home Grafana / Prometheus scrape went dark — scrape target used a floating DHCP address.
- You “fixed” by factory-resetting the Bitaxe — wiped pool fields for a LAN addressing problem.
- Pool session still Authorized; you assumed offline — dashboard was fine; local UI path was not.
- Two Bitaxes swapped IPs after renew — confusion about which board is which on the LAN.
- You already ran WiFi-drop checklists — RSSI is fine; the address moved.
- Guest isolation posts did not help — you are on main LAN; the lease just churned.
Separate these from radio flaps (WiFi drops killing stratum) and from isolation walls (guest WiFi / AP isolation).
Ordered diagnose-and-fix checklist
Run top to bottom. Stop when firmware holds a clean Authorized / Subscribed session on Bitmern Solo, you can open AxeOS at a stable LAN address (reservation or careful static), and accepts can move — without inventing a DHCP product SLA.
1. Confirm BTC easy-start string before you touch DHCP
Symptom: You rebuild reservations while the miner still has a wrong host, leftover :3102, or a bare wallet username.
Fix: On the Bitaxe (AxeOS or equivalent), set:
btc.bitmernsolo.com
Port:
3132
Username:
WALLET.worker
Password:
x
Never treat :3102 as the Bitaxe / home default. Wallet must be registered for that coin on Bitmern Solo.
2. Prove whether stratum still works despite the new LAN IP
Symptom: Local bookmark fails; you have not checked the Bitmern Solo session.
Fix: Open the matching coin tab. If the worker still shows under WALLET.worker and firmware still holds Authorized / Subscribed, the pool path is alive — fix LAN addressing for local access, not “the pool.” Card reading: dashboard workers / shares / effort.
3. Find the Bitaxe’s current LAN IP the honest way
Symptom: You keep typing yesterday’s address.
Fix: Check the router’s DHCP client list / ARP table for the Bitaxe MAC (often printed on the board or shown in AxeOS network info). Or use whatever local discovery your firmware exposes. Do not invent a Bitmern Solo LAN-discovery product.
4. Prefer a DHCP reservation keyed to the MAC
Symptom: You want a stable address without fighting the router’s DHCP server.
Fix: On the router, create a DHCP reservation (static lease) for the Bitaxe MAC → chosen LAN IP inside the DHCP pool’s reserved range (follow your router’s UI: “Address Reservation,” “Static Lease,” “DHCP Binding”). Reboot or renew the Bitaxe lease so it picks up the reserved address. This is usually safer than a board-side static IP that can collide if you guess wrong.
5. If you must set a static IP on the Bitaxe, avoid collisions
Symptom: Firmware offers static IP fields; reservation UI is unavailable.
Fix: Pick an address outside the dynamic DHCP pool (or firmly reserved), set correct gateway + DNS, and document it. A wrong gateway/DNS can break resolve for btc.bitmernsolo.com even when WiFi associates — then leave for DNS resolve fix if name resolution is the remaining failure.
6. Separate LAN IP churn from WiFi drops
Symptom: Association flaps, roam thrash, or RSSI cliffs without a lease story.
Fix: Use WiFi drops killing stratum. IP churn is an addressing wall; drops are a radio wall.
7. Separate LAN IP churn from guest / AP isolation
Symptom: Guest SSID or client isolation blocks outbound stratum/DNS.
Fix: Use guest WiFi / AP isolation. A reservation on an isolated guest VLAN does not create an outbound path.
8. Separate LAN IP churn from DNS-only failures
Symptom: Address is stable; btc.bitmernsolo.com still will not resolve.
Fix: Use DNS resolve fix. Static IP mistakes (bad DNS servers) can cause DNS failure — fix DNS fields, then return here only if address stability is still the gap.
9. Prefer ethernet when the desk allows it — then still reserve the IP
Symptom: You want fewer wireless variables and a stable scrape target.
Fix: Wired guidance: ethernet vs WiFi. Ethernet does not remove DHCP churn by itself — reserve the wired MAC too if you care about a fixed LAN address.
10. Update bookmarks and scrapers to the reserved address
Symptom: Reservation is live; old bookmarks and Prometheus targets still point at the ghost IP.
Fix: Update AxeOS bookmarks, home dashboards, and any scrape configs. Prefer documenting the reserved IP next to the worker label so the next reboot is boring.
11. Open the matching coin tab and prove the session
Symptom: You declare victory from a local ping alone.
Fix: Open the same coin the miner uses. Confirm the worker under WALLET.worker. Local ping ≠ pool session. Card reading: dashboard workers / shares / effort. If the worker row is wrong/missing after identity changes, use workers not appearing.
12. Prove the session — not a luck promise
After a stable LAN address + confirmed stratum:
- Firmware holds Authorized / Subscribed (or equivalent)
- Matching coin tab shows the worker under the expected label
- Fresh accepts can move while the board hashes
- You are not treating Current Effort as a find clock
Current Effort is an ops signal — not a find guarantee.
13. Soft fee reminder only after the session holds
Fee reminder only if you need it: flat 1% on finds; you keep 99%. A DHCP reservation is desk hygiene, not a fee event.
When WiFi drops, DNS, guest isolation, ethernet, or workers is the real story
If the radio flaps without a lease story, use WiFi drops killing stratum. If DNS alone is broken, use DNS resolve fix. If guest / AP isolation blocks the path, use guest WiFi / AP isolation. If you are choosing wired for stability, use ethernet vs WiFi. If the dashboard identity is wrong, use workers not appearing.
What this post will not invent
- No Bitmern Solo “DHCP reservation SLA” or guaranteed lease-time product claims
- No claim that
:3102is the home Bitaxe default (easy-start is :3132) - No luck formulas, dollar EV, or find-time promises from Current Effort
- No fabricated “official router whitelist” sold as Bitmern Solo policy
- No claim that a new LAN IP alone must kill outbound stratum when WiFi/DNS are healthy
- No competitor fee comparisons
Fee reminder: flat 1% on finds; you keep 99%. A stable LAN address + correct port is desk hygiene, not a luck product.
Quick retest sequence after a reservation or static IP change
After you bind the MAC or set a careful static IP:
- Confirm BTC easy-start still
btc.bitmernsolo.com+ :3132. - Confirm username
WALLET.worker, passwordx. - Renew the lease / reboot so the board uses the reserved address.
- Open AxeOS at the new stable IP; update bookmarks/scrapers.
- Open the matching coin tab — not a neighbor tab.
- Watch for Authorized / Subscribed and a worker row — not Current Effort as a find promise.
If stratum died only after you set bad static DNS/gateway, leave for DNS resolve fix. If the board is on guest isolation, leave for guest WiFi / AP isolation.
Common DHCP / static IP mistakes to avoid
- Assuming a new LAN IP means Bitmern Solo is down — outbound stratum can survive if WiFi/DNS are fine; prove the session on the matching coin tab.
- Treating
:3102as “the Bitmern port” — easy-start for Bitaxe / home BTC is:3132. - Skipping
.worker— username format matters for attribution after every reconnect. - Using a non-
xpassword — Bitmern Solo expects password exactlyx. - Static IP inside the dynamic pool without a reservation — collisions when another device gets the same lease.
- Factory-resetting the Bitaxe to “fix” a bookmark — you trade a LAN problem for wiped pool fields.
- Inventing a DHCP SLA — home routers vary; Bitmern Solo does not sell lease guarantees.
None of these mistakes invent a DHCP product. They only restore stable local access while keeping a real session and proven accepts.
How this checklist fits the ops library
- This post — ordered DHCP reservation / static IP diagnose-and-fix while pointed at Bitmern Solo.
- WiFi drops killing stratum — radio flaps without a lease story.
- DNS resolve fix — DNS-only failures.
- Guest WiFi / AP isolation — guest / AP / client isolation.
- Ethernet vs WiFi — wired vs wireless choice.
- Workers not appearing — dashboard identity / missing workers.
Start here when lease churn / router reboot moved the Bitaxe LAN IP and local access broke. Move sideways when the symptom clearly belongs to another lane.
Soft next step
Prove the Bitmern Solo session still holds on btc.bitmernsolo.com with port :3132, keep WALLET.worker with password x, then bind a DHCP reservation (or careful static IP) so AxeOS bookmarks stop chasing a moving address — before you chase luck myths or invent a DHCP SLA.
Start mining
Start Mining — after login, open the matching coin tab and confirm workers / shares / hashrate.
FAQ
Does a new Bitaxe LAN IP disconnect Bitmern Solo?
Not by itself. Stratum is outbound TCP. If WiFi and DNS still work, pool auth can survive while your local bookmark breaks. Prove the matching coin tab before you rebuild pool fields.
What BTC port should a home Bitaxe use?
:3132 on btc.bitmernsolo.com. Never treat :3102 as the Bitaxe / home default.
What username and password does Bitmern Solo expect?
Username WALLET.worker (wallet must be registered for that coin). Password exactly x.
DHCP reservation or static IP on the Bitaxe?
Prefer a router DHCP reservation keyed to the MAC when available. Board-side static IP works if you avoid pool collisions and set correct gateway/DNS.
Is this the same as guest WiFi isolation?
No. Isolation is a policy wall — guest WiFi / AP isolation. Use this post when the address moved on an otherwise working path.
Does Current Effort mean I am about to find a block?
No. Current Effort is an ops / attribution signal — not a find guarantee. See the dashboard guide.
Where do I confirm the fix on Bitmern Solo?
Matching coin tab → worker row → firmware holds Authorized / Subscribed → fresh accepts when the board hashes. Guide: dashboard workers / shares / effort.


