Dietpi: RPi + Allo USBridge Sig | Ethernet driver ax88179_178a fails

[dsnyder0pc]

ADMIN EDIT

Workaround for 32-bit kernel users:

wget https://dietpi.com/downloads/misc/ax88179_178a.ko_new2 -O /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
depmod 5.4.51-v7+
modprobe ax88179_178a

---

Creating a bug report/issue

Required Information

• DietPi version | v6.31.2
• Distro version | buster
• Kernel version | Linux usbridge 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
• SBC model | RPi CM 3+ (armv7l)
• Power supply used | Allo Shanti
• SDcard used | SanDisk ultra

Additional Information (if applicable)

• Hardware is the Allo USBridge + RPi Compute Module 3+
• Was the software title installed freshly or updated/migrated? apt update; apt upgrade; reboot
• Can this issue be replicated on a fresh installation of DietPi? Yes

Steps to reproduce

1. ... Flash the microSD card with the latest DietPi (timestamp: Jun 14 05:02)
2. ... Attempt to boot.

Expected behaviour

• ... NIC should be recognized

Actual behaviour

• ... Observe that the internal NIC is not recognized (no LAN access)

Extra details

• ... I've been able to workaround this problem by connecting a USB NIC and downgrading the kernel to build 1.20200212-1
• ... Please restore /sys/module/ax88179_178a and /lib/modules/*/kernel/drivers/net/usb/ax88179_178a.ko to future releases

[Joulinar]

Hi,

Many thanks for your message. Just as information, DietPi is not and will not create any kernel version. The kernel is provided by the underlying Debian base image, always.

[dsnyder0pc]

@Joulinar - Looks like I'm going to have to find an O/S other than DietPi for audio use going forward. The kernel choices have been a disaster for this use case. I understand that you don't create the kernels, but the ones you've been choosing to include in DietPi releases have made DietPi nearly unusual for audio applications. This is so disappointing since DietPi was otherwise excellent. for this purpose. Cheers.

[Joulinar]

Still a misunderstanding. DietPi is not choosing for a kernel. It's provided by the Debian Base image. Depending on the SBC used, DietPi is using different Debian images like Armbian or Meveric. In case of Raspberry Pi, the kernel is provided by Raspberry OS. The version of the kernel is not influenced by DietPi.

[MichaIng]

ax88179_178a is regular part of the RPi kernel, is it really missing in your case?

We install a special version that is provided by Allo, contains some ARM enhancements and makes their USBridge Signature running better, coincidence? It is pulled from here: http://3.230.113.73:9011/Allocom/USBridgeSig/

When you upgrade the kernel to lastet version:

1. It contains the driver itself, although it seems to not support the Allo USBridge Sig that fine, which is why Allo provides the special build.
2. /etc/kernel/postinst.d/dietpi-USBridgeSig pulls their driver automatically on kernel package installs/upgrades. If this somehow fails, you should see related output during APT install. Please try to upgrade the kernel packages and watch out for the driver download/install. Here you see what the script is doing+output: https://github.com/MichaIng/DietPi/blob/master/PREP_SYSTEM_FOR_DIETPI.sh#L1627-L1639

It worked fine in my case btw:

-rw-r--r-- 1 root root 42K Jul 14 11:27 /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko

[comassky]

I also have this issue with Allo UsbBridge & latest DietPi OS (6.32).

First boot UsbBridge have lan connection, upgrade with 5.4 kernel, and no networks at the reboot.

[MichaIng]

Can you please as well check if the file exists and if the module version matches loaded kernel:

ls -al /lib/modules/*/kernel/drivers/net/usb/ax88179_178a.ko
uname -a
dpkg -l raspberrypi-kernel

[comassky]

@MichaIng

First boot 👍

During upgrade :

Reboot after update :

[MichaIng]

Okay so the modules have been installed successfully. The dietpi-config error means that ip a doesn't show any ethN interface, right?
Has the module been loaded?

lsmod | grep ax88179_178a

Or can it be loaded?

modprobe ax88179_178a

[comassky]

Yes ip a only show localhost loopback

lsmod | grep ax88179_178a

Return nothing (empty)

modprobe ax88179_178a

Return "ERROR : could not insert 'ax88179_178a' : Exec format error"

Try to use : insmod ax88179_178a.ko, return "ERROR Could not insert module ax88179_178a.ko : Invalid module format"

The Allo module is no longer compatible with the 5.4 kernel ?

[MichaIng]

Hmm, the only explanation is that the module from Allo is broken. Generally Linux 5.4 is not an issue, they build it for (nearly) all versions, even the ones not packaged for RPi repo: http://3.230.113.73:9011/Allocom/USBridgeSig/
I'll forward it. Until then, revert to default package module:

wget https://dietpi.com/downloads/misc/ax88179_178a.ko -O /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
depmod 5.4.51-v7+
modprobe ax88179_178a

Reported to Allo: https://github.com/allocom/USBridgeSig/issues/1

[comassky]

Oh no :(

There is an sound quality impact ?

[MichaIng]

I'm afraid yes, but I don't know the details. Here are the driver sources, you could try to build it yourself, raspberrypi-kernel-headers and build-essentials required, probably more: https://github.com/allocom/USBridgeSig/tree/master/ethernet
Here is some discussion around it: https://github.com/raspberrypi/linux/issues/2942
Sad that the manufacturer (ASIX) did not send this driver to be included into Linux upstream from where all would benefit.

---

Worst case is that you need to downgrade the kernel + bootloader + firmware, I guess: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/?C=M;O=D
But probably I find time tomorrow to try compiling the driver, lets see.

[Joulinar]

@MichaIng
Just for my understanding. This is specific for these Allo devices?

[MichaIng]

It's when you use this: https://allo.com/sparky/usbridge-signature-pcb.html
It has ASIX ax88179 GBit Ethernet, but the Linux upstream driver for it seems to work not good on ARMs, according to Allo leading to audio distortion in that combination and lower transfer rates as well. ASIX provided a new ARM-optimised driver to them which they provide via their servers. We install their driver on RPi automatically via /etc/kernel/postinst.d/dietpi-USBridgeSig. I remember one case where they uploaded the new driver a little late, so the script failed to download it and the default one stays in place instead. But a broken driver is of course a problem, especially since there might be other ASIX ax88179 USB Ethernet users without the Allo PCB.

[Joulinar]

Thx for explanation @MichaIng

[MichaIng]

Running into this error when trying to compile the module: https://askubuntu.com/questions/1215551/ubuntu-server-19-10-ax88179-driver-problem
This looks like the reason: https://patchwork.kernel.org/patch/10578933/
Driver needs to be updated it seems, however probably its possible to ignore this warning or not treat as error.

[comassky]

So the next step is that Allo ask to ASIX to upgrade the module to be compatible with the current 5.4 kernel ?

[MichaIng]

So the next step is that Allo ask to ASIX to upgrade the module to be compatible with the current 5.4 kernel ?

Yes indeed that should be done.

I'm not sure how Allo manages to build the module with this error. I just commented this deprecated (now removed) option definitions, like it was done here: https://github.com/acooks/tn40xx-driver/issues/9#issuecomment-457736855
The new ones seem to take procedure anyway, if I understand the patch comment correctly, so defining the old one has no effect. I tried replacing the old [gs]et_settings with [gs]et_link_ksettings but that leads to some "incompatible pointer type" error.

Please try this:

wget https://dietpi.com/downloads/misc/ax88179_178a.ko_new -O /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
depmod 5.4.51-v7+
modprobe ax88179_178a

[comassky]

So the next step is that Allo ask to ASIX to upgrade the module to be compatible with the current 5.4 kernel ?

Yes indeed that should be done.

I'm not sure how Allo manages to build the module with this error. I just commented this deprecated (now removed) option definitions, like it was done here: acooks/tn40xx-driver#9 (comment)
The new ones seem to take procedure anyway, if I understand the patch comment correctly, so defining the old one has no effect. I tried replacing the old [gs]et_settings with [gs]et_link_ksettings but that leads to some "incompatible pointer type" error.

Please try this:

wget https://dietpi.com/downloads/misc/ax88179_178a.ko_new -O /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
depmod 5.4.51-v7+
modprobe ax88179_178a

curl https://dietpi.com/downloads/misc/ax88179_178a.ko_new => 403 ;)

[MichaIng]

Whoopsie, just fixed permissions 😄.

[allocom]

Hi Michalng , I think dietpi not used the latest update form rpi firmware.

Allo used this Module7.symvers for module compilation
https://github.com/Hexxeh/rpi-firmware/commit/8382ece2b30be0beb87cac7f3b36824f194d01e9

due to the module_layout difference asix driver module not loading.
root@DietPi:/usr/src# modprobe --dump-modversions /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/asix.ko | grep module_layout
0xd557e4fa module_layout

tested by installing the latest 5.4.51 version.
apt-get install rpi-update
rpi-update 8382ece2b30be0beb87cac7f3b36824f194d01e9

[MichaIng]

@allocom
DietPi uses the official Raspberry Pi firmware packages, exactly like it is on Raspberry Pi OS and Raspbian. Those are based on the stable branch: https://github.com/raspberrypi/firmware/tree/stable which matches the mirror from Hexxeh: https://github.com/Hexxeh/rpi-firmware/tree/stable
It contains Linux 5.4.51 so the commit you linked is included, although there has been another package update meanwhile, same kernel version but updated with some firmware fixes, not sure it it's related.

If you are currently on the testing system, could you retry with the latest stable commit that matches the kernel shipped with latest raspberrypi-kernel package? rpi-update ef72c17bcaaeb89093d87bcf71f3228e1b5e1fff

[MichaIng]

Meanwhile I rebuilt the driver based on new version: https://github.com/allocom/USBridgeSig/issues/1#issuecomment-685708039
From here: https://github.com/allocom/USBridgeSig-AX2v0

@comassky
If the previous one does not work, or if you are in mood to further test, do this:

wget https://dietpi.com/downloads/misc/ax88179_178a.ko_new2 -O /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
depmod 5.4.51-v7+
modprobe ax88179_178a

To avoid confusion 😄:

Official RPi kernel module:

• https://dietpi.com/downloads/misc/ax88179_178a.ko

ASIX driver v0.1.4 based on https://github.com/allocom/USBridgeSig/tree/master/ethernet:

• https://dietpi.com/downloads/misc/ax88179_178a.ko_new

ASIX driver v2.0.0 based on https://github.com/allocom/USBridgeSig-AX2v0:

• https://dietpi.com/downloads/misc/ax88179_178a.ko_new2

[comassky]

It works with

ASIX driver v2.0.0 based on https://github.com/allocom/USBridgeSig-AX2v0:

https://dietpi.com/downloads/misc/ax88179_178a.ko_new2

Is it possible to use it by default during DietPi OS installation ?

[allocom]

both commits module_layout is different.
tree/stable module_layout is as below
0x2a51cf90 module_layout

we will see how to overcome this 2 variants. yes allo always testing the driver with raspbian OS after executing rpi-update and uses same Module.symvers.

[allocom]

yes we can test the one which you compiled and update you tomorrow.

[MichaIng]

@comassky
Great, many thanks for testing!

Is it possible to use it by default during DietPi OS installation ?

In theory yes, now that I know how to build it. But the ones provided by Allo should generally work on all RPis with official RPi kernel, so no need to double the work and probably cause inconsistencies.

@allocom

after executing rpi-update

Currently you build the drivers for the latest kernel version, once it is available on master branch, it seems, based on timestamps? Makes sense since rpi-update by default pulls the current master/testing kernel+firmware. Probably it makes sense to additionally build it based on the current stable branch (or raspberrypi-kernel-headers package) and in case overwrite an existing module by the new build? So the driver is always build against the latest stable commit, if available and additional against the latest master/testing kernel, for users who use rpi-update on a regular basis (not recommended for end users).

[comassky]

@MichaIng

Thank you for your reactivity 👍 🥇

Great job, I'm looking forward to the official patch.

In the meantime my UsbBridge is working :)

[dsnyder0pc]

Testing today (as part of dietpi-update to v6.32.2). Looks great so far:

 DietPi-Update
─────────────────────────────────────────────────────
 Phase: Applying incremental patches

[ INFO ] DietPi-Update | Current version : v6.31.2
[ INFO ] DietPi-Update | Latest version  : v6.32.2
[ INFO ] DietPi-Patch | Patching 6.31 to 6.32
removed '/etc/apt/apt.conf.d/99-dietpi-norecommends'
removed '/etc/apt/apt.conf.d/98-dietpi-no_translations'
removed '/etc/apt/apt.conf.d/99-dietpi-forceconf'
[ INFO ] Updating asix ax88179 driver for kernel 5.4.51-v7+, as provided by allo.com:
[ INFO ] - https://github.com/allocom/USBridgeSig/tree/master/ethernet
[ INFO ] Downloading driver...
--2020-09-05 09:41:27--  http://3.230.113.73:9011/Allocom/USBridgeSig/rpi-usbs-5.4.51-v7+/ax88179_178a.ko
Connecting to 3.230.113.73:9011... connected.
HTTP request sent, awaiting response... 200 OK
Length: 42895 (42K)
Saving to: ‘/tmp/ax88179_178a.ko’

     0K .......... .......... .......... .......... .         100%  595K=0.07s

2020-09-05 09:41:27 (595 KB/s) - ‘/tmp/ax88179_178a.ko’ saved [42895/42895]

[ INFO ] Installing driver...
removed '/lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko'
'/tmp/ax88179_178a.ko' -> '/lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko'
[ INFO ] Running depmod...
[ INFO ] Cleaning up...
removed '/tmp/ax88179_178a.ko'
[ INFO ] Updating asix ax88179 driver for kernel 5.4.51-v8+, as provided by allo.com:
[ INFO ] - https://github.com/allocom/USBridgeSig/tree/master/ethernet
[ INFO ] Downloading driver...
--2020-09-05 09:41:29--  http://3.230.113.73:9011/Allocom/USBridgeSig/rpi-usbs-5.4.51-v8+/ax88179_178a.ko
Connecting to 3.230.113.73:9011... connected.
HTTP request sent, awaiting response... 200 OK
Length: 66800 (65K)
Saving to: ‘/tmp/ax88179_178a.ko’

     0K .......... .......... .......... .......... .......... 76%  244K 0s
    50K .......... .....                                      100% 10.6M=0.2s

2020-09-05 09:41:29 (316 KB/s) - ‘/tmp/ax88179_178a.ko’ saved [66800/66800]

[ INFO ] Installing driver...
removed '/lib/modules/5.4.51-v8+/kernel/drivers/net/usb/ax88179_178a.ko'
'/tmp/ax88179_178a.ko' -> '/lib/modules/5.4.51-v8+/kernel/drivers/net/usb/ax88179_178a.ko'
[ INFO ] Running depmod...
[ INFO ] Cleaning up...
removed '/tmp/ax88179_178a.ko'
[  OK  ] DietPi-Patch | Commenting "arm_freq_min" in config.txt until related system instabilities have been solved
[  OK  ] DietPi-Patch | Removing deprecated "max_usb_current" from config.txt
[ INFO ] DietPi-Patch | APT autopurge, please wait...
[  OK  ] DietPi-Patch | APT autopurge
[  OK  ] DietPi-Update | Incremental patching to v6.32.2 completed

 DietPi-Update
─────────────────────────────────────────────────────
 Phase: Completed

I'll reboot to confirm networking and then do some listening tests with my Allo USBridge Signature to see if there are pops and ticks (was a problem with earlier kernels). Many thanks to @MichaIng for digging into this issue!

[dsnyder0pc]

Well…I spoke too soon. The USBridge Sig did not return to the network after rebooting from the DietPi v6.32.2 update. I logged in and observed that the ax88179_178a driver is not showing up in lsmod. Here's what I see when I try to load it:

root@usbridge:~# modprobe ax88179_178a
modprobe: ERROR: could not insert 'ax88179_178a': Exec format error

Good news is that the workaround you provided works:

root@usbridge:~# wget https://dietpi.com/downloads/misc/ax88179_178a.ko_new2 -O /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
--2020-09-05 10:10:02--  https://dietpi.com/downloads/misc/ax88179_178a.ko_new2
Resolving dietpi.com (dietpi.com)... 104.27.179.199, 104.27.178.199, 172.67.173.4, ...
Connecting to dietpi.com (dietpi.com)|104.27.179.199|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 44124 (43K)
Saving to: ‘/lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko’

/lib/modules/5.4.51-v7+/kernel/driver 100%[=======================================================================>]  43.09K  --.-KB/s    in 0.01s

2020-09-05 10:10:02 (3.16 MB/s) - ‘/lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko’ saved [44124/44124]

root@usbridge:~# depmod 5.4.51-v7+

root@usbridge:~# modprobe ax88179_178a

root@usbridge:~# lsmod | grep ax
ax88179_178a           36864  0

However, applying this workaround is not trivial for USBridge owners who do not have an alternative way to connect the device to their network. I'm using one of these: https://www.amazon.com/gp/product/B00YUU3KC6/

@MichaIng - please let me know when you'd like me to test the update process again. Happy to re-test the update process and share results. Cheers.

[dsnyder0pc]

I should add that there are no pos and clicks (so far) with the 5.4.51-v7+ kernel on the Allo USBridge Signature. Sounds fine to me.

[MichaIng]

Jep the issue is not yet resolved, Allo driver has not yet been updated. Sadly underlying issue has been found after latest DietPi release, so we'll not ship a workaround quickly.
@allocom did you find time to test and think about a solution, e.g. rebuilding the driver whenever a new version of raspberrypi-kernel apt package has been released to assure compatibility with latest stable kernel?

[allocom]

@MichaIng

Yes we have verified the driver which you compiled and working fine.
also we have compiled and kept stable release link , will continue the link for further stable releases.

http://3.230.113.73:9011/Allocom/DietPi/stable/rpi-usbs-5.4.51-v7+/

[MichaIng]

@allocom
Many thanks, however that does not exactly fix the issue for our users since we use http://3.230.113.73:9011/Allocom/USBridgeSig/rpi-usbs-$(uname -r)/ in our kernel postinst script to pull the driver. Since the same issue is present for Raspbian/Raspberry Pi OS users as well, would you mind to update the driver at http://3.230.113.73:9011/Allocom/USBridgeSig/rpi-usbs-5.4.51-v7+/? 5.4.51-v8+ likely suffers the same issue, although the amount of users running a 64-bit kernel is tiny and the RPi foundation x64 kernel + firmware is under high development anyway.

Generally there is no need to keep things separated for Raspbian/Raspberry Pi OS and DietPi users, we use the same kernel and firmware packages, all 100% compatible, using the same APT repositories, which implies that a kernel/driver issue always appears on both sides the same way 🙂.

Generally I think that such a stable kernel release that is incompatible with a previews one (regarding kernel module builds) with matching version string, is extremely rare, so probably not necessary to change build strategy on a general basis. Time will solve it (next package release) on its own 😉.

[allocom]

@MichaIng
we are normally verifying compiled driver with raspbian os rpi-update , as we discussed earlier rpi-update always refers to the Master branch.
I think stable releases referring for custom image builds. We verified this with Moode audio, Volumio and Raspbian OS new updates. for the stable releases we can use new link for 5.4.51 onwards all updates. Yes we can update v8+ driver also in that new link. as a workaround use the new link for updates.
later stable releases driver can include it in http://3.230.113.73:9011/Allocom/USBridgeSig/ by adding proper checking mechanism.

[allocom]

@MichaIng
added link on same folder http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/
and modified install.sh to check module_layout before updating (http://3.230.113.73:9011/Allocom/USBridgeSig/install.sh) ,

[MichaIng]

@allocom
The direct module layout comparison is a nice idea 👍, I'll apply that to our script as well, including the /stable_rel/ fallback and if both layouts do not match, the download can be skipped to use the builtin module instead as last resort.

I think stable releases referring for custom image builds.

That is not the case. The following words might appear "hard" but I want to make the point very clear: We do not go any "custom" way with DietPi, we go the officially recommended way that matches what Raspbian/Raspberry Pi OS users are advised to do. Please read the official docs about that topic: https://www.raspberrypi.org/documentation/raspbian/applications/rpi-update.md

• The Raspberry Pi Foundation recommends to not use rpi-update and hence not the master (=development/unstable) branch unless a developer asks to do so, to test or resolve a specific issue. Raspbian (Raspberry Pi OS) ships with the kernel and firmware packages installed that are based on the stable branch, just like DietPi does. apt upgrade is hence the recommended way to upgrade the kernel, not rpi-update.
• So if Moode audio and Volumio use/promote rpi-update or the master branch or build their own kernel/firmware based on the master branch, then they should clearly change that, as it is not recommended for end user production systems!
• And if it counts, I'm regularly playing around and help testing fixes with the master branch and I can tell from own experience that it contains bugs and broke things from time to time. Every change, request or fix is merged before any external user has tested it and it happens by times that the fix/commit was not having the expected result or introduced new issues which are then fixed after testers feedback. So it's basically Russian roulette what you get when running rpi-update!

But as I said, for the ASIX driver builds I think it is fine to use the master branch to be able to test it with the new kernel early and for enthusiastic user which use rpi-update against recommendations. The case that the module layout changes without kernel version increment should be very rare. Having an additional build based on the current stable branch + layout comparison should be very failsafe.

[MichaIng]

Applied the new driver update method to try stable branch drivers first and abort if module layout does not match the one required for kernel:

• For DietPi-Update: https://github.com/MichaIng/DietPi/commit/55cf2680567811bd3296fec8ba4c241709aa21e7
• For new RPi images: https://github.com/MichaIng/DietPi/commit/5b0862933ce5a4df9e6183865acadbb121ad427f
• Changelog: https://github.com/MichaIng/DietPi/commit/aff1ac8f7e50c21b36b1cf998e56438b8bc9ea3f

[dsnyder0pc]

I just tested with the October 22nd DietPi_RPi-ARMv7-Buster_AlloGUI.img image, which is still v6.32.2, IIRC. The Allo USBridge Signature booted with no networking (missing a working ax88179_178a). I transferred the microSD card to another RPi and applied the workaround:

#!/bin/bash
curl -LO https://dietpi.com/downloads/misc/ax88179_178a.ko_new2
cp ax88179_178a.ko_new2 /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
depmod 5.4.51-v7+
modprobe ax88179_178a

After that, I was able to use dietpi-update to upgrade to DietPi v6.33.3, reboot, and still have networking. Here's the version of the driver in 5.4.72-v7+ (after the update):

# ls -l ax88179_178a.ko
-rw-r--r-- 1 root root 29544 Oct 22 15:25 ax88179_178a.ko
# md5sum ax88179_178a.ko
4d605f9759a8cb9af0eb8c8945c368fd  ax88179_178a.ko

So, Allo USBridge Signature owners are still in for a bumpy ride with the October 22nd image, but if the image after this one includes this new driver, they should be good to go. Thanks again, @MichaIng and @allocom for working on this. If they have another Raspberry Pi and a USB microSD card reader, they can use these commands to "patch" the October 22nd image so that it boots with networking:

ALLO_MICROSD=/dev/sdb  # use lsblk or dmesg to find the correct device for your card reader
curl -LO https://dietpi.com/downloads/images/DietPi_RPi-ARMv7-Buster_AlloGUI.7z
7z x DietPi_RPi-ARMv7-Buster_AlloGUI.7z
wipefs -a "${ALLO_MICROSD}"
dd if=DietPi_RPi-ARMv7-Buster_AlloGUI.img  of="${ALLO_MICROSD}" bs=4M conv=fsync
mount "${ALLO_MICROSD}2" /mnt
curl -L https://dietpi.com/downloads/misc/ax88179_178a.ko_new2 -o /mnt/lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
sync
umount /mnt

[dsnyder0pc]

BTW, while testing the above "patch" process, I observed a few 404 errors in the output. @allocom , this may be worth looking into:

FWIW, it looks like fall-back to the default driver actually worked, but fixing these 404's should be easy and is probably the right thing to do.

Here's a recording of the complete first-boot and dietpi-update process for the October 22nd image with my "patch" from above: https://youtu.be/rIt3jVPn6RM

[dsnyder0pc]

Not related to this issue, but I should add that the October 22nd kernel (5.4.72-v7+) is unusable for audio. When playing out to a USB DAC (what the USBridge Signature was made for), there's a constant stream of pops and ticks. :-\

Trying this workaround to roll back to the previous kernel (5.4.51-v7+):

curl -LO https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20200902-1_armhf.deb
curl -LO https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-bootloader_1.20200902-1_armhf.deb
curl -LO https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/libraspberrypi0_1.20200902-1_armhf.deb
curl -LO https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/libraspberrypi-bin_1.20200902-1_armhf.deb
dpkg -i *1.20200902-1*.deb
apt-mark hold $(dpkg -l | awk '/1.20200902-1/ {print $2}')

This seems to have resolved the pops and ticks for now. @allocom - please let me know if you have experienced the same thing in your testing of the 5.4.72-v7+ kernel on the USBridge Signature.

[dsnyder0pc]

I've tossed these kernel downgrade steps into a script to make it a bit easier:

curl -L ws-e.com/to-5451.sh | bash

[MichaIng]

Thanks for the hint, yes totally makes sense to add the fixed driver to our Allo GUI image! EDIT: Done

The issue with 5.4.72 is that there is no build available yet: http://3.230.113.73:9011/Allocom/USBridgeSig/
@allocom would you mind to trigger one as 5.4.72 has been officially released by RPi Foundation? 🙂 And would be great if the stable builds could be done for ARMv8 as well, as only the stable 5.4.51-v7+ has been build, no 5.4.51-v8+.

Possible 404 errors during kernel update are btw expected, note the "No matching stable driver found, trying to...".
We try to pull the updated ASIX driver for 5.4.X-v7+ and 5.4.X-v8+ for stable kernel build first, if that fails (404) or the module layout does not match, we try to pull it for master kernel build and if that fails the default RPi kernel driver stays in place, which is sadly unusable with audio output as you recognised.
@dsnyder0pc
Do you have an idea how we can make it clearer that the one or the other 404 is expected here? 🤔
I don't want to hide the HTTP response completely to not mute errors that really need to be fixed and we tried to keep the explanations short to not spam the console more that it already does, especially since it is only relevant for USBridge Sig users.

A pain that ASIX did not manage until now to push the updated driver to mainstream Linux. RPi Foundation refused to accept the new drivers when done coming from upstream 😞.

---

@dsnyder0pc
Just to assure, http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/rpi-usbs-5.4.51-v7+/ax88179_178a.ko works fine for your as well, right?

[dsnyder0pc]

@MichaIng - Yes. http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/rpi-usbs-5.4.51-v7+/ax88179_178a.ko works fine for me. I've verified that it's the same as what I'm currently running:

root@usbridge:~# curl -LO http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/rpi-usbs-5.4.51-v7+/ax88179_178a.ko
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 42895  100 42895    0     0  73324      0 --:--:-- --:--:-- --:--:-- 73450
root@usbridge:~# cksum ax88179_178a.ko /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
1297844159 42895 ax88179_178a.ko
1297844159 42895 /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko

I think the "No matching driver found. Cleaning up and aborting…" bit was the most concerning. I did notice that it was part of an "[INFO]" message, so, I didn't think I should take it too seriously. I guess if I was checking for a number of resources that may or may not exist, I'd probably just do a series of HEAD requests and say something like:

[INFO] Checking for updated Allo networking driver…[OK]

or

[INFO] Checking for updated Allo networking driver…[No Found]

Of course, if there's an error actually pulling down the driver, you should report that (eg., no space or whatever). But, probably no need to report the HTTP status code from the HEAD request.

For example:

curl -sL --head http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/rpi-usbs-5.4.51-v7+/ax88179_178a.ko | awk '/^HTTP/ {print substr($0, 14, 80)}'
OK

curl -sL --head http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/rpi-usbs-5.4.51-v7+/random_file_not_there | awk '/^HTTP/ {print substr($0, 14, 80)}'
Not Found

[MichaIng]

Many thanks for your suggestion. That would match a bid the way we perform downloads within dietpi-software currently, first with basically a HEAD request (wget --spider), then in case of success, do the actual download. But actually I wanted to skip the first test and directly perform the download, as in case of failure it produces the same error messages that can be parsed/printed. So actually a separate first test is an overhead that can take a few seconds on some internet connections (satellite, mobile, such).

But indeed here we expect at least one 404 for at least one of the two kernels (v7+ and v8+). An alternative to the separate HEAD request is to redirect error outputs into a variable first, and only if it's present + no 404, print it to console, if it's 404, print the smoother "No matching stable branch driver found, trying master branch driver..." actually is enough.
In case of failing master branch driver download, it however makes sense to print the error since this should not happen. It only affects users that actually use the driver of course, so most likely only USBridge Sig users, but it breaks their audio as you verified. I'm thinking about a way to reliably detect if it's actually in use/loaded, but that is actually hard since after a kernel upgrade, modprobe/modinfo do not work anymore as on RPi the old /lib/modules/* directory is removed directly 🤔.

[dsnyder0pc]

Well, the USBridge Signature is a Raspberry Pi Compute Module 3+

- Device model : RPi CM 3+ (armv7l)

Probably only a small percentage of non-industrial end users are running DietPi on CM 3+ boards, so perhaps you could only go to this trouble if you detect that you're installing on a CM 3+. :)

[MichaIng]

Good point, theoretically it could be completely skipped on non-CM3 🤔.

[theskystalker]

Hi, same issue on my Raspberry Pi 2 Model B V1.1

first setup of DietPi hangs in endless loop, trying to get Kernel-Module from this strange Server http://3.230.113.73:9011/Allocom/USBr.....

Raspi OS works like a charm without this stuff, but i want to use DietPi because of the other nice features

is there a option in the dietpi.txt to skip this step?

below is the console output of my 3rd try to finish setup :/

BR
Stefan

Removing 'diversion of /boot/overlays/uart2.dtbo to /usr/share/rpikernelhack/overlays/uart2.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/uart3.dtbo to /usr/share/rpikernelhack/overlays/uart3.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/uart4.dtbo to /usr/share/rpikernelhack/overlays/uart4.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/uart5.dtbo to /usr/share/rpikernelhack/overlays/uart5.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/udrc.dtbo to /usr/share/rpikernelhack/overlays/udrc.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/upstream-pi4.dtbo to /usr/share/rpikernelhack/overlays/upstream-pi4.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/upstream.dtbo to /usr/share/rpikernelhack/overlays/upstream.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/vc4-fkms-v3d.dtbo to /usr/share/rpikernelhack/overlays/vc4-fkms-v3d.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/vc4-kms-kippah-7inch.dtbo to /usr/share/rpikernelhack/overlays/vc4-kms-kippah-7inch.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/vc4-kms-v3d-pi4.dtbo to /usr/share/rpikernelhack/overlays/vc4-kms-v3d-pi4.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/vc4-kms-v3d.dtbo to /usr/share/rpikernelhack/overlays/vc4-kms-v3d.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/vga666.dtbo to /usr/share/rpikernelhack/overlays/vga666.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/w1-gpio-pullup.dtbo to /usr/share/rpikernelhack/overlays/w1-gpio-pullup.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/w1-gpio.dtbo to /usr/share/rpikernelhack/overlays/w1-gpio.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/w5500.dtbo to /usr/share/rpikernelhack/overlays/w5500.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/wittypi.dtbo to /usr/share/rpikernelhack/overlays/wittypi.dtbo by rpikernelhack'
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.4.72+ /boot/kernel.img
run-parts: executing /etc/kernel/postinst.d/dietpi-USBridgeSig 5.4.72+ /boot/kernel.img
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.4.72-v7+ /boot/kernel7.img
run-parts: executing /etc/kernel/postinst.d/dietpi-USBridgeSig 5.4.72-v7+ /boot/kernel7.img
/etc/kernel/postinst.d/dietpi-USBridgeSig:
[ INFO ] Updating asix ax88179 driver for kernel 5.4.72-v7+, as provided by allo.com:
[ INFO ] - https://github.com/allocom/USBridgeSig/tree/master/ethernet
[ INFO ] Downloading driver...
--2020-11-16 17:17:34--  http://3.230.113.73:9011/Allocom/USBridgeSig/rpi-usbs-5.4.72-v7+/ax88179_178a.ko
Connecting to 3.230.113.73:9011... failed: Connection timed out.
Retrying.

--2020-11-16 17:19:47--  (try: 2)  http://3.230.113.73:9011/Allocom/USBridgeSig/rpi-usbs-5.4.72-v7+/ax88179_178a.ko
Connecting to 3.230.113.73:9011...

[Joulinar]

@theskystalker
your issue is different than the original one. Looks like a temp issue at Allo side. At least for me the download is working fine right now. Just checked it on my Windows box.

[theskystalker]

@Joulinar you were right.
I can download the file from my web server.
Looks like my IP is blocked by this server. :(

[Joulinar]

Hmm probably your ISP is blocking it? 🤔

[theskystalker]

Looks like only the Webserver on this machine blocks my IP. There is also running an FTP Server and from there I got an answer. :man_shrugging:

Maybe it would be an good idea to load the source from Github an compile it on the pi, because loading "Stuff" from unknown sources is not best practice,

at least comparing the hash would be fine, but there is nothing provided on github

[Joulinar]

This is the Allo web server. But maybe there is something else in between blocking HTTP traffic?

[MichaIng]

Connecting to 3.230.113.73:9011... failed: Connection timed out.
Retrying.

--2020-11-16 17:19:47-- (try: 2)...

Strange that curl is retrying, as actually by default it should give up on a failure. Ah when updating from v6.32 to v6.33 then it is still the old script that used wget which does 20 retries by default. So that is solved already.

Okay, let's make this a minimal noise implementation:

• USBRidge Sig is RPi CM3+, so let's only apply the module upgrade for this single device. I was thinking that a better driver for this ASIX Ethernet chip is generally good, but finally it creates more issues/worries when the download fails compared to the near-to-zero change that someone attaches the same external Ethernet device onto another RPi model (which does still work, only breaks USB audio), especially as all but CMs have onboard Ethernet and CM1 is incompatible due to ARMv6 kernel.
• The pre-flashed DietPi image is using the ARMv7 kernel, switching to ARMv8 is possible but not reasonable without flashing the ARMv8 image. So no need to attempt downloading for both kernel versions, but only the one that is used. Furthermore Allo did not build the ARMv8 module for the last few versions anymore, and we don't have an Allo GUI ARMv8 image either, so we'll revert to only upgrade for ARMv7 for now.
• I'll adjust the messages to make it clear that a failing download can be ignored when not using the Allo USBridge Sig and otherwise that the script should be retried later: /etc/kernel/postinst.d/dietpi-USBridgeSig

@theskystalker
In your case: rm /etc/kernel/postinst.d/dietpi-USBridgeSig
You don't need it 😉.

[theskystalker]

Nice, and thanks for the Tip, will try it tomorrow :+1:

Ah when updating from v6.32 to v6.33 then it is still the old script that used wget which does 20 retries by default.

Oh, ok that's 40 minutes :grin: , nearly endless loop :laughing:

[MichaIng]

Another reason why migrating all downloads to curl is a good idea, aside of the fact that it inits faster (relevant for small downloads and HEAD requests).

Reopened to not forget about this.

[MichaIng]

Will now only be applied on CM 3+ now and only for v7+ kernel: https://github.com/MichaIng/DietPi/commit/d8ace2f62adb88fa8bbcb66dca1de1a60be67f31

A build for the latest stable kernel is btw available now: http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/
@dsnyder0pc so you could update your kernel now.