netctl: can ping from one interface but not the other

MALDATA · 04-09-2019, 05:22 PM

I've got a device that is connected to one network via ethernet and a different network via wifi. I use netctl to manage the interfaces. What I have noticed is that, when both netctl profiles are active, pings fail when the wifi interface is specified:

Code:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether b8:27:eb:eb:ab:dc brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.200/21 brd 192.168.7.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:feeb:abdc/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether b8:27:eb:be:fe:89 brd ff:ff:ff:ff:ff:ff
    inet 10.10.0.89/23 brd 10.10.1.255 scope global noprefixroute wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:febe:fe89/64 scope link 
       valid_lft forever preferred_lft forever

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
0.0.0.0         10.10.0.1       0.0.0.0         UG    303    0        0 wlan0
10.10.0.0       0.0.0.0         255.255.254.0   U     303    0        0 wlan0
192.168.0.0     0.0.0.0         255.255.248.0   U     0      0        0 eth0

$ ping -c4 -Ieth0 google.com
PING google.com (74.125.136.100) from 192.168.1.200 eth0: 56(84) bytes of data.
64 bytes from 74.125.136.100 (74.125.136.100): icmp_seq=1 ttl=44 time=21.4 ms
64 bytes from 74.125.136.100 (74.125.136.100): icmp_seq=2 ttl=44 time=21.3 ms
64 bytes from 74.125.136.100 (74.125.136.100): icmp_seq=3 ttl=44 time=21.10 ms
64 bytes from 74.125.136.100 (74.125.136.100): icmp_seq=4 ttl=44 time=37.1 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 21.317/25.440/37.086/6.729 ms

$ ping -c4 -Iwlan0 google.com
PING google.com (74.125.136.138) from 10.10.0.89 wlan0: 56(84) bytes of data.

--- google.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 154ms

If I do netctl stop my-ethernet-profile, then I can successfully ping using the wifi interface. If I start the ethernet profile again, then pinging from the wlan0 interface fails again.

What's more, if I leave both netctl profiles running but simply disconnect the ethernet cable, I notice that eth0 keeps its configuration, it just has its state changed from UP to DOWN in the output of ip a. Nothing else changes, and I still can't ping from wlan0.

I'm sure there's a reasonable explanation for this, but I'm struggling to put together the right search terms to describe it. Can anyone offer an explanation?

Thanks!

frankbell · 04-09-2019, 05:25 PM

Is ICMP blocked on one of the interfaces?

MALDATA · 04-09-2019, 09:48 PM

Quote:

Is ICMP blocked on one of the interfaces?

No. As I mentioned above, if I do netctl stop my-ethernet-profile, then I can successfully ping using the wifi interface. If I start the ethernet profile again, then pinging from the wlan0 interface fails again.

Thanks

pingu_penguin · 04-15-2019, 09:51 AM

Did you try using the same dns for both profiles? (8.8.8.8)

my gut feeling says the dns for both networks are different, activating one interface gives one dns that is not accessible over the other network.

Hope this helps.

thinknix · 04-15-2019, 10:20 AM

I believe this is your issue:

Quote:

$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 10.10.0.1 0.0.0.0 UG 303 0 0 wlan0

You have two default routes, attached to both eth0 and wlan0. A higher metric means lower priority, so when you activate eth0 its default route takes priority and all your packets that don't match a specific route head out eth0 instead of wlan0. To fix it you should remove the default route from eth0, typically internal interfaces on a multi-homed server don't need a default route attached to them.