Sabrent USB 2.5G Ethernet Adapter: Realtek 8152 Chipset Drivers from AUR?

[johntdavis84]

Followup to this post: [SOLVED] [RTL8151] Ethernet not working via multiport adapter

I’m trying to get the Sabrent USB 3 to Ethernet 2.5Gbps adapter working on my Pi.

I successfully mode-switched the device as described in the above thread. (By default, it’s in USB storage mode so that the user can install the Windows driver off the tiny flash memory inside).

However, the AUR package it wants me to install is not tagged as being for the aarch64 architecture.
This is the package: AUR (en) - r8152-dkms

Someone in the AUR package comments looks like they’ve got it built for ARM, but the comment is fairly old and I’m not sure if the process is supposed to be this involved. @Darksky or anyone else who might know: how badly am I likely to screw up my system if I try forcing the build? Can I just uninstall it if it doesn’t work?

Right now, with the adapter plugged in, I get this via ip addr show:

4: enp1s0u1c2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether $MAC brd ff:ff:ff:ff:ff:ff

[Darksky]

@johntdavis84

However, the AUR package it wants me to install is not tagged as being for the aarch64 architecture.
This is the package: AUR - r8152-dkms

This is already in the kernel:

[johntdavis84]

Oh, cool. Thanks, @Darksky ! Where is that list, so I can look at it next time before I start contemplating pulling random AUR drivers?

Do I need to do something specific to make this work? The adapter shows up in Network Manager, but it’s not getting an IP from the router via the switch. I’m wondering if it’s because Network Manager does not seem to recognize 2.5Gb/s as a possible link speed. (It’s not in the “Speed” dropdown).

The auto-negotiation feature is currently set to ignore. I’ll try setting it to automatic and see what happens.

[Darksky]

@johntdavis84

Where is that list, so I can look at it next time before I start contemplating pulling random AUR drivers?

If the kernel headers are installed:

nano /usr/lib//modules/uname -r/build/.config # (back tick uname -r back tick)

If not (remember grep is case sensitive when searching):

sudo modprobe configs
zcat /proc/config.gz | grep 8152

[johntdavis84]

Excellent. I’ll try this. Which headers do I need installed? I have the rpi-mainline ones, at least. What does the double slash do? Create a new folder?

Any idea why the adapter isn’t working? I didn’t see anything untoward in dmesg, but I also wasn’t sure what I should be prepping for. It finds the adapter, identifies the manufacturer and type (from the usb_modeset command), and gives it the name of a network interface.

Do I need to bring it up manually? I’ve not had to do that before.

[Darksky]

@johntdavis84

I’ll try this. Which headers do I need installed? I have the rpi-mainline ones

The ones for the current kernel:

linux-rpi4-mainline-headers

@johntdavis84

What does the double slash do?

Done like in the pic it will find the current running kernel

@johntdavis84

Any idea why the adapter isn’t working?

No clue

[johntdavis84]

@Darksky

nano /usr/lib//modules/uname -r/build/.config

This worked great. Done without sudo, does it just create a file in memory and not save it anywhere? That’s what I assume is happening.

[Darksky]

@johntdavis84

does it just create a file in memory and not save it anywhere? That’s what I assume is happening.

modprobe creates a compressed file /proc/config.gz and will disappear on reboot.

zcat decompresses it in memory then grep finds what you are looking for and prints it out. You can also do this and it will decompress and write the file in the current directory so you can open it up and view:

zcat /proc/config.gz > config.txt

I hooked up my 8152 and it did not work on the usb 2.0 port. Then I put it on the usb 3.0 port and it worked.

[johntdavis84]

@Darksky

I hooked up my 8152 and it did not work on the usb 2.0 port. Then I put it on the usb 3.0 port and it worked.

I double-checked, it was definitely in the USB3 port.

I switched the ethernet cable for an older, way too long CAT5E cable I know works. It connected fine, using all default settings on the switch. The switch recognizes it as a 2.5G connection.

Still need to do a speed test … and test the possibly faulty Cat 6A cable I was using before.

[Darksky]

@johntdavis84

Still need to do a speed test … and test the possibly faulty Cat 6A cable I was using before.

Check in the connectors that all wires are being used. I have seen some years ago you would buy not having all of the wires run to the crimp point at the end which would work fine at the time but with the new high speed nic’s use more wires I have read. I make my own and always run all wires to the crimp point.

I used to do that along with maintaining 6 servers for 120 workstations all networked to 14 cities here in Arkansas. Including the inter-agency phone system. I have been out of the business for a very log time.

[johntdavis84]

I will check the wires shortly. The NIC just stopped working again, so I don’t think that’s it.

I just plugged the 2.5GbE adapter straight into my router, bypassing the switch, in case that was the issue. Now, not only is it not getting an IP address from the router, but it’s also only negotiating with the router at 100 Mbps or less.

Starting to wonder if I got a dud.

[Darksky]

Sometimes I have found that auto negotiating causes issues. Sometimes you might have to set the speed a little lower. Sometimes I had to buy another brand of nic. This usually was due to incompatibility with the brand of the router opposed to the brand of nic. Sometimes a firmware update on the router helps. Then also there could be an issue with the module the nic uses. Networking can at times be a headache.

[johntdavis84]

Aye.

I just checked their website. There are Windows/Mac/Linux drivers listed, so I’m trying the Mac drivers first to see if I can at least get it working on a computer I know is otherwise in fine working order.

This is the message the installer greets you with:

Welcome to Realtek USB NICs world…

So that seems encouraging. </ s>

[johntdavis84]

@Darksky , I think I’ve figured out the problem. Maybe.

Some queries:

]$ dmesg | grep r8152
[    1.446287] usbcore: registered new interface driver r8152

]$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
    |__ Port 2: Dev 4, If 0, Class=Communications, Driver=cdc_ncm, 5000M
    |__ Port 2: Dev 4, If 1, Class=CDC Data, Driver=cdc_ncm, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
]$ lsusb
Bus 002 Device 004: ID 0bda:8156 Realtek Semiconductor Corp. USB 10/100/1G/2.5G LAN
Bus 002 Device 002: ID 152d:0583 JMicron Technology Corp. / JMicron USA Technology Corp. JMS583Gen 2 to PCIe Gen3x2 Bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So I successfully loaded the r8152 Realtek chipset driver. And it’s using something called cdc_ncm. I’m less clear what that is, but assume it’s part of the driver/network stack.

But! It is my understanding that this device, actually uses the Realtek r8156 chipset.

The AUR version, which does not want to install on ARM by default, specifically mentions supporting the RTL8156. I’m not sure if 2.14-1 is actually different than 2.14, but … maybe?

]$ pamac info r8152-dkms
Name                  : r8152-dkms
Version               : 2.14-1
Description           : A kernel module for Realtek RTL8152/RTL8153/RTL8154/RTL8156 Based USB Ethernet Adapters
URL                   : http://www.realtek.com
Licenses              : GPL
Repository            : AUR
Depends On            : glibc dkms
Optional Dependencies : linux-headers [Installed]
                        linux-lts-headers
Conflicts With        : r8152
Maintainer            : wget
First Submitted       : 09/17/2016
Last Modified         : 10/23/2020
Votes                 : 8

Realtek themselves indicate their linux driver version 2.14 is only compatible with kernels up to 5.6: Oops!

There’s a thread on OpenWRT’s forum about this, but it’s way over my head: 2.5G USB->Ethernet, kmod-usb-net-rtl8152? - Installing and Using OpenWrt - OpenWrt Forum

I’ve never in my life attempted to compile a kernel module, so I’m really lost where to. start with that, or how to even tell if there’s something useful to try there.

EDIT: I installed ethtool and asked it for driver info, and got this:
> ~]$ ethtool -i enp1s0u2c2

    driver: cdc_ncm
    version: 5.11.0-3-MANJARO-ARM
    firmware-version: CDC NCM
    expansion-rom-version: 
    bus-info: usb-0000:01:00.0-2
    supports-statistics: yes
    supports-test: no
    supports-eeprom-access: no
    supports-register-dump: no
    supports-priv-flags: no

Is it even loading the right driver?

EDIT 2: One more bit of possibly useful troubleshooting info, here’s udevadm monitor when the NIC is plugged in:

KERNEL[5200.633854] add      /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2 (usb)
KERNEL[5200.635540] add      /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0 (usb)
KERNEL[5200.658000] add      /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/usb0 (net)
KERNEL[5200.658121] add      /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/usb0/queues/rx-0 (queues)
KERNEL[5200.658187] add      /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/usb0/queues/tx-0 (queues)
KERNEL[5200.658601] bind     /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0 (usb)
KERNEL[5200.659050] add      /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.1 (usb)
KERNEL[5200.659177] bind     /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.1 (usb)
KERNEL[5200.659288] bind     /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2 (usb)
UDEV  [5201.328759] add      /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2 (usb)
UDEV  [5201.335527] add      /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0 (usb)
UDEV  [5201.339548] add      /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.1 (usb)
KERNEL[5201.353403] move     /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/enp1s0u1u2c2 (net)
UDEV  [5201.358415] bind     /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.1 (usb)
UDEV  [5201.421952] add      /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/enp1s0u1u2c2 (net)
UDEV  [5201.445248] add      /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/usb0/queues/rx-0 (queues)
UDEV  [5201.449428] add      /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/usb0/queues/tx-0 (queues)
UDEV  [5201.454736] bind     /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0 (usb)
UDEV  [5201.490287] bind     /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2 (usb)
UDEV  [5201.498396] move     /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/enp1s0u1u2c2 (net)

[0n0w1c]

Maybe you could try blacklisting the cdc_ncm driver to see if the r8152 then loads instead.
The r8152 module is being compiled, you just need to get it loaded. No need to compile a different one unless the kernel version does not work.

Something like this should work:
$ nano /etc/modprobe.d/blacklist.conf

blacklist cdc_ncm

The Arch Wiki has some more information.

[Darksky]

I compiled the one from aur that says:

Description: A kernel module for Realtek RTL8152/RTL8153/RTL8154/RTL8156 Based USB Ethernet Adapters

And installed it and it looks a lot different.

The one in the kernel does not specify firmware for the 8156:

Summary

[ray@pi4 ~]$ modinfo r8152
name: r8152
filename: (builtin)
version: v1.11.11
license: GPL
file: drivers/net/usb/r8152
description: Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
author: Realtek linux nic maintainers nic_swsd@realtek.com
firmware: rtl_nic/rtl8153b-2.fw
firmware: rtl_nic/rtl8153a-4.fw
firmware: rtl_nic/rtl8153a-3.fw
firmware: rtl_nic/rtl8153a-2.fw

The one from AUR:

Summary

[ray@vim3 r8152-dkms]$ modinfo /usr/lib/modules/5.11.1-1-MANJARO-ARM/updates/r8152.ko.gz
filename: /usr/lib/modules/5.11.1-1-MANJARO-ARM/updates/r8152.ko.gz
version: v2.14.0 (2020/09/24)
license: GPL
description: Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
author: Realtek nic sw nic_swsd@realtek.com
srcversion: 76D1CDFA8C39E2E2C6F2D59
alias: usb:v13B1p0041ddcdscdpic02isc0Dip00in*
alias: usb:v13B1p0041ddcdscdpic02isc06ip00in*
alias: usb:v13B1p0041ddcdscdpicFFiscipin*
alias: usb:v0955p09FFddcdscdpic02isc0Dip00in*
alias: usb:v0955p09FFddcdscdpic02isc06ip00in*
alias: usb:v0955p09FFddcdscdpicFFiscipin*
alias: usb:v2357p0601ddcdscdpic02isc0Dip00in*
alias: usb:v2357p0601ddcdscdpic02isc06ip00in*
alias: usb:v2357p0601ddcdscdpicFFiscipin*
alias: usb:v17EFpA387ddcdscdpic02isc0Dip00in*
alias: usb:v17EFpA387ddcdscdpic02isc06ip00in*
alias: usb:v17EFpA387ddcdscdpicFFiscipin*
alias: usb:v17EFpA359ddcdscdpic02isc0Dip00in*
alias: usb:v17EFpA359ddcdscdpic02isc06ip00in*
alias: usb:v17EFpA359ddcdscdpicFFiscipin*
alias: usb:v17EFp8153ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp8153ddcdscdpic02isc06ip00in*
alias: usb:v17EFp8153ddcdscdpicFFiscipin*
alias: usb:v17EFp721Eddcdscdpic02isc0Dip00in*
alias: usb:v17EFp721Eddcdscdpic02isc06ip00in*
alias: usb:v17EFp721EddcdscdpicFFiscipin*
alias: usb:v17EFp7214ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp7214ddcdscdpic02isc06ip00in*
alias: usb:v17EFp7214ddcdscdpicFFiscipin*
alias: usb:v17EFp720Cddcdscdpic02isc0Dip00in*
alias: usb:v17EFp720Cddcdscdpic02isc06ip00in*
alias: usb:v17EFp720CddcdscdpicFFiscipin*
alias: usb:v17EFp720Bddcdscdpic02isc0Dip00in*
alias: usb:v17EFp720Bddcdscdpic02isc06ip00in*
alias: usb:v17EFp720BddcdscdpicFFiscipin*
alias: usb:v17EFp720Addcdscdpic02isc0Dip00in*
alias: usb:v17EFp720Addcdscdpic02isc06ip00in*
alias: usb:v17EFp720AddcdscdpicFFiscipin*
alias: usb:v17EFp7205ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp7205ddcdscdpic02isc06ip00in*
alias: usb:v17EFp7205ddcdscdpicFFiscipin*
alias: usb:v17EFp3098ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3098ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3098ddcdscdpicFFiscipin*
alias: usb:v17EFp3082ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3082ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3082ddcdscdpicFFiscipin*
alias: usb:v17EFp3069ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3069ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3069ddcdscdpicFFiscipin*
alias: usb:v17EFp3062ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3062ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3062ddcdscdpicFFiscipin*
alias: usb:v17EFp3057ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3057ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3057ddcdscdpicFFiscipin*
alias: usb:v17EFp3054ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3054ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3054ddcdscdpicFFiscipin*
alias: usb:v17EFp3052ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3052ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3052ddcdscdpicFFiscipin*
alias: usb:v17EFp304Fddcdscdpic02isc0Dip00in*
alias: usb:v17EFp304Fddcdscdpic02isc06ip00in*
alias: usb:v17EFp304FddcdscdpicFFiscipin*
alias: usb:v04E8pA101ddcdscdpic02isc0Dip00in*
alias: usb:v04E8pA101ddcdscdpic02isc06ip00in*
alias: usb:v04E8pA101ddcdscdpicFFiscipin*
alias: usb:v045Ep07C6ddcdscdpic02isc0Dip00in*
alias: usb:v045Ep07C6ddcdscdpic02isc06ip00in*
alias: usb:v045Ep07C6ddcdscdpicFFiscipin*
alias: usb:v045Ep07ABddcdscdpic02isc0Dip00in*
alias: usb:v045Ep07ABddcdscdpic02isc06ip00in*
alias: usb:v045Ep07ABddcdscdpicFFiscipin*
alias: usb:v0BDAp8156ddcdscdpic02isc0Dip00in*
alias: usb:v0BDAp8156ddcdscdpic02isc06ip00in*
alias: usb:v0BDAp8156ddcdscdpicFFiscipin*
alias: usb:v0BDAp8155ddcdscdpic02isc0Dip00in*
alias: usb:v0BDAp8155ddcdscdpic02isc06ip00in*
alias: usb:v0BDAp8155ddcdscdpicFFiscipin*
alias: usb:v0BDAp8153ddcdscdpic02isc0Dip00in*
alias: usb:v0BDAp8153ddcdscdpic02isc06ip00in*
alias: usb:v0BDAp8153ddcdscdpicFFiscipin*
alias: usb:v0BDAp8152ddcdscdpic02isc0Dip00in*
alias: usb:v0BDAp8152ddcdscdpic02isc06ip00in*
alias: usb:v0BDAp8152ddcdscdpicFFiscipin*
alias: usb:v0BDAp8050ddcdscdpic02isc0Dip00in*
alias: usb:v0BDAp8050ddcdscdpic02isc06ip00in*
alias: usb:v0BDAp8050ddcdscdpicFFiscipin*
depends:
name: r8152
vermagic: 5.11.1-1-MANJARO-ARM SMP mod_unload aarch64

The new modules from aur works with my 8152 device but it is not the one you have. Also I was getting spammed with cdc_ncm messages with the kernel module and it is not happening with the aur one.

The fly in the onitment is the kernel module is built in the kernel and I will have to recompile the kernel before you can test.

[Darksky]

@johntdavis84

Here is the new kernel and the dkms package.

I installed it on my pi4 and discovered that it can not exist on the same USB 3.0 bridge as my usb SSD. I lost my SSD drive the second the 8152 dongle was plugged in. Seems like I may seen similar happening to you previously in your logs above. My previous test was on the vim3 using the internal eMMc.

I then plugged the 8152 dongle into my usb 2.0 port and it worked:

Summary

[ 9.350416] usbcore: registered new interface driver cdc_ether
[ 9.425567] usb 1-1.3.4: reset high-speed USB device number 4 using xhci_hcd
[ 9.611047] r8152 1-1.3.4:1.0 eth1: v2.14.0 (2020/09/24)
[ 9.611059] r8152 1-1.3.4:1.0 eth1: This product is covered by one or more of the following patents:
US6,570,884, US6,115,776, and US6,327,625.

[ 9.611397] usbcore: registered new interface driver r8152
[ 9.621814] r8152 1-1.3.4:1.0 enp1s0u1u3u4: renamed from eth1
[ 11.292813] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0u1u3u4: link becomes ready
[ 11.293627] r8152 1-1.3.4:1.0 enp1s0u1u3u4: carrier on
[ 11.329232] bcmgenet fd580000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 11.329273] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Procedure:

Download the tarball and unpack it
cd 8152
sudo pacman -U linux-rpi4-5.10.17-2-aarch64.pkg.tar.zst linux-rpi4-headers-5.10.17-2-aarch64.pkg.tar.zst

Unplug your 8152 usb dongle and reboot. Once rebooted install the dkms package from the 8152 directory:

sudo pacman -U r8152-dkms-2.14-1-aarch64.pkg.tar.zst

Plug in your 8152 dongle and cross your fingers.

8152.tar

[johntdavis84]

This is amazing. Thanks for doing this, @Darksky . What a lovely birthday present.

I’ll try this later tonight. I’m presently booting off a USB3 enclosed nvme drive, so I’m not sure this is going to be workable if I can’t have them both plugged in. On the USB2 bus, won’t the dongle always be slower than the 800 or so Mbps I get now?

@0n0w1c Thanks for this. I just discovered the modprobe stuff last night, but it was 2AM and I didn’t have a chance to do more than realize it existed. You saved me quite a lot of research time.

I ended up doing this:

]$ cat blacklist.conf 
install cdc_ncm /bin/true
install cdc_wdm /bin/true
install cdc_ether /bin/true
install cdc_mbim /bin/true

According to the wiki page you linked, this not only unloads those modules at boot, but also keeps any other loaded module from calling them.

Without the driver @Darksky prepared, I’m still not getting anything useful off the adapter. It reports itself as using the usb-network driver via inxi -N, which isn’t a listed kernel module in lsmod. I’m not sure if that can even be turned off if there’s not another driver installed.

Where does usb-network get loaded from? Can I use the same blocklist on it even though it doesn’t show up in lsmod?

[0n0w1c]

That sounds like your adapter is not supported by the current r8152 linux driver. I would undo the blacklisting, as it did not result in a functional adapter. And then follow what @Darksky has prepared.

[johntdavis84]

Yeah. I figured that was probably the case.

I’m guessing the usb-network driver is some baseline, “we do USB Network Adapters” thing that other drivers sit on top of? That would make sense as to why it can’t be unloaded.