I have an OdroidH2 with docker setup.
It was working fine for a few months and suddenly, out of nowhere it stopped having any internet/intranet connectivity.
It's connectivity is going through an Ethernet cable, not WiFi and the interface that is supposed to have the connection is enp3s0 with an ip address of 192.168.1.100.
I have performed the following troubleshooting steps:
Restart (of course, always the first step)
Checked interface settings via ifconfig and also in /etc/network/interfaces
Checked the routing via route -n
Checked iptables (iptables was populated with the docker configuration, I've flushed the iptables including nat and mangle and set the default policy to ACCEPT for input, forward and output. Restarted the networking service afterwards)
Checked if it was able to ping itself and the default gateway (it is able to ping itself but not the gateway, or any other devices)
Checked if another device was able to ping the OdroidH2 (host unreachable)
Checked dmesg and for some reason, I had 2 firmwares that were not able to be loaded (already installed and rebooted after installation):
rtl_nic/rtl8168g-2.fw (after checking, this is the firmware for the network interfaces)
i915/glk_dmc_ver1_04.bin (didn't research much about this one, something to do with runtime power management??)
After all of these steps, I still am unable to get the network connectivity going.
Below you can find information regarding my current configuration:
dmesg output
Stackoverflow does not allow me to put all the information from my dmesg output so I had to put it on google drive: dmesg_output
/etc/hosts
127.0.0.1 localhost
192.168.1.100 dc1 dc1.samdom.andrewoliverhome.local samdom.andrewoliverhome.local
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
iptables -nvL output (after clearing and reloading the networking service)
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
/etc/resolv.conf
#nameserver 127.0.0.1
#nameserver 8.8.8.8
#nameserver 8.8.4.4
search samdom.andrewoliverhome.local
#domain samdom.andrewoliverhome.local
nameserver 192.168.1.100
nameserver 8.8.8.8
route -n output
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 enp3s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker_gwbridge
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-debc10cb5b21
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
/etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo enp2s0 enp3s0
#auto lo br0
iface lo inet loopback
# The primary network interface
iface enp2s0 inet dhcp
allow-hotplug enp2s0 enp3s0
#iface enp2s0 inet manual
# post-up iptables-restore < /etc/iptables.up.rules
# This is an autoconfigured IPv6 interface
#iface enp2s0 inet dhcp
iface enp3s0 inet static
address 192.168.1.100
netmask 255.255.255.0
# broadcast 169.254.99.255
network 192.168.1.0
gateway 192.168.1.254
#iface enp2s0 inet manual
#iface enp3s0 inet manual
#iface br0 inet static
# bridge_ports enp2s0 enp3s0
# address 192.168.1.100
# broadcast 192.168.1.255
# netmask 255.255.255.0
# gateway 192.168.1.254
#
In /etc/resolv.conf, the reason I have the primary nameserver to be itself is because I am running a docker container that is serving as a samba-ad-dc.
In order for OdroidH2 to find all of my devices in the domain, it needs to make dns queries to the samba dc, if samba is not able to find a dns record, it will autoforward it to 8.8.8.8.
Any help would be greatly appreciated (:
After all the troubleshooting done, the issue is not within the OdroidH2 itself, it was with my router.
The LAN port that I'm using malfunctioned. I switched the Ethernet cable to a different LAN port and it worked.
Related
I have one linux box with 2 interfaces, wlan0 and wlan1. wlan0 connects to an external wlan AP of subnet 192.168.43.x. On wlan1 a softap is running on subnet 192.168.60.x.
I have run following commands to start nat and ip_forward:
iptables -F
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -t nat -F
iptables -t mangle -F
iptables -A INPUT -j ACCEPT
iptables -A OUTPUT -j ACCEPT
iptables -A FORWARD -j ACCEPT
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
Another pc e6220 is connected to 192.168.60.x softap. I want to forward pc's traffic to external network 192.168.43.x.
network graph:
external AP (192.168.43.1) <~~~> {wlan0(192.168.43.2), <-- forward --> internal AP on wlan1(192.168.60.1)} <~~~> e6220 (192.168.60.46)
After adding route on pc, icmp and udp works fine, both can reach 192.168.43.1, but tcp doesn't work!
userg#e6220:~ $ ping 192.168.43.1
PING 192.168.43.1 (192.168.43.1) 56(84) bytes of data.
64 bytes from 192.168.43.1: icmp_seq=1 ttl=63 time=9.74 ms
64 bytes from 192.168.43.1: icmp_seq=2 ttl=63 time=9.57 ms
^C
user#e6220:~ $ telnet 192.168.43.1
Trying 192.168.43.1...
telnet: Unable to connect to remote host: Network is unreachable
Capture on linux box wlan1:
17:10:57.579994 IP 192.168.60.46.56412 > 192.168.43.1.telnet: Flags [S], seq 1764532258, win 29200, options [mss 1460,sackOK,TS val 2283575078 ecr 0,nop,wscale 7], length 0
17:10:57.580075 IP 192.168.60.1 > 192.168.60.46: ICMP net 192.168.43.1 unreachable, length 68
No packets seen on wlan0.
It's strange kernel says unreachable, but UDP works.
// route -n output
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.43.1 0.0.0.0 UG 0 0 0 wlan0
192.168.43.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
192.168.60.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan1
I think this may be kernel-version specific. On Linux 3.4.x both tcp and udp are good. This issue is seen on Linux 3.10.61. I want to know if there's any way to fix it, kernel configuration or iptables command. Thanks!
Finally I got the solution.
The routing box is configured with CONFIG_IP_MULTIPLE_TABLES, which is policy routing. The routing rule is:
# ip rule list
0: from all lookup local
10000: from all fwmark 0xc0000/0xd0000 lookup legacy_system
13000: from all fwmark 0x10063/0x1ffff lookup local_network
15000: from all fwmark 0x0/0x10000 lookup legacy_system
16000: from all fwmark 0x0/0x10000 lookup legacy_network
17000: from all fwmark 0x0/0x10000 lookup local_network
23000: from all fwmark 0x0/0xffff uidrange 0-0 lookup main
32000: from all unreachable
So every packet goes to "unreachable". TCP turns good after adding following rules:
# ip rule add iif wlan0 table main
# ip rule add iff wlan1 table main
# ip rule list
0: from all lookup local
9998: from all iif wlan0 lookup main
9999: from all iif wlan1 lookup main
10000: from all fwmark 0xc0000/0xd0000 lookup legacy_system
13000: from all fwmark 0x10063/0x1ffff lookup local_network
15000: from all fwmark 0x0/0x10000 lookup legacy_system
16000: from all fwmark 0x0/0x10000 lookup legacy_network
17000: from all fwmark 0x0/0x10000 lookup local_network
23000: from all fwmark 0x0/0xffff uidrange 0-0 lookup main
32000: from all unreachable
But I still don't know why UDP is good before adding these 2 rules.
I created a custom Buildroot 2015.01 distribution w/ 3.10.0 Linux Kernel with enabled IPv6 support in the Toolchain and the uClibc library.
There is a strange behaviour that takes place when trying to contact any IPv6 routed address, for example:
# wget google.com
Connecting to google.com ([2a00:1450:4002:809::200e]:80)
wget: can't connect to remote host: Network is unreachable
But, if I try the same thing on a non-IPv6 address, everything works correctly:
# wget abc.com
Connecting to abc.com (199.181.132.250:80)
Connecting to abc.go.com (23.21.209.55:80)
index.html 100% |*******************************| 46408 0:00:00 ETA
This is the IPv6 kernel routing table:
# route -A inet6
Destination Next Hop Flags Metric Ref Use Iface
::1/128 :: U 0 0 1 lo
fe80::20a:a5ff:fe12:3446/128 :: U 0 0 1 lo
fe80::/64 :: U 256 0 0 eth0
ff02::1:ffdc:adf/128 :: UC 0 1 0 eth0
ff02::1:fff4:5e3d/128 :: UC 0 1 0 eth0
ff00::/8 :: U 256 0 0 eth0
IPv4 one:
# route -A inet
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.230 0.0.0.0 UG 0 0 0 eth0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
Any help or suggestion would be very appreciated.
I solved the issue by installing standard wget instead of the Busybox's integrated one.
As it seems our internal network was not IPv6 capable and Busybox's wget stopped when it couldn't reach the destination. Standard wget, instead, falls back to the IPv4 address, completing the download.
EDIT: apart from our network, seems Busybox's wget has some issues
I'm newbie in networking field. I have trouble with my web server Network configuration (OS is Centos).
I have 2 NICs (eth0 + eth2 - physically) running 2 public IP which have the same subnet, same gateway.
When I configure nginx to listen on these 2 NICs, everything works just fine. But when I monitor the traffic, all traffic is on the eth0 only, nothing on eth2.
My question is: How can I configure so that traffic goes in a NIC, go out on that NIC, too?
This is my ethernet card config:
DEVICE="eth0"
ONBOOT=yes
BOOTPROTO=static
IPADDR=x.x.x.38
PREFIX=27
GATEWAY=x.x.x.x.33
DNS1=8.8.8.8
DNS2=8.8.4.4
NAME="System eth0"
DEVICE="eth2"
ONBOOT=yes
BOOTPROTO=static
IPADDR=x.x.x.39
PREFIX=27
GATEWAY=x.x.x.33
DNS1=8.8.8.8
DNS2=8.8.4.4
NAME="System eth2"
This is my route -n result
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.14.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
y.z.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
y.z.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1
y.z.0.0 0.0.0.0 255.255.0.0 U 1004 0 0 eth2
0.0.0.0 x.x.x.33 0.0.0.0 UG 0 0 0 eth0
Hope you can help, thanks in advanced!
In Linux, routing is performed by looking at the destination address only, so a packet will follow whichever route can be used to reach the packet's destination, with no regard to the source address.
The behaviour you want requires choosing a route depending not only on the destination address, but also on the source address — this is sometimes called source-sensitive routing or SADR (source-address dependent routing). The most portable way of implementing source-sensitive routing under Linux is to define routing rules across multiple routing tables using the ip rule and ip route ... table ... commands.
This is described in detail in Section 4 of the Linux Advanced Routing and Traffic Control HOWTO
Probably, the problem can be solved even with NAT.
ip tuntap add dev tap0 mode tap
ip tuntap add dev tap1 mode tap
Then you can assign separate ip addresses to these devices:
ifconfig tap0 10.10.10.1 netmask 255.255.255.255
ifconfig tap1 10.10.10.2 netmask 255.255.255.255
And finally - redirect incoming traffic to specific virtual device
iptables -t nat -A PREROUTING -i eth0 -j DNAT --to-destination 10.10.10.1
iptables -t nat -A PREROUTING -i eth2 -j DNAT --to-destination 10.10.10.2
In this case, all traffic will be routed definetely to the interface it came from.
Quite easy use-case: I have two Ethernet interfaces which should both be connected using DHCP. It does not matter which one the default route is, since it is just a dedicated proof-of-concept setup. However, hot-plugging must work for both interfaces (one of them is a CDC-NCM connection).
connman 1.17 seems only to try to establish a connection to one of the interfaces. If I unplug this connection, DHCP is started on the second interface and everything continues to work. I can connect the second interface always by using “connmanctl connect” manually. But…
… is there any way to configure connman to connect AUTOMATICALLY to both networks via DHCP?
is there any way to configure connman to connect AUTOMATICALLY to both networks via DHCP?
By default most DHCP servers are configured to issue a default route to the client. If you get two default routes, it's impossible for the linux networking stack to function properly.
Since you would want DHCP clients on both networks to be able to function properly, perhaps the best thing you can do is scan the system routing table and remove one of the default routes.
Typically you'd use netstat -rn to find the duplicate default...
[mpenning#tsunami micro]$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
172.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
172.16.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
239.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
0.0.0.0 172.16.1.1 0.0.0.0 UG 0 0 0 eth0 <--
0.0.0.0 172.16.2.1 0.0.0.0 UG 0 0 0 eth1 <--
[mpenning#tsunami micro]$
Then remove one of them...
[mpenning#tsunami micro]$ sudo route del default dev eth1
[mpenning#tsunami micro]$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
172.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
172.16.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
239.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
0.0.0.0 172.16.1.1 0.0.0.0 UG 0 0 0 eth0
[mpenning#tsunami micro]$
It's not so hard to write a shell script to check for this issue. However, a better solution is just to get a static address on one of the networks so you don't have to manage around the DHCP issue.
I'm trying to test a gateway I wrote(see What's the easiest way to test a gateway? for context). Due to an issue I'd rather not get into, the gateway and "sender" have to be on the same machine. I have a receiver(let's say 9.9.9.9) which the gateway is able to reach.
So I'll run an application ./sendStuff 9.9.9.9 which will send some packets to that IP address.
The problem is: how do I get the packets destined for 9.9.9.9 to go to the gateway on localhost? I've tried:
sudo route add -host 9.9.9.9 gw 127.0.0.1 lo
sudo route add -host 9.9.9.9 gw <machine's external IP address> eth0
but neither of those pass packets through the gateway. I've verified that the correct IPs are present in sudo route. What can I do?
Per request, here is the route table, after running the second command(IP addresses changed to match the question. x.y.z.t is the IP of the machine I'm running this on):
Destination Gateway Genmask Flags Metric Ref Use Iface
9.9.9.9 x.y.z.t 255.255.255.255 UGH 0 0 0 eth0
x.y.z.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
0.0.0.0 <gateway addr> 0.0.0.0 UG 100 0 0 eth0
127.0.0.1 is probably picking up the packets, then forwarding them on their merry way if ipv4 packet forwarding is enabled. If it's not enabled, it will drop them.
If you are trying to forward packets destined to 9.9.9.9 to 127.0.0.1, look into iptables.
Edit: try this:
iptables -t nat -A OUTPUT -d 9.9.9.9 -j DNAT --to-destination 127.0.0.1
That should redirect all traffic to 9.9.9.9 to localhost instead.