On 04/01/2017 04:24 PM, David C. Rankin wrote:

Yes, this is a PITA. There is supposed to be a rate prioritization routine that runs to always provide a route via the fastest connection. My experience is that it just confuses the sh.. out of whatever is supposed to provide the default route, and network traffic comes to a screeching halt.

Indeed. I seem to recall this had something to do with the "metric" parameter. While refreshing my memory on the meaning of the "metric" column in the following:

jsa@poulsbo:~> ip r default via 192.168.2.1 dev eth0 proto static metric 100 default via 192.168.86.1 dev wlan0 proto static metric 600 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.232 metric 100 192.168.86.0/24 dev wlan0 proto kernel scope link src 192.168.86.232 metric 600 192.168.193.0/24 dev vmnet8 proto kernel scope link src 192.168.193.1

...I came across an oblique reference to the fact that modern kernels seem to pay that value no heed any more. See https://www.cyberciti.biz/faq/what-is-a-routing-table/ -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/01/2017 10:39 PM, Andrei Borzenkov wrote:

02.04.2017 01:55, John Andersen пишет:

...

On My laptop:

If I plug a cat5 cable in, my wlan0 becomes unuseable.

It still has an IP. Network Manager still shows it connected. Kde Connect to my phone still works.

But: Ping -I wlan0 <target> doesn't work via wlan0 wget --bind-address=(wlan0-IP) fails Existing ssh connections via wlan0 become dead

Is this Intentional and Normal?

Show "ip a" and "ip r" output with both interfaces connected.

Here it is, along with a simple ping test, one via each:

jsa@poulsbo:~> ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 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 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:15:c5:55:97:51 brd ff:ff:ff:ff:ff:ff inet 192.168.2.232/24 brd 192.168.2.255 scope global dynamic eth0 valid_lft 10767sec preferred_lft 10767sec inet6 fe80::215:c5ff:fe55:9751/64 scope link valid_lft forever preferred_lft forever 3: wlan0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:16:cf:89:40:37 brd ff:ff:ff:ff:ff:ff inet 192.168.86.232/24 brd 192.168.86.255 scope global dynamic wlan0 valid_lft 86361sec preferred_lft 86361sec inet6 fe80::216:cfff:fe89:4037/64 scope link valid_lft forever preferred_lft forever 4: vmnet8: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff inet 192.168.193.1/24 brd 192.168.193.255 scope global vmnet8 valid_lft forever preferred_lft forever jsa@poulsbo:~> jsa@poulsbo:~> ip r default via 192.168.2.1 dev eth0 proto static metric 100 default via 192.168.86.1 dev wlan0 proto static metric 600 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.232 metric 100 192.168.86.0/24 dev wlan0 proto kernel scope link src 192.168.86.232 metric 600 192.168.193.0/24 dev vmnet8 proto kernel scope link src 192.168.193.1 jsa@poulsbo:~> ping -I wlan0 www.alaska.net PING aws01.nwc.acsalaska.net (209.112.129.41) from 192.168.86.232 wlan0: 56(84) bytes of data. ^C --- aws01.nwc.acsalaska.net ping statistics --- 6 packets transmitted, 0 received, 100% packet loss, time 5034ms

Ping tests:

jsa@poulsbo:~> ping -I eth0 www.alaska.net PING aws01.nwc.acsalaska.net (209.112.129.41) from 192.168.2.232 eth0: 56(84) bytes of data. 64 bytes from 209.112.129.41: icmp_seq=1 ttl=53 time=47.7 ms 64 bytes from 209.112.129.41: icmp_seq=2 ttl=53 time=46.2 ms ^C --- aws01.nwc.acsalaska.net ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 46.242/46.988/47.734/0.746 ms

If I reach around back and disconnect the cat5, then wlan0 will ping just fine but with both up, wifi gets essentially choked off somehow. I remember quite explicity that this did use to work on this very same hardware a version or two ago 13.2 or maybe 12.?. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/02/2017 01:15 AM, Andrei Borzenkov wrote:

02.04.2017 09:38, John Andersen пишет:

...

On 04/01/2017 10:39 PM, Andrei Borzenkov wrote:

...

02.04.2017 01:55, John Andersen пишет:

...

On My laptop:

If I plug a cat5 cable in, my wlan0 becomes unuseable.

It still has an IP. Network Manager still shows it connected. Kde Connect to my phone still works.

But: Ping -I wlan0 <target> doesn't work via wlan0 wget --bind-address=(wlan0-IP) fails Existing ssh connections via wlan0 become dead

Is this Intentional and Normal?

Show "ip a" and "ip r" output with both interfaces connected.

Here it is, along with a simple ping test, one via each:

...

jsa@poulsbo:~> ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 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 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:15:c5:55:97:51 brd ff:ff:ff:ff:ff:ff inet 192.168.2.232/24 brd 192.168.2.255 scope global dynamic eth0 valid_lft 10767sec preferred_lft 10767sec inet6 fe80::215:c5ff:fe55:9751/64 scope link valid_lft forever preferred_lft forever 3: wlan0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:16:cf:89:40:37 brd ff:ff:ff:ff:ff:ff inet 192.168.86.232/24 brd 192.168.86.255 scope global dynamic wlan0 valid_lft 86361sec preferred_lft 86361sec inet6 fe80::216:cfff:fe89:4037/64 scope link valid_lft forever preferred_lft forever 4: vmnet8: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff inet 192.168.193.1/24 brd 192.168.193.255 scope global vmnet8 valid_lft forever preferred_lft forever jsa@poulsbo:~> jsa@poulsbo:~> ip r default via 192.168.2.1 dev eth0 proto static metric 100 default via 192.168.86.1 dev wlan0 proto static metric 600 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.232 metric 100 192.168.86.0/24 dev wlan0 proto kernel scope link src 192.168.86.232 metric 600

How these two interfaces are connected? Do they go to the same router?

eth0 is connected via cat5 to 192.168.2.1 (192.168.2.1 is an opensuse box which is my main router/firewall/gateway). Wlan0 is connected by wifi to 192.168.86.1 (wifi router) which is connected to that same 192.168.2.1 network. So yes, eventually wlan0 arrives at the same router as does eth0. But here's the thing... After bringing up both interfaces: eth0 can ping just about anywhere. wlan0 can't ping anywhere beyond its own subnet. Taking down eth0 makes wlan0 instantly able to ping anywhere.

Does it work if you create explicit route to this host?

ip route add 209.112.129.41/32 via 192.168.86.1 dev wlan0

Yes, after adding this route I can ping that specific machine. Removing that route blocks pinging that IP again. Does this suggest that Network Manager removes ALL routes from a wifi interface when a wired interface becomes available? Is this intentional? It didn't use to be that way in past releases. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/02/2017 09:01 PM, Andrei Borzenkov wrote:

When Ethernet interface comes up, NM adds default route with better priority (lower metric), so now all traffic will go via this route. "ping -I" does not select *interface* via which packets are sent - it just selects own (source) address. Via which interface packet will flow is determined by routing table ("source address selection" vs. "outgoing interface selection").

The above differs from that the opensuse Ping man page says. It says, with regard to the -I parameter:

-I interface interface is either an address, or an interface name. If interface is an address, it sets source address to specified interface address. If inter- face in an interface name, it sets source interface to specified interface.

Maybe we need to file a bug report against the man page. The third sentence clearly states it should go out the specified interface. Reading many bug reports on this, I suspect I'm not the first one to read it that way. However, a quick test reveals that ping -I wlan0 lists.opensuse.org and ping -I 192.169.86.232 lists.opensuse.org Both fail in the same way: 100% packet loss.

What happens now, system sends packet with source address 192.168.86.232 via default gateway 192.168.2.1 to the outside world. It means 192.168.2.1 must be able to do two things

a) correctly mangle packet by replacing source address with external (otherwise no reply can be received)

b) correctly forward packet received on mangled address back to your system

This seems like a reasonable explanation and agrees with what James Knott's tests shows. But it puts the lie to the man page.

Either of this may fail. You 192.168.2.1 box may be configured to masquerade only 192.168.2.0/24 range. Even if it does masquerading, when it receives reply and demangles it, it most likely does not know what to do with packet for destination 192.168.86.232, because 192.168.86.0/24 network is itself hidden behind the second box. Finally, if it arrives at your wlan0, kernel may actually drop it depending on rp_filter setting.

Capturing traffic on both eth0 and wlan0 during ping may give some hints where it chokes.

You may make it work by creating second routing table and making all traffic with source 192.168.86.232 using it. Something like (untested)

ip route add 192.168.86.0/24 dev wlan0 src 192.168.2.232 scope link table 128 ip route add default via 192.168.86.1 dev wlan0 table 128 ip rule add from 192.168.86.232 table 128

I'm going to give these a try tomorrow when I have time to set up the machines while watching the logs. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/02/2017 12:27 PM, James Knott wrote:

Are the Ethernet and WiFi connections on the same network? If so, only one will be usable. This is entirely normal, due to something called "metric". This represents the cost of using the connection and the lowest cost will be used. Use the "ip route show" command to see what the metrics are. On my notebook, WiFi is 600 and Ethernet 100, so Ethernet will be used. When the Ethernet cable is disconnected, only the WiFi connection is listed, with a metric of 600 and is used.

When you tell ping to use a specific interface, you have already overridden metric. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/02/2017 01:52 PM, James Knott wrote:

So, it appears the ip route metric overrides the ping -I <interface> and chooses the lowest cost path regardless.

Nope. ping -I wlan0 lists.opensuse.org will never go out any other interface than wlan0. Metric plays no part. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/02/2017 09:48 PM, James Knott wrote:

On 04/02/2017 08:58 PM, John Andersen wrote:

...

On 04/02/2017 01:52 PM, James Knott wrote:

...

So, it appears the ip route metric overrides the ping -I <interface> and chooses the lowest cost path regardless. Nope.

ping -I wlan0 lists.opensuse.org will never go out any other interface than wlan0. Metric plays no part.

Actually, I tried it and watched what happened with Wireshark. I also verified the arp cache to see what MAC address was used. As I mentioned, I tried it first with both interfaces on the same network and even though I specified WiFi, it went via Ethernet. When I put the Ethernet port on a different network, the ping then went via WiFi.

BTW, I agree specifying the interface should take precedence over the metric, but it doesn't appear to. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

03.04.2017 06:07, John Andersen пишет:

...

BTW, I agree specifying the interface should take precedence over the metric, but it doesn't appear to.

Does here. Those packets go nowhere. No ping completed, all packets lost.

What about packet capture during ping from wlan0? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/02/2017 09:48 PM, James Knott wrote:

On 04/02/2017 08:58 PM, John Andersen wrote:

...

On 04/02/2017 01:52 PM, James Knott wrote:

...

So, it appears the ip route metric overrides the ping -I <interface> and chooses the lowest cost path regardless. Nope.

ping -I wlan0 lists.opensuse.org will never go out any other interface than wlan0. Metric plays no part.

Actually, I tried it and watched what happened with Wireshark. I also verified the arp cache to see what MAC address was used. As I mentioned, I tried it first with both interfaces on the same network and even though I specified WiFi, it went via Ethernet. When I put the Ethernet port on a different network, the ping then went via WiFi.

I've been wondering, does -I actually force an interface or just specify where the ping command starts from and routing sends it out the other port? I seem to recall Cicso routers do that, but I'll have to verify. When I use -I to specify wlan0, the IP address is the one for wlan0, but the ping still comes out eth0. I just tried an experiment. I used -I wlan0 and used Wireshark to monitor wlan0. There I see the MAC for wlan0 on outgoing pings, but I don't see any replies. Wireshark on the target computer shows packets in both directions, but with the MAC for eth0. When I monitor eth0, I see only the replies to the wlan0 IP address, but eth0 MAC. The ARP cache on the target computer shows the eth0 MAC for both eth0 and wlan0 IP addresses. This implies the ARP reply for the wlan0 address came out through eth0 too. In all cases, the wlan0 IP address was shown. Bottom line, the ping originates from the wlan0 IP & MAC address, gets passed out eth0 with the eth0 MAC and replies are to the wlan0 IP address, but eth0 MAC. The computer is routing to the appropriate interface, based on the metric. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/03/2017 10:37 AM, James Knott wrote:

Bottom line, the ping originates from the wlan0 IP & MAC address, gets passed out eth0 with the eth0 MAC and replies are to the wlan0 IP address, but eth0 MAC. The computer is routing to the appropriate interface, based on the metric.

If I ping the wlan0 address from the other computer, Wireshark shows both ping request & reply on eth0 and nothing on wlan0. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org