Hi,

On Thu, 2023-12-21 at 16:08 +0000, Gary Buhrmaster wrote:
> On Thu, Dec 21, 2023 at 2:49 PM Tom Hughes via devel
> <devel@lists.fedoraproject.org> wrote:
> > 
> > On 21/12/2023 14:33, Steven A. Falco wrote:
> > > On 12/21/23 08:53 AM, Neal Gompa wrote:
> > > > On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott
> > > > <leigh123li...@gmail.com>
> > > > wrote:
> > > > > 
> > > > > I'm -1 for this change, it shouldn't be enabled by default as
> > > > > it will
> > > > > cause issues for users using router mac filtering.

If you configure the devices MAC addresses on your router, you have a
somewhat established procedure how to do that. E.g. when a family
member gets a new notebook.

The upgrade to Fedora 40, will be a one time event, where you have to
do that again (or you opt out from the change).

> > > > 
> > > > What this seems to state is that the MAC address would be
> > > > unique for
> > > > each SSID, but once it's picked, it would be locked in. That
> > > > should
> > > > still make router-level MAC filtering possible, since the MAC
> > > > address
> > > > would be stable for that network.
> > > 
> > > What would happen on a network where I've set up the DHCP server
> > > in my
> > > router to map mac addresses to static IP addresses?  Sounds like
> > > I'd
> > > have to disable the feature, at least on my home network.
> > 
> > Either that or you would make a one off change to your DHCP server
> > to use the new per-network MAC address instead of the old one.
> 
> Would it not have to be done every time
> one reinstalls their system?

Yes. Unless you copy over /etc/machine-id and
/var/lib/NetworkManager/secret_key.

These 2 files are the identity of your machine. If you lose them during
re-install, you get a different machine. The same already applies with
`ipv6.addr-gen-mode`, which defaults to "stable-privacy" to get RFC7217
IPv6 interface identifiers (meaning, you'll get a different IPv6
address after reinstall).

>   And on
> each SSID one connects to (so connect
> to your HOME-5G (for your 5GHz AP),
> and HOME-2.4G (for your 2.4GHz AP),
> wifi networks would get different MAC
> addresses as the SSID is different?)

for the two profiles of your home network, you most likely would do

  for PROFILE in HOME-5G HOME-2.4G ; do
      nmcli connection modify "$PROFILE" \
           connection.stable-id "my-home-wifi" \
           wifi.cloned-mac-address stable
  done

(or `wifi.cloned-mac-address permanent`).


With Wi-Fi we commonly have many profiles (Hotels, public Wi-Fis). Only
a small number are our home networks, where we might care about the MAC
address. You can select the best behavior for those selected few
profiles, but getting a more reasonable default ("stable-ssid") for all
other profiles.

To be clear, I also use "stable" MAC at home. For most cases, there is
little reason to use the MAC address of their hardware. Yes, I somewhat
care that for the most time I get the same IP address from my DHCP
server. If that IP address changes once after upgrade to Fedora 40, I
don't care. And it's not even said, that the IP address is going to
change. NetworkManager has the DHCP lease stored on disk, it will ask
the server to hand out the same IP address.


> 
> (side note:  some DHCP servers may
> not like assigning different MACs to
> the same IP address to allow individuals
> to choose their own access point
> frequency range based SSID).
> 
> While doing so as an individual would
> probably be minorly annoying, for some
> orgs, "re-imaging" a system is the
> standard practice for repair (or
> redeployment, or for each reboot
> for guest systems) and having a stable
> MAC address (whether wired or wireless)
> is necessary for institutional requirements.


Would a company network really care about the MAC address? It doesn't
seem to scale, that new devices need to be registered.


Seems such an org is also pre-deploying configuration on the machine.
The profiles can be pre-deployed with "wifi.cloned-mac-address
permanent".

Or just a

  $ touch /etc/NetworkManager/conf.d/22-wifi-mac-addr.conf

to disable all what this change brings.


> 
> And for some orgs with advanced 802.1x
> network access controls, changing MAC
> addresses may result in even more
> additional tasks across different parts
> of the organization (yes, one should not
> use mac authentication alone for
> 802.1x, but that is a different topic).

> 
> For orgs with a more sophisticated
> process, updating their ansible
> provisioning scripts to change the
> NetworkManager to use the hardware
> address may be possible, although for
> others, that will be one more step for
> tech support to have to do manually
> (and, of course, occasionally forget to
> do, as they are always overworked),

If you company tech support expects a call if the MAC address of the
users notebook changes, they can also expect a call when they use a
different notebook. That is asking for work.

>  but
> at the very least the proposal should
> probably call out that change
> requirement more explicitly for such
> orgs.
> 
> Given the unknown impact on larger
> organization customers (rather than
> individuals taking their own devices
> to an overpriced coffee shop), I am
> currently leaning on the -1 side.


The Change is about using a generated MAC address. You can obviously
find scenarios, where you can notice the change or even be badly
affected by it. Obviously, this is cumbersome for affected users,
because they'll need to take actions for a change they don't want. I am
sorry for that burden. Regardless, I think the change benefits the vast
majority of users.


AFAIK, Android, IPhone and Windows do something similar for a while
already. It's a bit embarrassing that we don't.



Thomas
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to