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?
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.
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.
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
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
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?
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?
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
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
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.
Hello,
That sounds reasonable
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.
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.
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
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)