Moin Tom,
Yes, that’s what I expect based on the specification. It’s the same as the serial protocol. A few post back I found one variable initialization issue, maybe that is it. If you have the time, can you retry with the latest version?
I’ll also write some python to that runs a TCP server echoing that message, and see if it breaks my code 
Greetings,
Reinder
Moin Reinder,
Github says, that my fork is 09d2921 (3 days old) and in sync. But if I look at your repo, this is false, because your repo is b4a6ffd, last updated yesterday. Curious, after logout and login it is ok. I will try it.
Greetings, Tom
Moin Tom,
You need to update your fork manually I think that isn’t done automatically as far as I know. (I don’t have much experience with that…)
It works using a Python dummy server:
Greetings,
Reinder
Moin Reinder,
Yes, I know, but Github means I were in sync. Must logoff and logon.
I start the server and than the client:
Enable the communication:
2026-04-02 23:03:22.185856 traintastic I1001: Traintastic v0.4.0-dev
2026-04-02 23:03:22.185908 traintastic I1006: boost 1.81.0
2026-04-02 23:03:22.185917 traintastic I1007: nlohmann::json 3.10.5
2026-04-02 23:03:22.185933 traintastic I1008: libarchive 3.6.2 zlib/1.2.13 liblzma/5.4.1 bz2lib/1.0.8 liblz4/1.9.4 libzstd/1.5.4
2026-04-02 23:03:22.185944 traintastic I1009: zlib 1.2.13
2026-04-02 23:03:22.185952 traintastic I9002: Lua 5.4.4 Copyright (C) 1994-2022 Lua.org, PUC-Rio
2026-04-02 23:03:22.186035 settings N1008: Loaded settings
2026-04-02 23:03:22.186067 traintastic I1005: Building world index
2026-04-02 23:03:22.197450 script_1 N9001: Starting script
2026-04-02 23:03:22.197893 traintastic N1027: Loaded world: Ferbach-Laubach
2026-04-02 23:03:22.197969 server N1005: Discovery enabled
2026-04-02 23:03:22.197989 server N1007: Listening at 127.0.0.1:5740
2026-04-02 23:03:24.499963 client[127.0.0.1:56480] I1003: New connection
2026-04-02 23:04:34.501802 world N1012: Communication: enabled
2026-04-02 23:04:34.502218 cbus_2 E1007: Socket read failed (Bad address)
Click on green run arrow:
2026-04-02 23:04:34.501802 world N1012: Communication: enabled
2026-04-02 23:04:34.502218 cbus_2 E1007: Socket read failed (Bad address)
2026-04-02 23:05:39.482431 world N1016: Running
The checkmark for Online is not active:
I have to click the online checkmark several times until it stays.
2026-04-02 23:08:32.206152 cbus_2 E1007: Socket read failed (Bad address)
2026-04-02 23:08:33.094164 cbus_2 E1007: Socket read failed (Bad address)
2026-04-02 23:08:33.701826 cbus_2 E1007: Socket read failed (Bad address)
2026-04-02 23:08:34.146515 cbus_2 E1007: Socket read failed (Bad address)
2026-04-02 23:08:36.615410 cbus_2 E1007: Socket read failed (Bad address)
2026-04-02 23:08:36.986833 cbus_2 E1007: Socket read failed (Bad address)
2026-04-02 23:08:37.290270 cbus_2 E1007: Socket read failed (Bad address)
2026-04-02 23:08:37.754598 cbus_2 W2001: Received malformed data dropped 48 bytes
During this test the telnet connection and JMRI Hub are open and every 5s I see the current message of CANCMDB with telnet and JRMI.
Hope that helps!
Greetings, Tom
Moin Tom,
It helps, but I’m still confused, I build a few protocol implementations that uses sockets and never had these issue. I’m going to try to run JMRI, I’d hope I can run the Hub without being connected to a real CBUS. See if I can reproduce and maybe I’ll need WireShark to double check the data that is sent/received.
Greetings,
Reinder
Moin Tom,
Just fired up JMRI using MREG+Simulation and enabled the Hub:
It works…
Greetings,
Reinder
Moin Reinder,
with the hardware not 
I made a tcpdump, beginning with the start of Traintastic.
traintastic.pcap.txt (11.7 KB)
Greetings, Tom
Moin Reinder,
I just test MMC-Server with JMRI CBUS Hub. This runs without problems:
I wrote a small test prg to check, if some other errors exists:
tom@amarok:~/projects/linux/samples/boosttcp$ ./main
Connected to 127.0.0.1:5550
:SBFE0ND0FFFE00010000;:SBFE0ND0FFFE00010000;:SBFE0ND0FFFE00010000;
The code:
#include <iostream>
#include <boost/asio.hpp>
using boost::asio::ip::tcp;
int main()
{
try {
boost::asio::io_context io;
tcp::socket socket(io);
tcp::endpoint endpoint(
boost::asio::ip::make_address("127.0.0.1"), 5550);
socket.connect(endpoint);
std::cout << "Connected to 127.0.0.1:5550" << std::endl;
while (true) {
char data[1024];
boost::system::error_code ec;
std::size_t length = socket.read_some(
boost::asio::buffer(data), ec
);
if (ec == boost::asio::error::eof) {
std::cout << "\nConnection closed by server." << std::endl;
break;
} else if (ec) {
throw boost::system::system_error(ec);
}
std::cout.write(data, length);
std::cout.flush();
}
} catch (std::exception& e) {
std::cerr << "Error: " << e.what() << std::endl;
}
}
Compiled with g++ -std=c++17 main.cpp -o main -pthread
Just for your info.
Greetings, Tom
Moin Tom,
It is a weird issue, I checked the PCAP communication, it seems all correct. I even wrote a WireShark protocol dissector for CBUS/VLCB to make my life a bit easier
Your C++/boost output seems fine too, I have no clue what is wrong yet. I’d hope I’m able to reproduce with the JMRI+CANUSB once the CANUSB arrived. I thin I need to dig deeper what the causes can be of the Bad address read error.
Other thing, I can add a Hub feature as well to Traintastic, than you can run Traintastic and MMC at the same time Would that be useful?
Greetings,
Reinder
Moin Reinder,
that would be fantastic! So we don’t need JMRI and we could configure all the nodes with MMC. One program for every job, the Unix philosophy
I will do some testing with the start() function in cbuscanetheriohandler.cpp
Greetings, Tom
I’ll add it This might be useful for other protocols as well (e.g. OpenLCB/LCC in the future).
I will do some testing with the
start()function incbuscanetheriohandler.cpp
Thanks, do you run a debug build of Traintastic? If so you can also add some additional LOG_DEBUG(...) macro’s to log some additional values that could help.
Greetings,
Reinder
Nice @reinder
Was hoping to bring it up later if we have some of the fundamentals sorted.
Usually 5550 is the standard port for Cbus eth and or jmri hub
Also means I can change the docs 
Moin Reinder,
I’m getting desperate with GitHub! GitHub keeps claiming my fork is in sync, but it isn’t. As a result, I’ve been missing updates for four days, including this one, and this was the cause:
[cbus] fix: ASCIIIOHandler m_readBufferOffset wasn't initialized
I found it myself with debugging and after that I view in your repo where I see that it is initialized. Why Github says, that my fork is in sync?
Now the problem with the Online checkmark is also gone.
Greetings, Tom
Moin,
could I disable this?
My decoders have these parameters, so it’s kind of redundant. When I accelerate in the throttle, Traintastic very slowly increases the speed.
Greetings, Tom
Usually 5550 is the standard port for Cbus eth and or jmri hub
Also means I can change the docs
I’ll set the default port to 5550. The docs will need some changes indeed, I’ll have a look later this week.
I’m getting desperate with GitHub! GitHub keeps claiming my fork is in sync, but it isn’t. As a result, I’ve been missing updates for four days, and this was the cause;
Ah, mistery solved! Where does it state it is in sync on the GitHub website, or local on your system?
Now the problem with the Online checkmark is also gone.
Great, at @MZwa can you also verify/confirm with the latest build?
Disabling is currently not an option, I have to add that. You could set them to 10,00 the maximum for now.
When using the traintastic throttle you can press ctrl while changing speed to force immidiate speed change (a option to have that by default would be nice). The WebTrottle already has that.
Greetings,
Reinder
Lets give this new build a try ( 1949 ) on canEther via Jmri CBUS.
Will re-run via USB direct.
first:
Do you recognize this error after update/install?
Download is performed unsandboxed as root as file '/root/traintastic-server_0.4.0~ubuntu~noble~cbus~1949~4c4ca76e_amd64.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
After install of packages: my own world files gone 
… i know how to get that back, been there
It looks like i only see 1 board detected and no log entries of failures.
Food for thought:
If you have powered off in the GUI, should we present the world of sensors in dark → no info?
Reason: I just powered on and everything seems fine..
Except it is not → ghosts + some sensors seem to have lost reference to their CBUS nodes ( potentially due to switching from USB ↔ Ether while deleting the interface in previous versions … )
… that might be my wrongdoing but in this case slightly confusing?
Restored all the connections ( sensors on CBUS → sensors in world )
World powered off:
What makes even less sense to me:
World is powered on, track power is switched off at the command station
Expectation: no power to tracks → sensors should not be showing occupancy.
Block East 2 shows YELLOW with a train; except there is no longer a train defined 
After checking ports + screens no port 5550 up and no quick visible spots where to configure. I may be holding it wrong / be to early to ask
User root is only for system administration, not for software development! The warning tells you a security issue and the file couldn’t access from other users.
The trains remain stationary on the tracks even without power. If the sensors are independent of DCC, why shouldn’t anything be displayed? It is even an advantage over control with DCC that switch positions, occupancy information, etc. can be displayed.
Greetings, Tom
Lets retry this with via CanUSB…
How hard would it be to allow
⚡ root@dcc-master ~ ls -la /dev/ttyACMCANUSB4
lrwxrwxrwx 1 root root 7 Mar 30 21:07 /dev/ttyACMCANUSB4 -> ttyACM0
⚡ root@dcc-master ~
Especially if you have multiple devices ( DCC-EX, CAN-USB, hand-rolled sensors/ CMRI / Servo controllers etc ) the bouncing around of devices becomes problematic [ been there … ]
I know this is an advanced topic but if at least Traintastic would be kind anough to work with symlinks if if where to filter based on /dev/ttyACM* …
JMRI allows that naming scheme without hiccups.
Bigger problem:
I changed my CANUSB from ethernet to /dev/ttyACM0. Ofourse it fails to come online. Fine; Save & reboot so nothing claims the port.
Surprise: Traintastic fails to start and it is the only thing that is claiming USB ports.
Nothing special in the logfiles:
=== Traintastic v0.4.0-cbus-1949-4c4ca76e
2026-04-06;01:02:20.547945;traintastic;I1001;Traintastic v0.4.0-cbus-1949-4c4ca76e
2026-04-06;01:02:20.548068;traintastic;I1006;boost 1.83.0
2026-04-06;01:02:20.548082;traintastic;I1007;nlohmann::json 3.10.5
2026-04-06;01:02:20.548129;traintastic;I1008;libarchive 3.7.2 zlib/1.3 liblzma/5.4.5 bz2lib/1.0.8 liblz4/1.9.4 libzstd/1.5.5
2026-04-06;01:02:20.548148;traintastic;I1009;zlib 1.3
2026-04-06;01:02:20.548157;traintastic;I9002;Lua 5.4.6 Copyright (C) 1994-2023 Lua.org, PUC-Rio
2026-04-06;01:02:20.548256;settings;N1008;Loaded settings
2026-04-06;01:02:20.548300;traintastic;I1005;Building world index
=== Traintastic v0.4.0-cbus-1949-4c4ca76e
2026-04-06;01:02:20.732681;traintastic;I1001;Traintastic v0.4.0-cbus-1949-4c4ca76e
2026-04-06;01:02:20.732806;traintastic;I1006;boost 1.83.0
2026-04-06;01:02:20.732822;traintastic;I1007;nlohmann::json 3.10.5
2026-04-06;01:02:20.732875;traintastic;I1008;libarchive 3.7.2 zlib/1.3 liblzma/5.4.5 bz2lib/1.0.8 liblz4/1.9.4 libzstd/1.5.5
2026-04-06;01:02:20.732898;traintastic;I1009;zlib 1.3
2026-04-06;01:02:20.732910;traintastic;I9002;Lua 5.4.6 Copyright (C) 1994-2023 Lua.org, PUC-Rio
2026-04-06;01:02:20.733034;settings;N1008;Loaded settings
2026-04-06;01:02:20.733090;traintastic;I1005;Building world index
=== Traintastic v0.4.0-cbus-1949-4c4ca76e
2026-04-06;01:02:20.984333;traintastic;I1001;Traintastic v0.4.0-cbus-1949-4c4ca76e
2026-04-06;01:02:20.984483;traintastic;I1006;boost 1.83.0
2026-04-06;01:02:20.984499;traintastic;I1007;nlohmann::json 3.10.5
2026-04-06;01:02:20.984550;traintastic;I1008;libarchive 3.7.2 zlib/1.3 liblzma/5.4.5 bz2lib/1.0.8 liblz4/1.9.4 libzstd/1.5.5
2026-04-06;01:02:20.984571;traintastic;I1009;zlib 1.3
2026-04-06;01:02:20.984583;traintastic;I9002;Lua 5.4.6 Copyright (C) 1994-2023 Lua.org, PUC-Rio
2026-04-06;01:02:20.984701;settings;N1008;Loaded settings
2026-04-06;01:02:20.984754;traintastic;I1005;Building world index
=== Traintastic v0.4.0-cbus-1949-4c4ca76e
2026-04-06;01:02:21.236941;traintastic;I1001;Traintastic v0.4.0-cbus-1949-4c4ca76e
2026-04-06;01:02:21.237059;traintastic;I1006;boost 1.83.0
2026-04-06;01:02:21.237075;traintastic;I1007;nlohmann::json 3.10.5
2026-04-06;01:02:21.237135;traintastic;I1008;libarchive 3.7.2 zlib/1.3 liblzma/5.4.5 bz2lib/1.0.8 liblz4/1.9.4 libzstd/1.5.5
2026-04-06;01:02:21.237159;traintastic;I1009;zlib 1.3
2026-04-06;01:02:21.237172;traintastic;I9002;Lua 5.4.6 Copyright (C) 1994-2023 Lua.org, PUC-Rio
2026-04-06;01:02:21.237298;settings;N1008;Loaded settings
2026-04-06;01:02:21.237375;traintastic;I1005;Building world index
=== Traintastic v0.4.0-cbus-1949-4c4ca76e
2026-04-06;01:02:21.485090;traintastic;I1001;Traintastic v0.4.0-cbus-1949-4c4ca76e
2026-04-06;01:02:21.485207;traintastic;I1006;boost 1.83.0
2026-04-06;01:02:21.485223;traintastic;I1007;nlohmann::json 3.10.5
2026-04-06;01:02:21.485282;traintastic;I1008;libarchive 3.7.2 zlib/1.3 liblzma/5.4.5 bz2lib/1.0.8 liblz4/1.9.4 libzstd/1.5.5
2026-04-06;01:02:21.485305;traintastic;I1009;zlib 1.3
2026-04-06;01:02:21.485318;traintastic;I9002;Lua 5.4.6 Copyright (C) 1994-2023 Lua.org, PUC-Rio
2026-04-06;01:02:21.485483;settings;N1008;Loaded settings
2026-04-06;01:02:21.485549;traintastic;I1005;Building world index
traintastic.txt (END)
and no service start:
✘ ⚡ root@dcc-master /var/opt/traintastic/log systemctl status traintastic-server.service accounts-daemon.servic
Unit accounts-daemon.servic.service could not be found.
× traintastic-server.service - Traintastic server daemon
Loaded: loaded (/usr/lib/systemd/system/traintastic-server.service; enabled; preset: enabled)
Active: failed (Result: signal) since Mon 2026-04-06 01:02:21 AEST; 1min 9s ago
Duration: 61ms
Process: 3144 ExecStart=/opt/traintastic/bin/traintastic-server -d -u traintastic -g traintastic -D /var/opt/traintastic -P (code=exited, status=0/SUCCESS)
Main PID: 3146 (code=killed, signal=SEGV)
CPU: 77ms
Apr 06 01:02:21 dcc-master.cook-rd.internal systemd[1]: traintastic-server.service: Scheduled restart job, restart counter is at 5.
Apr 06 01:02:21 dcc-master.cook-rd.internal systemd[1]: traintastic-server.service: Start request repeated too quickly.
Apr 06 01:02:21 dcc-master.cook-rd.internal systemd[1]: traintastic-server.service: Failed with result 'signal'.
Apr 06 01:02:21 dcc-master.cook-rd.internal systemd[1]: Failed to start traintastic-server.service - Traintastic server daemon.
✘ ⚡ root@dcc-master /var/opt/traintastic/log
IMHO: If you cut all track power, any DTC4 should not be able to detect any power differential useage → sensor should go to false
Moreover: i am installing a thing → generally apt install requires root right. Unless i am holding it fundamentally wrong?
Apologies if i am going to be the pain in your sides for attempting things that might break stuff → ultimately i hope it will make traintastic better
Traintastic shows a block red/green based in the reported sensor values, this in independent of the track signal, there are systems that can detect a train even if there is no track power. Blocks are yellow if they are reserved by a train. A train must always in at least one block. Normally if a block goes from “red” to “green” the train has left the block (if it is the tail block), if a train is in a single block and it goes “green”, the block stays “yellow”, else the train would be vanished, you have to explicitly remove a train in that case. Else trains could disappear easily e.g. due to bad contact causing sensor triggering.
It looks like i only see 1 board detected and no log entries of failures.
Can you enable communication debug logging? That will help to see what is missing.
some sensors seem to have lost reference to their CBUS nodes ( potentially due to switching from USB ↔ Ether while deleting the interface in previous versions … )
If you delete an interface all linked sensors are lost, as the interface no longer exists.
After checking ports + screens no port 5550 up and no quick visible spots where to configure. I may be holding it wrong / be to early to ask
Do you mean for the Hub feature? It is not yet available, still working on it, it might take a few days (depending on how much time I have), I’m working on a more generic solution that I can reuse for other CAN based protocols as well (e.g. MarklinCAN and future OpenLCB/LCC)
Greetings,
Reinder