Issues with RBOOM connecting to server

Technical Support
21

Hello James,

I’m glad to hear that your Shake&Boom is back online! If you need anything else from us, just let us know.

22

[Forum post draft] Solved: “Your system is currently offline, wait for it to restart” — root cause + permanent fix

(Suggested category: Technical Issues or Hardware Support on community.raspberryshake.org)

Title: Solved: “Your system is currently offline” stuck forever — root-caused (3 bugs) + permanent fix

If your Shake’s web UI shows the red “Your system is currently offline, wait for it to restart or start it up manually” banner — even though community.raspberryshake.org, station.raspberryshake.org, or stationview.raspberryshake.org show your station as online and streaming — this is for you.

I’ve spent the last few hours tracing this through the firmware and found three distinct compounding bugs. The popular workaround sudo docker restart $(docker ps -q) does not actually fix it — it only superficially clears one symptom. The real fix is one command, but unless you know where to look, you won’t find it.

TL;DR — the actual permanent fix


sudo systemctl restart raspberryshake.service

That’s it. Not docker restart. The reason: the Shake’s “system status” flag is set once at boot and never re-checked. If anything failed at boot time (typically DNS), the status stays BOOTING forever, even after the network heals.

If you’re on a mesh router like a TP-Link Deco that’s been reported to cause weird DHCP behaviour, you’ll likely also want to fix /etc/dhcpcd.conf so this doesn’t recur on every reboot — full details below.

What’s actually happening

Three bugs combine to create the symptom:

1. The factory /etc/dhcpcd.conf ships structurally broken

It has lines like static ip_address=192.168.1.144/ (no CIDR prefix length) hardcoded to a subnet most of us aren’t on. dhcpcd hits a parse error (is not a valid CIDR), silently invalidates the entire file, and falls back to managing every interface — including the Docker veth pairs the Shake’s containers create. dhcpcd then assigns IPv4LL (169.254.x.x) addresses to those veths and installs default routes through them.

2. Some routers (notably TP-Link Deco mesh) send an empty routers='' DHCP option

This leaves eth0 with no real default route. The bogus IPv4LL route on a Docker veth is now the only default route — and that’s a dead end. Internet dies.

3. The boot script that flips status from BOOTING to RUNNING runs exactly once

raspberryshake.service (which runs /usr/local/bin/postboot.rshake) checks for internet at boot, and only writes the magic string R-Shake System boot-up sequence completed to /opt/log/postboot.log if it succeeds. The Shake’s web UI looks for that exact string in that exact file — if it’s missing, the device shows BOOTING (and the red “system offline” banner) forever, even with full internet later.

docker restart momentarily tears down a Docker veth, which briefly clears the bogus default route, giving you a window of working internet. But it does not re-run the postboot script, so the BOOTING flag never clears. That’s why so many of us have lived with a misbehaving GUI for so long.

Permanent fix

SSH into your Shake (ssh [email protected], default password shakeme) and run:

Step 1 — fix /etc/dhcpcd.conf (replace the broken factory file with a parseable one):


sudo cp /etc/dhcpcd.conf /etc/dhcpcd.conf.factory-broken

sudo tee /etc/dhcpcd.conf >/dev/null <<EOF

clientid

persistent

option rapid_commit

option domain_name_servers, domain_name, domain_search, host_name

option classless_static_routes

option ntp_servers

require dhcp_server_identifier

slaac private

# Stop dhcpcd managing Docker bridge/veth interfaces

denyinterfaces docker0 veth* br-*

# eth0 — DHCP, but force a gateway if upstream sends empty routers=

interface eth0

static routers=YOUR_GATEWAY_HERE

static domain_name_servers=YOUR_GATEWAY_HERE 1.1.1.1 8.8.8.8

# wlan0 — same fallback

interface wlan0

static routers=YOUR_GATEWAY_HERE

static domain_name_servers=YOUR_GATEWAY_HERE 1.1.1.1 8.8.8.8

EOF

Replace YOUR_GATEWAY_HERE with your router’s LAN IP (usually 192.168.1.1 or 192.168.68.1 — whatever ip route show default reports, or your router’s admin panel address). Then:


sudo systemctl restart dhcpcd

Step 2 — clear stale veth leases:


sudo find /var/lib/dhcpcd5/ -name 'dhcpcd-veth*.lease' -delete

(You’ll likely have hundreds of these from years of container churn.)

Step 3 — re-run the postboot script so the BOOTING flag clears:


sudo systemctl restart raspberryshake.service

This will take a few minutes (the script does NTP sync + software update check + container startup). At the end it may reboot the Shake. Once it comes back, refresh the web UI — the “system offline” banner will be gone.

Verifying it worked

Check the API directly:


curl -s http://rs.local/api/summary | python3 -m json.tool | grep -E "(systemStatus|serverConnected)"

You want to see:


"systemStatus": "RUNNING",

"serverConnected": true,

Why I’m posting this

I emailed [email protected] with the full technical breakdown (filenames, line numbers, the exact broken config), but I wanted to put this on the forum too because operators have been hitting this for years with no real fix. If you’ve been stuck on the “docker restart” treadmill, this should be the last time.

Full technical report (with code references to rfe-2’s app.py:355 and ioutils.py:196, dhcpcd journal excerpts, and the reproduction steps):

:page_facing_up: Raspberry Shake: device stuck in BOOTING after boot-time DNS failure — 3 root causes + fix · GitHub

Reference issue on the public raspishake GitHub (filed for searchability — the firmware itself lives in a private GitLab so there’s no upstream issue tracker for the actual bugs):

:link: [firmware, not rsudp] Shake stuck in BOOTING state forever after boot-time DNS failure — 3 root causes + fix · Issue #90 · raspishake/rsudp · GitHub

To the Shake team if you’re reading

Suggested upstream fixes:

  1. Ship a dhcpcd.conf that actually parses (the current one fails dhcpcd --test with is not a valid CIDR)

  2. Either make raspberryshake.service retry on failure, OR have the front-end surface “raspberryshake.service has been failed for >N minutes” as a diagnostic so operators don’t have to guess

  3. Document sudo systemctl restart raspberryshake.service in support docs — the “docker restart” folklore needs to die

Happy to provide additional repro data (DHCP packet captures, full journals, etc.) — already shared in the support email.

(Verified on: Pi 3B+, RBOOM/SnB, software v0.21.2, rsh-fe-config:v21.2, Raspbian Buster. Reproduced on a TP-Link Deco mesh network. Fix verified end-to-end.)

2 Likes
23

hello Jamest1965,

to let you know: i am very much reading this! this is fantastic work on your part, for which i am very grateful. one reason this has remained outstanding for so long is that in all of our various test environments, this has not been encountered, nor able to be easily recreated (needless to say, in absence of understanding the root cause, it’s pretty difficult to simulate the sets of conditions giving rise to the problem).

thank you again for your time, and especially the detailed feedback. this will be examined in full detail and incorporated to the greatest extent possible in the next release.

warm regards,
richard

1 Like
24

Hi Richard,

your welcome I love the product and look forward to any feedback and willing to provide any further info if required.