August-12th-2020, 02:08 PM
(This post was last modified: August-12th-2020, 02:26 PM by Armin@netPI.)
Ok but why are your screen shots show that 172.17.0.3:1099 "remote object is not reachable and "connect time out". If you use IP address 192.168.160.20 - as you say - to address agent 2 ... so why do your screen shots not show 192.168.160.20 "remote object is not reachable"? I do not understand this behaviour. Please explain.
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
August-12th-2020, 04:30 PM
(This post was last modified: August-12th-2020, 05:52 PM by Armin@netPI.)
Yes I realized that this is the IP address of your agent 1 container, but I think I cannot help here any further. You know your Java application better than I. You see yourself that a simple ping command works properly and it addresses the agent 2 fine, but why your Java application is addressing the local container IP address you have to examine yourself. Maybe your Java app uses the address the "localhost" which is indeed 192.168.160.20 in the view of an app inside the container ... this is speculation only from my side ... I personally don't know the reason.
There is one additional note: If your agent 1 sends out data on port 1099 then port mapping like you configured for bridge mode it is not necessary at all. For ALL applications in a container that want to send telegrams over TCP/IP to a remote station all outgoing ports are always "open" and no port mapping is needed. A port mapping is only needed in bridged mode if an application located in an network outside the Docker host wants to reach an application inside a container on the host. But this is not the case here. You want to initiate sending data from agent 1 to agent 2 and sending works always.
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
August-13th-2020, 08:33 AM
Since netPI's Desktop container also works on a standard Raspberry Pi you can deploy it there as well. So make a test with an RPi3 ... I am pretty sure that you will see the very same effect and that it is not a netPI related problem.
Here is an example how to start the Desktop container on a normal Rpi3:
Code:
docker run -d --privileged --network=bridge --restart=always -e SSHPORT=23 --device=/dev/tty0:/dev/tty0 --device=/dev/tty2:/dev/tty2 --device=/dev/fb0:/dev/fb0 --device=/dev/input:/dev/input --device=/dev/snd:/dev/snd -p 23:23/tcp -p 5900:5900 hilschernetpi/netpi-desktop-hdmi
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)