Bitmern Solo
Bitmern Solo
Log inStart Mining
← Back to blog

MAC Address Filter Blocking Bitaxe on Bitmern Solo

If a MAC address filter is blocking your Bitaxe on Bitmern Solo — router whitelist mining, MAC filter drops WiFi after reboot, new-device approval never…

11 min read
MAC Address Filter Blocking Bitaxe on Bitmern Solo
MAC Address Filter Blocking Bitaxe on Bitmern Solo

Your Bitaxe used to hash on Bitmern Solo. Then you flipped “MAC filtering,” enabled a wireless allow list, swapped a board, or the router demanded “approve new device” after a lease refresh — and WiFi association never returns. Phones still browse. AxeOS may show disconnected or endlessly reconnecting. The stratum URL looks perfect. The failure is LAN admission, not a pool outage.

If a MAC address filter is blocking your Bitaxe on Bitmern Solo — router whitelist mining, MAC filter drops WiFi after reboot, new-device approval never clears the miner, or wireless allow/deny list silent-fails association — 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, allow the Bitaxe MAC (or disable the filter for a controlled test), then prove a durable Authorized / Subscribed session. This post is not the guest-wifi-ap-isolation lane, the firewall-blocking-stratum lane, the wifi-drops-stratum lane, the dhcp-reservation-static-ip lane, or the router-reboot-recovery lane — and Current Effort is not a find guarantee.

This is the MAC filter / wireless admission lane. Guest / AP isolation: guest WiFi / AP isolation. Outbound TCP / firewall: firewall blocking stratum. RF flaps: WiFi drops killing stratum. LAN IP churn: DHCP reservation / static IP. Post-reboot stack: router reboot recovery.

Bitmern Solo is solo infrastructure: flat 1% fee on finds only, you keep 99%. Fee context stays light here — the job is restoring WiFi admission so outbound stratum to :3132 can exist at all.

MAC filter ≠ guest isolation ≠ firewall ≠ WiFi drops ≠ DHCP ≠ router reboot

Six patterns get mixed up:

  1. MAC filter / wireless allow-deny / new-device approval — the AP refuses association (or DHCP after associate) because the Bitaxe MAC is not admitted. That is this post.
  2. Guest WiFi / AP isolation — clients associate but cannot talk (isolation/VLAN). Use guest WiFi / AP isolation.
  3. Firewall blocking stratum — WiFi works; outbound TCP to the pool is blocked. Use firewall blocking stratum.
  4. WiFi drops (generic) — RF flaps without an admission policy story. Use WiFi drops killing stratum.
  5. DHCP reservation / static IP — address churn without auth block. Use DHCP reservation / static IP.
  6. Router reboot recovery — reboot timeline without a MAC policy change. Use router reboot recovery.

Do not invent a Bitmern Solo “device approval” product, cloud MAC whitelist, 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. Home routers brand MAC filtering differently — follow your AP’s docs; Bitmern Solo does not publish a MAC-filter compatibility matrix.

Critical clarify: MAC filtering is LAN WiFi admission. Stratum itself is outbound TCP once WiFi + DNS work. Fixing the allow list does not invent inbound ports, and Bitmern Solo does not sell a router device-approval feature.

What MAC-filter fallout usually looks like on a Bitaxe desk

Common desks:

  1. Worked for months; died the day you enabled “MAC filter: Allow” — empty allow list or wrong MAC.
  2. Swapped Ultra → Gamma (or replaced a board); new MAC unknown — allow list still has the old address.
  3. Router “approve new devices” pending forever — phone approved; miner never cleared.
  4. After reboot, deny-list mode returned — policy restored with the AP.
  5. AxeOS never associates; phones fine — classic admission wall.
  6. Associates briefly then kicked — some APs enforce MAC after DHCP.
  7. You already checked guest isolation — clients associate there; here association itself fails.
  8. You already opened firewall ports outbound — WiFi never came up, so firewall was never the first gate.

Separate these from isolation after associate (guest WiFi / AP isolation) and from outbound blocks (firewall blocking stratum).

Ordered diagnose-and-fix checklist

Run top to bottom. Stop when firmware associates, holds a clean Authorized / Subscribed session on Bitmern Solo, the matching coin tab shows the worker, and accepts can move — without inventing a Bitmern device-approval product.

1. Confirm BTC easy-start string before you chase MAC UI

Symptom: You rewrite allow lists 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. Confirm MAC filtering / new-device approval is actually enabled

Symptom: You blame “MAC filter” while association fails for password / SSID / RF reasons.

Fix: Open the router wireless security / access control page. Note allow vs deny mode, and any “approve new devices” queue. If filtering is off and association still flaps, leave for WiFi drops killing stratum.

3. Read the Bitaxe MAC from AxeOS (or the sticker) — do not guess

Symptom: You allow-listed a phone MAC or an old board’s address.

Fix: Copy the WiFi MAC from AxeOS network status (or the board label). Match format your router expects (colon vs dash). One wrong nibble = permanent deny on allow-list mode.

4. Allow the Bitaxe MAC — or temporarily disable the filter for a controlled test

Symptom: Allow list empty, deny list includes the miner, or approval queue stuck.

Fix: Add the Bitaxe MAC to the allow list (allow mode) or remove it from deny. Clear / approve pending devices if your router uses that flow. For a short test only, disable MAC filtering, prove association + stratum, then re-enable with the correct entry — do not leave the LAN wide open as a permanent “fix.” Bitmern Solo does not invent a router approval product; this is your AP’s feature.

5. Confirm association + LAN IP after the MAC is admitted

Symptom: MAC allowed; board still shows disconnected or no DHCP.

Fix: Reboot the Bitaxe once after the policy change. Confirm SSID association and a real LAN IP. If IP churn alone is the remaining pain after stratum works, use DHCP reservation / static IP.

6. Soft-reconnect stratum after WiFi admission returns

Symptom: WiFi is healthy; firmware still shows an old dead session.

Fix: Save pool settings (even if unchanged) or reboot the Bitaxe once so firmware opens a new outbound session to btc.bitmernsolo.com:3132. Outbound stratum should resume when WiFi + DNS are healthy — that is desk practice, not a Bitmern admission SLA.

7. Separate MAC filter from guest isolation

Symptom: The board associates and gets an IP but cannot reach anything useful.

Fix: Use guest WiFi / AP isolation. Return here when association itself is refused.

8. Separate MAC filter from firewall blocking stratum

Symptom: WiFi + browsing from the same LAN works; only pool TCP fails.

Fix: Use firewall blocking stratum. MAC filter is the gate before outbound TCP matters.

9. Separate MAC filter from generic WiFi drops

Symptom: Association flaps without an allow/deny policy story.

Fix: Use WiFi drops killing stratum.

10. Separate MAC filter from router-reboot recovery

Symptom: Timeline starts with a known router restart; MAC policy unchanged.

Fix: Use router reboot recovery. If after reboot the allow list restored and still blocks the miner, return here.

11. Open the matching coin tab and prove the session

Symptom: You declare victory from a router “client online” LED.

Fix: Open the same coin the miner uses. Confirm the worker under WALLET.worker. Card reading: dashboard workers / shares / effort.

12. Prove the session — not a luck promise

After MAC admitted + WiFi + DNS + new session:

  • 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%. Surviving a MAC filter is desk hygiene, not a fee event.

When guest isolation, firewall, WiFi drops, DHCP, or reboot is the real story

If clients associate but isolation blocks traffic, use guest WiFi / AP isolation. If WiFi works and outbound TCP to the pool fails, use firewall blocking stratum. If RF flaps without admission policy, use WiFi drops killing stratum. If only LAN address bookmarks broke, use DHCP reservation / static IP. If a reboot started the outage, use router reboot recovery.

What this post will not invent

  • No Bitmern Solo “device approval” or cloud MAC whitelist product
  • No claim that :3102 is the home Bitaxe default (easy-start is :3132)
  • No luck formulas, dollar EV, or find-time promises from Current Effort
  • No fabricated “official router MAC matrix” sold as Bitmern Solo policy
  • No claim that inbound ports are required once WiFi is admitted
  • No competitor fee comparisons

Fee reminder: flat 1% on finds; you keep 99%. Admitted MAC + correct port is desk hygiene, not a luck product.

Quick retest sequence after allowing the Bitaxe MAC

After the allow list / approval queue is correct:

  1. Confirm BTC easy-start still btc.bitmernsolo.com + :3132.
  2. Confirm username WALLET.worker, password x.
  3. Confirm AxeOS associates + has a LAN IP.
  4. Soft-reconnect or reboot the Bitaxe once so firmware opens a new session.
  5. Open the matching coin tab — not a neighbor tab.
  6. Watch for Authorized / Subscribed and a worker row — not Current Effort as a find promise.

If association works but guest isolation remains, leave for guest WiFi / AP isolation. If WiFi works and only outbound TCP fails, leave for firewall blocking stratum.

Common MAC-filter mistakes to avoid

  1. Assuming Bitmern Solo is down because WiFi never associates — prove MAC admission first.
  2. Treating :3102 as “the Bitmern port” — easy-start for Bitaxe / home BTC is :3132.
  3. Skipping .worker — username format matters for attribution after every reconnect.
  4. Using a non-x password — Bitmern Solo expects password exactly x.
  5. Allow-listing the wrong MAC after a board swap — copy from AxeOS, not memory.
  6. Leaving MAC filter disabled forever “for testing” — controlled test only; then re-lock with the correct entry.
  7. Inventing a Bitmern device-approval product — the approval UI is your router’s, not Bitmern Solo’s.

None of these mistakes invent an admission product. They only restore WiFi so outbound stratum can reach a real session and proven accepts.

How this checklist fits the ops library

Start here when association fails (or is kicked) under an allow/deny / approval policy. Move sideways when the symptom clearly belongs to another lane.

Soft next step

After the Bitaxe MAC is admitted, lock BTC easy-start btc.bitmernsolo.com with port :3132, keep WALLET.worker with password x, confirm WiFi + DNS, open a new session, then confirm Authorized / Subscribed plus a worker row — before you chase luck myths or invent a Bitmern device-approval product.

Start mining

Start Mining — after login, open the matching coin tab and confirm workers / shares / hashrate.

FAQ

Can a MAC filter block Bitmern Solo?

It can block WiFi association so the Bitaxe never reaches outbound stratum. Once WiFi and DNS work, a correct pool string should open a session. There is no invented Bitmern Solo device-approval product.

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.

Is this the same as guest WiFi isolation?

No. Guest isolation usually associates then walls traffic: guest WiFi / AP isolation. Use this post when the MAC policy refuses or kicks association.

Is MAC filter the same as a firewall block?

No. Firewall blocks outbound TCP after WiFi works: firewall blocking stratum. MAC filter is LAN admission.

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.

Related posts