• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Default Gateway does not work
#11
See the result in my Wireshark trace of my out/ingoing traffic to my Internet connection and this screws me totally up

   

you see the forwarded ping 8.8.8.8 to the internet ...
you see the reply from the internet from 8.8.8.8 ...
and then you see exactly this reply that initially should go to my 2nd network card to my Raspberry Pi (169.254.100.123) but instead you see it going out to my network connected to the internet.

So the packet seems not to find its way back to the correct interface card in my notebook.

At this time I have to admit that I am a network amateur.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#12
On the internet I found the IP address space 169.254.x.x seems to be treated special and maybe Linux is taking care of this "handling"

See here:

https://tools.ietf.org/html/rfc3927 (special treatment of 169.254.x.x networks)

https://en.wikipedia.org/wiki/Reserved_IP_addresses

https://www.xnetsolutions.de/support/sx-...69-254-x-x

https://www.linux.com/learn/intro-to-lin...addressing (169.254.x.x address space is not routable)

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

  Reply
#13
My colleague found an interesting article here https://etherarp.net/basics-link-local/ that might explain why Linux and its network/routing protocol stack is treating the IP address range 169.254.x.x so special.
I think at this time everybody understands here that Hilscher is not able to make a deep dive into the Linux source code (the Raspbian OS source code by the way is the base for netPI's YOCTO linux) to search the root cause for this treatment.
Since it is proven that the original Raspberry Pi handles the packets the same like netPI we are fine with that issue and accept it as given.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#14
Hello,

I did the same test, as you Armin, with a standard Raspberry Pi 3 Model B Rev 1.2. I used the lastes Firmware.
   

I connect the rasppbery to the network 169.254.100.xxx Here is my config file.
   

With the standard raspberry I have been able to reach the internet via modem.
   

Where ist the difference between the standard raspberry and the netPi ? Hast the netPi any special network settings.

BR
Philipp
  Reply
#15
Hello Philipp,

I repeated my tests.

I used my Raspberry Pi with Kernel 4.19.x and this time I have to admit that it sends out the ping 8.8.8.8 command. (Don't know what I did wrong two weeks ago, so sorry for that one)

I used my Raspberry Pi with Kernel 4.9.80 from here https://downloads.raspberrypi.org/raspbi...018-03-14/ and it sends out the ping 8.8.8.8.

I used my netPI with firmware V1.2.0.0 with Kernel 4.9.80 and it does not send out the ping 8.8.8.8 to the network with the same network settings in a container.

I also used a debug netPI image that allows me to login to the netPI Host Linux, so I am able to use the ping command outside a container and without Docker at all and netPI does not send out a ping to 8.8.8.8.

I will be investigating a little deeper now with help of the development team what could be the reason of this issue.

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

  Reply
#16
The response from our development team came 5 minutes after I sent them the issue over an internal email:

This is what I got as response:

>
Armin, this is a link-local IP network setup and to my knowledge it is not routeable, so no gateway is possible and even if configure it is without effect.
Here are some links you can read
https://en.wikipedia.org/wiki/Link-local_address
https://tools.ietf.org/html/rfc3927
   
<

So the development team came to the very same conclusion as I have written in my post to this topic before. Linux is filtering all IP addresses outside the range 169.254.x.x automatically.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#17
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
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)

  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  [SOLVED] netPI stops working (502 - Bad Gateway) Andi 3 35 June-19th-2019, 03:58 PM
Last Post: Andi
  netPI & Edge Gateway differences MGharat 5 29 May-10th-2019, 10:48 AM
Last Post: Armin@netPI
  Pull image does not work Jonas.Sellmann@outlook.de 3 195 August-1st-2018, 08:07 AM
Last Post: Armin@netPI
  Edge Gateway Manager - Docker Management HagnSchool 1 89 June-8th-2018, 07:50 AM
Last Post: Armin@netPI
  Default listening TCP/UDP ports Armin@netPI 0 91 February-9th-2018, 01:36 PM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)