Trouble connecting BlueROV2 to Windows version of Cockpit

Blue Robotics Software Cockpit
1

I’m having trouble connecting to the windows version of cockpit. Main issue seems to be editing the vehicle network connection (global address) setting under Settings/General.

This is set to ‘http:/blueos-avahi.local’ but doesnt connect to the vehicle. I tried changing it to the vehicle IP address 192.168.2.1 but it doesnt seem possible to edit this setting? When I click on reset to default I get an error message saying ‘The address should not include protocol (eg."http://, “ws.//”)’. This is weird because the default address which I cannot change includes http://.

The vehicle connects fine using the browser page blueos.local and the browser version of cockpit works fine too.I’m using BlueOS version 1.3.1 and have the latest versions of cockpit (browser and binary).

2

I think there’s a bug on the default address for the standalone version.

The address should indeed not include the protocol, so I recommend trying blueos-avahi.local in this case.

Another thing: the vehicle is usually on 192.168.2.2, not 192.168.2.1. You can also check the vehicle IP by opening BlueOS and clicking the wifi/eth icon in the top-right corner.

3

Many Thanks Rafael, for some reason it was difficult to edit the default address, think I was trying to click and drag but eventually got rid of the http and works great now.

This version of cockpit is very impressive already :+1: - only drawback so far has been with the SonarView extension within an iframe widget which remains visible when changing views although does dissapear when cycling through views after a while.

Also, cannot figure out how to view the BR Ping 1D Sonar within cockpit/iframe - do I need to use it’s udp address or something? The Cerulean Ominiscan sonar extension works fine in an iframe (apart from the ‘stickiness’ issue above) and being able to add the BlueOS mainpage as a seperate cockpit view using iframe is VERY COOL!!!

Interstingly found the windows version of cockpit seems to work fine on a very low spec fanless mini pc which is great as lugging a laptop around in the field/boat is not. Not sure how stable it will be but coupled with a cheap 15" 5V touch screen, nReal AR glasses and wireless xbox controller should make for a useful topside setup.

EDIT - minipc worked fine on the bench but not when putting the ROV in the water. Issue seems to be the graphics/video processing.

3 Likes
4

@rafael.lehmkuhl

The address should indeed not include the protocol, so I recommend trying blueos-avahi.local in this case.

Why this suggestion? Is there some reason to prefer the host’s avahi service rather than the mdns service in Beacon?

5

Actually the Beacon service is who announces the mdns, while the system avahi service is who’s discovering (at least that’s my understandment, I’m not an avahi specialist).

You can use the IP directly (that’s always the preferred way, since no one has to solve the mdns in this case), as well as blueos.local or blueos-avahi.local. I recommended the latter as it’s the primary mdns on BlueOS (it solves for ETH, WIFI and USBC interfaces).

6

Yes, avahi is used to both advertise and to discover MDNS - I’m only talking about the advertising part here.

The beacon service advertises blueos.local, blueos-wifi.local, blueos-hotspot.local[1].
The avahi daemon is advertises blueos-avahi.local[2].

I guess my question is twofold:

  1. Why do we even have MDNS hostnames assigned per-interface since, at least for Cockpit, you don’t recommend them?
  2. Why doesn’t Beacon advertise a MDNS name that is interface-independent?

  1. BlueOS/core/services/beacon/main.py at 3b6cd4c00a9d044de026c25991ae8b2d57c268d6 · bluerobotics/BlueOS · GitHub ↩︎

  2. BlueOS/install/network/avahi.sh at 3b6cd4c00a9d044de026c25991ae8b2d57c268d6 · bluerobotics/BlueOS · GitHub ↩︎

7

1: this is from before cockpit.

2: it does: blueos.local (and avahi) should be on all interfaces. The issue we have is that most systems will accept and resolve MDNS addresses for networks they are not configured to. In my case, my desktop will happily resolve ‘blueos.local’ to 192.168.2.2 even though the network interface receiving this is not configured for that subnet. This means nothing happens when I try to open http://blueos.local

Adding more specific address allows to target individual interfaces/ips when/if we have to.

The truth is that we don’t have a good solution for this problem yet.

1 Like
8
  1. That it’s before cockpit is besides the point - I was just using cockpit as an example of supposed best practice.
  2. In theory, that shouldn’t happen, and it sounds like maybe a misconfiguration (e.g. incorrect DHCP info inside of docker - does this happen with blueos-avahi which is advertised from outside of Docker?).

When a Multicast DNS responder sends a Multicast DNS response message containing its own address records, it MUST include all addresses that are valid on the interface on which it is sending the message, and MUST NOT include addresses that are not valid on that interface (such as addresses that may be configured on the host’s other interfaces).[1]

There might also be another issue like the ones called out by the later sections 14,15 - Considerations for Multiple Interfaces, Considerations for Multiple Responders on the Same Machine. Indeed, we do have multiple responders. It also sounds like the issue could be bad bridging of networks by Docker or maybe something with dnsmasq.

  1. RFC 6762 - Multicast DNS ↩︎

9

This is puzzling to me and specifically seems to not be the case. I see blueos on only the wired interface, not the wireless interface when I look at the Beacon REST API. Also, it looks like there’s logic to override the hostname specifically for WIFI and HOTSPOT interfaces: BlueOS/core/services/beacon/main.py at a584c2a6b0ef6bd4f099cc1c4961246003daad85 · bluerobotics/BlueOS · GitHub