netdev - Re: vxlan mac address generation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20200416095314.0a1dff38@strong.id.au>
Date:   Thu, 16 Apr 2020 09:53:14 +1000
From:   Russell Strong <russell@...ong.id.au>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org
Subject: Re: vxlan mac address generation

On Wed, 15 Apr 2020 13:21:31 +0300
Ido Schimmel <idosch@...sch.org> wrote:

> On Wed, Apr 15, 2020 at 05:28:00PM +1000, Russell Strong wrote:
> > I tried debian ( 4.19.0-8-amd64 ) and got the same result as you.
> > I am using Fedora 31 ( 5.5.15-200.fc31.x86_64 ).  I have discovered
> > a difference:
> > 
> > On fedora /sys/class/net/v0/addr_assign_type = 3
> > On debian /sys/class/net/v0/addr_assign_type = 1
> > 
> > The debian value is what I would expect (NET_ADDR_RANDOM).  I
> > thought addr_assign_type was controlled by the driver.  Do you
> > think this could be a Fedora bug, or perhaps something has changed
> > between 4.19 and 5.5?  
> 
> I assume you're using systemd 242 or later. I also hit this issue.
> Documented the solution here:
> 
> https://github.com/Mellanox/mlxsw/wiki/Persistent-Configuration#required-changes-to-macaddresspolicy

Thank you.  You have hit on the issue.

So for future googlers:

I was not using systemds' networking, I'm building my own embedded
router for radio and satellite networks, but because they have spilled
their functionality into udev as well, it can not be turned off without
modifying /usr/lib/systemd/network/99-default.link. This is not a
directory listed in the udev man page, and udev seems to be ignoring any
administrative overrides in /etc/udev/rules.d

I changed the line
MACAddressPolicy=persistent
to
MACAddressPolicy=none

The systemd requirement that implemented this says it all:

Keep MACPolicy=persistent. If people don't want it, they can always
apply local configuration, but in general stable MACs are a good thing.
I have never seen anyone complain about that.

Not the first time and won't be the last time systemd policy decisions
have caught me out.

Thanks again everyone,
Russell