mwan3: Limit sed IPv6 source address lookup to one address only

[jamesmacwhite]

Maintainer: @feckert Environment: OpenWrt 19.07.2 Linksys WRT3200ACM

Description:

The improvements by @brianjmurrell are great for IPv6 interfaces, however a possible scenario with an IPv6 interface is having more than one IPv6 global address configured, in my case one WAN interface has a /64 and /128 global address like this:

eth0.3    Link encap:Ethernet
          inet addr:192.168.2.2  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: 2a01:4c8:c50:cf10:xxxx:xxx:xxxxx:xxxx/64 Scope:Global
          inet6 addr: 2a01:4c8:c50:cf10:xxx:xxxx:x:xxxx/128 Scope:Global
          inet6 addr: fe80::3023:3ff:fedf:2c80/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5048775 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7443033 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4148993889 (3.8 GiB)  TX bytes:4522163208 (4.2 GiB)

This will mean the ADDR variable in mwan3track will return the two global IPv6 addresses. In this case the /64 being the first one is the correct source address, but because there is no handling of multiple IPv6 addresses being returned, the mwan3track ping test will fail even though the connectivity is fine, as it will try to use the value of the source address as:

2a01:4c8:c50:cf10:xxxx:xxx:xxxx:xxxx
2a01:4c8:c50:cf10:xxxx:xxxx:x:xxx

My initial thought would be to add | head -1 so only the first match from sed is returned, which is then passed to the ping test command.

[dersch81]

Having exactly the same issue here.

[jamesmacwhite]

I think in fairness the IPv6 source address additions were primarily written from an 6in4 interface viewpoint, which only will have one global address, but given my own recent testing and experience, OpenWrt doesn't seem to be able to automatically determine the correct source address in some cases, so this code greatly improves compatibility with IPv6 interfaces and mwan3 overall it just needs to be perhaps aware of the potential scenario of multiple global IPv6 address being configured.

The first address always being the right source address, that's another question and would need to be expanded on if not suitable, but for me limiting the sed output to 1 match works.

[brianjmurrell]

I thought this was just some weird aspect of my ISP. I naïvely made this change:

ADDR=$(ip -6 addr ls dev "$DEVICE" | sed -ne '/\/128/d' -e 's/ *inet6 \([^ \/]*\).* scope global.*/\1/p')

I'm not sure that that's sufficiently robust enough though. Any thoughts?

[jamesmacwhite]

Better than my suggestion of just limiting to the first output if it excludes any match of a /128 address if found, it works on my eth0.3 interface, I guess the only issue might be if you have more than one global address on interface that's not a /128 though, but how possible that scenario would be is debatable.

[dersch81]

I thought this was just some weird aspect of my ISP. I naïvely made this change:

ADDR=$(ip -6 addr ls dev "$DEVICE" | sed -ne '/\/128/d' -e 's/ *inet6 \([^ \/]*\).* scope global.*/\1/p')

I'm not sure that that's sufficiently robust enough though. Any thoughts?

@brianjmurrell can you show me where you changed the code? It is in the mwan3.sh file?

[jamesmacwhite]

@dersch81 It's in mwan3track here:

https://github.com/openwrt/packages/blob/master/net/mwan3/files/usr/sbin/mwan3track#L139

[dersch81]

@jamesmacwhite ok many thanks! But the code change doesn't work for me :( the tracking of wan6 is online for a few seconds and then switching to offline.

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:69:79:76 brd ff:ff:ff:ff:ff:ff
    inet 172.10.10.7/26 brd 172.10.10.63 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2001:470:xxxx:xxx:xxxx:xx:xxxx:xxxx/64 scope global dynamic noprefixroute 
       valid_lft 86398sec preferred_lft 14398sec
    inet6 2001:470:xxx:xxx::x/128 scope global dynamic noprefixroute 
       valid_lft 6889sec preferred_lft 4189sec
    inet6 fe80::5054:ff:fe69:7976/64 scope link 
       valid_lft forever preferred_lft forever

Thu Apr 30 09:35:30 2020 user.info mwan3track[5718]: Check (ping) failed for target "2001:500:2::c" on interface wan6 (eth0)
Thu Apr 30 09:35:37 2020 user.info mwan3track[5718]: Check (ping) failed for target "2001:500:2::c" on interface wan6 (eth0)
Thu Apr 30 09:35:37 2020 user.notice mwan3[7757]: Execute ifdown event on interface wan6 (eth0)
Thu Apr 30 09:35:39 2020 user.info mwan3track[5718]: Detect ifdown event on interface wan6 (eth0)
Thu Apr 30 09:35:44 2020 user.notice mwan3track[5718]: Interface wan6 (eth0) is offline

[dersch81]

Oh! now it seems to work. I've changed the tracking ip. But i'm just using IANA root servers to track. So i'm wondering why one of those did not work.

[jamesmacwhite]

@dersch81 Probably best to use some of the public IP addresses here:

https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3#reliable_public_ip_addresses_to_ping

Google DNS and OpenDNS are common ones.

[dersch81]

@dersch81 Probably best to use some of the public IP addresses here:

https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3#reliable_public_ip_addresses_to_ping

Google DNS and OpenDNS are common ones.

I did that in the past. I have about 6 LB Setups out there. But then i have read an article about to NOT and NEVER use public DNS or Facebook etc as tracking ip's. The stable suggestion was to use root servers because they are the most reliable solutions. I searched that article but couldn't find it anymore. They also linked some articles with lockdown's of ISP's because of that issue.

Anyway i'm fine with it :)

[feckert]

ADDR=$(ip -6 addr ls dev "$DEVICE" | sed -ne '/\/128/d' -e 's/ *inet6 \([^ \/]*\).* scope global.*/\1/p')

To fix this issue could please open a pullrequest with this working change? So we could merge your fix and cherry-pick this to owrt-19.07?

[brianjmurrell]

But then i have read an article about to NOT and NEVER use public DNS or Facebook etc as tracking ip's.

Was a reason given? Sounds like FUD.

The stable suggestion was to use root servers because they are the most reliable solutions.

Root servers (I suspect) tend to be 1 machine, 1 address. Whereas the 8.8.8.8, 8.8.4.4, 1.1.1.1, etc. DNS servers are a single address with many (many) hosts behind it to respond to, so you don't have a single machine taking down a single IP address.

[brianjmurrell]

To fix this issue could please open a pullrequest with this working change?

12018

[jamesmacwhite]

@brianjmurrell Thanks!

[feckert]

Fixed by https://github.com/openwrt/packages/commit/49cf5eac5cfcfbf371e84d8ddaa0e1b55175100f