pmos-base-ui-networkmanager: set up dnsmasq for filtering lookup
Testing
Please help test! This patch adds a Network Manager dispatcher script that toggles options in dnsmasq, which control filtering for IPv4 and IPv6 DNS answers. The reason for this madness is to (almost completely) solve the problem where outgoing connections on a device might be routed out of the "wrong" interface. The case I hit all the time before this patch was: I'm connected to wifi and mobile data at the same time, but I was rapidly using up my mobile data cap because a lot of traffic was being routed over it. This is despite being connected to a perfectly fine, unmetered wifi network.
It can be installed using mrtest add 3823
. After installing, the easiest way to load up things is to just reboot. No other configuration is necessary.
What to test
1) USB tethering
- !3819, cc @dylanvanassche (in case you have time, but anyone else welcome to try it too)
- Does DNS function properly for both the phone and the target?
- Does having dnsmasq running already via NM cause problems with configuring things for usb tethering?
2) Does MMS work for different carriers?
- It requires a very peculiar DNS setup to work.
3) Does IPv6 work as you'd expect when it is only routable over a non-primary connection?
- IPv6 only on mobile data, while connected also to wifi that is IPv4 only? FWIW, wifi is already prioritized over mobile data in all other network manager config.
- With the current patch, you shouldn't get any IPv6 responses via DNS (unless you bypass the default nameserver, e.g.
dig @X.X.X.X
). Which means basically no traffic should go over mobile data / IPv6. Is that reasonable?
4) Do VPNs work as expected?
- I've lightly tested wireguard and it seemed fine, but definitely interested if there are setups that don't work!
5) What else?
- I'm sure I'm forgetting something... so try to think of any situations where this could blow up
😅
Additional info
When a connection changes state, the dispatcher script should run and configure dnsmasq to filter A or AAAA answers depending on which gateways are available on the current primary connection. Network Manager has preferences for which connection to "use" based on which other connections are active, it prefers wifi over mobile data, for example. Anyways, the output in syslog should look something like this:
Mar 13 00:08:24 foo user.notice nm-dns-filter[2262]: iface: eth0, action: up ...
Mar 13 00:08:24 foo user.notice nm-dns-filter[2285]: ip4 gateway: 10.0.2.2
Mar 13 00:08:24 foo user.notice nm-dns-filter[2301]: ip6 gateway:
Mar 13 00:08:24 foo user.notice nm-dns-filter[2302]: disabling IPv4 filter
Mar 13 00:08:24 foo daemon.info dnsmasq[1887]: Disabling --filter-a option from D-Bus
Mar 13 00:08:24 foo user.notice nm-dns-filter[2304]: enabling IPv6 filter
Mar 13 00:08:24 foo daemon.info dnsmasq[1887]: Enabling --filter-aaaa option from D-Bus
Mar 13 00:08:24 foo daemon.info dnsmasq[1887]: cleared cache
Despite the efforts of this patch, there are still opportunities for traffic to go over the wrong interface... This trick only works for apps that use the libc resolver, or are already reading /etc/resolv.conf. Apps that have external DNS servers configured could still receive DNS answers that might steer their traffic away from the primary connection. In practice, I really haven't seen any unexplainable mobile data usage when connected to wifi, but maybe I'm just lucky so far
Please report any new problems in a new comment thread in this MR, and I'll try to get to it ASAP.
See #1430 for more details.
Background
This uses a dispatcher script to configure filtering A and AAAA records based on which IP versions are routable on the NM primary connection.
See #1430 for more details. fixes #1430
TODO:
-
repackage busctl so that elogind isn't "required" - I hit a problem with this, help appreciated! /usr/libexec/libelogind-shared-*.so is installed by
elogind
package but busctl links against it, and there doesn't appear to be a straight forward way to break that .so off intolibelogind
... - submitted patch to aports: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/43543
- UPDATE merged in aports, and patch updated to depend on busctl
- I hit a problem with this, help appreciated! /usr/libexec/libelogind-shared-*.so is installed by
-
add dnsmasq patch to aports, then drop patch from this series - patch was submitted upstream to dnsmasq, I kinda want to wait for feedback on that first..
- UPDATE dnsmasq upstream seems busy(?), so I submitted the patch to Alpine aports: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/44092
- UPDATE patch accepted in upstream dnsmasq, will be in the next release
-
[ ] wait for https://gitlab.com/postmarketOS/pmaports/-/merge_requests/3819, test- this triggers on the "reapply" event, which is added in a NM upstream patch and supported in !3819. @dylanvanassche says it works, but let's just make sure after the final versions of those are merged...
- UPDATE: discussed and decided that this shouldn't be blocked on that