August-15th-2019, 02:01 PM
(This post was last modified: August-19th-2019, 08:50 AM by Armin@netPI.)
Hi Philipp,
we have investigated the problem and found a solution.
You need to know that netPI is using the "NetworkManager" dealing with the system's network setup whereas on a Raspberry Pi the service "networking" is dealing the network setup by default. There is a main different between both services:
The Network-Manager embodies all rules defined the RFC specifications such as RFC 3927 IPv4 Link-Local or RFC 1918 private subnet. If you now define an ip network on netPI's web GUI of a 169.254.x.x. range the Network-Manager configures the eth0 interface with best knowledge according the spec. Since for a 169.254.x.x network no ip frame shall get routeable as stated in the RFC the Network-Manager configures eth0 under the scope "link".
So calling the command on a netPI
will return
...
inet 169.254.100.123/16 brd 169.254.255.255 scope link eth0
...
The scope link causes the system's IP stack to send out all frames with a source ip address 0.0.0.0 ... which is in turn of course not routeable.
On a Raspberry Pi the very same setup results in
...
inet 169.254.100.123/16 brd 169.254.255.255 scope global eth0
...
With the global setting whereas all frames will be sent with the correct source ip address 169.254.100.123 as needed.
The trick is now to get around the "link" setting within a container. For this a new route needs to be defined when the container is started. REMARK!!!: Precondition to be able to define a new route in a container is that it is started in "privileged" mode.
Here is the call you have to initiate in the container to set the scope to "global" while defining another default route with
Since the definition happens in the container only it is gone during the next reboot. So take care to insert the command in the start script of your container.
Thx
Armin
we have investigated the problem and found a solution.
You need to know that netPI is using the "NetworkManager" dealing with the system's network setup whereas on a Raspberry Pi the service "networking" is dealing the network setup by default. There is a main different between both services:
The Network-Manager embodies all rules defined the RFC specifications such as RFC 3927 IPv4 Link-Local or RFC 1918 private subnet. If you now define an ip network on netPI's web GUI of a 169.254.x.x. range the Network-Manager configures the eth0 interface with best knowledge according the spec. Since for a 169.254.x.x network no ip frame shall get routeable as stated in the RFC the Network-Manager configures eth0 under the scope "link".
So calling the command on a netPI
Code:
ip a
will return
...
inet 169.254.100.123/16 brd 169.254.255.255 scope link eth0
...
The scope link causes the system's IP stack to send out all frames with a source ip address 0.0.0.0 ... which is in turn of course not routeable.
On a Raspberry Pi the very same setup results in
...
inet 169.254.100.123/16 brd 169.254.255.255 scope global eth0
...
With the global setting whereas all frames will be sent with the correct source ip address 169.254.100.123 as needed.
The trick is now to get around the "link" setting within a container. For this a new route needs to be defined when the container is started. REMARK!!!: Precondition to be able to define a new route in a container is that it is started in "privileged" mode.
Here is the call you have to initiate in the container to set the scope to "global" while defining another default route with
Code:
ip route add 0.0.0.0/0 via 169.254.100.97 src 169.254.100.123 dev eth0 scope global
Since the definition happens in the container only it is gone during the next reboot. So take care to insert the command in the start script of your container.
Thx
Armin
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)