Torizon Quickstart Demo Network Config

I’m stepping through the Torizon Quickstart. I’m on the “Container Hello World on the Command-Line” chapter.

Both the Ixora board and my Ubuntu desktop are connected to the same router.
My router’s config:

  • IP address: 192.168.175.101
  • Subnet Mask: 255.255.255.0
  • Default Gateway: 192.168.175.1
  • Primary DNS: 192168.175.1
  • LAN IP address: 192.168.1.1
  • DNS Proxy: On
  • DHCP Address Range: 192.168.1.102 to 192.168.1.149
    My Ubuntu desktop:
  • IP address: 192.168.1.147

I am not an IP expert, but I do know enough to configure small non-routable networks.
I have no idea how the Torizon Demo comes up with:

  • Subnet: 172.18.0.0/16
  • Default Gateway: 172.18.0.1

and is able to fetch containers over the internet. It’s configuration does not seem compatible with my router.
Moreover, I have no idea how I’m supposed to ssh to the demo.

Could someone please de-mystify what’s going on with the network config in the Torizon Demo, please?

Thank you.

Greetings @cb_cross,

I believe the 172* addresses you are looking at are the default docker IP addresses. To explain the container engine we use, “Docker” sets up bridge networks by default in order to have some semblance of isolation between the container network and the host network. For more details about how Docker handles such network specifics under the hood please see their articles here: Networking overview | Docker Documentation

But for example on my device if I run ifconfig I see the following:

apalis-imx6-05228985:~$ ifconfig
br-00baf6913cd4 Link encap:Ethernet  HWaddr 02:42:0a:17:dd:4c
          inet addr:172.18.0.1  Bcast:172.18.255.255  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

docker0   Link encap:Ethernet  HWaddr 02:42:16:12:74:be
          inet addr:172.17.0.1  Bcast:172.17.255.255  Mask:255.255.0.0
          inet6 addr: fe80::42:16ff:fe12:74be/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:572 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1162 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:32969 (32.1 KiB)  TX bytes:9607770 (9.1 MiB)

ethernet0 Link encap:Ethernet  HWaddr 00:14:2d:4f:c9:b9
          inet addr:192.168.1.21  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::61ce:279b:d87:bc13/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13262 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1273 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:11707796 (11.1 MiB)  TX bytes:101615 (99.2 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:80 errors:0 dropped:0 overruns:0 frame:0
          TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6128 (5.9 KiB)  TX bytes:6128 (5.9 KiB)

As you can see I also have some 172* network addresses, these are set up by Docker automatically. The “real” IP address of the device is via the ethernet0 interface, so in my case my board’s IP address is 192.168.1.21. This is address you’d use for stuff like accessing the board via ssh.

It should be noted I believe you can configure Docker to use address other than the 172* range. Also when running containers you can include an argument in the command to make that container use the host system’s network stack rather than the bridged network. Though of course this gets rid of an network isolation between the host and that container.

I hope this quick explanation makes sense and helps explain the phenomenon you’re seeing.

Best Regards,
Jeremias

1 Like

OK…
How do I get a command prompt???
I don’t see anything in the Torizon GUI to give me a command prompt. I don’t see anything in the Torizon GUI which gives any sort of network information other than what I already reported.
For the record, I have tried UART1. There’s no response.

You’re not able to access the device via serial UART? How are you attempting to do this and what issues/errors are you running into?

Can you SSH into your device via the host name method described here: Linux Terminal and Basic Usage - Linux

Best Regards,
Jeremias

Where in the GUI is the information that the local IP address is the same one that you see from TEZI? The Torizon GUI really needs the local network info in it.
I came here after running the Quickstart for the Embedded Vision Starter Kit, so my board was already assembled. I skipped the first module for the Torizon Quickstart since I’d assembled the kit and flashed Torizon.

OK. Yes, using that IP address, I can ssh to the SOM.

Is there a way from the GUI to get a local console?

Ok wait so currently what Image do you have flashed on your device? Do you have Torizon with the Vision Kit demo image? Or do you just have a plain Torizon image? Could you describe or send a picture of what GUI you’re referring to? Depending on which image you have flashed we could be talking about different GUIs here.

As for console from GUI, the default GUI for the vanilla Torizon image is Portainer which is just a GUI for managing Docker images. As far as I know it has no feature to access the system’s console. The recommend way to access the local console of a Torizon system is either with serial UART or SSH connection.

Best Regards,
Jeremias

I have the Torizon Container Demo loaded - the one which TEZI installs.
I figured out getting UART 1 working.
I believe I am now up and running, since I have a serial connection and now know the IP address.
I’m still confused why there’s no local information in the GUI.

Glad you were able to get the serial interface working.

As for the GUI allow me to explain further. Portainer is a 3rd party GUI that can be used to manage containers, as I said previously. Furthermore Portainer itself runs in a container. Due to the nature of being run in a container, this means Portainer is isolated from the host system in many ways.

As such things like host network and host console aren’t inherently reachable from a container. Not to say that it’s impossible just rather it would require a non-standard configuration to give a container like Portainer such access and privileges to the host.

With that all said, if you do need to access the host rather than the container I really do recommend either serial/SSH to access the host system/console directly.

Best Regards,
Jeremias