Cannot access BlueOS web interface (192.168.2.2) — ping succeeds, browser and SSH fail

SYSTEM SPECIFICATIONS
BlueOS version
1.4.0-beta.4
Image
arm64-v8 / bookworm
Host OS
Ubuntu (Linux)

Target IP
192.168.2.2
Connection method
Ethernet
BlueOS image download link
https://github.com/bluerobotics/BlueOS/releases/download/1.4.0-beta.4/BlueOS-raspberry-linux-arm64-v8-bookworm.zip
PROBLEM DESCRIPTION

I am unable to access the BlueOS web interface at 192.168.2.2 via browser, and I cannot SSH into the device. I have completed the standard network interface configuration (set host adapter IP to 192.168.2.1 / 255.255.255.0).

The device responds to ICMP ping, which confirms the network layer is functional, but all HTTP and SSH traffic is unresponsive.

SYMPTOMS

  1. Ping succeeds:

ping 192.168.2.2
PING 192.168.2.2: 56 data bytes
64 bytes from 192.168.2.2: icmp_seq=0 ttl=64 time=X ms

  1. Browser: Page does not load at http://192.168.2.2 — connection hangs with no response.

  2. SSH: Cannot SSH into the device. Connection attempt times out or is refused.

no response — hangs here

TROUBLESHOOTING STEPS ALREADY ATTEMPTED

  1. Verified ethernet adapter is configured with IP 192.168.2.1 and subnet mask 255.255.255.0.

  2. Confirmed ping to 192.168.2.2 is successful — network layer is reachable.

  3. Tried multiple browsers (no change).

  4. Cannot SSH into the device to inspect Docker container status or logs.

QUESTIONS

— Could this be caused by the BlueOS web server (nginx/Docker containers) failing to start or crashing silently after boot?

— Is this a known issue with BlueOS 1.4.0-beta.4 on the bookworm image?

I attach my connection setting in the image

I can connect to 192.168.2.2 by web browser for three hours. then after three hours, the connection keep comes and goes. Now I can’t access it through the browser. I did’nt unplug the battery the whole time since it shows the battery is about 70% full.

and I don’t want to unplug the battery for debugging cuz all of the stuffs I install by apt-get install in ROS2 extension will gone…..

Hi @Zi-Hao -

Sorry for the issues!

BlueOS 1.4 beta 4 is VERY old - I’d recommend updating to 1.4.3 stable ASAP! That may fix many of your network issues - you can do so within BlueOS, or by re-flashing your SD card. Backup your parameters file first!

I’ve never seen the system respond to pings but not load the webpage or respond to ssh. Is the blue light flashing on the Navigator on the Pi?

What OS are you using on your topside computer? Could it be blocking access to the vehicle via firewall?

If you’re relying on installing things in docker containers to work on your application, and thus lose your progress on every restart, you’re definitely doing things in “hard mode” ! I’d suggest setting up a BlueOS extension that has the dependencies you’d like installed, or using one of the existing ROS extensions? That will prevent you from needing to re-install things so often - which is definitely a hassle that shouldn’t be undertaken during a deployment….

It’s really quite easy to do, especially with the help of a LLM (pointed at the docs and example repos.) Let us know if you get stuck in the process!

Hi @tony-white — thanks so much for the quick response!
Topside is ubuntu.
As for the Navigator blue light , it blinks when the power is on.

On the extension workflow: yes, this is exactly the root of our problem and I think we’ve now identified the right path forward. We were apt-installing build tools and compiling our ROS workspace directly inside the running ROS extension container, which of course gets wiped on every power cycle. On top of that, building a full ROS workspace on the Pi was clearly hammering the CPU , we actually suspect that caused the instability and the connectivity issues we saw (the system needed time to cool down before it recovered).
the link for the extension that we use: GitHub - itskalvik/blueos-ros2: The BlueOS ROS 2 Extension bridges ROS 2 with BlueOS, enabling streamlined control, sensor integration, and real-time data visualization for ArduPilot-based vehicles such as the BlueBoat and BlueROV2. · GitHub
After discussing with my colleague, we’re planning to move to the proper workflow:

  • Modify the ROS extension Dockerfile on our development machine to include all dependencies and run the full colcon build at image build time.
  • Push the pre-built image to Docker Hub .
  • Point the BlueOS extension manifest to our custom image, so the Pi only ever pulls and runs , never compiles.
1 Like