mwan3 not respecting source IP #12836

cirruspl · 2020-07-16T08:59:16Z

Hello,
after fresh configuration mwan3track is unable to track wan-s. With balanced policy ICMP traffic if routed without respecting source IP address.

Documentation:
https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3
says:

As of version 2.0 mwan3 does respect the already set source address.

conntrack -L shows

icmp 1 24 src=x.y.z.170 dst=8.8.4.4 type=8 code=0 id=29464 packets=1 bytes=84 src=8.8.4.4 dst=192.168.a.46 type=0 code=0 id=29464 packets=1 bytes=84 mark=256 use=1
icmp 1 29 src=x.y.z.170 dst=8.8.4.4 type=8 code=0 id=29587 packets=1 bytes=84 [UNREPLIED] src=8.8.4.4 dst=x.y.z.170 type=0 code=0 id=29587 packets=0 bytes=0 mark=512 use=1
icmp 1 29 src=x.y.z.170 dst=8.8.8.8 type=8 code=0 id=29591 packets=1 bytes=84 src=8.8.8.8 dst=192.168.a.46 type=0 code=0 id=29591 packets=1 bytes=84 mark=256 use=1

icmp 1 23 src=192.168.a.46 dst=8.8.4.4 type=8 code=0 id=29664 packets=1 bytes=84 [UNREPLIED] src=8.8.4.4 dst=x.y.z.170 type=0 code=0 id=29664 packets=0 bytes=0 mark=512 use=1
icmp 1 18 src=192.168.a.46 dst=8.8.8.8 type=8 code=0 id=29601 packets=1 bytes=84 src=8.8.8.8 dst=192.168.a.46 type=0 code=0 id=29601 packets=1 bytes=84 mark=256 use=1
icmp 1 28 src=192.168.a.46 dst=8.8.4.4 type=8 code=0 id=29735 packets=1 bytes=84 [UNREPLIED] src=8.8.4.4 dst=x.y.z.170 type=0 code=0 id=29735 packets=0 bytes=0 mark=512 use=2

/etc/config/mwan3

config globals 'globals'
option mmx_mask '0x3F00'
option rtmon_interval '5'

config interface 'wan'
option enabled '1'
list track_ip '8.8.4.4'
list track_ip '8.8.8.8'
list track_ip '208.67.222.222'
list track_ip '208.67.220.220'
option family 'ipv4'
option reliability '2'
option count '1'
option timeout '2'
option failure_latency '1000'
option recovery_latency '500'
option failure_loss '20'
option recovery_loss '5'
option interval '5'
option down '3'
option up '8'

config interface 'wan_o_2'
option enabled '1'
list track_ip '8.8.4.4'
list track_ip '8.8.8.8'
list track_ip '208.67.222.222'
list track_ip '208.67.220.220'
option family 'ipv4'
option reliability '1'
option count '1'
option timeout '2'
option failure_latency '1000'
option recovery_latency '500'
option failure_loss '20'
option recovery_loss '5'
option interval '5'
option down '3'
option up '8'

config member 'wan_m1_w3'
option interface 'wan'
option metric '1'
option weight '3'

config member 'wan_m2_w3'
option interface 'wan'
option metric '2'
option weight '3'

config member 'wan_o_2_m1_w2'
option interface 'wan_o_2'
option metric '1'
option weight '2'

config member 'wan_o_2_m2_w2'
option interface 'wan_o_2'
option metric '2'
option weight '2'

config policy 'wan_only'
list use_member 'wan_m1_w3'

config policy 'wan_o_2_only'
list use_member 'wan_o_2_m1_w2'

config policy 'balanced'
list use_member 'wan_m1_w3'
list use_member 'wan_o_2_m1_w2'

config policy 'wan_wan_o_2'
list use_member 'wan_m1_w3'
list use_member 'wan_o_2_m2_w2'

config policy 'wan_o_2_wan'
list use_member 'wan_m2_w3'
list use_member 'wan_o_2_m1_w2'

config rule 'https'
option sticky '1'
option dest_port '443'
option proto 'tcp'
option use_policy 'balanced'

config rule 'default_rule'
option dest_ip '0.0.0.0/0'
option use_policy 'balanced'

/etc/config/network

config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fdd0:7f18:94e4::/48'

config interface 'lan'
option type 'bridge'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option _turris_mode 'managed'
option ipaddr 'q.w.e.r'
option ifname 'lan0'

config interface 'wan'
option ifname 'eth2'
option proto 'static'
option ipaddr '192.168.a.46'
option netmask '255.255.255.0'
option gateway '192.168.a.1'
option ipv6 '0'
option metric '10'

config interface 'wan6'
option ifname '@wan'
option proto 'none'

config interface 'wan_o_2'
option ifname 'lan4'
option proto 'static'
option ipaddr 'x.y.z.170'
option gateway 'x.y.z.169'
option delegate '0'
option metric '20'
option netmask '255.255.255.248'

My workaround: I just added to two rules (before default_rule):

config rule 'src_wan_o_2'
option src_ip 'x.y.z.170'
option proto 'all'
option sticky '0'
option use_policy 'wan_o_2_only'

config rule 'src_wan'
option src_ip '192.168.a.46'
option proto 'all'
option sticky '0'
option use_policy 'wan_only'

BR,
Michał Szamocki
Cirrus

aaronjg · 2020-07-31T22:25:17Z

What version of mwan3 are you using? mwan3track specifies the interface directly using /bin/ping -I. However, some earlier versions would use iputils ping if installed, but the default version of that package is very old and broken for this application.

cirruspl · 2020-08-03T10:35:16Z

I use mwan3 2.8.8-1.0 and

root@rtr-1# find / | grep bin/ping
/bin/ping6
/bin/ping
/usr/bin/ping
/usr/bin/ping6
root@rtr-1# opkg search /bin/ping
busybox - 1.30.1-5.25
root@rtr-1# opkg search /usr/bin/ping
iputils-ping - 20101006-1.3
root@rtr-1# /bin/ping
BusyBox v1.30.1 () multi-call binary.

Usage: ping [OPTIONS] HOST

Send ICMP ECHO_REQUEST packets to network hosts
    -4,-6           Force IP or IPv6 name resolution
    -c CNT          Send only CNT pings
    -s SIZE         Send SIZE data bytes in packets (default 56)
    -i SECS         Interval
    -A              Ping as soon as reply is recevied
    -t TTL          Set TTL
    -I IFACE/IP     Source interface or IP address
    -W SEC          Seconds to wait for the first response (default 10)
                    (after all -c CNT packets are sent)
    -w SEC          Seconds until ping exits (default:infinite)
                    (can exit earlier with -c CNT)
    -q              Quiet, only display output at start
                    and when finished
    -p HEXBYTE      Pattern to use for payload
root@rtr-1# /usr//bin/ping -V
ping utility, iputils-sss20101006

Should I uninstall iputils-ping package?

feckert · 2020-08-03T14:09:05Z

Should I uninstall iputils-ping package?

Yes this should fix your issue.

aaronjg · 2020-08-03T15:37:47Z

Wasn't the commit to force using busybox ping before 2.8.8?

@cirruspl, if that doesn't fix the issue, could you post the output of the mwan3 troubleshooting page:
cgi-bin/luci/admin/status/mwan/troubleshooting

BKPepe · 2020-08-04T08:05:53Z

Should I uninstall iputils-ping package?

Yes this should fix your issue.

Are you sure about that? In the source for for OpenWrt 19.07, I see that you advise to install iputils-ping.
https://github.com/openwrt/packages/blob/openwrt-19.07/net/mwan3/files/usr/sbin/mwan3track#L27

Anyway, I found it interesting that it works with busybox, but it does not work with iputils-ping.

feckert · 2020-08-04T09:07:18Z

Should I uninstall iputils-ping package?

Yes this should fix your issue.

Are you sure about that? In the source for for OpenWrt 19.07, I see that you advise to install iputils-ping.
https://github.com/openwrt/packages/blob/openwrt-19.07/net/mwan3/files/usr/sbin/mwan3track#L27

Yes this is still an artefact from times past. Unfortunately, I no longer know when the regression with ip-utils began.

Anyway, I found it interesting that it works with busybox, but it does not work with iputils-ping.

This has to do with the combination of kernel version and ip-utils (ping) as I remember!
With the busybox ping the -I option works as expected.
In openwrt-19.07 we have the version 20101006 and in master we have the version 20190709

The version in openwrt-19.07 does not work! I have not tried the new version in master.

BKPepe · 2020-08-04T09:11:02Z

If something does not work, shouldn't there be issue created? In this case on bugs.openwrt.org or rather send a pull request for OpenWrt 19.07 to update it?

feckert · 2020-08-04T09:20:14Z

There are two issue open on bugs.openwrt.org
https://bugs.openwrt.org/index.php?do=details&task_id=1486&string=iputils
https://bugs.openwrt.org/index.php?do=details&task_id=2724&string=iputils
But they are mutually exclusive!
I can only say that if I take the busybox version then mwan3 tracking works.

BKPepe · 2020-08-04T09:23:04Z

Ok. I will try locally the version from master on OpenWrt 19.07 and if it is going well, I will send it to openwrt-devel mailing list.

pevik · 2020-08-04T12:30:22Z

@BKPepe please if something is not working in iputils s20190709 (the latest iputils release), please let me know. I also plan to release new iputils version this week, thus testing on iputils master would be great.

aaronjg · 2020-08-04T23:55:55Z

I have had no issue with either busybox ping, nor iputils ping 20190709.

https://bugs.openwrt.org/index.php?do=details&task_id=2724&string=iputils

I hadn't seen this one! I have no issues with busybox ping, but I am running 19.07.3, not snapshot. Maybe something in the new kernel broke the busybox ping. There was another reported issue with the snapshot as well - perhaps those are related. #10712

@cirruspl did using the busybox ping or upgrading to iputils fix your issue?

Rather than using a special mwan3 user to manage mwan3track's tracking packets, this commit implements a small helper library to bind to device and to set a fwmark so that the tracking packets can be routed out of the correct interface. This provides a consistent method for binding to a device rather than relying on various packages potentially buggy implementations. For example: openwrt#8139 and openwrt#12836 This helper issue also allows for more tracking methods to be added even if they do not have a command line option to bind to device, such as iperf3 (eg openwrt#13050). Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>

cirruspl · 2020-09-04T08:06:46Z

@aaronjg I have just noticed that my first diagnosis was made using version 2.8.4 which was without PING="/bin/ping"
Now I use 2.8.8 and everything works fine. 👍

Rather than using a special mwan3 user to manage mwan3track's tracking packets, this commit implements a small helper library to bind to device and to set a fwmark so that the tracking packets can be routed out of the correct interface. This provides a consistent method for binding to a device rather than relying on various packages potentially buggy implementations. For example: openwrt#8139 and openwrt#12836 This helper issue also allows for more tracking methods to be added even if they do not have a command line option to bind to device, such as iperf3 (eg openwrt#13050). Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>

BKPepe mentioned this issue Aug 4, 2020

iputils: update to 20151218 openwrt/openwrt#1804

Closed

aaronjg mentioned this issue Aug 22, 2020

mwan3: mwan3track via default routing table and use procd from mwan3track & mwan3rtmon #13169

Merged

feckert closed this as completed in #13169 Oct 21, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

mwan3 not respecting source IP #12836

mwan3 not respecting source IP #12836

cirruspl commented Jul 16, 2020 •

edited

Loading

aaronjg commented Jul 31, 2020

cirruspl commented Aug 3, 2020 •

edited

Loading

feckert commented Aug 3, 2020

aaronjg commented Aug 3, 2020

BKPepe commented Aug 4, 2020

feckert commented Aug 4, 2020

BKPepe commented Aug 4, 2020

feckert commented Aug 4, 2020

BKPepe commented Aug 4, 2020

pevik commented Aug 4, 2020

aaronjg commented Aug 4, 2020

cirruspl commented Sep 4, 2020

mwan3 not respecting source IP #12836

mwan3 not respecting source IP #12836

Comments

cirruspl commented Jul 16, 2020 • edited Loading

aaronjg commented Jul 31, 2020

cirruspl commented Aug 3, 2020 • edited Loading

feckert commented Aug 3, 2020

aaronjg commented Aug 3, 2020

BKPepe commented Aug 4, 2020

feckert commented Aug 4, 2020

BKPepe commented Aug 4, 2020

feckert commented Aug 4, 2020

BKPepe commented Aug 4, 2020

pevik commented Aug 4, 2020

aaronjg commented Aug 4, 2020

cirruspl commented Sep 4, 2020

cirruspl commented Jul 16, 2020 •

edited

Loading

cirruspl commented Aug 3, 2020 •

edited

Loading