Tachyon DNS: tachyon-dns-cellular-fix.sh breaks resolution when Wi-Fi is the default route

Tachyon
1

Setup: Tachyon, NM 1.22.10-1ubuntu2.4particle1, systemd-resolved, Wi-Fi (wlan0) and cellular (rmnet_data0) both up.

What ships enabled on the device

  • /etc/systemd/system/tachyon-dns-cellular.service (oneshot at boot, 25 s delay, enabled)
  • /etc/NetworkManager/dispatcher.d/99-tachyon-dns-cellular (fires on wlan*|rmnet* up / dhcp4-change / reapply)
  • /usr/local/sbin/tachyon-dns-cellular-fix.sh, which effectively runs:

resolvectl default-route wlan0 no

resolvectl dns wlan0 ""

resolvectl domain wlan0 ""

resolvectl default-route rmnet_data0 yes

resolvectl dns rmnet_data0 1.1.1.1 8.8.8.8

So every boot and every wlan0 link event, wlan0's DNS is cleared and cellular is pinned as the DNS default.

The failure

With Wi-Fi associated, NM uses its default metrics: wlan0 = 600, rmnet_data0 = 700. ip route get 1.1.1.1 goes out wlan0. But the override script has told systemd-resolved that rmnet_data0 is the DNS-default link, so resolved binds its outbound query socket to rmnet_data0. Kernel routes it out wlan0, source/exit interface mismatch, query dies.

Evidence from the device:

ip route get 1.1.1.1 → via 192.168.10.1 dev wlan0

resolvectl status wlan0 → Current Scopes: none

resolvectl status rmnet_data0 → DefaultRoute: yes, DNS Servers: 1.1.1.1 8.8.8.8

ping -I rmnet_data0 1.1.1.1 → works (106-419 ms)

getent hosts dogs.com → exit 2 (no answer)

Disabling the service + dispatcher restores resolution. NM correctly publishes wlan0's DNS and resolved picks the right link.

Also: particle-tachyon-rild already sets rmnet_data0 DNS from carrier DHCP (Setting DNS to "8.8.8.8 8.8.4.4" in the journal) with DefaultRoute=yes, so for cell-only operation the override script is largely redundant with rild.

What I'd like to understand

  1. Is tachyon-dns-cellular-fix.sh meant to run on all Tachyons, or only cell-only deployments? Mine came enabled.
  2. Given rild already configures cellular DNS, what failure mode is the override script protecting against?
  3. What's the supported pattern for a Tachyon that uses Wi-Fi DNS when Wi-Fi is up and falls back to cellular when it isn't — without the device needing different config in the bench vs field?
  4. On ptcl_* connection profiles managed by particled, do edits to ipv4.dns, ipv4.ignore-auto-dns, or ipv4.route-metric persist, or will particled resync and overwrite them from the Device Twin?

My current workaround is to disable the service and chmod -x the dispatcher, which makes both Wi-Fi-up and Wi-Fi-absent work in my testing. Happy to validate any other approach Particle recommends.