search

openwrt / packages

Community maintained packages for OpenWrt. Documentation for submitting pull requests is in CONTRIBUTING.md
GNU General Public License v2.0
3.94k stars 3.46k forks source link

mwan3: IPv6 address tracking doesn't work for IPv6-in-IPv4 tunnel interfaces #9861

Closed ashway83 closed 4 years ago

ashway83 commented 5 years ago

Maintainer: @feckert , @luizluca Environment: OpenWrt 18.06.4 r7808-ef686b7292 / LuCI openwrt-18.06 branch (git-19.170.32094-4d6d8bc)

Description:

mwan3track fails to track IPv6-in-IPv4 tunnel interfaces as

ping -I <interface>...

results in link local address being used as a source address.

root@OpenWRT:~# ifconfig
6in4-wan6 Link encap:IPv6-in-IPv4
          inet6 addr: fe80::xxxx:xxxx/64 Scope:Link
          inet6 addr: 2001:xxx:xx:xxx::2/64 Scope:Global
          UP POINTOPOINT RUNNING NOARP  MTU:1280  Metric:1
          RX packets:2551 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3885 errors:0 dropped:689 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:217476 (212.3 KiB)  TX bytes:525551 (513.2 KiB)

ICMP request are sent with a link local address set as a source:

root@OpenWRT:~# ping -I 6in4-wan6 -c 3 2001:4860:4860::8888
PING 2001:4860:4860::8888 (2001:4860:4860::8888): 56 data bytes

--- 2001:4860:4860::8888 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Expected behavior (public IPv6 address is used as a source address):

root@OpenWRT:~# ping -I 2001:xxx:xx:xxx::2 -c 3 2001:4860:4860::8888
PING 2001:4860:4860::8888 (2001:4860:4860::8888) from 2001:470:70:46b::2: 56 data bytes
64 bytes from 2001:4860:4860::8888: seq=0 ttl=58 time=15.708 ms
64 bytes from 2001:4860:4860::8888: seq=1 ttl=58 time=17.387 ms
64 bytes from 2001:4860:4860::8888: seq=2 ttl=58 time=15.723 ms

--- 2001:4860:4860::8888 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 15.708/16.272/17.387 ms

The same issue mentioned here remained without attention for some reason: https://github.com/openwrt/packages/issues/5761#issuecomment-449735810

feckert commented 5 years ago

So your suggestion is to use the on IPv6 public IP on this Interface and not the device itself on the ping -I option. Because if not the link address is used as the source IP?

ashway83 commented 5 years ago

Apparently, ping -I uses first IP address on the interface. In case of IPv6, it's a link local address, packets with such source address are not supposed to travel to the outer world. Thus, it doesn't make sense to ping Internet hosts this way. A more universal solution would be to introduce "src_address" option on the interface, that would allow to specify an exact IP address, when there are multiple addresses on the interface.

jow- commented 5 years ago

Interestingly the order of the addresses is reversed in my case:

root@jj:~# ifconfig 
6in4-wan6 Link encap:IPv6-in-IPv4  
          inet6 addr: 2001:xxxx::2/64 Scope:Global
          inet6 addr: fe80::xxxx/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1280  Metric:1
          RX packets:359794 errors:0 dropped:0 overruns:0 frame:0
          TX packets:413788 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:478579495 (456.4 MiB)  TX bytes:52696312 (50.2 MiB)

And ping -I netdev works as expected:

root@jj:~# ping -I 6in4-wan6 -c 3 2001:4860:4860::8888
PING 2001:4860:4860::8888 (2001:4860:4860::8888): 56 data bytes
64 bytes from 2001:4860:4860::8888: seq=0 ttl=57 time=41.787 ms
64 bytes from 2001:4860:4860::8888: seq=1 ttl=57 time=40.020 ms
64 bytes from 2001:4860:4860::8888: seq=2 ttl=57 time=41.639 ms

--- 2001:4860:4860::8888 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 40.020/41.148/41.787 ms

@ashway83 - I wouldn't rule out a bug in busybox' ping source address selection logic. Can you cross-check with a full featured ping6 from iputils-ping6 ?

ashway83 commented 5 years ago

@jow- Just tried ping6 from iputils-ping6 - works as expected.

jamesmacwhite commented 4 years ago

I'm experiencing the same issue with pinging on v6 interfaces, it looks related to the source address. ping6 from iputils-ping6 works without having to explicitly define the source address on the interface, but mwan3 doesn't using ping6 for testing, it seems it's the same ping commands across both IPv4/IPv6, however installing iputils-ping, causes ping tests to fail entirely with:

ping: unknown host 2001:4860:4860::8888

Although this may be fixed by this now:

https://github.com/openwrt/packages/pull/11564

feckert commented 4 years ago

Yes this change https://github.com/openwrt/packages/commit/6721587e8b491f1a539cdcc507b0f4811ff2b448 should fix the problem. It no longer uses the link local adress the correct assigned IPv6 adress. This change was only made in the master branch. Should we cherry-pick this also to 19.07?. The branch 18.06 is EOL.

jamesmacwhite commented 4 years ago

It would be nice if it was cherry picked to 19.07 branch, I tested the version in master on 19.07.2 and it fixes the issue specifically with the 6in4-wan6 interface.

feckert commented 4 years ago

Please try my changes in this pull request https://github.com/TDT-AG/packages/tree/pr/20200428-mwan3. If this works for you then I will merge this into 19.07

jamesmacwhite commented 4 years ago

I did test mwan3 2.8.3-2 and it works on 19.07.2 aside from that rogue character that snuck in on the line 139, but removing that works fine. So given the change between 2.8.3-2 and 2.8.4 is just the removal of the character, I can say it works on 19.07.2. The 6in4-wan6 interface is seen as "online" because the ping test is more absolute with the source address.