I have various small NUCs with attached on each one some of this USB3 LAN adapters (because the NUCs have only one Ethernet, so I added extra ones with USB3 adapters).

You can see an image of the product here.

All of a sudden, probably due to an unattended automatic upgrade, these devices started getting random MAC addresses.


Each USB3 attached device had an address in the form:


Each one was distinct and always the same (stable), surviving reboots.

Now they have address like:

eth1 - be:7d:ee:6a:26:ab  
eth2 - be:7d:ee:6a:26:ab  
eth3 - be:7d:ee:6a:26:ab  
eth4 - be:7d:ee:6a:26:ab  
eth5 - be:7d:ee:6a:26:ab  

all sharing the same randomly picked address.

In short, troubles:

  • Each time the machine reboots, this random MAC address changes.
  • They all share the same random MAC address.  Previously each one had a different and clearly distinct one.

The devices are identified in lsusb as:

   ASIX Electronics Corp. AX88179 Gigabit Ethernet

I have no idea what happened since latest automatic update, it's matter of the latest 2 days, 1h ago everything was working OK, after all these devices started to have this weird behaviour.

Could it be a problematic update?  Could it be a new driver been released that randomizes the MAC address each time?  Could it be a feature from the Linux kernel or the distro or GRUB setting where USB LAN devices now get random MAC address each time?  But in this case, why all of them share the same?  They should be totally random....

I am seeking help and willing to do tests...

Regarding the OS:

Debian Version: 12.5

Linux 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux

Workarounds suggested so far, including the final one always working thanks to @A.B:

1 Answer 1


This 6.8 kernel commit, backported to 6.1.x:

net: usb: ax88179_178a: avoid two consecutive device resets

intended to avoid a double reset on the AX88179-based NIC had as side effect to get a random MAC address for the NIC.

There's a fix in the works for future 6.9 kernel, already backported to kernel 6.1.85+ which acknowledges the previous issue (and is supposed to fix it). Here's the acknowledge part:

net: usb: ax88179_178a: avoid the interface always configured as random address

After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets"), reset is not executed from bind operation and mac address is not read from the device registers or the devicetree at that moment. Since the check to configure if the assigned mac address is random or not for the interface, happens after the bind operation from usbnet_probe, the interface keeps configured as random address, although the address is correctly read and set during open operation (the only reset now).

The problem is that Debian's kernel 6.1.0-20-amd64 already uses upstream kernel 6.1.85 which includes the fix. From OP's comment this doesn't appear to work correctly, since OP is using kernel 6.1.0-20-amd64.

What is guaranteed to work is to revert to the previous state: before the patch backported to 6.1.x on 2024-02-05. It appears that currently that means reverting TWO patches:

to be guaranteed to get it working as before (and getting the double-reset behavior back which didn't appear to be a problem then).

I could verify in the past weeks that reverting net: usb: ax88179_178a: avoid two consecutive device resets made it work, I didn't verify how the newer state (eg: kernel 6.1.85 or Debian 6.1.0-20-amd64) behaves. OP's Q/A suggests that maybe the 2nd patch intended to fix the behavior caused after the 1st patch is not enough and possibly yet-an-other-fix has to be provided.

To summarize, possible options today:

  • Ok let me check if I understood correctly, they did something from the kernel 6.1.0-20 (debian 6.1.85-1) that made ax88179 not reading correctly the mac stored inside the eeprom right? So the patch you are suggesting should be able to fix the devices reading of the eeprom, but how this patch should be applied? I'm not very used to this. For now I tried using kernel 6.1.0-18 and works but I don't think this is a definitive solution. The patch you are providing would work even if new kernel will be released after 6.1.0-20 ? thanks! Commented Apr 15 at 18:29
  • I used the method suggested in this post: askubuntu.com/questions/82140/… and booted in 6.1.0-18 showing correct mac addresses. What I'm asking is can I use the 6.1.0-20 or following ones with the patch in place ? If tomorrow the 6.1.0-22 will be released will I lose the function again until we reach the 6.8 version of the kernel where the thing is fixed ? thanks I'm not very competent regarding kernel diffs, commits and patches hence why I'm asking in a more simple way. Commented Apr 15 at 18:37
  • I see... or wait until we reach the kernel 6.8 where the patch was officially applied. But because I'm using debian 12 probably this will never happen because they will stay on 6.1.0-xx all the time and in order to get 6.8 I will have to wait debian 14 probably or use "sid" right? So the options are: apply the patch myself on the kernel and recompile that one or use the old 6.1.0-18 kernel. Commented Apr 15 at 18:46
  • Actually I found that there's a fix in the pipeline for kernel 6.9 I'll edit my answer to include it.
    – A.B
    Commented Apr 15 at 18:56
  • @user3450548 I found that the patch supposed to fix your case was already applied inside Debian's kernel 6.1.0-20-amd64 but that it didn't fix your case. Changed my answer accordingly to present possible options.
    – A.B
    Commented Apr 15 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .