[Networkmanager] Howto add 802-1x settings for all new ethernet connections

Thomas Haller thaller at redhat.com
Mon Feb 13 09:10:26 UTC 2023


On Mon, 2023-02-13 at 08:19 +0100, Till Maas wrote:
> 
> 
> Am So., 12. Feb. 2023 um 21:20 Uhr schrieb Thomas Haller
> <thaller at redhat.com>:
> > Hi,
> > 
> > 
> > On Sun, 2023-02-12 at 11:00 +0100, John Doe wrote:
> > > We're currently looking into requiring 802-1x for all wired
> > > ethernet
> > > connections.
> > > We have a large number of Linux clients. Mostly slim laptops that
> > > don't have an ethernet adapter. These connect to the wired
> > > network
> > > using docking stations or usb to ethernet adapters. All Linux
> > > clients
> > > are deployed using PXE boot to deploy the company image.
> > > Problem is during the deploy process there's of course only the
> > > adapter used for the deploy availbale on the client. I can get
> > > the
> > > 802-1x settings added for this adapter as part of the deploy.
> > > But then I'm out of control. I can't control NetworkManager to
> > > setup
> > > 802-1x for the connection created by NetworkManager when the user
> > > connects to a docking station. Yes, unfortunately it creates a
> > > new
> > > wired connection.
> > 
> > you can disable that with "[main].no-auto-default=*" in
> > NetworkManager.conf. Of course, the the user plugs in a new
> > ethernet
> > device and NetworkManager isn't doing anything automatically.
> > Whether
> > that is more desirable is unclear.
> > 
> 
> 
> It seems to me that having NM ship a default profile
> with "connection.multi-connect=multiple" that contains the settings
> that the automatically created profile simplifies the configuration
> and makes the behavior accessible via the API and reduces the need to
> configure this with the NetworkManager-config-server subpackage.

Predeploying a profile doesn't seem to make anything more accessible
via the API.

> What would be the downside of removing the auto-default behavior?

If a suitable profile would be pre-deployed, then the auto-default
behavior is already not taking effect.

yes, could be done. But it's not clearly better. After all, multi-
connect profiles are slightly more confusing. It's also more confusing
to edit a profile pre-deployed in /usr/lib (because it gets copied to
/etc). Unless the profile gets placed to /etc, which seems not great to
ship from an RPM.


Thomas

> 
> Cheers
> Till
>  
> > 
> > That profile only gets created, because there is no otherwise
> > suitable
> > profile. If you pre-deploy an ethernet profile that can activate on
> > any
> > interface, then this has no effect.
> > 
> > > It doesn't use the existing one.
> > > I've looked into setting up connection settings in
> > > NetworkManager.conf. Unfortunately it only supports the 802-
> > > 1x.auth-
> > > timeout setting.
> > > I've tried using a pre-up dispatcher script, unfortunately it
> > > don't
> > > pick up on adding settings to the connection profile.
> > > I've tried using 2 pre-created connection profiles that only list
> > > the
> > > type as ethernet and don't point to a specific interface. This
> > > works
> > > for Ubuntu 20.04 and 22.04 but not 18.04, nmcli in Ubuntu 18.04
> > > requires specifying ifname when creating a connection profile.
> > 
> > That also works with older nmcli: 
> > 
> >   nmcli connection add ... ifname "*"
> > 
> > > Is there some way to hook into NetworkManager whenever it picks
> > > up a
> > > new device and add the 802-1x settings for all new wired
> > > connection
> > > profiles?
> > 
> > No, the "Wired connection 1" is (almost) not configurable,
> > certainly
> > not for a 802-1x settings. In any case, there is usually no need
> > for a
> > way to hook that, just create the profile you want instead.
> > 
> > 
> > It sounds like, you just should create a profile that is not tied
> > to a
> > particular interface and has the 802.1x settings. If you want,
> > maybe
> > also set "connection.multi-connect=multiple", so that the profile
> > can
> > activate on more than one devices at a time.
> > 
> > 
> > Thomas
> > 
> 
> 



More information about the Networkmanager mailing list