AntMinerV2020 Pause::pause does not support older stock set_miner_conf.cgi payload shape

[DanNicolau]

Summary

AntMinerV2020::pause() currently sends a partial JSON payload to /cgi-bin/set_miner_conf.cgi, but at least some older
Bitmain stock firmware versions require the browser/UI-style full config payload with Content-Type: text/ plain;charset=UTF-8.

As a result, pause() returns false or times out, and the miner does not enter sleep mode.

Current behavior

For stock Antminer firmware, Pause::pause() reads /cgi-bin/get_miner_conf.cgi, then sends one of these partial JSON
payloads:

{"miner-mode":"1"}

or:

  {"bitmain-work-mode":"1"}

via AntMinerWebAPI::set_miner_conf.

On the affected firmware, this does not change the mode. get_miner_conf.cgi continues to report:

  "bitmain-work-mode": "0"

Affected device / firmware

Observed on:

Antminer S19j Pro
Linux 4.9.113 #1 SMP PREEMPT Mon Dec 26 17:29:52 CST 2022
system_filesystem_version: Mon Dec 26 17:10:01 CST 2022
firmware_type: Release

Browser behavior that works

The stock web UI sends a full config payload to the same endpoint:

POST /cgi-bin/set_miner_conf.cgi
Content-Type: text/plain;charset=UTF-8
X-Requested-With: XMLHttpRequest
Accept: application/json, text/javascript, /; q=0.01

Example body:

  {
    "bitmain-fan-ctrl": false,
    "bitmain-fan-pwm": "100",
    "miner-mode": 1,
    "freq-level": "100",
    "pools": [
      {
        "url": "stratum+tcp://example:3334",
        "user": "user1",
        "pass": ""
      },
      {
        "url": "stratum+tcp://example:3334",
        "user": "user2",
        "pass": ""
      },
      {
        "url": "stratum+tcp://example:443",
        "user": "user3",
        "pass": ""
      }
    ]
  }

Notable differences from the current asic-rs request:

• Content-Type is text/plain;charset=UTF-8, not application/json
• the body is the full miner config, not only the mode key
• the UI uses miner-mode: 1 as a number
• the UI includes existing pool/fan/frequency fields

Expected behavior

AntMinerV2020::pause() should support this older stock UI payload shape, or fall back to it when the partial JSON update
does not apply.

A possible approach:

1. Read get_miner_conf.cgi
2. Try the current partial JSON behavior
3. Re-read config and verify sleep mode
4. If unchanged, send a full UI-style config payload using text/plain;charset=UTF-8
5. Confirm either miner-mode == 1 or bitmain-work-mode == 1

Why this matters

Consumers of Pause::pause() expect a successful result to mean the miner is actually entering sleep mode. On this
firmware, the current call can fail or time out without changing the miner state, preventing safe workflows that need
mining stopped before installation or maintenance.

[DanNicolau]

Let me know if this is in scope for asic-rs. I realize there may be some complications around sending the full payload because there are other fields which really should be orthogonal to miner-mode, so I'd understand if this won't be supported, but I think it should be addressed at least.

[b-rowan]

Makes sense. As always, the goal is the best miner support possible, so I think the fix for this is to try to figure out the newest firmware where this isn't an issue, then create a versioned struct for that, making these changes on the current v2020 version.

@DanNicolau could you test a few things?

• Can you try sending the work mode value and an integer instead with the small payload, to see if that improves it?
• Can you see if you can find the version where this stops being an issue and starts working properly?
• If possible, could you try on some other bitmain S miner types with firmware versions similar to this to see if the functionality is the same, and do the same thing with testing the latest version for those where this stops happening?

I want to answer a few questions here, namely:

• Is it just needing an int?
• What firmware should we switch this functionality at?
• Is it miner specific which version it changes on?

[DanNicolau]

Sure I'll get some more details in the next few days. I'm not sure if I have a lot of versions similar, but I'll look around. Also, in my exploration of stock firmware I've learned that the changes bitmain makes are not necessarily chronological between versions; i.e. an S19kpro version released in October 2025 may contain changes that are not in an S21 pro from January 2026 for instance. I think for most or all of the asic-rs features this can be ignored, but it may come up in the future.

[DanNicolau]

After some further testing the S19jpro firmware that I'm testing on (even if a good request is made) still doesn't actually go to sleep until a reboot occurs. I'll check to see if other stock firmware versions have a working sleep mode without reboot, and if the current api is compatible with them. This change may not even be necessary if it's just for this version and the api is broken.