DEV Community: Fauzan Febriansyah

Fix ASIX AX88179 Ethernet Crash Loop on Linux When Using a UGREEN USB-C Hub

Fauzan Febriansyah — Sun, 29 Mar 2026 13:34:55 +0000

You buy a new USB-C hub. You plug it into a Windows partition, and the Gigabit Ethernet adapter lights up instantly via plug-and-play magic. You reboot into Linux, and the interface is dead. Wired cable unplugged.

If you are running the UGREEN UNO 7-in-1 Hub (Model 45155) featuring the ASIX AX88179 chipset on a modern kernel (6.1+ on Ubuntu 24.04 or Linux Mint 22), standard user-space debugging is a waste of time. Restarting Network Manager or disabling USB autosuspend won't save you.

This isn't a configuration typo. It is a fundamental architectural conflict between a proprietary hardware gimmick and strict Linux kernel module dependencies. Here is the pointer arithmetic behind the USB-C hub crash loop, and how to rewrite the rules.

🧠 The Root Cause: Why Your USB Ethernet Adapter is Dead on Linux

USB network adapters are composite devices, and this specific UGREEN hub exposes exactly how fragile Linux's handling of these configurations can be. Bridging the gap between "broken" and "functional" requires looking at how the drivers interact with the metal.

The Generic Blindness (cdc_ncm): If you let the system default to the generic Linux standard driver, it connects without throwing kernel panics. But the connection is a ghost. Run ethtool and you get Speed: Unknown!. The generic driver assumes the hardware is smart enough to power on its own Physical Layer (PHY). It isn't. ASIX chips are built cheap; they sit in the dark, waiting for the OS to send a proprietary wake-up command. The generic driver doesn't know the command, so the hardware stays asleep.
The Interrupt Storm (ax88179_178a): Force the native Linux driver, and the kernel immediately spits out -110 (Timeout) and -32 (Broken Pipe) errors, entering an infinite Ethernet crash loop. Here is the punchline: The UGREEN UNO features a "Smart LED Emoji Face." That LCD is driven by an internal microcontroller that constantly spams the USB bus with interrupt polling requests to sync its animations. When the native Linux driver tries to execute a simple read of the Ethernet chip's MAC address, it gets drowned in this hidden hardware interrupt storm. The driver times out, panics, forcefully drops the connection, and the cycle repeats.

🛠️ The Fix: Compiling the Official ASIX Linux Driver via DKMS

To actually fix this Gigabit Ethernet adapter issue, we have to abandon the broken in-tree modules. We force the hardware into its native configuration, compile the official ASIX driver from source, and cryptographically sign it to bypass Secure Boot.

Step 1: Automating the Fetch

Install the compilation toolchain, bypass the web portal, and drop the source code into a staging directory.

# Install the required Linux headers and compilation toolchain
sudo apt-get update
sudo apt-get install -y dkms build-essential linux-headers-$(uname -r) git curl wget

# Pull the latest official ASIX AX88179 Linux driver and extract it
curl -sL https://www.asix.com.tw/en/product/USBEthernet/Super-Speed_USB_Ethernet/AX88179A | grep -A 10 'Linux kernel' | grep -oP 'data-href="\K[^"]+' | head -n 1 | xargs -I {} wget -O /tmp/ax88179a_linux.tar.bz2 {}

# Extract into a properly named staging directory
sudo mkdir -p /usr/src/ax_usb_nic-4.0.0
sudo tar -xf /tmp/ax88179a_linux.tar.bz2 -C /usr/src/ax_usb_nic-4.0.0 --strip-components=1

Step 2: Arbitration and Blacklists

We need udev rules to block the generic driver, and blacklists to suppress the broken in-tree driver. The ASIX Makefile handles this device arbitration for us.

cd /usr/src/ax_usb_nic-4.0.0

# Install ASIX udev rules and hardware blacklists
sudo make udev_install
sudo make blacklist_install

# Purge the conflicting network modules from active memory
sudo modprobe -r ax88179_178a cdc_ncm cdc_ether cdc_mbim

# Rebuild the boot image so the kernel respects the blacklist on the next boot
sudo update-initramfs -u

Step 3: Compiling via DKMS (Dynamic Kernel Module Support)

Running a standard make install is how you break your internet connection the next time apt updates your Ubuntu kernel. We use DKMS so the custom driver recompiles itself automatically during system updates.

# Patch the Makefile for DKMS compatibility
sudo sed -i 's/TARGET = ax88179_178a/TARGET = ax_usb_nic/g' /usr/src/ax_usb_nic-4.0.0/Makefile

# Generate the DKMS config file
sudo bash -c 'cat > /usr/src/ax_usb_nic-4.0.0/dkms.conf <<EOF
PACKAGE_NAME="ax_usb_nic"
PACKAGE_VERSION="4.0.0"
CLEAN="make clean"
MAKE="make KERNELRELEASE=\$kernelver"
BUILT_MODULE_NAME="ax_usb_nic"
DEST_MODULE_LOCATION="/updates/dkms"
AUTOINSTALL="yes"
EOF'

# Build and install the ASIX driver
sudo dkms add -m ax_usb_nic -v 4.0.0
sudo dkms build -m ax_usb_nic -v 4.0.0
sudo dkms install -m ax_usb_nic -v 4.0.0

Step 4: Bypassing the Secure Boot Bouncer

If Secure Boot is enforcing signatures in your BIOS, the kernel will block your custom driver (Key was rejected by service). Because we used DKMS, the system generated a Machine Owner Key (MOK). We need to inject that cryptographic signature into the newly compiled binary.

# Sign the new module with the DKMS key
sudo kmodsign sha512 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der $(modinfo -n ax_usb_nic)

# Force the Linux kernel to load the signed driver
sudo modprobe ax_usb_nic

📝 System Status

Unplug the UGREEN hub. Wait five seconds for the hardware capacitors to drain. Plug it back in.

Run ethtool enx... using your specific predictable interface name. The interface powers up the PHY cleanly, bypassing the LCD interrupt storm. You will see Speed: 1000Mb/s alongside Link detected: yes.

No magic code. Just a resilient networking stack engineered to survive the next Linux kernel update.

From npm install to insmod: My Journey into Linux Kernel Module

Fauzan Febriansyah — Tue, 23 Dec 2025 04:38:31 +0000

For a long time, I treated the OS as a black box. I knew how to write APIs in NestJS, but I had no idea how the server actually listened to a port. That changed when I joined the CusDeb Operating System Camp.

The goal was simple: stop relying on high-level abstractions and understand the machine. I wanted to move from just being a user of the OS to an engineer who could build inside it.

Here is what I learned when I finally broke the "Black Box" and accepted a challenge from an AI to build a self-destructing kernel module.

1. The Kernel is just an Express.js App

When I first looked at a Character Device Driver, I was overwhelmed by structs and pointers. But then I realized: The Kernel is just a Server.

Coming from web development, I mapped the concepts, and suddenly, the "magic" disappeared:

The Port (alloc_chrdev_region): You reserve a Major/Minor number. This is just like opening port 80. The Kernel needs to know where to route traffic.
The Server (cdev_init): This is effectively app.listen(). It tells the Kernel to start accepting traffic for your specific Device ID.
The Controller (file_operations): This is where your business logic lives. When a user runs cat /dev/mydevice, the Kernel routes it to your .read function.
The Response (copy_to_user): You can't just return json. You have to manually copy bytes across the boundary to the client.

Once I treated the Kernel as an API, I stopped fearing the C code.

2. The Challenger: Gemini 3.0

The CusDeb Camp gave me the foundation, how to build the kernel and run User-Mode Linux (UML). But I didn't want to just copy-paste a "Hello World."

I asked my AI thought partner, Gemini 3.0, for a "Boss Fight." I told it: "Don't give me code. Give me a problem."

It gave me The VoidBox.

The Spec:

Read-Once: A secure drop-box. Users write secrets in.
Incinerate: When read, the data is returned to User Space and immediately zeroed out in Kernel Memory.
Thread-Safe: Use mutex to prevent race conditions.

This wasn't a tutorial. This was a specification sheet.

3. The Holy Trinity of Kernel Hacking

Building the VoidBox forced me to confront three things I usually ignore in TypeScript.

The Boundary (User vs. Kernel)

In JS, variables are just variables. In Kernel space, you never trust a pointer from User Space.

You cannot access the user's buffer directly. You must use copy_from_user and copy_to_user. If you try to dereference a user pointer directly, you might crash the system.

Concurrency is Manual

In Node.js, we are spoiled by the single-threaded Event Loop. We rarely worry about two requests modifying a variable at the exact same nanosecond.

In the Kernel, that protection is gone. If two processes try to write to /dev/voidbox simultaneously, they will corrupt the memory.

I had to implement a mutex lock.

mutex_lock(&void_device.lock);
// ... Critical Section ...
// Copy data, update length
mutex_unlock(&void_device.lock);

If I didn't lock it, the memory will be corrupted.

The "Filesystem" is a Lie

/dev/voidbox looks like a file. You can echo into it. You can cat it. But it's not a file. It's a stream.

I learned the hard way that if you don't manually update the cursor position (*ppos), the cat command will read forever, looping your data infinitely until you kill the process.

4. The Logic: Self-Destructing Memory

The logic I wrote was ruthless.

The Write: I checked if the box was full. If it was, I returned -EBUSY. I threw an I/O Error on purpose because this is a secure box. No overwriting allowed.

The Read: I first checked whether any data existed. If it did, I copied the data to user space, then immediately incinerated it void_device.data[0] = '\0'; and reset the stored length to 0, enforcing strict read-once semantics.

The screenshot above shows the result. I wrote "NUS Msc..." into the void. I read it once. I tried to read it again, and it was gone. Total erasure.

Conclusion

I am still a "wannabe" Systems Engineer. My Makefile is messy, and the pointers still scare me.

But the "Black Box" is open. I know that insmod isn't magic, it's just loading a library. I know that cat isn't just reading a file, it's triggering a driver function.

If you are a web developer, stop fearing the low level. Spin up a User-Mode Linux instance and break things. It's the only way to see how the machine actually works.

If you want to check my messy code, here is the repo: github.com/fauzanfebrian/linux-kernel-hacking

From NestJS to malloc: My Nightly Battle with Memory

Fauzan Febriansyah — Tue, 09 Dec 2025 03:47:18 +0000

By day, I am a Software Engineer. I build scalable systems using TypeScript and NestJS. I am used to Garbage Collectors and strict typing that only exists before compilation.

By night, I leave that comfort zone. I am on a mission to understand First Principles. I want to stop being just a coder and become a Systems Engineer.

I used to be ignorant about memory. I thought, "Who cares? Hardware is cheap.". I was wrong. Here is what I learned when I stopped relying on abstractions and started looking at the raw bytes.

1. Memory Padding: Your Data is Wasting Space

In TypeScript, we don't care how an object is stored. In C, if you don't care, you pay the price.

Look at this struct:

typedef struct {
    char a;   // 1 byte
    double b; // 8 bytes
    int c;    // 4 bytes
} Point;

How big is this? Math says 1 + 8 + 4 = 13 bytes. If you say 13, you are wrong. The answer is 24 bytes.

Why? Because the CPU is picky, it fetches data in aligned chunks (usually 8 bytes), it cannot grab that double easily if it is stuck between two chunks. So, the compiler adds an invisible padding, empty bytes to align it.

In this simple struct, we wasted 11 bytes just for padding. I learned that just by reordering the struct (putting int before double), I could reduce the padding to only 3 bytes. High-level languages hide this from you. C forces you to see it.

2. "Don't Reinvent the Wheel" is Bad Advice

People say: Never rewrite the standard library. I say: Rewrite it, or you will never understand how it works.

I spent days rebuilding realloc and memcpy from scratch. You think you understand Dynamic Memory Allocation? You don't. Not until you manually calculate byte size, malloc a new block, loop through the old block to copy bytes one by one, and then free the old pointer.

If you only use the built-in functions, you are just a consumer, not an engineer.

3. The Paradox: Why "One Loop" is Slower than "Two Loops"

This was a hard lesson for me. I had a challenge: remove duplicates from an array. My first attempt was simple: "I want to be efficient. I will do it in one pass."

Loop through the array.
If I find a unique item, use realloc to grow the array and add it.

It sounded smart. But actually, it was garbage.

The Problem: realloc is expensive. Very expensive. It often has to find a new memory block, copy everything to the new place, and delete the old one. My "efficient" loop was triggering heavy memory operations constantly.

The Better Way (Instructor's Method):

Loop once just to count the unique items.
malloc once with the exact size.
Loop again to fill it.

Iterating twice is actually faster here.

Think about packing a suitcase. My way was: put one sock in a small bag. Bag is full? Buy a bigger bag, move the sock, add a shirt. Bag is full? Buy a bigger bag... The better way: Lay everything on the floor. See exactly how big it is. Buy the right suitcase once. Pack it.

4. Pointers to Pointers (The Real Headache)

You think pointers are hard? Try ***ptr (Pointer to Pointer to Pointer).
I struggled with this when trying to allocate 2D arrays by reference. I kept getting "Segmentation Faults" because I was writing *(ref[i]) instead of (*ref)[i]. The brackets matter.

But you need this. It simplifies memory management. If you want to swap rows in a matrix, you don't move the values. You just swap the pointers using an XOR operation. It is cleaner and faster.

5. Discipline Over Syntax

I finished this learning phase by building a School Management System.
The code wasn't complex. The logic was standard. The hard part was the discipline.

Every malloc needs a free.
If I remove a Student from a Course, I must update the Average Grade immediately.
No memory leaks allowed.

In NestJS, I structure my code to be readable. In C, I structure my data to survive.

Conclusion

I am still a "wannabe" Systems Engineer. My code is not perfect. My repo is just a "scratchpad", no documentation, just raw learning.

But at least now, I am not ignorant. I know what happens under the hood.

If you want to check my journey or laugh at my code, here is the repo: github.com/fauzanfebrian/c-memory-playground