routing table adds additional default entry

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












I'm using a beaglebone black with the newest IoT Debian 9 image (BeagleBoard.org Debian Image 2018-03-05)



Here is how I configured my network interfaces:



/etc/network/interfaces



# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.0.220
netmask 255.255.255.0
gateway 192.168.0.155

# Ethernet/RNDIS gadget (g_ether)
iface usb0 inet static
address 192.168.7.2
netmask 255.255.255.252
network 192.168.7.0
gateway 192.168.7.1

# Nameservers
dns-nameservers 192.168.0.155


After I start the interface, my routing table looks like this:



debian@beaglebone:~$ ip route
default via 192.168.0.155 dev eth0 onlink
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.220
192.168.6.0/30 dev usb1 proto kernel scope link src 192.168.6.2 linkdown
192.168.7.0/30 dev usb0 proto kernel scope link src 192.168.7.2


I can reach the internet via my default gateway and everything works as it should, but after 1-2 minutes some additional entries appear.



Now my routing table looks like this:



debian@beaglebone:~$ ip route
default dev eth0 scope link
default via 192.168.0.155 dev eth0 onlink
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.220
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.66.227
192.168.6.0/30 dev usb1 proto kernel scope link src 192.168.6.2 linkdown
192.168.7.0/30 dev usb0 proto kernel scope link src 192.168.7.2


Now the upper default gateway seems to be used instead of the one defined by me. As a result, the internet (and other internal networks) is not reachable.



This only happens if eth0 is connected to a network. All the other devices within the network I am using are also configured statically.



How can I get my system to use the default gw I want it to use?



I already tried to remove the default gateway from usb0 or putting it into an separate routing table, which resulted in the beaglebone being not reachable via any interface.



Here is the output of ifconfig, just in case somebody finds something suspicious here.



debian@beaglebone:~$ ifconfig
eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 192.168.0.220 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::564a:16ff:fee5:e79d prefixlen 64 scopeid 0x20<link>
ether 54:4a:16:e5:e7:9d txqueuelen 1000 (Ethernet)
RX packets 79 bytes 9988 (9.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 458 bytes 85028 (83.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 181

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 180 bytes 14118 (13.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 180 bytes 14118 (13.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.7.2 netmask 255.255.255.252 broadcast 192.168.7.3
inet6 fe80::564a:16ff:fee5:e79f prefixlen 64 scopeid 0x20<link>
ether 54:4a:16:e5:e7:9f txqueuelen 1000 (Ethernet)
RX packets 740 bytes 79447 (77.5 KiB)
RX errors 0 dropped 4 overruns 0 frame 0
TX packets 525 bytes 97473 (95.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.6.2 netmask 255.255.255.252 broadcast 192.168.6.3
ether 54:4a:16:e5:e7:a2 txqueuelen 1000 (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






share|improve this question

















  • 3




    Can you check if network-manager is installed and running? This might conflict with your static config.
    – Winnie Tigger
    May 29 at 8:51











  • @Winnie Tigger - network-manager does not seem to be installed.
    – Detonar
    May 29 at 9:11










  • 169.254.*.* is a link-local IP, so something thinks eth0 is not configured, and is triggering configuration for it. My guess is that the 10.168.178.0 route comes from a DHCP server. (1) Look at syslog etc. for anything suspicious (2) Run tcpdump or wireshark on eth0 and see if you can catch any DHCP packets, then at least you know where it comes from.
    – dirkt
    May 29 at 9:19










  • Sure does the false entries come from a DHCP Server. But DHCP is quite normal in a Network. The cause of the problem must be something on the BB wich overrides the static config not the DHCP Server.
    – Winnie Tigger
    May 29 at 9:26






  • 1




    So this situation looks just strange to me. As I can see in your second routing-table, your default-gw ist still 192.168.0.155 on dev eth0. The 169... is, as "dirkt" stated, a Link-Local address, which means your BB sends DHCP request and gets no answer. Also it is /16 and your static IP is /24, which also means that this will be the preferred addres because of "longest prefix match" in ip-routing. So this needs some more debugging here. Are you familiar with tcpdump or tshark? Can you check if there is any program or process which is sending DHCP requests?
    – Winnie Tigger
    May 29 at 13:49














up vote
1
down vote

favorite












I'm using a beaglebone black with the newest IoT Debian 9 image (BeagleBoard.org Debian Image 2018-03-05)



Here is how I configured my network interfaces:



/etc/network/interfaces



# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.0.220
netmask 255.255.255.0
gateway 192.168.0.155

# Ethernet/RNDIS gadget (g_ether)
iface usb0 inet static
address 192.168.7.2
netmask 255.255.255.252
network 192.168.7.0
gateway 192.168.7.1

# Nameservers
dns-nameservers 192.168.0.155


After I start the interface, my routing table looks like this:



debian@beaglebone:~$ ip route
default via 192.168.0.155 dev eth0 onlink
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.220
192.168.6.0/30 dev usb1 proto kernel scope link src 192.168.6.2 linkdown
192.168.7.0/30 dev usb0 proto kernel scope link src 192.168.7.2


I can reach the internet via my default gateway and everything works as it should, but after 1-2 minutes some additional entries appear.



Now my routing table looks like this:



debian@beaglebone:~$ ip route
default dev eth0 scope link
default via 192.168.0.155 dev eth0 onlink
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.220
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.66.227
192.168.6.0/30 dev usb1 proto kernel scope link src 192.168.6.2 linkdown
192.168.7.0/30 dev usb0 proto kernel scope link src 192.168.7.2


Now the upper default gateway seems to be used instead of the one defined by me. As a result, the internet (and other internal networks) is not reachable.



This only happens if eth0 is connected to a network. All the other devices within the network I am using are also configured statically.



How can I get my system to use the default gw I want it to use?



I already tried to remove the default gateway from usb0 or putting it into an separate routing table, which resulted in the beaglebone being not reachable via any interface.



Here is the output of ifconfig, just in case somebody finds something suspicious here.



debian@beaglebone:~$ ifconfig
eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 192.168.0.220 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::564a:16ff:fee5:e79d prefixlen 64 scopeid 0x20<link>
ether 54:4a:16:e5:e7:9d txqueuelen 1000 (Ethernet)
RX packets 79 bytes 9988 (9.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 458 bytes 85028 (83.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 181

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 180 bytes 14118 (13.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 180 bytes 14118 (13.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.7.2 netmask 255.255.255.252 broadcast 192.168.7.3
inet6 fe80::564a:16ff:fee5:e79f prefixlen 64 scopeid 0x20<link>
ether 54:4a:16:e5:e7:9f txqueuelen 1000 (Ethernet)
RX packets 740 bytes 79447 (77.5 KiB)
RX errors 0 dropped 4 overruns 0 frame 0
TX packets 525 bytes 97473 (95.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.6.2 netmask 255.255.255.252 broadcast 192.168.6.3
ether 54:4a:16:e5:e7:a2 txqueuelen 1000 (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






share|improve this question

















  • 3




    Can you check if network-manager is installed and running? This might conflict with your static config.
    – Winnie Tigger
    May 29 at 8:51











  • @Winnie Tigger - network-manager does not seem to be installed.
    – Detonar
    May 29 at 9:11










  • 169.254.*.* is a link-local IP, so something thinks eth0 is not configured, and is triggering configuration for it. My guess is that the 10.168.178.0 route comes from a DHCP server. (1) Look at syslog etc. for anything suspicious (2) Run tcpdump or wireshark on eth0 and see if you can catch any DHCP packets, then at least you know where it comes from.
    – dirkt
    May 29 at 9:19










  • Sure does the false entries come from a DHCP Server. But DHCP is quite normal in a Network. The cause of the problem must be something on the BB wich overrides the static config not the DHCP Server.
    – Winnie Tigger
    May 29 at 9:26






  • 1




    So this situation looks just strange to me. As I can see in your second routing-table, your default-gw ist still 192.168.0.155 on dev eth0. The 169... is, as "dirkt" stated, a Link-Local address, which means your BB sends DHCP request and gets no answer. Also it is /16 and your static IP is /24, which also means that this will be the preferred addres because of "longest prefix match" in ip-routing. So this needs some more debugging here. Are you familiar with tcpdump or tshark? Can you check if there is any program or process which is sending DHCP requests?
    – Winnie Tigger
    May 29 at 13:49












up vote
1
down vote

favorite









up vote
1
down vote

favorite











I'm using a beaglebone black with the newest IoT Debian 9 image (BeagleBoard.org Debian Image 2018-03-05)



Here is how I configured my network interfaces:



/etc/network/interfaces



# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.0.220
netmask 255.255.255.0
gateway 192.168.0.155

# Ethernet/RNDIS gadget (g_ether)
iface usb0 inet static
address 192.168.7.2
netmask 255.255.255.252
network 192.168.7.0
gateway 192.168.7.1

# Nameservers
dns-nameservers 192.168.0.155


After I start the interface, my routing table looks like this:



debian@beaglebone:~$ ip route
default via 192.168.0.155 dev eth0 onlink
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.220
192.168.6.0/30 dev usb1 proto kernel scope link src 192.168.6.2 linkdown
192.168.7.0/30 dev usb0 proto kernel scope link src 192.168.7.2


I can reach the internet via my default gateway and everything works as it should, but after 1-2 minutes some additional entries appear.



Now my routing table looks like this:



debian@beaglebone:~$ ip route
default dev eth0 scope link
default via 192.168.0.155 dev eth0 onlink
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.220
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.66.227
192.168.6.0/30 dev usb1 proto kernel scope link src 192.168.6.2 linkdown
192.168.7.0/30 dev usb0 proto kernel scope link src 192.168.7.2


Now the upper default gateway seems to be used instead of the one defined by me. As a result, the internet (and other internal networks) is not reachable.



This only happens if eth0 is connected to a network. All the other devices within the network I am using are also configured statically.



How can I get my system to use the default gw I want it to use?



I already tried to remove the default gateway from usb0 or putting it into an separate routing table, which resulted in the beaglebone being not reachable via any interface.



Here is the output of ifconfig, just in case somebody finds something suspicious here.



debian@beaglebone:~$ ifconfig
eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 192.168.0.220 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::564a:16ff:fee5:e79d prefixlen 64 scopeid 0x20<link>
ether 54:4a:16:e5:e7:9d txqueuelen 1000 (Ethernet)
RX packets 79 bytes 9988 (9.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 458 bytes 85028 (83.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 181

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 180 bytes 14118 (13.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 180 bytes 14118 (13.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.7.2 netmask 255.255.255.252 broadcast 192.168.7.3
inet6 fe80::564a:16ff:fee5:e79f prefixlen 64 scopeid 0x20<link>
ether 54:4a:16:e5:e7:9f txqueuelen 1000 (Ethernet)
RX packets 740 bytes 79447 (77.5 KiB)
RX errors 0 dropped 4 overruns 0 frame 0
TX packets 525 bytes 97473 (95.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.6.2 netmask 255.255.255.252 broadcast 192.168.6.3
ether 54:4a:16:e5:e7:a2 txqueuelen 1000 (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






share|improve this question













I'm using a beaglebone black with the newest IoT Debian 9 image (BeagleBoard.org Debian Image 2018-03-05)



Here is how I configured my network interfaces:



/etc/network/interfaces



# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.0.220
netmask 255.255.255.0
gateway 192.168.0.155

# Ethernet/RNDIS gadget (g_ether)
iface usb0 inet static
address 192.168.7.2
netmask 255.255.255.252
network 192.168.7.0
gateway 192.168.7.1

# Nameservers
dns-nameservers 192.168.0.155


After I start the interface, my routing table looks like this:



debian@beaglebone:~$ ip route
default via 192.168.0.155 dev eth0 onlink
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.220
192.168.6.0/30 dev usb1 proto kernel scope link src 192.168.6.2 linkdown
192.168.7.0/30 dev usb0 proto kernel scope link src 192.168.7.2


I can reach the internet via my default gateway and everything works as it should, but after 1-2 minutes some additional entries appear.



Now my routing table looks like this:



debian@beaglebone:~$ ip route
default dev eth0 scope link
default via 192.168.0.155 dev eth0 onlink
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.220
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.66.227
192.168.6.0/30 dev usb1 proto kernel scope link src 192.168.6.2 linkdown
192.168.7.0/30 dev usb0 proto kernel scope link src 192.168.7.2


Now the upper default gateway seems to be used instead of the one defined by me. As a result, the internet (and other internal networks) is not reachable.



This only happens if eth0 is connected to a network. All the other devices within the network I am using are also configured statically.



How can I get my system to use the default gw I want it to use?



I already tried to remove the default gateway from usb0 or putting it into an separate routing table, which resulted in the beaglebone being not reachable via any interface.



Here is the output of ifconfig, just in case somebody finds something suspicious here.



debian@beaglebone:~$ ifconfig
eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 192.168.0.220 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::564a:16ff:fee5:e79d prefixlen 64 scopeid 0x20<link>
ether 54:4a:16:e5:e7:9d txqueuelen 1000 (Ethernet)
RX packets 79 bytes 9988 (9.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 458 bytes 85028 (83.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 181

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 180 bytes 14118 (13.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 180 bytes 14118 (13.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.7.2 netmask 255.255.255.252 broadcast 192.168.7.3
inet6 fe80::564a:16ff:fee5:e79f prefixlen 64 scopeid 0x20<link>
ether 54:4a:16:e5:e7:9f txqueuelen 1000 (Ethernet)
RX packets 740 bytes 79447 (77.5 KiB)
RX errors 0 dropped 4 overruns 0 frame 0
TX packets 525 bytes 97473 (95.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.6.2 netmask 255.255.255.252 broadcast 192.168.6.3
ether 54:4a:16:e5:e7:a2 txqueuelen 1000 (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








share|improve this question












share|improve this question




share|improve this question








edited Jun 10 at 21:10









Jeff Schaller

31k846105




31k846105









asked May 29 at 8:26









Detonar

1062




1062







  • 3




    Can you check if network-manager is installed and running? This might conflict with your static config.
    – Winnie Tigger
    May 29 at 8:51











  • @Winnie Tigger - network-manager does not seem to be installed.
    – Detonar
    May 29 at 9:11










  • 169.254.*.* is a link-local IP, so something thinks eth0 is not configured, and is triggering configuration for it. My guess is that the 10.168.178.0 route comes from a DHCP server. (1) Look at syslog etc. for anything suspicious (2) Run tcpdump or wireshark on eth0 and see if you can catch any DHCP packets, then at least you know where it comes from.
    – dirkt
    May 29 at 9:19










  • Sure does the false entries come from a DHCP Server. But DHCP is quite normal in a Network. The cause of the problem must be something on the BB wich overrides the static config not the DHCP Server.
    – Winnie Tigger
    May 29 at 9:26






  • 1




    So this situation looks just strange to me. As I can see in your second routing-table, your default-gw ist still 192.168.0.155 on dev eth0. The 169... is, as "dirkt" stated, a Link-Local address, which means your BB sends DHCP request and gets no answer. Also it is /16 and your static IP is /24, which also means that this will be the preferred addres because of "longest prefix match" in ip-routing. So this needs some more debugging here. Are you familiar with tcpdump or tshark? Can you check if there is any program or process which is sending DHCP requests?
    – Winnie Tigger
    May 29 at 13:49












  • 3




    Can you check if network-manager is installed and running? This might conflict with your static config.
    – Winnie Tigger
    May 29 at 8:51











  • @Winnie Tigger - network-manager does not seem to be installed.
    – Detonar
    May 29 at 9:11










  • 169.254.*.* is a link-local IP, so something thinks eth0 is not configured, and is triggering configuration for it. My guess is that the 10.168.178.0 route comes from a DHCP server. (1) Look at syslog etc. for anything suspicious (2) Run tcpdump or wireshark on eth0 and see if you can catch any DHCP packets, then at least you know where it comes from.
    – dirkt
    May 29 at 9:19










  • Sure does the false entries come from a DHCP Server. But DHCP is quite normal in a Network. The cause of the problem must be something on the BB wich overrides the static config not the DHCP Server.
    – Winnie Tigger
    May 29 at 9:26






  • 1




    So this situation looks just strange to me. As I can see in your second routing-table, your default-gw ist still 192.168.0.155 on dev eth0. The 169... is, as "dirkt" stated, a Link-Local address, which means your BB sends DHCP request and gets no answer. Also it is /16 and your static IP is /24, which also means that this will be the preferred addres because of "longest prefix match" in ip-routing. So this needs some more debugging here. Are you familiar with tcpdump or tshark? Can you check if there is any program or process which is sending DHCP requests?
    – Winnie Tigger
    May 29 at 13:49







3




3




Can you check if network-manager is installed and running? This might conflict with your static config.
– Winnie Tigger
May 29 at 8:51





Can you check if network-manager is installed and running? This might conflict with your static config.
– Winnie Tigger
May 29 at 8:51













@Winnie Tigger - network-manager does not seem to be installed.
– Detonar
May 29 at 9:11




@Winnie Tigger - network-manager does not seem to be installed.
– Detonar
May 29 at 9:11












169.254.*.* is a link-local IP, so something thinks eth0 is not configured, and is triggering configuration for it. My guess is that the 10.168.178.0 route comes from a DHCP server. (1) Look at syslog etc. for anything suspicious (2) Run tcpdump or wireshark on eth0 and see if you can catch any DHCP packets, then at least you know where it comes from.
– dirkt
May 29 at 9:19




169.254.*.* is a link-local IP, so something thinks eth0 is not configured, and is triggering configuration for it. My guess is that the 10.168.178.0 route comes from a DHCP server. (1) Look at syslog etc. for anything suspicious (2) Run tcpdump or wireshark on eth0 and see if you can catch any DHCP packets, then at least you know where it comes from.
– dirkt
May 29 at 9:19












Sure does the false entries come from a DHCP Server. But DHCP is quite normal in a Network. The cause of the problem must be something on the BB wich overrides the static config not the DHCP Server.
– Winnie Tigger
May 29 at 9:26




Sure does the false entries come from a DHCP Server. But DHCP is quite normal in a Network. The cause of the problem must be something on the BB wich overrides the static config not the DHCP Server.
– Winnie Tigger
May 29 at 9:26




1




1




So this situation looks just strange to me. As I can see in your second routing-table, your default-gw ist still 192.168.0.155 on dev eth0. The 169... is, as "dirkt" stated, a Link-Local address, which means your BB sends DHCP request and gets no answer. Also it is /16 and your static IP is /24, which also means that this will be the preferred addres because of "longest prefix match" in ip-routing. So this needs some more debugging here. Are you familiar with tcpdump or tshark? Can you check if there is any program or process which is sending DHCP requests?
– Winnie Tigger
May 29 at 13:49




So this situation looks just strange to me. As I can see in your second routing-table, your default-gw ist still 192.168.0.155 on dev eth0. The 169... is, as "dirkt" stated, a Link-Local address, which means your BB sends DHCP request and gets no answer. Also it is /16 and your static IP is /24, which also means that this will be the preferred addres because of "longest prefix match" in ip-routing. So this needs some more debugging here. Are you familiar with tcpdump or tshark? Can you check if there is any program or process which is sending DHCP requests?
– Winnie Tigger
May 29 at 13:49










1 Answer
1






active

oldest

votes

















up vote
0
down vote













It seems like the problem was that connman was running on my machine. It ignored my configuration and inserted it's own stuff. After uninstalling connman everything worked as intended.






share|improve this answer





















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f446636%2frouting-table-adds-additional-default-entry%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote













    It seems like the problem was that connman was running on my machine. It ignored my configuration and inserted it's own stuff. After uninstalling connman everything worked as intended.






    share|improve this answer

























      up vote
      0
      down vote













      It seems like the problem was that connman was running on my machine. It ignored my configuration and inserted it's own stuff. After uninstalling connman everything worked as intended.






      share|improve this answer























        up vote
        0
        down vote










        up vote
        0
        down vote









        It seems like the problem was that connman was running on my machine. It ignored my configuration and inserted it's own stuff. After uninstalling connman everything worked as intended.






        share|improve this answer













        It seems like the problem was that connman was running on my machine. It ignored my configuration and inserted it's own stuff. After uninstalling connman everything worked as intended.







        share|improve this answer













        share|improve this answer



        share|improve this answer











        answered Jun 21 at 7:40









        Detonar

        1062




        1062






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f446636%2frouting-table-adds-additional-default-entry%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay