Hi.
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. If the drivers are the same then the issue was probably introduced by the changes made to start using ".link" vs .rules" files.
> 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!
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. If I can't then I will dig to see what is it exactly that makes it different in Bullseye. If it's reproducible I will see if I can work with maintainers in some part of the OS to help... Probably will try to start with the driver's maintainers.
BTW, Reco, my apologies once again for emailing you directly instead of through the list, that was inadvertent.