The connection I have above constantly toggles between connected and faulted and is generally unusable.
The reported error is:
io.netty.channel.AbstractChannel$AnnotatedNoRouteToHostException: No route to host: /172.16.0.244:4840
Caused by: java.net.NoRouteToHostException: No route to host
at java.base/sun.nio.ch.Net.pollConnect(Native Method)
at java.base/sun.nio.ch.Net.pollConnectNow(Unknown Source)
at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:336)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:339)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:784)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:732)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:658)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:998)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at java.base/java.lang.Thread.run(Unknown Source)
Configuration of endpoint as follows:
Haven’t been able to see a certificate to trust yet as I did in UaExpert.
Using Ignition Maker 8.3.3 on a Raspberry Pi 5.
You just don’t have a network route to this host available.
How did you get this hostname? Type it in manually or go through discovery?
What IP, subnet, etc… does the Pi have?
The device is 172.16.0.244 and the pi is 172.16.0.245
Network /24
As it happens the device is a soft dPAC running in docker on the same Raspberry Pi.
I don’t know why there’s the leading forward slash on the no route to host.
Comms must work somehow, it shows connected before it drops.
The hostname was typed in manually.
I think that it briefly shows connected is actually just a UI bug.
Is Ignition also in Docker, or running on the host?
Unless you’ve done some special networking setup you’ve left out, then you need to be connecting to this container at “localhost:4840” instead, and hopefully you started it with 4840 on the host forwarded to 4840 in the container (-p 4840:4840).
I believe 4840 is forwarded to the container. I can access it as opc.tcp://172.16.0.244:4840 from another computer with UaExpert as an OPC UA client.
This is partial config in UaExpert:
With that configuration, I am able to connect once I accept certificate errors.
To answer the question about the networking setup, part of the EAE dPAC deployment does have me creating a separate IP address for that docker container, so the dPAC is .244 and ignition is .245
If you go through the discovery process in Ignition can you reach it at either opc.tcp://localhost:4840 or opc.tcp://172.16.0.2:4840 (assuming 172.16.0.2 is the IP of the bridge in docker)?
If that doesn't work you're going to have to share actual details about how the docker container/networking are set up.
I have tried all of these with no luck.
This is the ifconfig on the server:
aaron.just@HomePi5:~$ ifconfig
br-a1d6a18b7c6f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.18.0.1 netmask 255.255.0.0 broadcast 172.18.255.255
inet6 fe80::484e:b2ff:fe2f:1379 prefixlen 64 scopeid 0x20
ether 4a:4e:b2:2f:13:79 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 fd00::1 prefixlen 80 scopeid 0x0
ether 22:95:c3:1c:6d:22 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.16.0.245 netmask 255.255.255.0 broadcast 172.16.0.255
inet6 fe80::da3a:ddff:fee0:b23b prefixlen 64 scopeid 0x20
ether d8:3a:dd:e0:b2:3b txqueuelen 1000 (Ethernet)
RX packets 138489193 bytes 8242874398 (8.2 GB)
RX errors 0 dropped 10449 overruns 0 frame 0
TX packets 76642004 bytes 5964311384 (5.9 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 109
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 4256897 bytes 599514012 (599.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4256897 bytes 599514012 (599.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
veth61423f4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::ec2f:99ff:fe11:9422 prefixlen 64 scopeid 0x20
ether ee:2f:99:11:94:22 txqueuelen 0 (Ethernet)
RX packets 2466165 bytes 468410064 (468.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1234868 bytes 231692536 (231.6 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
veth7f9faa2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::f8a0:bbff:fe0c:b4a1 prefixlen 64 scopeid 0x20
ether fa:a0:bb:0c:b4:a1 txqueuelen 0 (Ethernet)
RX packets 3 bytes 126 (126.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 44 bytes 6024 (6.0 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vethf485962: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::c7f:67ff:fe4d:a7bb prefixlen 64 scopeid 0x20
ether 0e:7f:67:4d:a7:bb txqueuelen 0 (Ethernet)
RX packets 1234892 bytes 231691603 (231.6 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2466226 bytes 468416548 (468.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
On the soft dPAC, it shows that it is connected through the ethernet interface eth0
The ARP table shows different MACs for .244 and .245
Interestingly I can’t ping 172.16.0.244 from 172.16.0.245 which I didn’t expect, given I can ping it from other computers on the same network.
I assume that once I sort the networking out then comms will be good and ultimately I’m stuck because of how network traffic moves from the linux host into the docker container and how this appears different to other devices on the network.
I think you've got your Docker container running on a macvlan or ipvlan network, and because of how Docker networking works you can't actually reach this from the Docker host.
The easiest thing to do would be run Ignition in Docker too, on the same network.
Otherwise you need to create a virtual interface on the host and configure it to route traffic through that interface.
more details on the docker networking that i’ve dug up:
The docker container is connected using a macvlan driver, and so should be appearing as 172.16.0.244/24 with a fixed MAC:
"Containers": {
"6c2553135e0905ad033e0fb5511dd746644c2c6ce64ec2e543f09137bd33c169": {
"Name": "extdpac-softdpac-manager-1",
"EndpointID": "43898f16cf9e4ddbfbd6ccd8cd1c4ec4a1bbaa82306fbcb5e6c3202fee72f47c",
"MacAddress": "e2:dc:74:8a:de:94",
"IPv4Address": "172.16.0.1/24",
"IPv6Address": ""
},
"c892e6213cedb2ee517235715acd5fbe4adb39cf9108579b6aa8608094d38324": {
"Name": "HomePi5dPAC",
"EndpointID": "6ccaacea4ae98c9d5624457eb60392d976b02136f49d37895b25c791122109d5",
"MacAddress": "c6:a5:9c:27:5f:65",
"IPv4Address": "172.16.0.244/24",
"IPv6Address": ""
}
When I ping the dPAC from another computer, its arp table correctly shows the MAC c6:a5…
When I ping the dPAC from the linux host; the arp table doesn’t resolve:
aaron.just@HomePi5:~$ ping 172.16.0.244
PING 172.16.0.244 (172.16.0.244) 56(84) bytes of data.
From 172.16.0.245 icmp_seq=1 Destination Host Unreachable
From 172.16.0.245 icmp_seq=2 Destination Host Unreachable
From 172.16.0.245 icmp_seq=3 Destination Host Unreachable
^C
--- 172.16.0.244 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3076ms
pipe 4
aaron.just@HomePi5:~$ arp -a
? (172.16.0.190) at 04:7c:16:c1:55:2d [ether] on eth0
? (172.16.0.244) at <incomplete> on eth0
Presumably this is where I have come unstuck:
It is a known limitation of the Linux kernel that a Docker host cannot directly communicate with containers on its own macvlan network by default. This traffic is intentionally filtered for isolation and security.
sudo ip link add macvlan-host link eth0 type macvlan mode bridge
sudo ip addr add 172.16.0.250/24 dev macvlan-host
sudo ip link set macvlan-host up
sudo ip route add 172.16.0.244 dev macvlan-host
This won't survive reboots. Exercise for the reader. Just ask an LLM.
Amazing. Happy days!
Discovery etc. worked with the code provided.
I very much appreciate your pointers on this one and I’ve learned more about how the network stack works for the Docker container in the process.
I guess the only thing to add now is that the UI shouldn’t have reported that it was connected when it seems that as it was, that communication was impossible.
