Enabling Dbus over TCP bricked Cerbo-GX

[robtor-de]

I have enabled dbus over tcp like described in Readme.md, but then after a reboot of the cerbo-gx didn't boot anymore.

[sbender9]

Are you it’s bricked? You’re not able to ssh into it any more?

[robtor-de]

Yes I'm abaolutely Sure, it showed only a Black screen and the VE.Bus connected MultiPlus-II Stopped working as well

Tomorrow I will try again to make the modifications to the dbus configuration file

I have alreasy fixes the cerbo by installing the Venus OS via sdcard image

[mpvader]

Hey @robtor-de , just jumping in here: how do you mean that the MultiPlus-II stopped working as well? It switched off at some point (what point?)

[robtor-de]

I wasn't there when the MultiPlus-II switched off, i think that was because the cerbo din't start anymore. When plugging of the cerbo from the MuliPlus by removing the VE.bus cable and restarting it it began with normal operation.

[robtor-de]

I tried it again today, the Cerbo isn't booting anymore as well. It only shows a blank black screen and the red led is flashing.

This step is what i've done and modified before the brick:
4. enable d-bus over tcp in your Venus device if you want to use dbus over TCP, otherwise skip this step. Edit /etc/dbus-1/system.conf and add the following directly above :

tcp:host=0.0.0.0,port=78
ANONYMOUS
<allow_anonymous/>

[robtor-de]

I Google a little bit and found this thread:
https://stackoverflow.com/questions/10158684/connecting-to-dbus-over-tcp

Tomorrow I will try again and put the <Listen... directive before the unix Socket Listen directive in the configuration file... maybe then it will work

[robtor-de]

I gave it another try today, after modifying /etc/dbus-1/system.conf the Cerbo only shows the orange wifi-led flashing and a black screen

[mpvader]

Hi, that the WiFi doesn't work is expected. It needs codes that were on the data partition before you ran the installer image. Installer-image erases the whole device. So note that, once this is all done, you'll also need to restore those files. Details about those files are here: https://www.victronenergy.com/live/venus-os:extended#appendix_a_-_repartitioning_venus_gx_flash_memory (step B)

Why it doesn't boot is a mystery to me. But then again, I've never tried this on a Cerbo, and also haven't recently tried what happens when trying to boot without those files present, other than the wifi not working.

One way to figure it out is if you can connect a serial console. Like this one: https://www.adafruit.com/product/954.

Would that work for you?

[mpvader]

Btw I'll update the readme section of this project where it explains how to modify the dbus config file, to explain that changing the dbus config is at ones own peril. I thought it had the required disclaimers, but I see now that it does not; at least not clearly.

The good news is that it is impossible to completely brick a device that way. But it does need to clearly state that fixing issues arising after this are not within normal Victron support. There are not a lot of people inside Victron that will know what to do with this.

[robtor-de]

I think the disclaimers aren't the problem, I clearly understood that doing this is at my own risk, thatswhy I started the issue here and didn't wrote directly to the victron support.

Maybe I will connect to the serial console if i have enough time for doing that to figure out, why enabling tcp support in dbus breaks the system.

[robtor-de]

I think the serial console would be the only way possible to gather some information because when the device crashes it's even not available via ssh although its connected to ethernet.

Might the <listen tcp.... statement crash the complete dbus system?

And maybe I also have to add that I'm not running the large image with nodered installed, that's the reason why I have to enable the tcp support, because the nodered is running on an already existing sever in my network

Is there a possibility to restart the dbus on the cerbo-gx during runtime to retrieve log messages?

[mpvader]

Hi, disclaimers: yes no problem for you - but might be some day. This thread just reminded me of them. Maybe I went a bit overboard though 😄, here is the new section.

Might the <listen tcp.... statement crash the complete dbus system?

Yes, thats exactly what happens when put in the wrong place or wrong way. But I don't see what you're doing wrong here. (And I can't test it myself now - sorry).

Is there a possibility to restart the dbus on the cerbo-gx during runtime to retrieve log messages?

Possibly yes. Or try run a second instance. Restarting it might cause a watchdog reboot, so that is not so very easy I think. But maybe it is; I'm no expert.

The commit that added the watchdog monitoring is here:
victronenergy/meta-victronenergy@7bfdbb6#diff-8e56f3a9652f31c88a78dcd60f20c05a

[robtor-de]

Thank you for the information, and yes it makes sense to update the disclaimer ^^
I will play around with these things the next week and give you an update if I figure something out

[robtor-de]

Is there an option to Backup the whole cerbo gx System with all its settings?
If possible I will try again to enable dbus over TCP, and if it doesn't Boot anymore I could just restore the old Installation

[3dGrabber]

I have enabled dbus over tcp [...] didn't boot anymore.

Been there.
Dbus config is a bthc...

For starters, the order of the config lines matters!
https://stackoverflow.com/questions/10158684/connecting-to-dbus-over-tcp/13275973#13275973

If dbus fails to init,
conmand cannot start
sshd depends on conmand, so does wifi.
And of course, all the Victron drivers and services depend on dbus.

So, I don't think your Cerbo is truly bricked.
However you'll probably need physical access to be able to get it back running.

[3dGrabber]

Here is my system.conf

<!-- IMPORTANT
This is a modified dbus config file for venus.
It allows remote connections to the dbus via tcp:55555
Obviously this has security implications.
It is intended for development/testing purposes and should not be used in production.
I have tested this config and "it works on my machine", but there
is a possibility that it breaks on yours. In this case, the venus
device might loose its network connection and become unreachable.
Use at your own risk!
Best try it first on a device where you have physical access to.
-->


<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

  <!-- Our well-known bus type, do not change this -->
  <type>system</type>

  <!-- Run as special user -->
  <user>messagebus</user>

  <!-- Fork into daemon mode -->
  <fork/>

  <!-- We use system service launching using a helper -->
  <standard_system_servicedirs/>

  <!-- This is a setuid helper that is used to launch system services -->
  <servicehelper>/usr/libexec/dbus-daemon-launch-helper</servicehelper>

  <!-- Write a pid file (must be the same as init script!) -->
  <pidfile>/var/run/messagebus.pid</pidfile>

  <!-- Enable logging to syslog -->
  <syslog/>

  <!-- Only listen on a local socket. (abstract=/path/to/socket 
       means use abstract namespace, don't really create filesystem 
       file; only Linux supports this. Use path=/whatever on other 
       systems.) -->

  <listen>tcp:host=0.0.0.0,bind=*,port=55555,family=ipv4</listen>
  <listen>unix:path=/var/run/dbus/system_bus_socket</listen>
  <auth>ANONYMOUS</auth>
  <allow_anonymous/>


  <policy context="default">
    <!-- All users can connect to system bus -->
    <allow user="*"/>

    <!-- Signals and reply messages (method returns, errors) are allowed
         by default -->
    <allow send_type="signal"/>
    <allow send_requested_reply="true" send_type="method_return"/>
    <allow send_requested_reply="true" send_type="error"/>
    <allow send_interface="*"/>
    <allow receive_interface="*"/>
    <allow receive_sender="*"/>

    <!-- All messages may be received by default -->
    <allow receive_type="method_call"/>
    <allow receive_type="method_return"/>
    <allow receive_type="error"/>
    <allow receive_type="signal"/>

    <!-- Allow everything to be sent -->
    <allow send_destination="*" eavesdrop="true"/>
    <!-- Allow everything to be received -->
    <allow eavesdrop="true"/>
    <!-- Allow anyone to own anything -->
    <allow own="*"/>

    <!-- Allow anyone to talk to the message bus -->
    <allow send_destination="org.freedesktop.DBus"/>
  </policy>

  <limit name="max_match_rules_per_connection">1024</limit>
  <limit name="max_replies_per_connection">50000</limit>
</busconfig>

[robtor-de]

Thank you for your extensive answer, I've already researched for the correct order of appending the line but it dindn't worked as well. Maybe it was my own mistake.

Until today I've restored the Cerbo-GX already by reinstalling venus os via sdcard.

I'm not at home today but next week I will compare mine with your system conf.

---

Many thanks

[mpvader]

closing this; having to do this dbus-tcp modding by hand is risky and annoying, but its just the way it is for now.

[robtor-de]

Alright, i've found another solution so far

[xises]

The same thing has happened to me that you could give me the solution if possible
Thanks

[mpvader]

Hi @xises sorry to hear this happened for you. Please go to https://community.victronenergy.com and then the modifications area. Search there, I would expect there is an explanation on how to recover. And if you can’t find it, open a new question