ASIX ax88179_178a USB-to-LAN adapter unusable after Core Update 170

Hi!

Upgraded today from 169 to 170 and did a restart. Afterwards my connection to my dmz (from any network) drops after a few minutes and won´t come back.

Nothing changed in my setup. After restarting ipfire all is fine for the next minutes and it drops again.

Any hints for debuging this?

Reproduceable: connection lost, ipfire restart and all is fine again.

I would look at the logs of your orange zone machines as well as IPFire logs, e.g.:

grep orange0 /var/log/messages
1 Like

Nothing special to see in the logs. Right now it’s working as intended. Will report back if it fails again. Strange since I didn’t change anything :slight_smile:

Hi,

well, this sounds like a driver issue with the NIC in question, but that is only a suspicion of mine. :slight_smile:

If this issue persists, please…

  • post your Fireinfo profile here (so we can see which NICs are used in combination with which drivers)
  • tell us if you use the IPS, and if so, which rulesets are enabled
  • what’s logged in /var/log/messages around the time the issue appears (not only related to orange0)

Thanks, and best regards,
Peter Müller

“deviceclass”: “255/255/0”,
“driver”: “ax88179_178a”,
“model”: “1790”,
“subsystem”: “usb”,
“vendor”: “0b95”

Thought about a kernel/driver issue too.

messages:

Sep 16 18:20:00 ipfire kernel: ax88179_178a 3-1:1.0 orange0: ax88179 - Link status is: 1
Sep 16 18:20:02 ipfire ntpd[11575]: Listen normally on 9 orange0 192.168.3.1:123
Sep 16 18:32:39 ipfire kernel: ax88179_178a 3-1:1.0 orange0: ax88179 - Link status is: 0
Sep 16 18:32:41 ipfire ntpd[11575]: Deleting interface #9 orange0, 192.168.3.1#123, interface stats: received=0, sent=0, dropped=0, active_time=759 secs
Sep 16 18:32:43 ipfire kernel: ax88179_178a 3-1:1.0 orange0: ax88179 - Link status is: 1
Sep 16 18:32:43 ipfire kernel: ax88179_178a 3-1:1.0 orange0: ax88179 - Link status is: 0
Sep 16 18:32:47 ipfire kernel: ax88179_178a 3-1:1.0 orange0: ax88179 - Link status is: 1
Sep 16 18:32:47 ipfire kernel: ax88179_178a 3-1:1.0 orange0: ax88179 - Link status is: 0
Sep 16 18:32:51 ipfire kernel: ax88179_178a 3-1:1.0 orange0: ax88179 - Link status is: 1
Sep 16 18:32:52 ipfire ntpd[11575]: Listen normally on 10 orange0 192.168.3.1:123

1 Like

Hi,

this is it:

For some reason, the kernel thinks the link of that NIC starts flapping. Unless we are dealing with a hardware failure (out of pure coincidence happening after upgrading to Core Update 170 :upside_down_face: ), this indeed sounds very much like a driver issue.

Unfortunately, there were no reports regarding such issues while C170 was still in the testing phase. Therefore, I guess this at least does not affect a significant portion of NICs out there, but is disappointing nevertheless.

While I doubt we have sufficient space in upcoming C171 left to ship a new kernel, I’ll investigate whether this relates to an issue already reported upstream.

Thanks, and best regards,
Peter Müller

5 Likes

Hi,

well these commits in the changelog of Linux 5.15.61 look pretty much related:

  • 635fd8953e4309b54ca6a81bed1d4a87668694f4
  • 4499288694751ddb63e5529e91fe67d9fe298d64

Thanks, and best regards,
Peter Müller

The commit solved one problem but created another: It causes a
use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c,
ax88179_178a.c, ch9200.c and smsc75xx.c:

* If the drivers receive a link change interrupt immediately before
  disconnect, they raise EVENT_LINK_RESET in their (non-sleepable)
  ->status() callback and schedule usbnet_deferred_kevent().
* usbnet_deferred_kevent() invokes the driver's ->link_reset() callback,
  which calls netif_carrier_{on,off}().
* That in turn schedules the work linkwatch_event().

You are right! Oh dear …

Hi,
I think I can confirm having the same issue after updating to 170.
I’ve got two AX88179 Gigabit Ethernet (ax88179_178a) USB3-ethernet adapters. One for red and one for orange.
Just after the update all worked well, but a couple of hours later I first lost the connection on orange then a few minutes later red was also down. After a restart they worked - for about an hour. Restarted IPFire. Then it worked for a while and so on - until I pulled the IPFire 170 SDD out and reinstalled IPFire 169 from backup on another SSD.
Regards
Willy Sejr

1 Like

all requests to ‘red’ seems to be dropped since Update 170

Sep 17 02:36:47 ipfire kernel: DMAR: [DMA Write NO_PASID] Request device [00:02.0] fault addr 0x9f323000 [fault reason 0x05] PTE Write access is not set
Sep 17 02:36:47 ipfire kernel: DMAR: DRHD: handling fault status reg 3

i’m sure theres no hardware failure.
Had Core 169 before - and everything worked.

/Edit: where can I get update 169, so that external connections work again?

Hi.

I have the same issue with this hardware
{
“deviceclass”: “255/255/0”,
“driver”: “ax88179_178a”,
“model”: “4a00”,
“subsystem”: “usb”,
“vendor”: “2001”
},
I rollback to C169 and everything is fine.
Thank you
Tg92

Hello,
I dowloaded Core 169 from here:

Cheers
Willy Sejr

I have reinstalled with my backup of 169, I have just one remark, networks were not setup to the right network cards. I have to login as admin in the console, run /usr/sbin/setup and redo the network configuration by doing what is describe here . wiki.ipfire.org - Step 5: Network Setup

I noticed the same when I restored from my 169 backup
I pretty much sure I used the right iso containing settings, because I was prompted if I wanted to install these during the process.
But upon reading the wiki guide on backup, I’m wondering if the network adapter setup is included :thinking:

Reinstall for my apu is a hassle. Is there a comfortable way to downgrade the kernel itself?

Would buy another eth usb dongle if someone can recommend one that just works :slight_smile:

Bought an Hama adapter (RTL 8153 chip), hopefully there are no more surprises :slight_smile:

1 Like

I also got similar problems after 170 with dongels, I have fireinfo.ipfire.org - Profile 72a721ca22ee04f59b30ada2f17f4a85fb1ebd07

Hi all,

thank you very much for the discussion here! :slight_smile:

Apparently, that affected ASIX chipset is used quite a lot (but not in the USB-LAN-adaptors I use, otherwise, I would have noticed during testing :expressionless: ), and upcoming Core Update 171 is currently at 39 MBytes, I will definitely try to add the latest 5.15.x kernel, to have this resolved sooner rather than later.

Thanks, and best regards,
Peter Müller

7 Likes

If Ichange my usb network card ASIX to an usb network card RTL8153, it will work (see previous message). I just have to relaunch /usr/sbin/setup to map network to network card? Drivers are already available or I have to make a clean setup of ipfire and then apply a backup configuration?

Thank for your help

+1 for this issue.

RED : “usb: ASIX Electronics Corp. AX88179 Gigabit Ethernet”

I am lucky to get 10 mins before DNS just dies and I have to restart networking to get it working again, reverting to 169.

Edit: Workaround by stealing a USB dongle from a Mac with a Realtek chipset in it, so didn’t roll back in the end.

As I had very limited time, I did a Quick and Dirty downgrade as described in this post: