VNC Connectivity

[pattacini]

Hi @davidetome

If we launch a docker container via the following command line (as per the instructions)

docker run -it --rm --network host ghcr.io/icub-tech-iit/test-skin-patches:latest

we are unable to connect to VNC.

This is explained by the fact that we should make the port 6080 reachable via:

docker run -it --rm -p 6080:6080 ghcr.io/icub-tech-iit/test-skin-patches:latest

I've tested this second solution and the VNC connection is correctly established.

The option --network (allegedly required to access the USB/CAN device?) and the option -p are mutually exclusive.

Do you have any insights?

cc @gabrielenava

[pattacini]

From the documentation, --network host does the following:

For standalone containers, remove network isolation between the container and the Docker host, and use the host’s networking directly.

So, it should be fine and thus exposes the 6080 to the host as well for connecting via VNC.

Perhaps, it doesn't work ok on Windows systems like mine.
(On Windows systems we also have other problems, see #12)

@gabrielenava, did you test it on a Linux system?

[gabrielenava]

@gabrielenava, did you test it on a Linux system?

no it is Ubuntu 20.04, but still we have a connection failed message when trying to reach locahost:6080 from the browser. The laptop I am trying to configure is one of the iCubGenova04 laptop (icub30) and I have the feeling that the network local settings have been modified in the past for some reasons. In fact, on my personal PC with the same OS I am able to connect to VNC.

with @HosameldinMohamed and @antonellopaolino we tried to debug the issue following the post-installation steps for docker, but nothing worked out.

[pattacini]

Hi @gabrielenava

Did you already try launching the container with the oneliner below that makes use of -p?

docker run -it --rm -p 6080:6080 ghcr.io/icub-tech-iit/test-skin-patches:latest

You won't be able to use the USB/CAN but this is meant just to check if you can connect to VNC on that specific machine.

[antonellopaolino]

Did you already try launching the container with the oneliner below that makes use of -p?

docker run -it --rm -p 6080:6080 ghcr.io/icub-tech-iit/test-skin-patches:latest

You won't be able to use the USB/CAN but this is meant just to check if you can connect to VNC on that specific machine.

Hi @pattacini, I get the following error when trying that command:

docker: Error response from daemon: driver failed programming external connectivity on endpoint jolly_ishizaka (4f34a32b408d343ccbae36e0218d7d078cc83222c8dba838aae5eca24f1cb8ef): Error starting userland proxy: listen tcp4 0.0.0.0:6080: bind: address already in use.

[pattacini]

Hi @antonellopaolino

It seems that the host 6080 port is already in use and thus cannot be bound to the container's 6080 port. To verify this, you may check /etc/services or use lsof¹.

To get around this, it may suffice to find out another unused dynamic port P of the host to bind and replace -p 6080:6080 with -p P:6080 in the oneliner above. Of course, you ought to connect to localhost:P then, from your browser.

Footnotes

1. See https://www.cyberciti.biz/faq/how-to-check-open-ports-in-linux-using-the-cli. ↩

[antonellopaolino]

Using port 6081 it works!

[pattacini]

Thanks heaps for the test @antonellopaolino 👍🏻

When we run the oneliner with --network host I presume that we remap all the ports, but you're already using port 6080 in that specific host.

My next guess would be looking for the host service using 6080 and disabling it (at least temporarily).

[pattacini]

Another possibility could be modifying the following line in the script start-vnc-session.sh within the container to use the port 6081.

test-skin-patches/dockerfiles/start-vnc-session.sh

Line 6 in 8e4210a

/opt/novnc/utils/novnc_proxy --web /opt/novnc --vnc localhost:5901 --listen 6080 > /dev/null 2>&1 & disown

Probably it won't be sufficient as the docker image we built exposes only the port 6080 as per:

test-skin-patches/dockerfiles/Dockerfile

Line 91 in 8e4210a

EXPOSE 5901 6080 10000/tcp 10000/udp

In this latter case, you ought to build your own docker image with the proper customization.

[antonellopaolino]

My next guess would be looking for the host service using 6080 and disabling it (at least temporarily).

I checked and found out it was the dockerd service, so I edited the docker.service options as shown in https://docs.docker.com/engine/install/linux-postinstall/#configuring-remote-access-with-systemd-unit-file, modifying the port from 6080 to 6088. Now I'm able to run without issues the command:

docker run -it --rm -p 6080:6080 ghcr.io/icub-tech-iit/test-skin-patches:latest

But still this other doesn't work:

docker run -it --rm --network host ghcr.io/icub-tech-iit/test-skin-patches:latest

[pattacini]

But still this other doesn't work:

docker run -it --rm --network host ghcr.io/icub-tech-iit/test-skin-patches:latest

Maybe because the port 5901¹ is also mapped onto a port in use on the host.
With --network host we remap all the ports exposed.

Footnotes

1. This port is used by the graphic service under the hood. ↩

[antonellopaolino]

The port 5901 seems not to be in use by other services.

[pattacini]

We may provide support @antonellopaolino but not immediately, unfortunately.

In the meanwhile, you may consider dropping the docker image. I bet your system is superbuild-ready, and if you peruse the docker recipe, you'll find that it takes very little to install the remaining required dependencies¹ and test the skin patches.

Footnotes

1. Of course, you don't need to install the X11 and VNC layers. ↩

[antonellopaolino]

In the meanwhile, you may consider dropping the docker image. I bet your system is superbuild-ready, and if you peruse the docker recipe, you'll find that it takes very little to install the remaining required dependencies1 and test the skin patches.

Indeed it was simple to install the remaining dependencies and I'm now able to test the skin (although not using the docker).

[pattacini]

That's great @antonellopaolino 👍🏻
Happy you managed to get it working. We'll be investigating the docker in the background.