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!