This updates mwan3 to use network_get_preferred_ipaddr6 instead of
network_get_ipaddr6 if possible to determine a source ip for the
connectivity checks. This avoids issues where the first ip address
that is returned from network_get_ipaddr6 does not work anymore while
the preferred one returned from network_get_preferred_ipaddr6 works.
Signed-off-by: Jonas Lochmann <git@inkompetenz.org>
The expression 'disabled' is more meaningful than 'not enabled' and can
therefore be better processed in the ubus output, since it is only one
word.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
This introduces a new concept of "unknown_wan" to mwan3. The action for
this can be configured in the globals section the default of which is
'none'. This can be set to 'none', 'default', 'unreachable' or 'blacklist'
switching out the matching ip rule for this match. This assignment for
a connection is temporary and is re-resolved for each additional
original direction packet through the firewall allowing the unknown WAN
to start resolving once the ifup has finished for the given interface.
An example configuration:
config globals 'globals'
option unknown_wan_action 'unreachable'
Prior to this commit, mwan3 had multiple hit spots for packets in the
following order:
1. Packets are checked to see if they originate from known WAN interfaces
2. Packets are checked to see if they destined for ipsets defined
3. Packets are checked against default WAN policies
The WAN list is maintained via hotplug 'ifup'/'ifdown' events and the local
route ipset list is maintained via monitoring the routing table. This
means that while a WAN interface is brought up, the list for 2 is
updated before the list for 1, since an interface is fully brought up
before the ifup event is fired off. Additionally, we want to make sure we
don't apply a WAN policy for incoming packets from a WAN interface that
is in the process of being brought up.
We can identify packets that are presumably coming from a WAN interface
we don't recognize yet by eliminating all packets that the source comes
from networks we don't know about in the ipsets that mwan3 manages. We
have to be careful here to only match the original direction of the
packet flow (e.g. for instance with ICMP, the ping request is in the
ORIGINAL direction, and the response is in the REPLY direction) or else
we might match something we didn't intend to.
By modifying the rule set to the following:
1. Packets are checked to see if they are in a REPLY direction of flow
2. Packets are checked to see if they originate from known WAN interfaces
3. Packets are checked to see if they not sourced from ipsets defined
4. Packets are checked to see if they destined for ipsets defined
5. Packets are checked against default WAN policies
If a packet is in the REPLY direction of flow, we definitely don't want
to do any routing table assignments - we only want to do this for the
original direction of traffic flow. This reduces the amount of rules
parsed within mwan3.
If a packet is not sourced from a defined ipset, this should match any
packet originating from a "default route" upstream. We do this post the
known WAN interface check since we don't know what mask to apply to this
packet at this time until the 'ifup' has completed. It's also setup to
reevaluate this decision by clearing this specific mark when a new
packet comes in in the REPLY direction of flow before any subsequent
evaluations. This allows additional packets for the same connection to
eventually be assigned the appropriate mask once the 'ifup' has
finished.
One easy way to test this out before and after this change is to:
- Bring down wan (e.g. ifdown wan)
- Manually bring up WAN
- This mitigates the firewall rules being added for 1 above, but 2
is still added since this is monitoring the routing interface
- Ping the device from a non-local subnet via the WAN interface; leave
running
- Observe mark set to ICMP session via conntrack
- Bring up wan (e.g. ifup wan)
- Observe mark set to ICMP session from above
Signed-off-by: Tim Nordell <tnordell@airgain.com>
Allow `mwan3 interfaces` to get uptime via an internal function and
thus remove the dependency on rpcd for `mwan3 interface` calls.
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
Use "mwan3 use" to wrap a command with interface bindings so that you can
avoid the mwan3 rules and test behavior on a specific interface.
eg "mwan3 use wan ping -c1 1.1.1.1"
Additional binding arguments to the command will have their system
calls intercepted and ignored.
eg "mwan3 use wan ping -c1 -I tun0 1.1.1.1" will use the
device associated with "wan", rather than "tun0".
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
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: #8139 and #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 #13050).
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
start all mwan3mon and mwan3track instances on mwan3 start
if an interface is down when mwan3track starts, it waits
for a signal from the hotplug script to start
procd can then handle stopping all of the scripts when mwan3
is halted
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
improve startup and runtime performance by
1) moving common startup procedures out of hotplug script when called
from mwan3 start
2) reducing calls to iptables to check status of rules
3) consolidating iptables updates and updating with iptables-restore
4) do not wait for kill if nothing was killed
5) running interface hotplug scripts in parallel
6) eliminate operations in hotplug script that check status on every
single interface unnecessarily
7) consolidate how mwan3track makes hotplug calls
8) do not restart mwan3track on connected events
This is a significant refactor, but should not result in any breaking
changes or require users to update their configurations.
version bump to 2.9.0
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
If the date is changed by ntp the age value of mwan3 on ubus could jitter.
Use instead the uptime value from /proc/uptime which will not change during
system run.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
