Recent testing and deployment work involving Raspberry Pi OS Trixie has identified significant behavioral changes in the networking subsystem compared with Raspberry Pi OS Bookworm. These changes have a direct impact on SvxLink appliance-style deployments that rely on hotspot-based provisioning and dynamic WiFi reconfiguration.

The purpose of this report is to summarise the architectural changes, explain why existing deployment methods are failing, and propose a stable approach for future SvxLink deployments on Trixie.

Background

Under Raspberry Pi OS Bookworm, hotspot provisioning workflows generally operated successfully using:

• NetworkManager
• nmcli
• persistent .nmconnection profiles stored in:

/etc/NetworkManager/system-connections/

Typical SvxLink deployment workflows used the following model:

1. Device boots into hotspot/AP mode
2. User connects to hotspot
3. Captive portal or Flask configuration interface gathers home WiFi credentials
4. nmcli creates infrastructure WiFi profile
5. Hotspot is disabled
6. Device joins home network
7. Configuration persists across reboot

This workflow was reliable because NetworkManager was effectively the authoritative controller of the networking stack.

Architectural Changes in Raspberry Pi OS Trixie

Trixie introduces two additional layers into the networking architecture:

The key issue is that NetworkManager is no longer necessarily the authoritative source of truth.

Instead:

• Netplan may generate network profiles dynamically
• cloud-init may regenerate configuration at boot
• NetworkManager may operate only as a renderer
• connections may be generated transiently in:

/run/NetworkManager/system-connections/

rather than persistently in:

/etc/NetworkManager/system-connections/

This fundamentally changes how nmcli behaves.

Observed Failure Modes

The following behaviors have been observed during hotspot provisioning and runtime WiFi switching:

These problems are not traditional SvxLink issues, but consequences of the new networking architecture in Trixie.

Why Hotspot Provisioning Is Particularly Affected

SvxLink hotspot provisioning workflows are dynamic and stateful.

They rely on:

• runtime creation/removal of WiFi profiles
• AP ↔ infrastructure role changes
• persistent storage of credentials
• deterministic fallback behavior

However, cloud-init and Netplan are designed primarily for:

• declarative infrastructure
• cloud deployment
• static provisioning
• boot-time configuration generation

These two design philosophies conflict.

As a result, appliance-style hotspot onboarding workflows are now significantly more difficult unless NetworkManager is restored as the authoritative controller.

Recommended Approach

For SvxLink appliance deployments on Raspberry Pi OS Trixie, the most stable approach appears to be:

Restore NetworkManager as the authoritative networking controller.

This can be achieved by:

• disabling cloud-init networking after first boot
• configuring Netplan to use NetworkManager strictly as renderer
• storing all persistent profiles under /etc/NetworkManager/system-connections/
• avoiding transient /run profiles

Recommended Configuration

1. Disable cloud-init network management

Create:

/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

Contents:

network: {config: disabled}

Optionally disable cloud-init entirely after provisioning:

sudo touch /etc/cloud/cloud-init.disabled

2. Force NetworkManager renderer ownership

Create:

/etc/netplan/01-network-manager.yaml

Contents:

network:
  version: 2
  renderer: NetworkManager

Then apply:

sudo netplan generate
sudo netplan apply

This ensures NetworkManager regains practical control of runtime networking.

3. Use Persistent NetworkManager Profiles Only

Avoid transient runtime-generated profiles under:

/run/NetworkManager/system-connections/

Instead ensure all profiles are stored persistently in:

/etc/NetworkManager/system-connections/

4. Pre-create a Persistent Hotspot Profile

Example:

nmcli connection add \
type wifi \
ifname wlan0 \
con-name svx-ap \
autoconnect yes \
ssid SvxLink-Setup

Then:

nmcli connection modify svx-ap \
802-11-wireless.mode ap \
ipv4.method shared \
wifi-sec.key-mgmt wpa-psk \
wifi-sec.psk "password"

5. Create Infrastructure WiFi Profiles Dynamically

Example:

nmcli connection add \
type wifi \
ifname wlan0 \
con-name homewifi \
ssid YOURSSID

Then:

nmcli connection modify homewifi \
wifi-sec.key-mgmt wpa-psk \
wifi-sec.psk "YOURPASS"

6. Use Autoconnect Priorities

Autoconnect priorities become essential under Trixie.

Example:

nmcli connection modify homewifi connection.autoconnect-priority 20
nmcli connection modify svx-ap connection.autoconnect-priority 5

This creates deterministic fallback behavior.

Recommended Appliance Workflow

The most reliable architecture currently appears to be:

This approach avoids aggressive runtime profile manipulation and aligns better with the new networking stack behavior.

Strategic Conclusion

Raspberry Pi OS Trixie appears to be moving toward a more Ubuntu-style networking model based around:

• cloud-init
• Netplan
• declarative infrastructure provisioning

This model works well for fleet/cloud/server deployment, but creates complications for embedded appliance onboarding systems such as SvxLink hotspot provisioning.

For appliance-style deployments, the current recommendation is:

• minimise cloud-init involvement
• retain NetworkManager authority
• use persistent .nmconnection files
• treat hotspot provisioning as an appliance workflow rather than a traditional Linux networking workflow

Without these adjustments, developers are likely to encounter persistent instability and unpredictable WiFi behavior when migrating SvxLink provisioning systems from Bookworm to Trixie.