feat: implement Linux support for connectivity detection (#5) by gabref · Pull Request #7 · silvermine/tauri-plugin-connectivity

gabref · 2026-05-01T05:08:55Z

Adds Linux support for connection_status() in tauri-plugin-connectivity.

implement the Linux backend using NetworkManager D-Bus state
map connectivity, metered, constrained, and transport status into the existing plugin types
use ModemManager roaming and NetworkManager device metering for constrained status
add passive fallback detection via /proc/net/route and sysfs when NetworkManager is unavailable
keep Linux D-Bus and ModemManager failures non-fatal
update docs to reflect Linux support
add example app backend logging for manual Linux testing

Closes #5

velocitysystems · 2026-05-05T16:36:52Z

+   status
+}
+
+fn map_connectivity(connectivity: u32) -> ConnectedState {


Should NM_CONNECTIVITY_PORTAL map to Connected with constrained: true, rather than Disconnected? I think this is similar to the question @jhafer raised in the other PR.

Agreed, updated this to report portal connectivity as connected but constrained.

velocitysystems · 2026-05-05T16:38:00Z

+   path.as_str() == "/"
+}
+
+fn default_route_interface(route_table: &str) -> Option<String> {


/proc/net/route lists every candidate route, including down ones. Should we filter on routes which are reported as being up?

Agreed. I updated the passive fallback to require the default route to have the RTF_UP flag before treating it as connected

velocitysystems · 2026-05-05T16:38:23Z

+| `constrained`    | `boolean`        | Whether the connection is data-constrained or restricted          |
+| `connectionType` | `ConnectionType` | The physical transport: `wifi`, `ethernet`, `cellular`, `unknown` |

 #### Platform mapping


Can we also please document the platform mapping for Linux?

Added the Linux mapping

velocitysystems · 2026-05-05T16:40:17Z

+      NM_CONNECTIVITY_NONE | NM_CONNECTIVITY_PORTAL | NM_CONNECTIVITY_LIMITED => {
+         ConnectedState::Disconnected
+      }
+      NM_CONNECTIVITY_UNKNOWN => ConnectedState::Unknown,


Nit: NM_CONNECTIVITY_UNKNOWN => Unknown and _ => Unknown are equivalent.

Good catch. I simplified the match so unknown and unrecognized values both use the fallback arm.

velocitysystems · 2026-06-02T13:05:26Z

+}
+
+fn is_constrained(connectivity_state: ConnectedState, metered: bool, roaming: bool) -> bool {
+   connectivity_state == ConnectedState::Constrained || metered || roaming


On Linux, metered: true always forces constrained: true, whereas the Windows backend derives the two from separate signals. Could you confirm that's the desired behavior?

Yes, this is intentional for Linux. NetworkManager does not expose a separate background-data policy signal, so we treat an explicitly or guessed metered primary device as constrained. I added a code comment to make that mapping explicit.

velocitysystems · 2026-06-02T13:08:31Z

+      .build()
+}
+
+fn service_has_owner(connection: &Connection, service: &str) -> std::result::Result<bool, String> {


This returns Result<bool, String>, while the rest of the module returns zbus::Result. Should this be updated?

Agreed. I updated service_has_owner() to return zbus::Result<bool> and propagate the zbus/name errors directly.

velocitysystems · 2026-06-02T13:09:21Z

+}
+
+#[derive(Debug, Clone, PartialEq, Eq)]
+struct PrimaryConnectionDetails {


This is field-for-field identical to DeviceDetails. Can these be unified into a single type?

I originally kept them separate because they represented different semantic levels: per-device details vs aggregated primary-connection details. Since the fields and behavior are identical, unifying them is cleaner. Updated to use a single ConnectionDetails type.

Linux needs a passive backend that works with NetworkManager when available. Smaller systems without NetworkManager should still get a predictable answer. Use cached NetworkManager properties for connectivity, metering, and transport. Fall back to the kernel route table and sysfs instead of active probes.

Update the Linux support matrix and API docs to describe how the backend maps NetworkManager connectivity, portal state, metering, transport, and constrained fallback behavior.

Manual Linux testing is easier when the example app emits plugin debug logs. Install a debug-friendly tracing subscriber in the example app. Refresh its lockfile for logging and the Linux backend dependency graph.

Document tested Linux scenarios, expected responses, and setup commands. Note that ModemManager cellular and roaming scenarios remain untested.

gabref force-pushed the gabref/linux-connectivity-status branch from 1be0251 to 9723253 Compare May 5, 2026 09:00

velocitysystems reviewed May 5, 2026

View reviewed changes

gabref force-pushed the gabref/linux-connectivity-status branch 2 times, most recently from 10f4dcb to c376dad Compare May 11, 2026 23:46

gabref marked this pull request as ready for review May 11, 2026 23:47

gabref force-pushed the gabref/linux-connectivity-status branch from c376dad to 70b2703 Compare May 11, 2026 23:49

gabref force-pushed the gabref/linux-connectivity-status branch from 70b2703 to 0737cff Compare June 2, 2026 09:18

velocitysystems suggested changes Jun 2, 2026

View reviewed changes

gabu added 4 commits June 2, 2026 17:16

docs: document Linux connectivity mappings

feac525

Update the Linux support matrix and API docs to describe how the backend maps NetworkManager connectivity, portal state, metering, transport, and constrained fallback behavior.

chore: add example backend logging

873a0ea

Manual Linux testing is easier when the example app emits plugin debug logs. Install a debug-friendly tracing subscriber in the example app. Refresh its lockfile for logging and the Linux backend dependency graph.

docs: add Linux manual testing guide

c245698

Document tested Linux scenarios, expected responses, and setup commands. Note that ModemManager cellular and roaming scenarios remain untested.

gabref force-pushed the gabref/linux-connectivity-status branch from 0737cff to c245698 Compare June 2, 2026 15:16

gabref requested a review from velocitysystems June 2, 2026 15:17

Conversation

gabref commented May 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants