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

I have received a RTL 8153 usb network card. I have plugged it and I have try to setup the red network on this new card. The card was found immediately, so I think it will work fine. I have not done the modification because tomorrow I will work from home and I don’t want to take any risks.

Hi all,

for your information: I just pushed an update to Linux 5.15.68 to the upcoming Core Update 171 (commit), which should include the aforementioned upstream fixes for making ASIX ax88179_178a NICs work again.

For x86_64, the updated kernel should be available in the “unstable” repository within the next four hours. ARM builds may take slightly longer.

It would be very helpful if you could test Core Update 171 from the “unstable” repository, to confirm that the issue is actually fixed by the updated kernel.

Lastly, please note that this thread has nothing to do with e1000 NICs going flaky after Core Update 170. Only post here if you experience trouble with ASIX ax88179_178a NICs, to keep things focused. :slight_smile:

Thanks, and best regards,
Peter Müller

5 Likes

Same problem with my “Plugable” ASIX AX88179 adapters on BLUE and RED
I had to take out my old USB 2.0 MosChip that I used with Ipcop :smiley:

Hello,
I’ve put back my original SSD with the Core 170 installed and quickly changed to the “unstable” repository and installed the Core 171 update.
Rebooted with filesystem check.
I’ll try using that for now and see if it will keep connections on the Asix adapters
Cheers
Williy Sejr

My FireInfo

1 Like

It worked for while. But then alas no connection on red.
But now there are no “Link Status is: 0” entries in /var/log/messages, just these right after booting:

Sep 20 19:27:16 ipfire kernel: ax88179_178a 3-4:1.0 orange0: ax88179 - Link status is: 1
Sep 20 19:27:16 ipfire kernel: ax88179_178a 3-4:1.0 orange0: ax88179 - Link status is: 1
Sep 20 19:27:18 ipfire kernel: ax88179_178a 3-1:1.0 red0: ax88179 - Link status is: 1
Sep 20 19:27:18 ipfire kernel: ax88179_178a 3-1:1.0 red0: ax88179 - Link status is: 1

At the time I lost connection I got this in /var/log/messages:

Sep 20 20:12:56 ipfire unbound: [2704:0] error: SERVFAIL <a1nvlh0fc0asuq.iot.eu-central-1.amazonaws.com. A IN>: all the configured stub or forward servers failed, at zone . upstream server timeout
Sep 20 20:12:56 ipfire unbound: [2704:0] error: SERVFAIL <captive.apple.com. A IN>: all the configured stub or forward servers failed, at zone . upstream server timeout
Sep 20 20:12:56 ipfire unbound: [2704:0] error: SERVFAIL <ad.turn.com. A IN>: all the configured stub or forward servers failed, at zone . upstream server timeout
.
Sep 20 20:13:01 ipfire unbound: [2704:0] error: SERVFAIL <hc-7-us-ca-1.services.vnc.com. A IN>: all the configured stub or forward servers failed, at zone . no server to query nameserver addresses not usable have no nameserver names
Sep 20 20:13:04 ipfire unbound: [2704:0] error: SERVFAIL <connectivitycheck.gstatic.com. A IN>: all the configured stub or forward servers failed, at zone . no server to query nameserver addresses not usable have no nameserver names
Sep 20 20:13:05 ipfire unbound: [2704:0] error: SERVFAIL <diag.meethue.com. A IN>: all the configured stub or forward servers failed, at zone . no server to query nameserver addresses not usable have no nameserver names
.
Sep 20 20:13:11 ipfire kernel: NETDEV WATCHDOG: red0 (ax88179_178a): transmit queue 0 timed out

(Now back on the Core 169 installation)

Hi,

thank you for reporting back.

Well, these can be ignored, since Unbound encounters a couple of SERVFAILs if the configured DNS resolvers are unreachable.

Um, that’s exactly the same error/behaviour as before. To ensure that you have actually tested C171 with the new kernel, do you happen to have the output of uname -a after the upgrade and a reboot?

Thanks, and best regards,
Peter Müller

2 Likes

Hi,
Well, I gave it a second shot late last night and was just about to ask about the kernel version.
Because poking about looking at files I also checked the “update-core-upgrade-171.log”.
And the las5 lines read:

Generating grub configuration file …
Found background: /boot/grub/splash.png
Found linux image: /boot/vmlinuz-5.15.59-ipfire
Found initrd image: /boot/initramfs-5.15.59-ipfire.img
done

And that would be the same kernel version as in core 170.
So I did try uname -a and it also returned 5.15.59 as version.

The /opt/pakfire/db/core/mine file does read “171”

But I then also noticed that
the update log was must shorter that any of the previous update logs
I could not create an iso back up
some of the system logs where no longer rapportering data in the web interface, i.e. Kernel and RED

So the 170->171 update was probably not successful.

I suggest I’ll make a tarball of my Core 171 SDD for reference and then reformat the SSD and install it with a new iso-backup from my working Core 169 installation and the do a Core 169->171 update?

Best regards
Willy Sejr

Right now there is another problem. After red reconnected, my orange0 interface was gone. lsusb shows the device but ipfire can’t assign a fourth network to it.

You may have downloaded before the nightly build with the kernel update was uploaded to the server.

I just checked and the “Latest” nightly build under next has Linux 5.15.68
This was uploaded to the server around 19:30 yesterday evening (20th Sep)
The version previous to that still had the Linux 5.15.59 version

If you are looking at doing a re-install then you could do the Core Update 171 directly.
The iso can be obtained from the nightly.
https://nightly.ipfire.org/next/latest/x86_64/

You could retry doing the upgrade first
Change the /opt/pakfire/db/core/mine file from 171 to 170 then pakfire will be able to redo the core update.
If that doesn’t work then you could try the fresh install of the Latest Core Update 171

2 Likes

Hello,

i’ve applied the latest unstable update 171 and checked that kernel 5.15.68 had been installed. With this update my USB-to-LAN adapter is now running for more than 10 hours. Before this update the problem appeared every 1-2 hours.

Thanks for this rapid solution!

Best regards. Nico Prenzel

3 Likes

Hello,
That sounds reasonable :grinning:
I tried retrying the Core 171 update after changing the “mine” file to 170, but it did not play nicely.
So I give a fresh install of the “Core 171 unstable update” a go.
Regards
Willy Sejr

Now on a fresh install of “Core 171 unstable”
Online without interruptions for almost 4 hours now. :+1:
Cheers
Willy Sejr

UPDATE 2022-09-23:
Lost connection on my orange network some time late 2022-08-22.
I did not notice until early morning 2022-09-23. (The orange network is where my work laptop is connected)
I did not find any clear indications why. And since I needed to be able to work from home, I quickly had to switch back to my Core 169 installation.
I have a hunch it might be due to a small network configuration correction I did using “setup” via a terminal session at the end of day. Since it restarted “network” I thought it to be OK. But perhaps a reboot was required?’
I’ll try to revert to the Core 171 installation during the week-end.

UPDATE 2022-09-24:
Back in a fresh Core 171 install. :grinning:

6 Likes

thanks for all the tests you are doing. I can’t wait to know the result.

1 Like

I probably have had the same problem after Upgrade from 169 to 170. I am also using a USB3.0 to GBit LAN Adapter for the “RED”-Interface which is connected to Fritz!box 7590.
I tried first to use another LAN-Adapter, Changed my Cables but nothing helped. Also removed all Addons. No success. After a week of problems (DNS broken, Red-Interface disconnected, even link says “Yes”) i formatted the HDD and installed fresh with 2.27 169. Now my System works again reliable.
Here some observations:

In error case (ping from red to gateway doesnt work):

  • ethtool red0 shows
Settings for red0:
	Supported ports: [ TP	 MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Half 1000baseT/Full
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 100Mb/s
	Duplex: Full
	Auto-negotiation: on
	Port: MII
	PHYAD: 3
	Transceiver: internal
	Supports Wake-on: pg
	Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
	Link detected: yes

ifconfig shows:

blue0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.1.15  netmask 255.255.255.0  broadcast 0.0.0.0
        ether 80:ee:73:7c:68:48  txqueuelen 1000  (Ethernet)
        RX packets 1082931  bytes 248900064 (237.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2114805  bytes 2778745497 (2.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

green0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.15  netmask 255.255.255.0  broadcast 0.0.0.0
        ether 80:ee:73:7c:68:47  txqueuelen 1000  (Ethernet)
        RX packets 262933  bytes 287096007 (273.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 215764  bytes 32371072 (30.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

imq0: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        ether a2:a8:1b:18:78:b0  txqueuelen 32  (Ethernet)
        RX packets 1870410  bytes 2451654449 (2.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1870410  bytes 2451654449 (2.2 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 27138  bytes 1897703 (1.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 27138  bytes 1897703 (1.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

red0: flags=67<UP,BROADCAST,RUNNING>  mtu 1500
        inet 192.168.178.21  netmask 255.255.255.0  broadcast 192.168.178.255
        ether 00:0e:c6:bf:ef:d4  txqueuelen 1000  (Ethernet)
        RX packets 2039760  bytes 2517607059 (2.3 GiB)
        RX errors 0  dropped 87670  overruns 0  frame 0
        TX packets 994859  bytes 256701511 (244.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

unbound log shows many SERVFAIL errors.

doing a “/etc/init.d/network restart” solves the problem for some time but than its broken again.

Hello,

For the benefit of the IPFire team guys and gals, I believe it would be beneficial if you could supply your IPFireinfo:
IPFire Web Interface → System → System Information: “Your profile ID”
E.g. mine is (presently): fireinfo.ipfire.org - Profile cef8c686f616a51ee47c7250d00f0eae97b4680f

Cheers
Willy Sejr
(Now on Core 171 unstable update - Online for 9 hours and counting with ASIX AX88179 USB3 Gigabit Ethernet on RED and ORANGE)

1 Like

Hello Willy thanks for your response, nice to see that using “UB3 Gigabit” is a common use case. Here is my Profile ID: My Profile ID

I will wait until 171 is released and than update, else my family will kill me :wink:

Regards
Matthias Wilde

2 Likes

@matwilde , why do you use the USB LAN adapter?
Your profile shows enough onboard(?) NICs for your red/green/blue config.

Hi @bbitsch the third NIC is a WLAN card, which i do not use. I use LAN-Bridges to provide WLAN.

1 Like