• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Default Gateway does not work
#1
I'm using a net PI Core (Firmware 1.0200.1368) in a LAN with a modem.  The net PI is used to send mails via modem.
The modem has the ip address 169.254.100.97.
The net PI got following LAN settings.
   

I'm using the docker container "hilschernetpi/netpi-debian-stretch:latest" and the network type of this container ist set up as host.
These settings lead to the following routing table.
   

It's possible to ping the gateway, in my case the modem. But I can't ping any address outside this network, e.g. 8.8.8.8. All other devices in my LAN can reach this address.
Adding a static route has no effect.

Has anybody some ideas ? Which setting is wrong ?

Many thanks for your support in advance.
  Reply
#2
Hi there, we can't see you screen shots in your post.

Please edit your post and add pictures as attachment and after inserted them as attachment you can select the option "insert into post".

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

  Reply
#3
What may be a problem is that when netPI CORE 3 receives an IP address through your DHCP it will receive also a default gateway. This gateway will have prio to any other additional LAN,Wifi ... USB modems.

So you should try to setup a manual ethernet connection with the very same IP address and network mask as received through the DHCP server beore but this time without setting the default gateway.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#4
(July-31st-2019, 02:26 PM)Armin@netPI Wrote: What may be a problem is that when netPI CORE 3 receives an IP address through your DHCP it will receive also a default gateway. This gateway will have prio to any other additional LAN,Wifi ... USB modems.

So you should try to setup a manual ethernet connection with the very same IP address and network mask as received through the DHCP server beore but this time without setting the default gateway.

The DHCP Server is running on the modem. It sets the default gateway as 169.254.100.97
  Reply
#5
Ok now I am able to see your screen shots.

When I am looking to your screen shot you made using the command

Code:
ip route show

 then I see a default gateway 169.254.100.97 which is pretty much the same as in your netPI's LAN settings page (screen shot 2). So this matches

So my expectation is like you that whenever you ping to 8.8.8.8 for example you are getting a reply instantly.

On the other hand you are telling me that you were able to pull the "hilscher debian container" which tells me also that the principle connection over your gateway works and also the DNS server must have been working correctly since pulling an image goes over the name https://registry-1.docker.io/v2/ internally always.

My netPI here in the office network receives its IP over a gateway/server too and I think this is the case in 99% of all applications I know of with netP. I tried the same like you ... loading the debian stretch container ... starting it with host mode setting.

Here is what I did

Code:
root@NTB827EBD50766:/# ip route show
default via 10.11.0.10 dev eth0 proto dhcp metric 100
10.11.0.0/16 dev eth0 proto kernel scope link src 10.11.5.13 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@NTB827EBD50766:/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=1.652 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=1.648 ms
^C--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.648/1.650/1.652/0.000 ms
root@NTB827EBD50766:/#

here it works as expected. Especially in "host mode" the container shares the TCP/IP stack of the host system so it runs 100% in the same context as the host ... and your host is able to pull images ... but the container is not able to ping an external IP address ... this really sounds weird to me and I defenitively cannot explain.

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

  Reply
#6
I tried my netPI at home connected to a Fritz.box as gateway/modem featuring DHCP support and I got the same result as in my previous post. No problem pinging 8.8.8.8 in a host mode driven container. Also I would expect that not even a "bridged driven container" should have a problem since Docker manages the routing between container and host in this case. This is Docker standard.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#7
(August-1st-2019, 08:00 AM)Armin@netPI Wrote: Ok now I am able to see your screen shots.

When I am looking to your screen shot you made using the command

Code:
ip route show

 then I see a default gateway 169.254.100.97 which is pretty much the same as in your netPI's LAN settings page (screen shot 2). So this matches

So my expectation is like you that whenever you ping to 8.8.8.8 for example you are getting a reply instantly.

On the other hand you are telling me that you were able to pull the "hilscher debian container" which tells me also that the principle connection over your gateway works and also the DNS server must have been working correctly since pulling an image goes over the name https://registry-1.docker.io/v2/ internally always.

My netPI here in the office network receives its IP over a gateway/server too and I think this is the case in 99% of all applications I know of with netP. I tried the same like you ... loading the debian stretch container ... starting it with host mode setting.

Here is what I did

Code:
root@NTB827EBD50766:/# ip route show
default via 10.11.0.10 dev eth0 proto dhcp metric 100
10.11.0.0/16 dev eth0 proto kernel scope link src 10.11.5.13 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@NTB827EBD50766:/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=1.652 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=1.648 ms
^C--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.648/1.650/1.652/0.000 ms
root@NTB827EBD50766:/#

here it works as expected. Especially in "host mode" the container shares the TCP/IP stack of the host system so it runs 100% in the same context as the host ... and your host is able to pull images ... but the container is not able to ping an external IP address ... this really sounds weird to me and I defenitively cannot explain.

Thx
Armin

Maybe i explained not precise enough in which way i have pulled the container. Therefore i have changed the ip settings and connected the netPI to a completly different network. The setup with the modem had never access to the internet.

I did another small test.
I have changed the modem IP address to 192.168.178.1 and changed the netPI LAN settings as following.
   

Then it is possible to ping devices at the internet. All is fine.
   

When I change the modem IP sddress to 169.254.100.97 and don't touch the netPI's settings no connection to the internet is possible annymore. The netPI's IP address is set through DHCP at 169.254.100.70.

I think the network 169.254.100.xxx creates the problems. I can't imagine what is the reason for this. But in I have to use this network in my appliication.
  Reply
#8
I setup my notebook (with internet connection) to work as a gateway using a second ethernet card.

I setup the 2nd card with exactly your modem settings and IP 169.254.100.97 and my netPI with 169.254.100.123 and subnet 255.255.0.0 and DNS to 169.254.100.97. I am having now an equivalent network setup like yours.

  1. I can confirm that I am able to ping my notebook with 169.254.100.97 but I am not able to ping 8.8.8.8.
  2. The I tried your settings you did in your second test ... 192.168.178.1 etc. With this test I can confirm that I am able to ping 8.8.8.8
  3. Since I am using a notebook I am able to start Wireshark to make recordings. In non-working setup I don't see any ping command for 8.8.8.8 leaving netPI. I see ping commands leaving for 169.254.100.97
Then I setup my original raspberry Pi with Linux V4.19.57 very latest version and the following /etc/network/interfaces file

Code:
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 169.254.100.123
netmask 255.255.0.0
gateway 169.254.100.97
dns-nameservers 169.254.100.97

and guess what ... with my original Raspberry Pi I am having exactly the same issue. I am not able to ping 8.8.8.8 and there are no Eth frames coming out from it if I start recording it with Wireshark.

So this an issue with Linux in general or a setting that I don't know right now. So it is not a specific netPI problem but a general problem. We have a network expert in the office, maybe he knows more.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#9
Many thanks for your afford. I look forward to the findings of your network expert.
  Reply
#10
There is a little progress in my notebook setup and Raspberry Pi.

I was specifically adding the gateway in the routing table using the command


Code:
ip route add 169.254.100.97 dev eth0

With this additional entry my Raspberry Pi is now sending out the ping command as intended. I was able to see in it Wireshark

... and I see with Wireshark my notebook sending out the same ping command out to the internet and I see the replay back to it too

... what I don't see is that my notebook routes back the ping reply back to my Raspberry Pi.

So there is still something missing.
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 3,506 June-19th-2019, 03:58 PM
Last Post: Andi
  netPI & Edge Gateway differences MGharat 5 3,334 May-10th-2019, 10:48 AM
Last Post: Armin@netPI
  Pull image does not work Jonas.Sellmann@outlook.de 3 2,869 August-1st-2018, 08:07 AM
Last Post: Armin@netPI
  Edge Gateway Manager - Docker Management HagnSchool 1 2,101 June-8th-2018, 07:50 AM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)