Re: 73-usb-net-by-mac.rules is no longer used in Bullseye for USB ethernet devices?

[Reco <recoverym4n@enotuniq.net>]

	Hi.

On Sun, Feb 20, 2022 at 05:30:10PM -0600, Flacusbigotis wrote:
> On Thu, Feb 17, 2022 at 1:06 AM Reco <recoverym4n@enotuniq.net> wrote:
> > On Thu, Feb 17, 2022 at 12:32:48AM -0600, Flacusbigotis wrote:
> > > Thanks Reco & Greg.  I did see the
> > > /lib/systemd/network/73-usb-net-by-mac.link file. Thanks for that.
> > >
> > > I don't know exactly what is happening, but the MAC address of the device
> > > keeps changing  after an ifdown/ifup cycle post boot.
> >
> > You should've said that first.
> >
> 
> I only found that out later after the 1st post :-)

:)


> > If the MAC address of the NIC is not persistent, that means udev will
> > provide you with different interface name each time you boot.
> > That means that you've hit yet another case of unpredictability of so
> > called Predictable Network Interface Names.
> >
> I did not have this problem in Debian 10.  I do not know if the card's
> driver has changed between the two versions of Debian, so I am going to
> boot into a Debian 10 live image and see if it displays the same behavior.

It's possible, of course. What's also possible is card's EEPROM may have
gone haywire. I had a similar problem back in the day with rtl8139 NIC,
IIRC. One day the thing simply started to assign itself a random MAC
(but worked in every other regard), and since the thing was a part of
the motherboard - I had to try almost every workaround in the existence.


> If the drivers are the same then the issue was probably introduced by the
> changes made to start using ".link" vs .rules" files.

".link" and ".rules" are merely means to configure udev, they mean
nothing to the kernel. By default udev should not randomize NIC's MAC.


> > > I also tried adding a udev file (/etc/udev/rules.d/99_fix_usb.rules) with
> > > the following content to try to force the addr_assign_type to 0, but this
> > > did nothing:
> > >
> > > SUBSYSTEMS=="usb", SUBSYSTEM=="net", ATTR{addr_assign_type}="0"
> >
> > Try this:
> >
> > 1) Create a file called /etc/systemd/network/00-usb.link with the following
> > contents:
> >
> > [Match]
> > Driver=ax88179_178a
> >
> > [Link]
> > MACAddressPolicy=none
> > NamePolicy=kernel
> >
> > You may have to create an appropriate directory, and the file name has
> > to start with double zeroes.
> >
> > 2) Invoke (really needed):
> >
> > update-initramfs -k all -u
> >
> > 3) Reboot.
> >
> > 4) Watch your network interface is called usb0 from now then.
> >
> > Thanks!

You're welcome.


> > Now, this approach has its caveats, so:
> >
> > 1) If you ever plug-in two USB devices that both served with
> > "ax88179_178a" - you won't be able to distinguish between them. They
> > will be called usb0, usb1, etc without any meaningful order.
> >
> > Ugghhh.. I am not entirely comfortable with that.
> 
> 
> > 2) If they decide to rename "ax88179_178a" in the kernel - this link
> > file will cease to work for obvious reasons.
> >
> >  Also not comfortable with this.
> 
> I'll first check if I can replicate the behavior in Buster.

IIRC in Buster .link files are ignored if 73-usb-net-by-mac.rules apply
to the NIC. But you can cheat it by creating an empty file called:
/etc/udev/rules.d/73-usb-net-by-mac.rules

Reco