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

[Flacusbigotis]

My internet connection is off the ethernet port of a PCI-E card that also has USB ports on it, so the ethernet device is recognized as a "USB ethernet device"...

Back in Debian Buster, I learned that the "predictive" naming of this USB ethernet interface would be governed by "73-usb-net-by-mac.rules" and so I had it configured accordingly with a config file in /etc/network/interfaces.d/... Namely that the device name would basically be its MAC.

Well, I just upgraded to Bullseye, and I can't bring up the darn interface.  I have tried fiddling around with the device name in my config file in /etc/network/interfaces.d/ directory, but it just won't come up.  The Networking.service also fails during bootup.

I also noticed that the 73-usb-net-by-mac.rules file has completely disappeared, never mind that the official Debian NetworkInterfaceNames page here still talks about it!

Anyone know how the heck this is supposed to work in Bullseye?

BTW, the device shows up as disabled in lshw (I obfuscated the MAC in the output):

 *-network DISABLED
       description: Ethernet interface
       physical id: 1
       bus info: usb@7:1
       logical name: enx00XXXXXXXXXX    <<<=== Yes, I tried using this name in the config
       serial: 00:XX:XX:XX:XX:XX
       size: 10Mbit/s
       capacity: 1Gbit/s
       capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=off broadcast=yes driver=ax88179_178a driverversion=5.10.0-11-amd64 duplex=half link=no multicast=yes port=MII speed=10Mbit/s

[Reco]

Hi.

On Wed, Feb 16, 2022 at 03:55:21AM -0600, Flacusbigotis wrote:
> Back in Debian Buster, I learned that the "predictive" naming of this USB
> ethernet interface would be governed by "73-usb-net-by-mac.rules" and so I
> had it configured accordingly with a config file in
> /etc/network/interfaces.d/... Namely that the device name would basically
> be its MAC.

It's still true in Bullseye, but the implementation has changed
somewhat.
Instead of /lib/udev/rules.d/73-usb-net-by-mac.rules now systemd uses
/lib/systemd/network/73-usb-net-by-mac.link.

> Well, I just upgraded to Bullseye, and I can't bring up the darn
> interface. I have tried fiddling around with the device name in my config
> file in /etc/network/interfaces.d/ directory, but it just won't come up.
> The Networking.service also fails during bootup.

A straightforward approach would be to learn the actual name of the
device via "ip a"/"ifconfig -a", and then using that name in /e/n/i.

> Anyone know how the heck this is supposed to work in Bullseye?

systemd.link(5), systemd.net-naming-scheme(7).
The keyword you need is NamePolicy=mac.

> BTW, the device shows up as disabled in lshw (I obfuscated the MAC in the
> output):
>
> *-network DISABLED

That could mean anything. Please show the output of "ip a".

Reco

[Greg Wooledge]

On Wed, Feb 16, 2022 at 05:30:17PM +0300, Reco wrote:
> Hi.
>
> On Wed, Feb 16, 2022 at 03:55:21AM -0600, Flacusbigotis wrote:
> > Back in Debian Buster, I learned that the "predictive" naming of this USB
> > ethernet interface would be governed by "73-usb-net-by-mac.rules" and so I
> > had it configured accordingly with a config file in
> > /etc/network/interfaces.d/... Namely that the device name would basically
> > be its MAC.
>
> It's still true in Bullseye, but the implementation has changed
> somewhat.
> Instead of /lib/udev/rules.d/73-usb-net-by-mac.rules now systemd uses
> /lib/systemd/network/73-usb-net-by-mac.link.
>
>
> > Well, I just upgraded to Bullseye, and I can't bring up the darn
> > interface. I have tried fiddling around with the device name in my config
> > file in /etc/network/interfaces.d/ directory, but it just won't come up.
> > The Networking.service also fails during bootup.
>
> A straightforward approach would be to learn the actual name of the
> device via "ip a"/"ifconfig -a", and then using that name in /e/n/i.

I don't use a USB ethernet device. I use the one that's inside my
computer. Here's how I configure it. First, I figured out what its MAC
address is. Then, I decided what *name* I wanted it to have. I chose
"lan0".

I created this file to assign that name to that interface, based on its
MAC address:

unicorn:~$ cat /etc/systemd/network/10-lan0.link
[Match]
MACAddress=18:60:24:77:5c:ec

[Link]
Name=lan0


Next, I told interfaces(5) to configure it with DHCP:

unicorn:~$ cat /etc/network/interfaces
[...]
auto lan0
iface lan0 inet dhcp
[...]


Finally, I configured my router (which is also my DHCP server) to assign
the IP address I want, based on the MAC address. In my case, it makes
the most sense to do this at the DHCP server, because I *also* configure
some IP port forwardings from the Internet to my computer in that same
router. Keeping the IP assignment and the port forwardings all together
in the same device makes sense.

If you don't need to worry about port forwarding or other special Internet
configurations, then you might choose to assign the IP address statically
in interfaces(5) instead of using DHCP. Both ways have their merits.

[Flacusbigotis]

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.  When the device boots up, it comes up with its own real MAC, but it is failing to get an IP.  So, then if I do an ifdown and then a subsequent ifup on it, the MAC then changes to a random number.   I also see that the addr_assign_type attribute of the interface changed from 0 (at boot) to 1 (after the ifdown/ifup cycle).  It then remains as 1 until I reboot...

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"

Also, here is the output showing all that after a fresh boot:

user1@server1:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff
    altname enp40s0
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.11/24 brd 10.8.0.255 scope global enp1s0
       valid_lft forever preferred_lft forever
4: enx001234567890: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:12:34:56:78:90 brd ff:ff:ff:ff:ff:ff
    inet 8.8.10.10/24 brd 255.255.255.255 scope global dynamic enx001234567890
       valid_lft 279980sec preferred_lft 279980sec

root@server1:~# cat /sys/class/net/enx001234567890/addr_assign_type
0

root@server1:~# ifdown enx001234567890
Killed old client process
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enx001234567890/00:12:34:56:78:90
Sending on   LPF/enx001234567890/00:12:34:56:78:90
Sending on   Socket/fallback
DHCPRELEASE of 8.8.10.10 on enx001234567890 to 192.168.64.33 port 67

root@server1:~# cat /sys/class/net/enx001234567890/addr_assign_type
0

root@server1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff
    altname enp40s0
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.11/24 brd 10.8.0.255 scope global enp1s0
       valid_lft forever preferred_lft forever
4: enx001234567890: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:12:34:56:78:90 brd ff:ff:ff:ff:ff:ff

root@server1:~# ifup enx001234567890
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

RTNETLINK answers: Invalid argument
Listening on LPF/enx001234567890/96:6e:37:f1:d0:34
Sending on   LPF/enx001234567890/96:6e:37:f1:d0:34
Sending on   Socket/fallback
DHCPDISCOVER on enx001234567890 to 255.255.255.255 port 67 interval 8
send_packet: Network is down
dhclient.c:2446: Failed to send 300 byte long packet over enx001234567890 interface.
receive_packet failed on enx001234567890: Network is down
DHCPDISCOVER on enx001234567890 to 255.255.255.255 port 67 interval 17
send_packet: Network is down
dhclient.c:2446: Failed to send 300 byte long packet over enx001234567890 interface.
DHCPDISCOVER on enx001234567890 to 255.255.255.255 port 67 interval 14
send_packet: Network is down
dhclient.c:2446: Failed to send 300 byte long packet over enx001234567890 interface.
DHCPDISCOVER on enx001234567890 to 255.255.255.255 port 67 interval 10
send_packet: Network is down
dhclient.c:2446: Failed to send 300 byte long packet over enx001234567890 interface.
DHCPDISCOVER on enx001234567890 to 255.255.255.255 port 67 interval 12
send_packet: Network is down
dhclient.c:2446: Failed to send 300 byte long packet over enx001234567890 interface.
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

root@server1:~# cat /sys/class/net/enx001234567890/addr_assign_type
1

root@server1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff
    altname enp40s0
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.11/24 brd 10.8.0.255 scope global enp1s0
       valid_lft forever preferred_lft forever
4: enx001234567890: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 96:6e:37:f1:d0:34 brd ff:ff:ff:ff:ff:ff permaddr 00:12:34:56:78:90

[Reco]

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.
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 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.


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.

2) If they decide to rename "ax88179_178a" in the kernel - this link
file will cease to work for obvious reasons.

Reco

[Flacusbigotis]

On Thu, Feb 17, 2022 at 1:06 AM Reco <recov...@enotuniq.net> wrote:

        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.

[Reco]

Hi.

On Sun, Feb 20, 2022 at 05:30:10PM -0600, Flacusbigotis wrote:
> On Thu, Feb 17, 2022 at 1:06 AM Reco <recov...@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

[Nicholas Geovanis]

On Tue, Feb 22, 2022, 5:18 AM Reco <recov...@enotuniq.net> wrote:

On Sun, Feb 20, 2022 at 05:30:10PM -0600, Flacusbigotis wrote:

.....

> > 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.

And you checked to make certain that really really really no firmware upgrades took place in the meantime? Or downgrades? Not even from some dual-booted OS on the same box?

[Reco]

Hi.

On Tue, Feb 22, 2022 at 10:56:43AM -0600, Nicholas Geovanis wrote:
> > 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.
> >
>
> And you checked to make certain that really really really no firmware
> upgrades took place in the meantime?

Of course I'm sure. I'd remember rewriting card's EEPROM.
That NIC had only built-in impossible to upgrade firmware, just in case.

And in the grand scheme of things ever-changing MAC was a nuisance, not
a problem. Changing the MAC on boot was a klugde, but it worked.

> Or downgrades?

See above.

> Not even from some dual-booted OS on the same box?

I don't do dual-boot for last 20 years at least. Dual-boot may be useful
to someone, but I have no need of it.


Besides, I don't own that hardware anymore. Unless I'm mistaken, it was
"retired" to a nearest garbage dump.

Reco

[Flacusbigotis]

> 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.

Good news:  I verified that this whole thing is indeed introduced in Debian 11 (Bullseye) and is not an issue on Debian 10 (Buster).

Bad news: this mean I can't use the card for now! :-)

I verified the above claim (bug in Bullseye) by booting into BUSTER using a Debian 10 live USB, and I also tested the same with a Debian 11 (Bullseye) live USB and obviously also with my hard drive install of bullseye.

The BUSTER USB booted fine and the interface came up without any issues 100% of the time, several times.  I even went back and forth randomly between the different distros, sometimes fully powering off the machine, others simply just rebooting...

In contrast, the BULLSEYE USB and the "BULLSEYE hard drive installed OS" each failed 100% of the time and exhibited the same exact problem, every single time I tested them.

Another bit of good news (well, progress) is that I also now noticed these logs in /var/log/messages:

Feb 22 17:22:53 server1 kernel: [    1.380198] xhci_hcd 0000:1c:00.0: xHCI Host Controller
Feb 22 17:22:53 server1 kernel: [    1.380205] xhci_hcd 0000:1c:00.0: new USB bus registered, assigned bus number 5
Feb 22 17:22:53 server1 kernel: [    1.380209] xhci_hcd 0000:1c:00.0: Host supports USB 3.0 SuperSpeed
Feb 22 17:22:53 server1 kernel: [    1.380260] usb usb5: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.10
Feb 22 17:22:53 server1 kernel: [    1.380261] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Feb 22 17:22:53 server1 kernel: [    1.380263] usb usb5: Product: xHCI Host Controller
Feb 22 17:22:53 server1 kernel: [    1.380264] usb usb5: Manufacturer: Linux 5.10.0-11-amd64 xhci-hcd
Feb 22 17:22:53 server1 kernel: [    1.380265] usb usb5: SerialNumber: 0000:1c:00.0
Feb 22 17:22:53 server1 kernel: [    1.380396] hub 5-0:1.0: USB hub found
Feb 22 17:22:53 server1 kernel: [    1.380411] hub 5-0:1.0: 4 ports detected
Feb 22 17:22:53 server1 kernel: [    5.508457] ax88179_178a 5-1:1.0 eth0: register 'ax88179_178a' at usb-0000:1c:00.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:11:22:33:44:55
Feb 22 17:23:25 server1 kernel: [   39.576966] xhci_hcd 0000:1c:00.0: WARNING: Host System Error
Feb 22 17:26:00 server1 kernel: [  194.596335] ax88179_178a 5-1:1.0 enx001122334455: Failed to read reg index 0x0002: -22
Feb 22 17:26:00 server1 kernel: [  194.596338] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0002: -22
Feb 22 17:26:11 server1 kernel: [  205.378965] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0002: -22
Feb 22 17:26:11 server1 kernel: [  205.378969] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0002: -22
Feb 22 17:26:11 server1 kernel: [  205.585506] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693515] ax88179_178a 5-1:1.0 enx001122334455: Failed to read reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693524] ax88179_178a 5-1:1.0 enx001122334455: Failed to read reg index 0x0006: -22
Feb 22 17:26:11 server1 kernel: [  205.693527] ax88179_178a 5-1:1.0 enx001122334455: invalid MAC address, using random
Feb 22 17:26:11 server1 kernel: [  205.693532] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0006: -22
Feb 22 17:26:11 server1 kernel: [  205.693535] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0005: -22
Feb 22 17:26:11 server1 kernel: [  205.693538] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693541] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693544] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693547] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693550] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0002: -22
Feb 22 17:26:11 server1 kernel: [  205.693553] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693555] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0002: -22
Feb 22 17:26:11 server1 kernel: [  205.693561] ax88179_178a 5-1:1.0 enx001122334455: Failed to read reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693564] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693567] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x001f: -22
Feb 22 17:26:11 server1 kernel: [  205.693570] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x0019: -22
Feb 22 17:26:11 server1 kernel: [  205.693573] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x001f: -22
Feb 22 17:26:11 server1 kernel: [  205.693576] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x000d: -22
Feb 22 17:26:11 server1 kernel: [  205.693579] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x000e: -22
Feb 22 17:26:11 server1 kernel: [  205.693581] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x000d: -22
Feb 22 17:26:11 server1 kernel: [  205.693586] ax88179_178a 5-1:1.0 enx001122334455: Failed to read reg index 0x000e: -22
Feb 22 17:26:11 server1 kernel: [  205.693590] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x000d: -22
Feb 22 17:26:11 server1 kernel: [  205.693593] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x000e: -22
Feb 22 17:26:11 server1 kernel: [  205.693595] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x000d: -22
Feb 22 17:26:11 server1 kernel: [  205.693598] ax88179_178a 5-1:1.0 enx001122334455: Failed to write reg index 0x000e: -22
Feb 22 17:26:11 server1 kernel: [  205.693604] ax88179_178a 5-1:1.0 enx001122334455: Failed to read reg index 0x0000: -22

And as you can see in those logs there is an issue with xhci_hcd on this card and later the USB ethernet driver complains too and says it's going to randomize the MAC!   None of these appear in the logs for the Buster OS Live USB.   So, at least now I know why the MAC changes randomly in Bullseye and I also now know that this is a bug that was introduced by Debian Bullseye.

Next up:  I am going to see if I can install an old kernel onto a bullseye install and see if that makes it go away.

[Tixy]

On Tue, 2022-02-22 at 22:32 -0600, Flacusbigotis wrote:
[...]

>
> Feb 22 17:26:11 server1 kernel: [ 205.693604] ax88179_178a 5-1:1.0
> enx001122334455: Failed to read reg index 0x0000: -22
>
> And as you can see in those logs there is an issue with xhci_hcd on
> this
> card and later the USB ethernet driver complains too and says it's
> going to
> randomize the MAC! None of these appear in the logs for the Buster
> OS
> Live USB. So, at least now I know why the MAC changes randomly in
> Bullseye and I also now know that this is a bug that was introduced
> by
> Debian Bullseye.

The change to randomise MAC [1] was introduced in the kernel at the end
of 2019. Note, that the old code didn't check for an error reading the
MAC address from the device and would use a garbage MAC address from
the data that happened to be in memory at the time. The new code (after
a fix [2]) does detect error indirectly.

So, it could be your device never always produced an error reading a
MAC address from it, and that went unnoticed until the recent kernel
changes. Or, it could be buggy kernel drivers can't access the device
properly any more.

Interesting, there's another change [3] to the driver that seems
related to writing a MAC address back to the device, but it also seems
to indicate you may need to use the 'ethtool' program, whatever that
is.

Sorry, I know nothing about all this, I just got curious about your
problem and looked at the source code.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/usb/ax88179_178a.c?h=v5.10.101&id=9fb137aef34e4eedaa23307d309b0ebe8358fea1
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/usb/ax88179_178a.c?h=v5.10.101&id=2e68890993d0940cedc1f0369282256854293a93
[3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/usb/ax88179_178a.c?h=v5.10.101&id=78734404ef9c133eac70339415c8028dbe19109a

--
Tixy

[Flacusbigotis]

On Wed, Feb 23, 2022 at 3:15 AM Tixy <ti...@yxit.co.uk> wrote:

Sorry, I know nothing about all this, I just got curious about your
problem and looked at the source code.

Wow.  That's quite impressive Tixy.  I would not even know where to begin looking!  Thank you for all that leg work.  I will be looking at those references you provided.

I have also sent an email to the debian kernel list with only the latest information I had before your email.  They suggested I open a bug report, so I will be doing that.  I will let you know here what I find.