Internet access through the container

Technical Support
, , ,
1

Hello,

I have Apalix imx8 - ixora boards, with Torizon easy pair last version installed on it, and Toradex extension for VS code last version.

I want to send XMLHttpRequest’s from js in QML, but I got 0 response which means that there is no internet connection.

I checked Torizon system ip and I found its: 172.24.x.x, but my device ip is: 192.168.0.41, I think the reason is that the container is running on an isolated private network, but I checked the network_mode in docker-compose.yml file and I found its value: host.

So, Why can’t I access the internet? Is this related to other settings? Why doesn’t the Torizon system take the same IP group?

Best regards,
Tarek

2

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

:handshake:

Hi, Tarek

It seems like there might be a few different issues at play here. Let’s go through some potential causes and solutions:

  1. Network Mode Configuration:

    • Since you mentioned that the network_mode in your docker-compose.yml is set to host, the container should share the host’s network stack. This means it should have the same IP address as the host and access to the same network interfaces.

  2. IP Address Discrepancy:

    • The IP address 172.24.x.x suggests that the container might still be using a bridge network. Ensure that the docker-compose.yml file is correctly configured and that the container is indeed using the host network mode. Double-check for any typos or misconfigurations.

  3. Firewall and Network Policies:

    • Ensure that there are no firewall rules or network policies on your host or within the container that might be blocking outbound traffic.

  4. DNS Configuration:

    • Sometimes, containers might face DNS resolution issues. Ensure that the container can resolve domain names. You can test this by running a simple DNS query inside the container:
      docker exec -it <container_name> nslookup google.com
    • If DNS resolution fails, you might need to configure the DNS settings in your docker-compose.yml or Docker daemon configuration.

  5. Proxy Settings:

    • If your network requires a proxy to access the internet, ensure that the proxy settings are correctly configured both on the host and within the container.

  6. NetworkManager Configuration:

    • Since Torizon uses NetworkManager, ensure that the network interface is correctly configured and that there are no conflicts or misconfigurations. You can use nmcli to check the status and configuration of the network interfaces.

  7. Testing Connectivity:

    • To further diagnose, you can try running a simple connectivity test from within the container:
      docker exec -it <container_name> ping -c 4 8.8.8.8
    • This will help determine if the container can reach external IP addresses.

If all the above checks are in place and the issue persists, it might be helpful to provide more details about your docker-compose.yml configuration and any relevant network settings.

Best regards,
Toradex AI Assistant

3

Hello,

This is my docker-compose.yml file:
docker-compose.yml (2.0 KB)

I’m running my software on the board using:
run-container-torizon-release-arm64

Best regards,
Tarek

4

Greetings @tarekmhnds,

but I checked the network_mode in docker-compose.yml file and I found its value: host.

Where do you see this exactly? In the docker-compose file you provided I see network_mode: host for the Weston container definition. But this isn’t defined anywhere for your container. The network configuration is per-container not for all containers.

Best Regards,
Jeremias

5

Dear Jeremias,

Sorry for the misunderstanding, I have little experience with Docker and containers, I’m new with them.

But, after adding: network_mode: host to my system container: van_sys_container, I got these errors when trying to run my Qt/QML code :

Attaching to van_sys_container-1
van_sys_container-1 | Failed to create wl_display (Connection refused)
van_sys_container-1 | qt.qpa.plugin: Could not load the Qt platform plugin “wayland” in “” even though it was found.
van_sys_container-1 | This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
van_sys_container-1 |
van_sys_container-1 | Available platform plugins are: vkkhrdisplay, wayland-egl, offscreen, minimalegl, xcb, minimal, linuxfb, wayland, eglfs, vnc.
van_sys_container-1 |
van_sys_container-1 exited with code 133

These errors did not happen before.

What could be the possible cause of these errors? How can I solve them please?
I tried but I don’t know how to solve these errors, and what is the reason.

Best regards,
Tarek

6

How exactly did you add network_mode: host? I just did a quick test with the default Qt/QML template in our VSCode extension. If I add network_mode: host to the Qt container I don’t see any errors when running.

Also are you running this in debug or release configuration?

Best Regards,
Jeremias

7

Hi Jeremias,

I added network_mode: host to my program container: van_sys_container, as in the attached file:
docker-compose.yml (2.0 KB)

I’m running my code on Apalis module using:
run-container-torizon-release-arm64
From `Task Runner’ menu in VS code.

Best Regards,
Tarek

8

This is strange on my side with the default Qt/QML application it works fine with the following:

docker-compose.yml 
version: "3.9"
services:
  test-debug:
    build:
      context: .
      dockerfile: Dockerfile.debug
    image: ${LOCAL_REGISTRY}:5002/test-debug:${TAG}
    network_mode: host
    ports:
      # SSH debug
      - 2231:2231
      # gdbserver
      - 2232:2232
      # qml debug
      - 2233:2233
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
    device_cgroup_rules:
      # ... for tty0
      - "c 4:0 rmw"
      # ... for tty7
      - "c 4:7 rmw"
      # ... for /dev/input devices
      - "c 13:* rmw"
      - "c 199:* rmw"
      # ... for /dev/dri devices
      - "c 226:* rmw"
    depends_on: [
      weston
    ]

  test:
    build:
      context: .
      dockerfile: Dockerfile
    image: ${DOCKER_LOGIN}/test:${TAG}
    network_mode: host
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
    device_cgroup_rules:
      # ... for tty0
      - "c 4:0 rmw"
      # ... for tty7
      - "c 4:7 rmw"
      # ... for /dev/input devices
      - "c 13:* rmw"
      - "c 199:* rmw"
      # ... for /dev/dri devices
      - "c 226:* rmw"
    depends_on: [
      weston
    ]

  weston:
    image: torizon/weston${GPU}:3
    environment:
      - ACCEPT_FSL_EULA=1
    # Required to get udev events from host udevd via netlink
    network_mode: host
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
      - type: bind
        source: /run/udev
        target: /run/udev
    cap_add:
      - CAP_SYS_TTY_CONFIG
    # Add device access rights through cgroup...
    device_cgroup_rules:
      # ... for tty0
      - "c 4:0 rmw"
      # ... for tty1
      - "c 4:1 rmw"
      # ... for tty7
      - "c 4:7 rmw"
      # ... for /dev/input devices
      - "c 13:* rmw"
      - "c 199:* rmw"
      # ... for /dev/dri devices
      - "c 226:* rmw"

This works without issue for me on both debug and release. Are you sure your most recent error was caused by the addition of network_mode: host? That would not make much sense at all. All this configuration does is make it so that the container uses the same network stack as the host OS (i.e same ports and IP address). I don’t see how this would cause the Qt application itself to fail in the way you showed.

Best Regards,
Jeremias

9

Hi Jeremias,

I compared my docker-compose.yml with yours, they are exactly the same.

I started also from default Qt/QML application, and modified it to make my program.

For the errors, I’m sure that they are happened when adding: network_mode: host to: docker-compose.yml, because when I remove these lines everything compile and run without any problems.

So, do you have any other ideas please? or any solutions please?
Any help would be appreciate.

Thanks a lot

Best regards,
Tarek

10

For the errors, I’m sure that they are happened when adding: network_mode: host to: docker-compose.yml, because when I remove these lines everything compile and run without any problems.

So wait is the issue specific to your application? For example if you create a completely fresh Qt/QML project and just add network_mode: host without modifying anything else, including the hello-world source code. Does that work for you or not?

That is essentially what I did, and I had no issues running the default hello-world code. If you’re having the same issue even with the hello-world code then that would be very strange. It would mean your setup is somehow behaving differently to mine, which wouldn’t make a lot of sense the way I understand this.

Otherwise if for some reason your application has issues with network_mode: host, then your other option would be port-mapping. You can map a port inside the container to a port outside of the container. For example if your application is communicating via port 80 inside the container, you can map this to say port 8080 outside of the container. Then your communication would be available at :8080 in this example. This is explained in more detail in the Docker documentation here: Publishing and exposing ports | Docker Docs

Best Regards,
Jeremias

11

Hi Jeremias,

I found that updating Torizon templates in Torizon extension solved this issue, in Dockerfile, the previous SDK_BASE_VERSION was: 3.2.0, and the new versoin after update is: SDK_BASE_VERSION=3.3.1 , now I can set network_mode: host without any errors.

Also, I found that the container can access the internet even without setting this option in docker-compose.yml file, but the problem was in the Rest api that I call by post request, which is related to ssl, the error: SSL routines::dh key too small but previously I didn’t print it out so I didn’t notice it.

Also, I found if I decrease the default security level in: /etc/ssl/openssl.cnf from 2 to 1 in:
[system_default_sect]
CipherString = DEFAULT:@SECLEVEL=2
It solves this issue, but I don’t want to do that to keep the board secure, and I’m trying to find a solution without decreasing the security level.

Best regards,
Tarek

12

Glad you figured out the general connection issue. Now about your new error:

but the problem was in the Rest api that I call by post request, which is related to ssl, the error: SSL routines::dh key too small

If I understand correctly, this has to do with the REST API you’re trying to contact. If you don’t want to lower the security level I suppose the next best method would be to fulfill the default security requirement. Not sure how much control you have over the REST API, but is it possible to convince the admins of the server where the REST API is coming from to use a sufficiently sized key, as to satisfy this security check?

Best Regards,
Jeremias

13

Hi Jeremias,

I have no control over the REST API, so I reduced the number of bits in the cypher key for this request only, using cypher like: AES128-GCM-SHA256 / protocol: TLSv1.2, and everything worked fine.

Thanks a lot for your help and support.

Best Regards,
Tarek

14

Perfect glad to hear you were able to find a resolution on your side. Is everything here resolved now?

Best Regards,
Jeremias

15

Hi Jeremias,

Yes everything resolved.

Thanks a lot.

Best regards,
Tarek

16

Glad to hear. Happy we were able to help.

Best Regards,
Jeremias