DATUM Gateway – Stratum LAN port 23334 repeatedly becomes unavailable on StartOS

Bitcoin
1

DATUM Gateway – BLAKE2b Stratum LAN port 23334 repeatedly becomes unavailable on StartOS

Hi Paul,

What to do with my question should I ask help from Start9?

We are seeing a recurring networking issue with the DATUM Gateway package on StartOS.

Our setup

We are mining BLAKE2b through a locally hosted DATUM Gateway on StartOS. The miners connect over the LAN to DATUM, and DATUM uses our local Bitcoin Knots node.

We are currently running:

  • Bitcoin Knots: #knots:29.4.2:3
  • DATUM Gateway: #pow:0.4.1:24
  • Mining algorithm: BLAKE2b
  • Stratum LAN endpoint: 192.168.1.7:23334
  • Approximately 7 miners / ~10–12 TH/s

Problem

DATUM itself continues running normally and its Stratum server remains reachable inside the LXC container on TCP 23334 , but the advertised LAN endpoint 192.168.1.7:23334 repeatedly stops listening/becomes unreachable.

When this happens, all miners disconnect simultaneously and DATUM drops to 0 Stratum clients / 0 TH/s . Bitcoin Knots and DATUM themselves remain healthy and operational.

We have now experienced this three times within approximately 24 hours .

What we verified

This is not simply caused by the DATUM container receiving a new IP address. During the latest failures, DATUM remained reachable internally at:

10.0.3.248:23334

while the StartOS LAN endpoint:

192.168.1.7:23334

was no longer listening/reachable.

Manually forwarding the LAN port directly to the DATUM container immediately restores all miners:

socat TCP-LISTEN:23334,bind=192.168.1.7,reuseaddr,fork TCP:10.0.3.248:23334

As soon as this forward is started, the miners reconnect and DATUM starts receiving Stratum clients and BLAKE2b hashrate again. No changes to the miners, DATUM configuration or Bitcoin Knots are required.

Temporary workaround

Because the failure occurs repeatedly, we currently have a temporary watchdog running on the StartOS host. It checks 192.168.1.7:23334 every 10 seconds and, if the listener disappears, automatically discovers which 10.0.3.x container is listening on port 23334 and recreates the socat forward.

This works, but obviously should not be necessary on a production StartOS setup and is not a proper long-term solution.

Requested structural fix

Could you please investigate how the DATUM package exposes its Stratum interface to the LAN and ensure that TCP 23334 is persistently managed/exposed by StartOS itself ?

The desired networking path is simply:

BLAKE2b miners → StartOS-LAN-IP:23334 → DATUM Stratum service

It should not require a manually maintained socat process or knowledge of DATUM’s internal 10.0.3.x LXC address.

Ideally the LAN listener/forward should automatically survive or be recreated after:

  • DATUM restarts
  • container/network restarts
  • internal LXC IP changes
  • service crashes/restarts
  • StartOS reboot or power loss

Since DATUM’s internal Stratum service remains available when the problem occurs, while only the StartOS LAN endpoint disappears, this appears to be specifically related to the LAN exposure/forwarding of DATUM TCP port 23334 , rather than a failure of DATUM, Bitcoin Knots, or the BLAKE2b miners themselves.

Thanks!

2

Yes, based on the description, that would most likely be an issue with StartOS. Other possibilities are a flaky router or conflicting static LAN IPs.

3

Paul, is it an idea to contact Start9 so they can prob fix this issue in an update?

4

Yes, sounds reasonable.