Background Information
=======================

Debian 12 Bookworm has been freshly installed on a laptop. The laptop is functioning as a simple home server and has three Ethernet devices, two USB Ethernet adapters and a built-in Ethernet adapter. Ethernet cables are permanently inserted into each of
the Ethernet ports on the server laptop, the other ends are only inserted into client devices as needed.

The output of "cat /etc/os-release" is:

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"; SUPPORT_URL="https://www.debian.org/support"; BUG_REPORT_URL="https://bugs.debian.org/";
IMAGE_ID=live
BUILD_ID=20241109T101058Z

The output of the "uname -a" command is:

Linux debian-12-server 6.1.0-27-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.115-1 (2024-11-01) x86_64 GNU/Linux

Problem
=========

Since installation, the Ethernet connections have refused to honor the "Connect Automatically" setting in Settings >> Network when a cable from the server is connected to a client. It is my expectation that when a cable from the server is connected to
the Ethernet port of a client device, the Debian server will automatically recognize the new physical connection and then automatically activate that connection. Unfortunately, this doesn't happen for any of the server's Ethernet ports.

The Debian server will recognize that a new physical connection has been made, which is demonstrated by the change from "Cable unplugged" to "100Mb/s" or "1000Mb/s" in the Network Settings window, but the server will not activate the connection
automatically. Each must be manually activated using the toggle either in Network Settings or through the top panel menu for the connection to become usable. This is true for the built-in Ethernet port and the USB adapter ports.

Each of the Ethernet devices uses the following common connection profile settings:

Details section:
   Connect Automatically ON
   Make available to other users OFF
Identity section:
   MAC address - each connection profile is pinned to the MAC address of a different Ethernet adapter
IPv4 section:
   Method MANUAL - the IP addresses are manually assigned so that each adapter uses a different subnet.
IPv6 section:
   Method DISABLE

Apart from this problem, all the network connections from the clients to the server function well once they are manually activated. There are no unexpected disconnections or problems with transfer speed.

Troubleshooting
================

I have tried deleting and re-creating the Network connection profile for each Ethernet device.

I have tried removing and re-inserting the USB ethernet adapters.

I have performed all system updates, currently on 12.10.

I noted that systemd-networkd service is not running by default. For testing purposes I enabled and started this service, but there was no improvement.

I have rebooted the server several times since installing Debian 12 and the problem remains after each reboot.

Additional Information
=======================

As an example, here is the output of 'ethtool' for USB Ethernet Adapter #1:

   Supported ports: [ TP MII ]
   Supported link modes:   10baseT/Half 10baseT/Full                         100baseT/Half 100baseT/Full                         1000baseT/Half 1000baseT/Full
   Supported pause frame use: No
   Supports auto-negotiation: Yes
   Supported FEC modes: Not reported
   Advertised link modes:  10baseT/Half 10baseT/Full                         100baseT/Half 100baseT/Full                         1000baseT/Full
   Advertised pause frame use: No
   Advertised auto-negotiation: Yes
   Advertised FEC modes: Not reported
   Speed: 1000Mb/s
   Duplex: Full
   Auto-negotiation: on
   Port: MII
   PHYAD: 32
   Transceiver: internal
   Supports Wake-on: pumbg
   Wake-on: g
        Current message level: 0x00007fff (32767)                                drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
   Link detected: yes

Here is the output of 'ip addr' for USB Ethernet Adapter #1 under different circumstances:

After physically inserting an Ethernet cable into a client port, but before manually  activating the connection on the server:

   2: enx3a2a15663da2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 3a:2a:15:66:3d:a2 brd ff:ff:ff:ff:ff:ff

After manually activating the connection on the server:

   2: enx3a2a15663da2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether c6:37:0d:d1:7b:9f brd ff:ff:ff:ff:ff:ff permaddr 3a:2a:15:66:3d:a2
    inet 192.168.1.1/24 brd 192.168.1.255 scope global noprefixroute enx3a2a15663da2
       valid_lft forever preferred_lft forever

Side Questions
===============

Is it normal for 'systemd-networkd' not to be running by default on a fresh installation of Debian 12, as a general rule? I disabled it again after troubleshooting this problem.

'ifconfig' is not installed by default. Is this also normal for a fresh installation of Debian 12?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 4 Apr 2025 00:56:05 +0200 (CEST)
[email protected] wrote:

Is it normal for 'systemd-networkd' not to be running by default on a
fresh installation of Debian 12, as a general rule? I disabled it
again after troubleshooting this problem.

Yes, it is.

Installation does no setup for systemd-networkd, and running it before
you have done that setup is meaningless. I usually install the Debian
ifupdown package via preseeding so I have networking on a fresh
installation. I then switch to either Network Manager or
systemd-networkd as appropriate. For the latter, I install one or more
files in /etc/systemd/network/, one for each interface. See "man systemd-networkd" for the gory details.

For what you are doing, I suggest Network Manager and firewalld. They
play well together, and handle connections coming and going well. You
can assign firewall zones to specific interfaces, which helps.

'ifconfig' is not installed by default. Is this also normal for a
fresh installation of Debian 12?

Yes. ifconfig is part of the net-tools package. Or you could use ip.
I've been using ifconfig for more than 25 years, and am slowly learning
ip.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Apr 03, 2025 at 09:38:29PM -0400, Jeffrey Walton wrote:

... when a cable from the server is connected to the Ethernet port
of a client device, the Debian server will automatically recognize
the new physical connection and then automatically activate that
connection.

It sounds like the client is connected directly to the server via
ethernet, presumably without a cross-over ethernet cable. So both
ethernet ports would need to auto-sense the configuration.

That hasn't really been a problem for 25 years, it's definitely not
something to worry about on consumer gigabit hardware. (Auto-MDI-X came
out around the year 2000 as an option on 10/100Mbps gear, and was more
common on consumer grade hardware originally--professionals being
presumed to know what cable to use. The earliest 1000baseT hardware was sometimes a bit flaky, but those issues were ironed out a long time ago
and the simplest $5 realtek chip you can buy these days doesn't care
whether you're using a straight through or crossover cable.)

As confirmation, the ip and ethool output show the link as up; if we
were looking at some bizarre hardware which had MDI/-X issues there
wouldn't be a link at all.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Apr 04, 2025 at 05:19:08PM +0800, jeremy ardley wrote:

Off Topic I just did a 1 year diploma in advanced networking. I
couldn't even comprehend why the still had crossover cables in the
lab. Perhaps to accommodate pre-2000 CISCO switches?

cisco was one of the companies that was late to the auto-mdi-x game,
they were selling them well past 2000.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Apr 4, 2025 at 11:56 PM <[email protected]> wrote:

Can you try it with Make available to other users ON

Toggling "Make available to other users" to ON solves the problem! First I tested this with the built-in Ethernet adapter. After this was successful I configured this to ON for the other adapters and rebooted the device. Now all the devices honor the "
Connect Automatically" setting. Thank you!

I think there is still the question of why this setting must be ON for this to work properly. I followed the steps suggested by Max Nikulin and I think there is something interesting in the output of 'journalctl -f'. For comparison I have included the
output of 'journalctl -f' from before and after I enabled "Make available to other users". Please see below.

On Thu, Apr 4, 2025 at 3:13 PM <[email protected]> wrote:

find moment of plugging in cable in output of
 
# journalctl -f

sudo journalctl -f:

<ETHERNET CABLE FROM SERVER PHYSICALLY CONNECTED TO CLIENT #2>

NetworkManager[887]: <info>   device (enp0s25): carrier: link connected kernel: e1000e 0000:00:19.0 enp0s25: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
NetworkManager[887]: <info>   device (enp0s25): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
gnome-shell[1958]: JS ERROR: Error: Argument str2 may not be null                    _sortByName@resource:///org/gnome/shell/ui/status/network.js:122:21
                   lowerBound@resource:///org/gnome/shell/misc/util.js:357:26
                   insertSorted@resource:///org/gnome/shell/misc/util.js:369:25
                   _upsert@resource:///org/gnome/shell/ui/status/network.js:131:21
                   upsert@resource:///org/gnome/shell/ui/status/network.js:150:21
                   _resortItem@resource:///org/gnome/shell/ui/status/network.js:543:38
                   _addConnection/<@resource:///org/gnome/shell/ui/status/network.js:567:40
                   NMDeviceConnectionItem/<@resource:///org/gnome/shell/ui/status/network.js:402:46
                   _generateAccessors/propdesc.set@resource:///org/gnome/gjs/modules/core/_common.js:37:26
                   _sync@resource:///org/gnome/shell/ui/status/network.js:595:9
                   _sync@resource:///org/gnome/shell/ui/status/network.js:630:15
                   _addConnection@resource:///org/gnome/shell/ui/status/network.js:573:14
                   _syncConnections@resource:///org/gnome/shell/ui/status/network.js:503:18
                   NMDeviceItem@resource:///org/gnome/shell/ui/status/network.js:461:14
                   NMWiredDeviceItem@resource:///org/gnome/shell/ui/status/network.js:603:1
                   _createDeviceMenuItem@resource:///org/gnome/shell/ui/status/network.js:1827:16
                   _ensureDeviceItem@resource:///org/gnome/shell/ui/status/network.js:1662:27
                   _syncDeviceItem@resource:///org/gnome/shell/ui/status/network.js:1635:18
                   _addDevice/<@resource:///org/gnome/shell/ui/status/network.js:1681:41
gnome-shell[1958]: JS ERROR: Error: Argument str2 may not be null                    _sortByName@resource:///org/gnome/shell/ui/status/network.js:122:21
                   lowerBound@resource:///org/gnome/shell/misc/util.js:357:26
                   insertSorted@resource:///org/gnome/shell/misc/util.js:369:25
                   _upsert@resource:///org/gnome/shell/ui/status/network.js:131:21
                   upsert@resource:///org/gnome/shell/ui/status/network.js:150:21
                   _resortItem@resource:///org/gnome/shell/ui/status/network.js:543:38
                   _addConnection/<@resource:///org/gnome/shell/ui/status/network.js:567:40
                   NMDeviceConnectionItem/<@resource:///org/gnome/shell/ui/status/network.js:403:47
                   setDeviceName@resource:///org/gnome/shell/ui/status/network.js:590:14
                   _ensureDeviceItem@resource:///org/gnome/shell/ui/status/network.js:1663:14
                   _syncDeviceItem@resource:///org/gnome/shell/ui/status/network.js:1635:18
                   _addDevice/<@resource:///org/gnome/shell/ui/status/network.js:1681:41

<CLIENT #2 ETHERNET CONNECTION MANUALLY ACTIVATED ON SERVER>

NetworkManager[887]: <info>   device (enp0s25): Activation: starting connection 'Built-in Ethernet' 
NetworkManager[887]: <info>   audit: op="connection-activate" name="Built-in Ethernet" pid=1958 uid=1001 result="success"
NetworkManager[887]: <info>   device (enp0s25): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
NetworkManager[887]: <info>   device (enp0s25): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
NetworkManager[887]: <info>   device (enp0s25): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
avahi-daemon[815]: Joining mDNS multicast group on interface enp0s25.IPv4 with address 192.168.1.1.
avahi-daemon[815]: New relevant interface enp0s25.IPv4 for mDNS. avahi-daemon[815]: Registering new address record for 192.168.1.1 on enp0s25.IPv4.
NetworkManager[887]: <info>   device (enp0s25): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
dbus-daemon[818]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.7' (uid=0 pid=887 comm="/usr/sbin/NetworkManager --no-daemon")
systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service...
dbus-daemon[818]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service.
NetworkManager[887]: <info>   device (enp0s25): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
NetworkManager[887]: <info>   device (enp0s25): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
NetworkManager[887]: <info>   device (enp0s25): Activation: successful, device activated.
systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.

<SYSTEM REBOOT>
<ETHERNET CABLE FROM SERVER PHYSICALLY CONNECTED TO CLIENT #2 WITH "Make available to other users" SET TO "ON">

NetworkManager[887]: <info>   device (enp0s25): carrier: link connected kernel: e1000e 0000:00:19.0 enp0s25: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
NetworkManager[887]: <info>   device (enp0s25): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
NetworkManager[887]: <info>   policy: auto-activating connection 'Built-in Ethernet' 
NetworkManager[887]: <info>   device (enp0s25): Activation: starting connection 'Built-in Ethernet' 
NetworkManager[887]: <info>   device (enp0s25): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
NetworkManager[887]: <info>   device (enp0s25): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
NetworkManager[887]: <info>   device (enp0s25): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
avahi-daemon[815]: Joining mDNS multicast group on interface enp0s25.IPv4 with address 192.168.1.1.
avahi-daemon[815]: New relevant interface enp0s25.IPv4 for mDNS. avahi-daemon[815]: Registering new address record for 192.168.1.1 on enp0s25.IPv4.
NetworkManager[887]: <info>   device (enp0s25): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
dbus-daemon[818]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.7' (uid=0 pid=887 comm="/usr/sbin/NetworkManager --no-daemon")
gnome-shell[1958]: JS ERROR: Error: Argument str2 may not be null                    _sortByName@resource:///org/gnome/shell/ui/status/network.js:122:21
                   lowerBound@resource:///org/gnome/shell/misc/util.js:357:26
                   insertSorted@resource:///org/gnome/shell/misc/util.js:369:25
                   _upsert@resource:///org/gnome/shell/ui/status/network.js:131:21
                   upsert@resource:///org/gnome/shell/ui/status/network.js:150:21
                   _resortItem@resource:///org/gnome/shell/ui/status/network.js:543:38
                   _addConnection/<@resource:///org/gnome/shell/ui/status/network.js:567:40
                   NMDeviceConnectionItem/<@resource:///org/gnome/shell/ui/status/network.js:402:46
                   _generateAccessors/propdesc.set@resource:///org/gnome/gjs/modules/core/_common.js:37:26
                   _sync@resource:///org/gnome/shell/ui/status/network.js:595:9
                   _sync@resource:///org/gnome/shell/ui/status/network.js:630:15
                   _addConnection@resource:///org/gnome/shell/ui/status/network.js:573:14
                   _syncConnections@resource:///org/gnome/shell/ui/status/network.js:503:18
                   NMDeviceItem@resource:///org/gnome/shell/ui/status/network.js:461:14
                   NMWiredDeviceItem@resource:///org/gnome/shell/ui/status/network.js:603:1
                   _createDeviceMenuItem@resource:///org/gnome/shell/ui/status/network.js:1827:16
                   _ensureDeviceItem@resource:///org/gnome/shell/ui/status/network.js:1662:27
                   _syncDeviceItem@resource:///org/gnome/shell/ui/status/network.js:1635:18
                   _addDevice/<@resource:///org/gnome/shell/ui/status/network.js:1681:41
gnome-shell[1958]: JS ERROR: Error: Argument str2 may not be null                    _sortByName@resource:///org/gnome/shell/ui/status/network.js:122:21
                   lowerBound@resource:///org/gnome/shell/misc/util.js:357:26
                   insertSorted@resource:///org/gnome/shell/misc/util.js:369:25
                   _upsert@resource:///org/gnome/shell/ui/status/network.js:131:21
                   upsert@resource:///org/gnome/shell/ui/status/network.js:150:21
                   _resortItem@resource:///org/gnome/shell/ui/status/network.js:543:38
                   _addConnection/<@resource:///org/gnome/shell/ui/status/network.js:567:40
                   NMDeviceConnectionItem/<@resource:///org/gnome/shell/ui/status/network.js:403:47
                   setDeviceName@resource:///org/gnome/shell/ui/status/network.js:590:14
                   _ensureDeviceItem@resource:///org/gnome/shell/ui/status/network.js:1663:14
                   _syncDeviceItem@resource:///org/gnome/shell/ui/status/network.js:1635:18
                   _addDevice/<@resource:///org/gnome/shell/ui/status/network.js:1681:41
dbus-daemon[818]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service...
systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service.
NetworkManager[887]: <info>   device (enp0s25): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
NetworkManager[887]: <info>   device (enp0s25): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
NetworkManager[887]: <info>   device (enp0s25): Activation: successful, device activated.
systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I am curious what nmcli subcommand reports when the cable is plugged in, but the connection has not activated manually.

Should I pursue the strange behavior of needing to have "Make available to others users" enabled for the "Connect Automatically" setting to be respected, in case there is a bug, or close this issue as solved? I'm happy either way.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/7/25 14:34, [email protected] wrote:

Should I pursue the strange behavior of needing to have "Make available to others users" enabled for the "Connect Automatically" setting to be respected, in case there is a bug, or close this issue as solved? I'm happy either way.

FWIW, I generally don't get along with NetworkManager on server
installations and end up uninstalling it and running either
systemd-networkd or netplan. I just got done with a server install where
the network was not coming up until after I logged into the desktop. I
removed NetworkManager and used systemd-networkd then everything worked
like I wanted.

After that, I noticed your 'fix' of 'Make available to other users.'
Sorry, my NetworkManager is already gone, otherwise I'd check if that
also works here.

--

Titus Newswanger
Curtiss WI

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon 07 Apr 2025 at 21:34:42 (+0200), [email protected] wrote:

I am curious what nmcli subcommand reports when the cable is plugged in, but the connection has not activated manually.

Should I pursue the strange behavior of needing to have "Make available to others users" enabled for the "Connect Automatically" setting to be respected, in case there is a bug, or close this issue as solved? I'm happy either way.

As someone who has never used NM, I can only guess that you're setting
up User connections rather than System ones. If they /are/ system ones,
they will be specified in system-connections/ under one of: /etc/NetworkManager/, /usr/lib/NetworkManager/, or /run/NetworkManager/
(least likely the second).

Can you demonstrate that? (As they're cable connections, there should
be no secrets in the files, unless you also have some wireless
configurations involved; but do obfuscate any sensitive items.)

AIUI making User connections is the way Windows and some desktop
environments are designed to work by default.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Apr 07, 2025 at 09:34:42PM +0200, [email protected] wrote:

Should I pursue the strange behavior of needing to have "Make available
to others users" enabled for the "Connect Automatically" setting to be >respected, in case there is a bug, or close this issue as solved? I'm
happy either way.

You're asking the system to automatically configure a connection, but
you're also asking it to not let other users use the connection. You
can't have both. It might be a wishlist bug to clarify that in the
interface, but I don't see a downside in the case to simply making the connection available to all users. (The only reason you would not want
to do that is if the connection included some user-specific
credentials and you'd want to control when it was used.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thank you for the continued responses. I performed some very basic testing using a Debian 12.8.0 Live CD. The results were confusing and highlighted some issues with the creation of network profiles in general, at least from my point of view.

The short version is that if the behavior with "Connect Automatically" and "Make available to other users"  is down to NetworkManager, then I sympathize with the suggestions to migrate from it to systemd-networkd. If someone could point me to a simple
guide for that I'll look into it.

Regarding reporting a bug, I have to say I'm not inclined to this, because I've learned from others this can get quite involved and lead to demands on the submitter's time. On the other hand, I think the behaviors I've experienced ought to be addressed
at some point, because the confusion is bound to affect other users, especially those trying Debian for the first time.

The long version, which is a description of the testing, and the results of my testing on the Live CD:

All testing was performed using the Network panel in the Settings application.

The default Debian Live user has admin privileges, so I used this for my initial testing. I configured the default wired network profile with a manual IPv4 address and _disabled_ "Make available to other users". As expected, the wired connection was
automatically activated once the physical connection was made to the server.

Within the same boot session, I created and switched to a new user via the GUI, a standard user with no admin privileges. The same default wired network profile was re-configured with "Make available to other users" _enabled_. As expected, the wired
connection from within this standard user account was automatically activated once the physical connection was made to the server.

So far, everything has worked as expected. But then I tested the scenario I was having trouble with.
As the same standard user, I set the default wired network profile so that "Make available to other users" was now _disabled_. Contrary to my expectations, the wired connection was still automatically activated once the physical connection was made to
the server. This seems to be at odds with the idea expressed by Lee and possibly Michael Stone that, when the the current GUI user doesn't have the correct privileges, "Connect Automatically" would fail in this case, but it's possible I've missed
something.

When I attempted to make changes to the Details tab as the standard user I came across something I think is surely a bug, though. The Details tab of a network profile created by a standard user is available to view by the standard user, but attempting to
modify the available settings triggers a prompt for admin authentication, and here's the problem: if the standard user chooses to Cancel the prompt (I  tap the Escape key), then _the GUI shows the setting as modified when it is not_. I was able to
determine that this is a visual feedback error because testing showed that the behavior of the network profile respected the settings in place _before_ the unauthenticated changes. This lack of accurate visual feedback survives the closing and re-opening
of the network profile being modified. I tested this with the "Connect Automatically" and "Make available to other users" settings.

Other issues I experienced during this testing were:

Admin credentials appear to be silently cached, similar to sudo, when authenticating in the Settings application. This is confusing and can make it difficult to perform troubleshooting. I would personally prefer credential caching in the GUI to be turned
off, or visible to the user with the option to clear the cache. Although I hate this behavior in Windows, not caching the credentials is definitely preferable, in my opinion, to silently caching. I think on Macs, users enable and disable admin privileges
to modify system settings with a GUI padlock (but this was years ago, it might have changed), and I always thought that was an elegant solution.
During the creation of the test network profile as a standard user, I was not allowed (in fact I wasn't even offered the option) to configure the settings on the Details tab - this is where the "Connect automatically" and "Make available to other users"
settings are. These settings appear to be available only to admin users. I found this confusing - does the standard user have ownership of a network profile they create or not? Why would these options only be available to admin users?
The active connection GUI in the Settings application's Network tab changes from a sliding button to a check mark when more than one network profile is configured. In fact, the sliding button disappears altogether. Also, the visual feedback of "Cable
unplugged" and "100 Mbps"/"1000 Mbps" indicating a cable's physical connection status disappears.
Without trying to be offensive, I actually encountered so much strange behavior during my testing that I would gladly migrate to something less confusing to use.

If there's an easy way to submit these issues without tying myself to a prolonged need to submit feedback and do independent testing, please let me know. I'd also be grateful to be told where exactly to file that feedback.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

12 Apr 2025, 03:59 by [email protected]:

On 12/4/25 08:16, [email protected] wrote:

The short version is that if the behavior with "Connect Automatically" and "Make available to other users"  is down to NetworkManager, then I sympathize with the suggestions to migrate from it to systemd-networkd. If someone could point me to a

simple guide for that I'll look into it.

This is O.K. as a guide. https://techdocs.akamai.com/cloud-computing/docs/network-configuration-using-systemd-networkd

<snip>

Thank you. When I find the time I'll look into following this and the additional steps you supplied.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)