192.168.x.y:23334 (errno 104: Connection reset by peer). I don’t see any login attempts or errors in the Datum logs.
Datum v. 0.4.1:15
Any ideas?
***UPDATE
I’ve check port access to :23334 ie. nc: connect to 192.168.x.y port 23334 (tcp) failed: Connection refused
***UPDATE 2
I’ve ssh’d into the Start9 machine and issued a netstat -ano | grep 23334 and no port open.
I installed a standalone version of Datum on a VM on the same network I have no problem with the miner attaching to it on port 23334. And I am able to RCP to the bitcoin node on the Start9 machine no problem.
I tried to rebuild the service but the issue persists.
Have the exact same issue. From what I learned, startd completely fails to open port 23334 – this is why it doesn’t even show up as listening port via ssh. I also rebuilt, uninstalled / reinstalled and there is no 23334 to use as indicated in the datum interface. I also checked to make sure there weren’t other hidden ports available for datum and there were not. My s9 install (0.4.0.1) is completely clean and from scratch as well (not an upgrade).
I put a bug report at github. However, I don’t know what anomaly it is that the “others” are able to use it. Well one thing is with my Start9 instance this is a new install of Datum after I upgraded from v0.3.5.1 to v0.4.0.1.
Not some app that was carried over from the upgrade.
Like you it’s a new install of the Datum app. Go over to GitHub if you get a chance and put in a bug report. Well at least now there are two of us that have the same issue with no 23334 port open.
I think what might confuse you is that there is no port 23334 open/visible at the start9 host level, but the package containers themselves can show the port is listening/connected. On my start9 host, the working Datum container can see the following ports (hex ports converted to decimal so we can pick out 23334 etc)
the output of your commands is affected by the different namespaces in use for each of the containers and the host. I get exactly the same output as you do when I run your command on my start9 host, yet my Datum server services my bitaxe machines OK. Try running my commands on your host.
The most likely cause is that **the service is listening inside the container’s network namespace, not on the LXC host**. Connecting to `1.2.3.4:23334` reaches the host’s IP stack; it does not automatically reach a container.
Common causes include:
- **No port forwarding/NAT or proxy:** The container may have its own address, such as `10.0.3.25`, and the service is reachable at `10.0.3.25:23334`, but nothing is listening on `1.2.3.4:23334`.
- **Service bound only to loopback:** Inside the container, it may listen on `127.0.0.1:23334` rather than `0.0.0.0:23334` or the container’s LAN address.
- **Wrong host/container address:** The container may be bridged directly and have its own IP; the host IP is not the correct destination unless forwarding is configured.
- **Host firewall actively rejecting the port:** An `iptables`/`nftables` rule using `REJECT` can produce an immediate “connection refused.” A `DROP` rule usually causes a timeout instead.
- **Container firewall rejecting the connection:** Similarly, firewall rules inside the container can reject traffic.
- **Incorrect port-forwarding rule:** DNAT may point to the wrong container IP or port, use the wrong interface, or fail to handle return traffic.
- **Service listening on IPv6 only:** It might listen on `[::]:23334` while the client is connecting over IPv4 to `1.2.3.4`.
- **LXC network isolation or bridge configuration:** The container interface may be down, attached to the wrong bridge, or not connected to the expected network.
- **The service exited or restarted:** A process can appear configured correctly while no process is currently listening.
Check from inside the container:
```bash
ss -ltnp | grep 23334
```
You want to see something like:
```text
0.0.0.0:23334
```
or the container’s actual IP, not only:
```text
127.0.0.1:23334
```
Then test locally and from the host:
```bash
# Inside the container
nc -vz 127.0.0.1 23334
nc -vz <container-ip> 23334
# On the LXC host
nc -vz <container-ip> 23334
nc -vz 1.2.3.4 23334
```
Inspect the addresses and routes:
```bash
# Inside container
ip addr
ip route
# On host
ip addr
ip route
```
If the service should be reached through the host address, verify that forwarding exists. For example, a DNAT rule would conceptually look like:
```bash
iptables -t nat -A PREROUTING \
-d 1.2.3.4 -p tcp --dport 23334 \
-j DNAT --to-destination <container-ip>:23334
```
You may also need forwarding enabled and an appropriate `FORWARD` rule:
```bash
sysctl net.ipv4.ip_forward
iptables -L FORWARD -n -v
nft list ruleset
```
The fastest way to distinguish the cases is packet capture:
```bash
# On the host
tcpdump -ni any tcp port 23334
```
Interpretation:
- **SYN arrives, host immediately sends RST:** no host listener, or an active reject.
- **SYN is DNATed and reaches the container, but container sends RST:** service is not listening on the container address/port.
- **SYN reaches the container and no reply returns:** firewall, routing, or service/network issue.
- **No SYN reaches the host:** the client is using the wrong address, has a local firewall issue, or there is a routing problem.
In a typical LXC setup, try the container’s own IP first. If that works but `1.2.3.4:23334` does not, the service is healthy and the missing piece is host-side port forwarding or a proxy listener.
Which network are you trying to connect from? Is the bitaxe on the same local network as the start9 server (and not on another subnet)? I have seen evidence that Local (as defined in the Interfaces tab in the StartOS GUI) connections are only permitted from the same local network that the Start9 host is on.
Does this work, from the Start9 host itself? (the empty reply is expected - it’s not the connection refused error)
start9@:~$ curl http://your-start9-192.168.ip-addr:23334/
curl: (52) Empty reply from server
It seems StartOS only allows (really) local network access through it’s nftables rules (here for my 192.168.0.16 start9 server, you can see no 0.0.0.0/0 saddr is defined for port 23334):
start9@:~$ sudo nft list ruleset | egrep 'table|chain|23334'| head -23
table ip startos {
chain prerouting {
ip saddr 192.168.0.0/24 ip daddr 192.168.0.16 meta l4proto { tcp, udp } th dport 23334 dnat to 10.0.3.61:23334 comment "F779ce76f8071f5f"
ip saddr 10.0.3.0/24 ip daddr 192.168.0.16 meta l4proto { tcp, udp } th dport 23334 dnat to 10.0.3.61:23334 comment "F779ce76f8071f5f"
ip saddr 127.0.0.0/8 ip daddr 127.0.0.1 meta l4proto { tcp, udp } th dport 23334 dnat to 10.0.3.61:23334 comment "F9150d6de2e8809b"
ip saddr 10.0.3.0/24 ip daddr 127.0.0.1 meta l4proto { tcp, udp } th dport 23334 dnat to 10.0.3.61:23334 comment "F9150d6de2e8809b"
ip saddr 10.0.3.0/24 ip daddr 10.0.3.1 meta l4proto { tcp, udp } th dport 23334 dnat to 10.0.3.61:23334 comment "Feb73d407f315100"
ip saddr 10.0.3.0/24 ip daddr 10.0.3.1 meta l4proto { tcp, udp } th dport 23334 dnat to 10.0.3.61:23334 comment "Feb73d407f315100"
chain output {
ip daddr 192.168.0.16 meta l4proto { tcp, udp } th dport 23334 dnat to 10.0.3.61:23334 comment "F779ce76f8071f5f"
ip daddr 127.0.0.1 meta l4proto { tcp, udp } th dport 23334 dnat to 10.0.3.61:23334 comment "F9150d6de2e8809b"
ip daddr 10.0.3.1 meta l4proto { tcp, udp } th dport 23334 dnat to 10.0.3.61:23334 comment "Feb73d407f315100"
chain postrouting {
fib saddr type local ct original ip daddr 192.168.0.16 ip daddr 10.0.3.61 meta l4proto { tcp, udp } th dport 23334 masquerade comment "F779ce76f8071f5f"
ip saddr 10.0.3.0/24 ip daddr 10.0.3.61 meta l4proto { tcp, udp } th dport 23334 masquerade comment "F779ce76f8071f5f"
fib saddr type local ct original ip daddr 127.0.0.1 ip daddr 10.0.3.61 meta l4proto { tcp, udp } th dport 23334 masquerade comment "F9150d6de2e8809b"
ip saddr 10.0.3.0/24 ip daddr 10.0.3.61 meta l4proto { tcp, udp } th dport 23334 masquerade comment "F9150d6de2e8809b"
fib saddr type local ct original ip daddr 10.0.3.1 ip daddr 10.0.3.61 meta l4proto { tcp, udp } th dport 23334 masquerade comment "Feb73d407f315100"
ip saddr 10.0.3.0/24 ip daddr 10.0.3.61 meta l4proto { tcp, udp } th dport 23334 masquerade comment "Feb73d407f315100"
chain forward {
ip daddr 10.0.3.61 meta l4proto { tcp, udp } th dport 23334 ct state new accept comment "F779ce76f8071f5f"
ip daddr 10.0.3.61 meta l4proto { tcp, udp } th dport 23334 ct state new accept comment "F9150d6de2e8809b"
ip daddr 10.0.3.61 meta l4proto { tcp, udp } th dport 23334 ct state new accept comment "Feb73d407f315100"
First of all thanks for working on this with me. I appreciate it.
You are correct! I again logged in to a machine that’s on the same local network as the Start9 machine and indeed StartOS is only allowing local network access.
On a side note, this seems to be also the case for Bitcoin Core ZeroMQ ports 28332-28333.
The only remedy at this point is to put the miners on the same network. I guess. Which is kind of inconvient. Hmmm. Or?
you could perhaps add more nftables rules for your other subnets, using the chroot-and-upgrade method, but it’s a bit techy. Depends on your comfort level. Or maybe try adding a public IP URL and see if your bitaxe can access that IP?