AX88179 USB Ethernet Fail to Up on Kernel 6.5.13-5-pve, Possible Fix in RC Kernel

ericdiao

New Member
Dec 9, 2023
6
5
3
I found my setup with a UGREEN USB Ethernet Adopter with the AX88179 chipset fail to bring up the USB interface.

Debug logs shows `ifupdown2` failed to find the interface corressponding interface:

Code:
Apr 11 22:32:28 xxxx networking[1297]: error: ifname enx000ec67988f0 not present in cache
Apr 11 22:32:28 xxxx /usr/sbin/ifup[1297]: error: ifname enx000ec67988f0 not present in cache

Digging into changes between 6.5.13-5-pve and 6.5.13-3-pve I used to run, I find the following commit that was brought to the upstream Ubuntu kernel between two versions may be blamed (using mirrors on GitHub for UX reasons):

https://github.com/torvalds/linux/commit/d2689b6a86b9d23574bd4b654bf770b6034e2c7e

Further dig into the kernel tree shows the following commit that is in kernel v6.9-rc3 have a fix on this issue:

https://github.com/torvalds/linux/commit/2e91bb99b9d4f756e92e83c4453f894dda220f09

Based on the information I gathered, I came up with a possible cause of the bug but have not get a chance to verify (it is past 12:00 here in East Coast US on a weekday):

1. The changes in d2689b6a86b9d23574bd4b654bf770b6034e2c7e cause the driver being unable to read the MAC address of the adopter;
2. Proxmox is using systemd's Predictable Network Interface Names (https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/) to name interface;
3. ASIX88179 interfaces fallbacks to the rule number 4 of the systemd scheme of using the MAC address to name the interface;
4. Because of 1, 2 and 3, the interface is having a different name (using the rule number 5 probably) causing `ifupdown2` being unable to locate the interface with the name in the config file, resulting it failed to bring up the interface.

I will try to verify my theory tommorow after getting home. But I want to keep folks in the forum posted for the possible issue and is asking for possible workaround for this (I am pined on 6.5.13-3-pve now and I have another Realtek card ordered also). Also I would like to know if it is possible to get the fix patch backported to Proxmox kernel.
 
Last edited:
  • Like
Reactions: thelinhlge and coq
Hello ericdiao
Yesterday i've upgraded my PVE host and lost my wan connection based on usb network adapter.
I'm not a Linux master, so I googled and found this post, (the only in my search) and understood I'll wouldn't have been able to repair my system, so I decide to reinstall my PVE host using 8.1-2.iso and restoring all my CTs and VMs.
Not an unrecoverable situation, not the first time, but always a little bit of fear.

I think my usb network adapter it's like yours:


Code:
usb-devices

T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=ff(vend.) Sub=ff Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=0b95 ProdID=1790 Rev=01.00
S:  Manufacturer=ASIX Elec. Corp.
S:  Product=AX88179
S:  SerialNumber=00000000000015
C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=496mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=00 Driver=ax88179_178a
E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=128ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms

How can understand when there wil a fix and I could safely upgrade my PVE host again?
 
Hi folks, is there any current solution/workarounds to this issue ? I'm actually totally "blocked" here with these adapters not mounting. Thanks a lot.
EDIT: got temporarily back online using disliked here REALTEK RTL8153's
 
Last edited:
Hi folks, is there any current solution/workarounds to this issue ? I'm actually totally "blocked" here with these adapters not mounting. Thanks a lot.
EDIT: got temporarily back online using disliked here REALTEK RTL8153's
I really used two workarounds:

1. I pinned my kernel to the last usable one `6.5.13-3-pve` by running the following

Bash:
proxmox-boot-tool kernel pin 6.5.13-3-pve

2. I brought another USB Ethernet using other chipsets. I borught UE300 by TP-Link using Realtek RTL8153 which using using rtl8152 in the Linux kernel on Amazon for around US$10 and use it on my PVE instead (also unpinned my kernel).

You can also incoperate the patch (https://git.proxmox.com/?p=pve-kernel.git;a=commit;h=70198d2b84710d4ee6ee254c1c49d91895fc1ec7; https://github.com/proxmox/pve-kernel/commit/64823a3dcecbe8bd56da700b511dfc670d47c7a5) to your kernel by recompile the thing with the patch.
 
Hi Eric,

Yes, my "quick" workaround has been to add USB3's TP-LINK RTL8153's although I do not like these adapters much.
Would you know if any fix in forthcoming PVE Kernel's will be added concerning the AX88179 chipset's ? I can wait for the official fix, I'm back online currently.

Thanks so much,
Kind regards,
m.

EDIT: another question which is not related although that situation got me questioning on any potential possibility to USB pass-through these AX88179 adapters to any given VM's ?? here these adapters are "solely" used for L2 hardware switches control data plane. Not sure it's a good idea though...
 
Last edited:
Hi Eric,

Yes, my "quick" workaround has been to add USB3's TP-LINK RTL8153's although I do not like these adapters much.
Would you know if any fix in forthcoming PVE Kernel's will be added concerning the AX88179 chipset's ? I can wait for the official fix, I'm back online currently.

Thanks so much,
Kind regards,
m.

EDIT: another question which is not related although that situation got me questioning on any potential possibility to USB pass-through these AX88179 adapters to any given VM's ?? here these adapters are "solely" used for L2 hardware switches control data plane. Not sure it's a good idea though...
Yes. I think a fix should be shipped with the next kernel update (?) accordding to https://bugzilla.proxmox.com/show_bug.cgi?id=5373#c2.

I have not tried any USB passtrhough stuff though. It is technically possible from my perspective but I personally will stay away from any "advanced" feature with USB because of all sort of issues exactly like this one.

The reason I opt for USB ethernet here is that I have a real 100Mbps PCI-E ethernet in a active-backup bond with it which I thought will prevent issues like this but it turns out I am wrong - ifupdown2 refuse to start the bond if it thinks an interface is missing (i dont know if it is expected or a bug, will dig into one day). But this is another story.
 
My setup is also affected by this, and I'm pinning my kernel to work around the issue. Is there a way to find out when the patch is likely to flowdown to the mainstream releases?