Need help! Openwrt + USB LAN Asix AX88179 (Ugreen 50922) crashes continuously, has to reboot constantly

Hello everybody. Currently I'm running Openwrt on Raspberry and have tried a lot of different Openwrt builds. Constant problem with USB lan Asix 88179. I need your advice. thank you very much...

Hardware

  • Raspberry Pi 4B- MicroSD Kingston 32GB Class 10
  • Power 3A for Raspberry and Power 3A for Hub USB 3.0
  • 2 Ugreen 50922 USB 3.0 Gigalan Asix AX88179 10/100/1000

Software

  • OpenWrt SNAPSHOT r18269-c47e82d255 Linux 5.10.82
  • Mwan3
  • kmod-usb-net-asix-ax88179

- I have tested from Linux version 5.4 to 5.10 all get the USB WAN error Asix AX88179. (Tested on 2 USB Lan Realtek r8152 runs relatively well, no problem)
- When used for a period of 2.3 hours, the 2 usb Asix AX88179 automatically failed to connect to the wan and had problems. If I restart Openwrt, the connection is normal. (If tested with App Speedtest or website Speedtest, tested about 2.3 times, these 2 USBs suddenly died for no reason)
Does anyone know how to fix this on Openwrt? I suspect due to Asix AX88179 USB. Thank you!
(Power supply is excluded because I have tested various 3A power sources)

[  186.063289] ------------[ cut here ]------------
[  186.070262] NETDEV WATCHDOG: eth2 (ax88179_178a): transmit queue 0 timed out
[  186.079744] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:467 dev_watchdo                                                                                                 g+0x2b0/0x2c0
[  186.090477] Modules linked in: pppoe ppp_async iptable_nat brcmfmac xt_state                                                                                                  xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_gen                                                                                                 eric nf_nat nf_flow_table nf_conntrack ipt_REJECT cfg80211 ax88179_178a xt_time                                                                                                  xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG usbne                                                                                                 t usbhid slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_m                                                                                                 angle iptable_filter ip_tables hid_generic crc_ccitt compat brcmutil snd_bcm2835                                                                                                 (C) hid evdev nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tabl                                                                                                 es ip6t_REJECT x_tables nf_reject_ipv6 snd_rawmidi snd_seq_device snd_pcm_oss sn                                                                                                 d_pcm_dmaengine snd_mixer_oss snd_hwdep snd_compress snd_pcm snd_timer snd sound                                                                                                 core nls_utf8 vfat fat nls_iso8859_1 nls_cp437
[  186.172815] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G         C        5.10.82                                                                                                  #0
[  186.182825] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
[  186.191200] pstate: 40400005 (nZcv daif +PAN -UAO -TCO BTYPE=--)
[  186.199756] pc : dev_watchdog+0x2b0/0x2c0
[  186.206241] lr : dev_watchdog+0x2b0/0x2c0
[  186.212676] sp : ffffffc010b8bd70
[  186.218341] x29: ffffffc010b8bd70 x28: ffffffc010b2a000
[  186.225950] x27: 0000000000000140 x26: 00000000ffffffff
[  186.233505] x25: 0000000000000000 x24: 0000000000000000
[  186.240976] x23: ffffff8041d90480 x22: 0000000000000001
[  186.248433] x21: ffffffc010a16000 x20: ffffff8041d90000
[  186.255834] x19: 0000000000000000 x18: 000000000000013e
[  186.263209] x17: ffffffc0126d0598 x16: ffffffc0126d059c
[  186.270543] x15: ffffffc010a278d0 x14: 00000000000003ba
[  186.277835] x13: 000000000000013e x12: ffffffc010b8ba48
[  186.285092] x11: ffffffc010a7f8d0 x10: 00000000fffff000
[  186.292300] x9 : ffffffc010a7f8d0 x8 : 0000000000000000
[  186.299456] x7 : ffffffc010a278d0 x6 : 0000000000000001
[  186.306538] x5 : 0000000000000000 x4 : 0000000000000000
[  186.313585] x3 : 0000000000000000 x2 : ffffff807fb95028
[  186.320584] x1 : ffffffc06f18e000 x0 : 0000000000000040
[  186.327539] Call trace:
[  186.331566]  dev_watchdog+0x2b0/0x2c0
[  186.336774]  call_timer_fn.constprop.0+0x24/0x80
[  186.342900]  __run_timers.part.0+0x240/0x280
[  186.348659]  run_timer_softirq+0x3c/0x74
[  186.354030]  _stext+0x124/0x290
[  186.358592]  irq_exit+0xa0/0xf0
[  186.363077]  __handle_domain_irq+0x80/0xe0
[  186.368451]  gic_handle_irq+0x78/0xa0
[  186.373304]  el1_irq+0xcc/0x180
[  186.377563]  arch_cpu_idle+0x18/0x30
[  186.382186]  default_idle_call+0x20/0x70
[  186.387078]  do_idle+0x21c/0x280
[  186.391247]  cpu_startup_entry+0x28/0x60
[  186.396092]  rest_init+0xbc/0xcc
[  186.400221]  arch_call_rest_init+0x10/0x1c
[  186.405198]  start_kernel+0x438/0x454
[  186.409766] ---[ end trace b9f206aa7400cbc2 ]---
1 Like

crashlog+conditions suggest nic hardware / load induced lockup... even more probable considering 5.4 and 5.10 manifest similar behavior...

i'd not exclude some arch + driver specific complications given the maturity of said chipsets, nor power circuitry as a factor

a little more info on how much data exactly you were pumping through each nic is just as relavent as time frames to crash... ( as is temperature I suppose... but not everyone has a thermal camera :wink: )

i think the first point of call would be to also reproduce with only a single usb nic inserted / used ...
(or save the trouble and use alternate nic/s?)

1 Like

what id you skip the hub, and connect the NICs directly to the RPi ?

1 Like

The temperature or power is definitely not because I use 3A and the fan is cool. machine temperature is very cool. My per wan speed is 250mb/wan and I use mwan3 to make 2 wan bandwidth into 1 Lan. Lan is equivalent to 400 ~ 450mb (After a few tests using the app or Speedtest website, 2 usb asix ax88178 is enabled and it is disabled. It seems that Asix ax88179 really has a problem. restart Raspberry .

I tested not using a usb 3.0 hub. Or just use 1 Usb Asix ax88179 but the problem is still the same. Check with the Speedtest application 3.4 times that the usb has a problem. Or leave it for 1.2 hours, the problem still occurs...

1 Like

yeah... if there is an issue... I was sort of implying it's lower down in the power delivery layers... in the regulator ic's or components themselves...

rpi4 is known to interact in a non predictable way with hubs and power bleed also...

given the above... i'd go with another chipset / nic...

Can you give me advice on this? I really want to run 2 wan on raspberry.

ue300 / rtl8153? is popular and has generally proved reliable for many users here...

at those speeds... vlans via a smart switch are also a reliable option... ( and bypass the hassle of having to handle boot usb -> nic interface reassignments )

I also consulted a lot of articles about Ax88179. and last response is This device should not be used for Raspberry + Openwrt to avoid problems. Thank you so much my friend!

2 Likes

Out of curiosity why are/were you using the hub? Given the RPi4 has two USB 3.0 ports and as far as I am aware ethernet adapters aren't that power hungry.

1 Like

not sure about the OP, but I'd lean towards using a hub here...

mostly for the space/wear and tear factor... but the onboard power regulator is the achilles heel of the pi4... so if in doubt use a (powered) hub... but some hubs cause more issues than they solve...

a single usb->ethernet + a single usb3 thumb drive would probably be ok... and as you say 2 nics would probably be ok too...

but when hardware starts acting funny... it's definately one of the first things to try on these boards...

  • I replaced the Hub using a better one for the Asix ax88179a. But the problem is still the same. (The problem of lack of power can be ignored)

  • And I also tried 1 usb ax88179 to the Raspberry board, the problem is still the same, combining a lot of linux 5.4 > 5.10

  • Asix ax88179 tried on both PfSense and same error. It seems that Asix ax88179 is really problematic on Linux systems.

All 3 tests give the same result: Asix automatically dies after some time, you have to restart Openwrt, pfsense... Test App Speedtest or website 3,4 times Asix88179 will die on its own.

I firmly believe that the problem is related to the Driver that all Asix ax88179 currently on the market drive when running on Lunux. And I'm still waiting for a fix from someone in the community.

1 Like

I want to use 2 Wan Asix ax88179 in combination with Mwan3 for load balancing.

I had the same issue with the ax88179 adapter. Seemed to be triggered not by high throughput, but by a high packet per second rate. I disabled QoS (qdisc set to none) on the ax88179 adapter interface and that appears to have resolved the issue.

The same issue.

lsusb
Bus 003 Device 003: ID 0b95:1790 ASIX Elec. Corp. AX88179

dmesg | grep asix
[  608.073560] usbcore: registered new interface driver asix


dmesg | grep ax88
[   11.232362] ax88179_178a 3-1.1:1.0 eth1: register 'ax88179_178a' at usb-d0058000.usb-1.1, ASIX AX88179 USB 3.0 Gigabit Ethernet, XX:XX:XX:XX.....
[   11.246326] usbcore: registered new interface driver ax88179_178a


root@Espresso1:~#  dmesg | grep usb
[    0.223957] usbcore: registered new interface driver usbfs
[    0.229601] usbcore: registered new interface driver hub
[    0.235139] usbcore: registered new device driver usb
[    0.676942] orion-ehci d005e000.usb: EHCI Host Controller
[    0.682470] orion-ehci d005e000.usb: new USB bus registered, assigned bus number 1
[    0.690340] orion-ehci d005e000.usb: irq 21, io mem 0xd005e000
[    0.721702] orion-ehci d005e000.usb: USB 2.0 started, EHCI 1.00
[    0.737146] usbcore: registered new interface driver usb-storage
[    2.761808] xhci-hcd d0058000.usb: xHCI Host Controller
[    2.767237] xhci-hcd d0058000.usb: new USB bus registered, assigned bus number 2
[    2.775010] xhci-hcd d0058000.usb: hcc params 0x0a000998 hci version 0x100 quirks 0x0000000000010090
[    2.784491] xhci-hcd d0058000.usb: irq 20, io mem 0xd0058000
[    2.799195] xhci-hcd d0058000.usb: xHCI Host Controller
[    2.804629] xhci-hcd d0058000.usb: new USB bus registered, assigned bus number 3
[    2.812280] xhci-hcd d0058000.usb: Host supports USB 3.0 SuperSpeed
[    2.818846] usb usb3: We don't know the algorithms for LPM for this host, disabling LPM.
[    3.081782] usb 2-1: new high-speed USB device number 2 using xhci-hcd
[    3.567030] usb 3-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[    4.573250] usb 3-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[   11.010796] usbcore: registered new interface driver asix
[   11.371047] ax88179_178a 3-1.1:1.0 eth1: register 'ax88179_178a' at usb-d0058000.usb-1.1, ASIX AX88179 USB 3.0 Gigabit Ethernet, XX:XX:XX:XX:.....
[   11.385028] usbcore: registered new interface driver ax88179_178a

@hiendd @diego Same issue with my 4 different AX88179

1 is by StarTech and I have 2 by D-Link and 1 by cheap company

After a boot, they come up with issues after a few minutes with all 4

I tried my AX88772C USB 2.0 to ethernet adapter and it works fine

I have a RealTek USB 3.0 adapter that I just tested and works fine also - RTL8153 but the RTL8152 driver in OpenWrt works fine with it.

This is with RPi3 , 22.03 rc6

This is ax88179 issue.

Hope this helps somebody

Thanks to this thread because I was going a bit crazy trying to figure out what was happening

2 Likes

Same issue here - purchased a Cable Creations RTL8153 from Amazon that worked beautifully. Went to buy another and they had changed chipset to the ASIX88179 without listing the change anywhere. It failed to work no matter what I tried and the adapter was returned. For $15 it's not worth the hassle, just go RTL8153.

2 Likes

How do you do this on OpenWrt? (disable QoS (qdisc set to none))
Has that permanently solved the issue?

It did not permanently disable the problem. It just made it a little better. I switched to an RTL8152 USB Ethernet adapter and have had zero issues with it, even with QoS enabled.