• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
EtherCAT Master: any options?
#31
Hello Armin,

Now I made the step back to the origninal hilschernetpi/netpi-netx-ethernet-lan container to make sure everything is unmodified. I installed it in host mode with the two devices (/dev/spidev0.0 and /dev/net/tun) made accessible in privileged mode and configured IP_ADDRESS = dhcp.
I can access the webinterface now from the netx port and log in via ssh. Unfortunately from there on I observe a similar behavior as described above. With only wlan0 connected and only wlan0 set as default route I get internet connection. (webinterface and container). As soon as I disconnet wlan0 and set cifx0 as default route to the router (verified internet connection) I have no internet connection anymore (not in the webinterface and also not in the container - note that before with my own merge I had at least connection inside the container but not in the webinterface)
The way I verify internet connection in the webinterface is to open the portainer app templates page and see if it loads.
Further I can't re-install the official node-red container -> Some docker error : error creating overlay mount to /run/.system_part/docker/overlay2/48bf49d1....

I'm running out of time here. This docker thing may be safe but I'm blind on the host side, need a lot of time for every debugging step and over all things do not work. Sorry running out of patience.
Best Andreas
  Reply
#32
Hello Andreas,

can't confirm.

I deployed the latest container as you do. I configured "dhcp" also. I do not use any Wifi at all, just "eth0"l.

Then I connected a cable to netPIs industrial ethernet port with a DHCP server. So "cifx0" is getting an ip address and gateway settings etc. automatically.

Then I started a putty session and opened a console on port 22 over "cifx0". The I removed the "eth0" cable, so the only physical connection is "cifx0"

Then I called:
Code:
root@2d70db465dc3:~# ping google.com
^C
root@2d70db465dc3:~# ip route show
default via 172.17.0.1 dev eth0
10.11.0.0/16 dev cifx0 proto kernel scope link src 10.11.5.54
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
root@2d70db465dc3:~# ip route del default
root@2d70db465dc3:~# ip route add default via 10.11.0.10 dev cifx0
root@2d70db465dc3:~# ip route show
default via 10.11.0.10 dev cifx0
10.11.0.0/16 dev cifx0 proto kernel scope link src 10.11.5.54
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
root@2d70db465dc3:~# ping google.com
PING google.com (172.217.23.142): 56 data bytes
64 bytes from 172.217.23.142: icmp_seq=0 ttl=55 time=2.812 ms
64 bytes from 172.217.23.142: icmp_seq=1 ttl=55 time=2.340 ms

Since "eth0" is no more ... the first ping failed. Looking to route shows me that the default gateway goes over "eth0". I change to "cifx0" and then ping to google.com works, so I have Internet access.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#33
Hello,

So at the moment I get a ping with cifx0 as you do. (I think the hosts file missing the hostname was the problem for that)
Nevertheless no internet conneciton in portainer, just in the host mode container.

Andreas
  Reply
#34
Hello Andreas,


Quote:Nevertheless no internet conneciton in portainer, just in the host mode container.

do you mean netPI's standard portainer? Or do you have portainer running inside the container?

If you mean netPI's standard portainer then this will never work in bridge mode. The container's readme says


Quote:Servicing the cifx0 interface is only possible in the container it was created.

So your created "cifx0" inside the container cannot be seen on netPI's host ... where portainer is running. This is encapsulated and protected by Docker techniques.


Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#35
Hello,

Yes I remember reading that. However I'm not familiar with docker (Host mode, privileged etc) and Linux to such an extent to deduce that this means no internet connection from any other system location (other container in bridge mode or the original portainer installation). Is that correct?

If that is the case then I assume the only possible way is to install everything I need to acces the internet in a single container, which controls cifx0?

Thank you very much for your help,
Andreas
  Reply
#36
Hello Andreas,

the point is that the "cifx0" LAN interface is a construct made within the container only. All settings concerning ip addresses and routing remain in the container only in case bridge mode used. So imagine you have a set of 100 containers ... and all containers want to adjust the IP settings ... can't imagine what would happen. So this is why Docker is encapsulating and separating those network settings.

In case of Host mode the behaviour is different. The containers LAN respectively TCP/IP stack is shared with the one of the Host. So all your container settings will have immediate effect on the software running outside the container.

The conclusing is that netPI gets internet access via eth0 or wlan0 only, via "cifX0" only in Host mode. But why don't you want to run the container in Host mode?

Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#37
Hello Armin,

I do run the container with cifx0 in host mode. Nevertheless I have only internet access inside this container. Any other location on the system (bridge mode containers and original portainer) do not have internet access.#
This is here the case for my own container merge and also observed for the hilschernetpi/netpi-netx-ethernet-lan container (host mode)

Best Andreas
  Reply
#38
Hello Andreas,

the point is as follows. The reason why you are getting access to portainer.io via "cifx0" but in the end this portainer.io not to DockerHub is the following:

If you remove the "eth0" or "wlan0" interface physically then the Host Linux will remove the DNS server from its local "/etc/resolve.conf" file.

If now portainer.io wants to request an image from "registry-1.docker.io" then the Host Linux cannot resolve this name and give you back an error like


Code:
Failure

Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: server misbehaving

And even if a container is started in Host and priviledge mode, it cannot access the file "/etc/resolve.conf" on the host, else you could easily insert a new DNS server entry like "nameserver 8.8.8.8" for example.


Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#39
Andreas,

what you can do of course if the name resolution does not work - like we both see - is to setup a local container registry located in somewhere your network with a fixed IP address.

So instead of pulling containers from DockerHub you can pull containers from e.g. 192.168.x.x. In portainer.io you can setup this IP address as new registry and pull from there.

For example: at home I am running a registry on my netPI itself and hence I am pulling images from a single device.

....just an idea.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#40
(May-22nd-2019, 02:18 PM)Armin@netPI Wrote: Hello Andreas,

the point is as follows. The reason why you are getting access to portainer.io via "cifx0" but in the end this portainer.io not to DockerHub is the following:

If you remove the "eth0" or "wlan0" interface physically then the Host Linux will remove the DNS server from its local "/etc/resolve.conf" file.

If now portainer.io wants to request an image from "registry-1.docker.io" then the Host Linux cannot resolve this name and give you back an error like


Code:
Failure

Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: server misbehaving

And even if a container is started in Host and priviledge mode, it cannot access the file "/etc/resolve.conf" on the host, else you could easily insert a new DNS server entry like "nameserver 8.8.8.8" for example.


Armin

Hello Armin,

I did insert an nameserver 8.8.8.8 in /etc/resolv.conf in the host mode container (not the host system). This was the way to get DNS working in the container. Is there a way to get this line in the host systems /etc/resolv.conf?
My solution was now to additionally install Node-Red in the host mode container manually like described here https://nodered.org/docs/hardware/raspberrypi

The new issue now is that it seems that the NetPi crashes completely after a couple of hours of operation. This varies between 3 hours and 12 hours of operation. Last time when I observed that I could not connect to the container via ssh and I could not reach the Edge Gateway Manager web interface and got no ping to the device. Where should I start to investigate?

Thank you for your Help,
Andreas

Andreas
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  communication cycle as EtherCAT slave tad 2 2,113 April-20th-2021, 11:14 AM
Last Post: tad
  NodeRed and EtherCAT Schranz 3 6,054 September-23rd-2020, 08:01 AM
Last Post: Armin@netPI
  Ethercat master mapping SteP 1 2,268 March-2nd-2020, 12:42 PM
Last Post: Armin@netPI
  EtherCAT Slave OP mode (netPI RTE3) mauroriva 1 2,465 June-20th-2018, 08:38 AM
Last Post: Armin@netPI
  Container IP address - Network Options kimsmyth 2 3,216 January-30th-2018, 11:04 AM
Last Post: kimsmyth

Forum Jump:


Users browsing this thread: 2 Guest(s)