diff --git a/404.html b/404.html index e2596c5..df0401a 100644 --- a/404.html +++ b/404.html @@ -4,4 +4,4 @@ 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/about/index.html b/about/index.html index ba1bede..22a7e90 100644 --- a/about/index.html +++ b/about/index.html @@ -4,4 +4,4 @@ 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/categories/index.html b/categories/index.html index 38ea517..ee7ffad 100644 --- a/categories/index.html +++ b/categories/index.html @@ -4,4 +4,4 @@ 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/index.html b/index.html index 63a452d..2013590 100644 --- a/index.html +++ b/index.html @@ -4,4 +4,4 @@ 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/index.xml b/index.xml index 672ce94..9127723 100644 --- a/index.xml +++ b/index.xml @@ -1,4 +1,25 @@ -Eric X. Liu's Personal Page/Recent content on Eric X. Liu's Personal PageHugoenThu, 02 Oct 2025 07:22:54 +0000UniFi VLAN Migration to Zone-Based Architecture/posts/unifi-vlan-migration-to-zone-based-architecture/Mon, 22 Sep 2025 00:00:00 +0000/posts/unifi-vlan-migration-to-zone-based-architecture/<p>Embarking on a network migration to a properly segmented VLAN architecture is a rite of passage for any serious home lab or small business operator. The goal is clear: improve security and organization by separating traffic. However, the path from a flat network to a segmented one is often paved with subtle but critical configuration details that can lead to hours of frustrating troubleshooting.</p> +Eric X. Liu's Personal Page/Recent content on Eric X. Liu's Personal PageHugoenThu, 02 Oct 2025 08:34:05 +0000Flashing Jetson Orin Nano in Virtualized Environments: A Technical Deep Dive/posts/flashing-jetson-orin-nano-in-virtualized-environments/Thu, 02 Oct 2025 00:00:00 +0000/posts/flashing-jetson-orin-nano-in-virtualized-environments/<h1 id="flashing-jetson-orin-nano-in-virtualized-environments-a-technical-deep-dive"> + Flashing Jetson Orin Nano in Virtualized Environments: A Technical Deep Dive + <a class="heading-link" href="#flashing-jetson-orin-nano-in-virtualized-environments-a-technical-deep-dive"> + <i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"></i> + <span class="sr-only">Link to heading</span> + </a> +</h1> +<h2 id="introduction"> + Introduction + <a class="heading-link" href="#introduction"> + <i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"></i> + <span class="sr-only">Link to heading</span> + </a> +</h2> +<p>Flashing NVIDIA Jetson devices remotely presents unique challenges when the host machine is virtualized. This article documents the technical challenges, failures, and eventual success of flashing a Jetson Orin Nano Super developer kit using NVIDIA SDK Manager in various virtualized environments, specifically focusing on QEMU/KVM virtual machines and LXC containers on Proxmox VE.</p>OpenWrt: Fix WireGuard Connectivity with MWAN3 by Excluding the VPN Endpoint/posts/openwrt-mwan3-wireguard-endpoint-exclusion/Sun, 28 Sep 2025 00:00:00 +0000/posts/openwrt-mwan3-wireguard-endpoint-exclusion/<h3 id="overview"> + Overview + <a class="heading-link" href="#overview"> + <i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"></i> + <span class="sr-only">Link to heading</span> + </a> +</h3> +<p>When using WireGuard together with MWAN3 on OpenWrt, the tunnel can fail to establish or flap when the peer&rsquo;s IP is routed into the tunnel itself. This is a classic routing bootstrap problem: WireGuard wants to route 0.0.0.0/0 into the tunnel, but the UDP packets to the peer&rsquo;s public endpoint also get captured, so they never reach the Internet to bring the tunnel up.</p>UniFi VLAN Migration to Zone-Based Architecture/posts/unifi-vlan-migration-to-zone-based-architecture/Mon, 22 Sep 2025 00:00:00 +0000/posts/unifi-vlan-migration-to-zone-based-architecture/<p>Embarking on a network migration to a properly segmented VLAN architecture is a rite of passage for any serious home lab or small business operator. The goal is clear: improve security and organization by separating traffic. However, the path from a flat network to a segmented one is often paved with subtle but critical configuration details that can lead to hours of frustrating troubleshooting.</p> <p>This article documents that journey. It details the pitfalls encountered, the core networking concepts that were essential to understand, and the best practices that ultimately led to a stable, secure, and logical network design built on a zone-based firewall model.</p>Quantization in LLMs/posts/quantization-in-llms/Tue, 19 Aug 2025 00:00:00 +0000/posts/quantization-in-llms/<p>The burgeoning scale of Large Language Models (LLMs) has necessitated a paradigm shift in their deployment, moving beyond full-precision floating-point arithmetic towards lower-precision representations. Quantization, the process of mapping a wide range of continuous values to a smaller, discrete set, has emerged as a critical technique to reduce model size, accelerate inference, and lower energy consumption. This article provides a technical overview of quantization theories, their application in modern LLMs, and highlights the ongoing innovations in this domain.</p>Breville Barista Pro Maintenance/posts/breville-barista-pro-maintenance/Sat, 16 Aug 2025 00:00:00 +0000/posts/breville-barista-pro-maintenance/<p>Proper maintenance is critical for the longevity and performance of a Breville Barista Pro espresso machine. Consistent cleaning not only ensures the machine functions correctly but also directly impacts the quality of the espresso produced. This guide provides a detailed, technical breakdown of the essential maintenance routines, from automated cycles to daily upkeep.</p> <h4 id="understanding-the-two-primary-maintenance-cycles"> <strong>Understanding the Two Primary Maintenance Cycles</strong> diff --git a/posts/breville-barista-pro-maintenance/index.html b/posts/breville-barista-pro-maintenance/index.html index 0b77105..9644979 100644 --- a/posts/breville-barista-pro-maintenance/index.html +++ b/posts/breville-barista-pro-maintenance/index.html @@ -25,4 +25,4 @@ Understanding the Two Primary Maintenance Cycles Link to heading The Breville Ba 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/espresso-theory-application-a-guide-for-the-breville-barista-pro/index.html b/posts/espresso-theory-application-a-guide-for-the-breville-barista-pro/index.html index 406b53e..a790847 100644 --- a/posts/espresso-theory-application-a-guide-for-the-breville-barista-pro/index.html +++ b/posts/espresso-theory-application-a-guide-for-the-breville-barista-pro/index.html @@ -20,4 +20,4 @@ Our overarching philosophy is simple: isolate and change only one variable at a 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/flashing-jetson-orin-nano-in-virtualized-environments/index.html b/posts/flashing-jetson-orin-nano-in-virtualized-environments/index.html new file mode 100644 index 0000000..a415931 --- /dev/null +++ b/posts/flashing-jetson-orin-nano-in-virtualized-environments/index.html @@ -0,0 +1,171 @@ +Flashing Jetson Orin Nano in Virtualized Environments: A Technical Deep Dive · Eric X. Liu's Personal Page

Flashing Jetson Orin Nano in Virtualized Environments: A Technical Deep Dive

+ +11-minute read

Flashing Jetson Orin Nano in Virtualized Environments: A Technical Deep Dive + +Link to heading

Introduction + +Link to heading

Flashing NVIDIA Jetson devices remotely presents unique challenges when the host machine is virtualized. This article documents the technical challenges, failures, and eventual success of flashing a Jetson Orin Nano Super developer kit using NVIDIA SDK Manager in various virtualized environments, specifically focusing on QEMU/KVM virtual machines and LXC containers on Proxmox VE.

S3 File

The Constraint: Hypervisor-Only Infrastructure + +Link to heading

This project operated under a specific constraint: the only available x86_64 machines were homelab servers running Proxmox VE as bare-metal hypervisors. There was no x86 laptop available, and the primary workstation was an Apple M4 Mac (ARM64 architecture incompatible with SDK Manager).

Installing SDK Manager directly on the Proxmox host OS was explicitly ruled out for several reasons:

  1. Hypervisor Stability: The Proxmox hosts run critical infrastructure (Kubernetes clusters, Ceph storage, network services). Installing development tools and potentially conflicting dependencies directly on the hypervisor risks system stability.

  2. Dependency Conflicts: SDK Manager requires numerous dependencies (QEMU, specific Python versions, USB libraries) that could conflict with Proxmox’s carefully managed package versions.

  3. Clean Separation: Best practices dictate keeping hypervisor hosts minimal, with all workloads running in VMs or containers. This separation simplifies maintenance, updates, and disaster recovery.

  4. Repeatability: A solution confined to a VM or container can be easily replicated, backed up, and destroyed without affecting the host system.

This constraint made the flashing process significantly more complex, as it required finding a virtualization method that could reliably handle the Jetson’s USB communication requirements without installing anything on the Proxmox host beyond standard virtualization features.

Background: Jetson Flashing Requirements + +Link to heading

NVIDIA Jetson devices use a specialized flashing process that requires:

  1. USB Connection: The device must be connected in Force Recovery Mode (APX mode, USB ID 0955:7523)
  2. Initrd Flash Method: Modern Jetson devices boot a temporary Linux kernel over USB (0955:7035) that establishes USB networking
  3. USB Network Communication: The host system must establish network connectivity (typically 192.168.55.1 or IPv6 fc00:1:1::1) with the Jetson during the flash process
  4. SDK Manager: NVIDIA’s SDK Manager orchestrates the entire process, requiring specific kernel modules and capabilities

The initrd flash method is particularly sensitive to timing and USB device handling, making it challenging in virtualized environments.

MethodUSB PassthroughNetwork NamespaceTiming SensitivityResult
QEMU VM (device-level)EmulatedVM-isolatedHigh latency❌ Failed (USB timeout)
LXC ContainerHost devicesHost namespaceNear-native❌ Failed (network isolation)
QEMU VM (PCI-level)Direct hardwareVM-isolatedNative✅ Success

First Attempt: QEMU/KVM Virtual Machine with USB Passthrough + +Link to heading

Configuration + +Link to heading

Given the constraint of not having an x86 laptop, initial attempts used a QEMU/KVM virtual machine running Ubuntu 22.04 x86_64 on an Apple M4 Mac via UTM (a QEMU frontend for macOS). This approach allowed running SDK Manager on an emulated x86_64 system while connecting the Jetson device via USB passthrough configured through UTM’s USB settings.

While this satisfied the requirement of having an x86_64 environment without using the Proxmox hosts, it introduced additional virtualization overhead as the entire x86_64 instruction set was being emulated on ARM64 hardware.

Issues Encountered + +Link to heading

The flash process consistently failed during the USB communication phase with the error:

ERROR: might be timeout in USB write.
+

Root Cause Analysis + +Link to heading

QEMU/KVM’s USB passthrough implementation has known reliability issues with complex USB protocols. The Jetson’s initrd flash process requires:

  1. Rapid USB re-enumeration when switching between recovery mode and initrd mode
  2. High-throughput data transfer for writing the root filesystem
  3. Bidirectional USB network communication with strict timing requirements

Individual USB device passthrough in QEMU emulates USB at the device level, introducing latency and potential timing issues. The Jetson’s USB networking during initrd boot is particularly sensitive to these delays, causing the timeout errors.

Conclusion + +Link to heading

This approach was abandoned due to fundamental limitations in QEMU’s USB emulation layer. USB passthrough at the device level is insufficient for the Jetson flash process.

Second Attempt: LXC Container on Proxmox + +Link to heading

Rationale + +Link to heading

After the Mac-based VM approach failed, attention shifted to the Proxmox infrastructure. LXC containers provide near-native performance with minimal virtualization overhead compared to full VMs. Unlike running SDK Manager directly on the Proxmox host (which was ruled out for stability reasons), an LXC container offers:

  1. Isolation: Complete separation from the host OS with its own filesystem and process space
  2. Near-Native Performance: Containers share the host kernel, eliminating instruction emulation overhead
  3. Easy Management: Containers can be created, destroyed, and backed up without affecting the host
  4. USB Access: Proxmox supports passing USB devices to containers via cgroup device permissions

The hypothesis was that an LXC container with proper USB device access would provide the necessary USB timing characteristics while maintaining the clean separation requirement.

Configuration Progression + +Link to heading

The LXC container (ID 106, Ubuntu 22.04) required extensive configuration on the Proxmox host (/etc/pve/lxc/106.conf):

# Enable mknod capability for creating device nodes
+features: nesting=1,mknod=1
+
+# USB device passthrough (Bus 003)
+lxc.cgroup2.devices.allow: c 189:* rwm
+lxc.mount.entry: /dev/bus/usb/003 dev/bus/usb/003 none bind,optional,create=dir 0 0
+
+# Loop device access for mounting disk images
+lxc.cgroup2.devices.allow: b 7:* rwm
+lxc.mount.entry: /dev/loop0 dev/loop0 none bind,optional,create=file 0 0
+lxc.mount.entry: /dev/loop1 dev/loop1 none bind,optional,create=file 0 0
+# ... (loop2-7)
+lxc.mount.entry: /dev/loop-control dev/loop-control none bind,optional,create=file 0 0
+

Issues Encountered and Resolutions + +Link to heading

1. mknod Permission Errors + +Link to heading

Error: mknod: .../rootfs/dev/random: Operation not permitted

Cause: LXC containers lack CAP_MKNOD capability by default, required by L4T flash scripts to create device nodes in the rootfs.

Solution: Enable mknod=1 feature on the Proxmox host:

pct set 106 -features nesting=1,mknod=1
+

2. ARM64 Binary Execution + +Link to heading

Error: chroot: failed to run command 'dpkg': Exec format error

Cause: The L4T rootfs contains ARM64 binaries that cannot execute on x86_64 without emulation.

Solution: Install and enable qemu-user-static and binfmt-support on the Proxmox host (not the container):

apt-get install qemu-user-static binfmt-support
+update-binfmts --enable qemu-aarch64
+

3. Loop Device Access + +Link to heading

Error: losetup: cannot find an unused loop device

Cause: The L4T flash scripts use loop devices to mount disk images. LXC containers don’t have loop device access by default.

Solution: Add loop device permissions and mount entries to the container configuration.

4. USB Networking Failure + +Link to heading

Error: Device failed to boot to the initrd flash kernel

Cause: This was the most complex issue. When the Jetson boots into initrd mode (0955:7035), it creates a USB network interface (enx* or usb0). However, in LXC containers, this interface appeared in the host’s network namespace, not the container’s namespace.

Attempted Solution:

  1. Loaded USB networking kernel modules on the Proxmox host:
modprobe rndis_host cdc_ether cdc_ncm cdc_subset
+echo "rndis_host" >> /etc/modules
+echo "cdc_ether" >> /etc/modules
+echo "cdc_ncm" >> /etc/modules
+echo "cdc_subset" >> /etc/modules
+
  1. Created udev rules to automatically move USB network interfaces to the container:
# /etc/udev/rules.d/99-jetson-usb-network.rules
+ACTION=="add", SUBSYSTEM=="net", KERNEL=="enx*", RUN+="/usr/local/bin/handle-jetson-usb-network.sh %k"
+
  1. Created handler script to move interfaces into container namespace:
#!/bin/bash
+INTERFACE=$1
+CONTAINER_ID=106
+CONTAINER_PID=$(pct exec $CONTAINER_ID -- pidof systemd | awk '{print $1}')
+ip link set "$INTERFACE" netns "ct$CONTAINER_ID"
+pct exec $CONTAINER_ID -- ip link set dev $INTERFACE up
+pct exec $CONTAINER_ID -- dhclient $INTERFACE
+

Fundamental LXC Limitation + +Link to heading

Despite all configuration efforts, the LXC container could not properly handle USB network interfaces due to network namespace isolation. LXC containers have separate network namespaces from the host, and moving USB network interfaces between namespaces proved unreliable and often failed to establish proper connectivity.

The initrd flash process has strict timing requirements:

  1. Jetson boots into initrd mode
  2. USB network interface must appear and be configured within seconds
  3. SSH connection must establish for flash commands

Even when the interface was successfully moved to the container’s namespace, DHCP configuration often failed, causing the flash process to timeout.

Conclusion + +Link to heading

LXC containers, despite their near-native performance, have fundamental limitations for this use case due to network namespace isolation. USB networking devices created dynamically during the flash process cannot be reliably handled.

Final Solution: Proxmox VM with PCI USB Controller Passthrough + +Link to heading

Architecture Change + +Link to heading

With both the Mac-based VM (due to QEMU USB emulation issues) and the LXC container (due to network namespace isolation) ruled out, the final approach combined the best aspects of both previous attempts while working within the Proxmox infrastructure constraint:

  1. Use a VM (not a container) to provide proper network namespace isolation for USB networking
  2. Pass through the entire USB controller at the PCI level (not individual USB devices) to eliminate emulation overhead and any potential timing issues
  3. Keep the host OS clean by running SDK Manager only within the disposable VM

This approach leverages Proxmox’s PCI passthrough capability—a feature designed exactly for scenarios where VMs need direct hardware access without installing drivers or tools on the hypervisor host.

Implementation + +Link to heading

1. Identify USB Controller + +Link to heading

# Find which USB controller the Jetson is connected to
+lsusb -t | grep -B5 "0955:7523"
+
+# Map USB buses to PCI addresses
+for bus in {1..8}; do
+    pci=$(readlink /sys/bus/usb/devices/usb$bus 2>/dev/null | grep -oE '[0-9a-f]{4}:[0-9a-f]{2}:[0-9a-f]{2}\.[0-9]')
+    echo "USB Bus $bus → PCI $pci"
+done
+

Result: Jetson on Bus 4, controlled by PCI device 0000:22:00.3

Verification that no other critical devices shared this controller:

lsusb | grep "Bus 003"  # Empty except root hub
+lsusb | grep "Bus 004"  # Only Jetson device
+

2. Create VM with PCI Passthrough + +Link to heading

# Create VM
+qm create 200 --name jetson-flash --memory 4096 --cores 4 \
+    --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci
+
+# Set machine type to q35 (required for PCIe passthrough)
+qm set 200 --machine q35
+
+# Import Ubuntu cloud image
+qm importdisk 200 ubuntu-22.04-server-cloudimg-amd64.img local-lvm
+
+# Configure disk and cloud-init
+qm set 200 --scsi0 local-lvm:vm-200-disk-0 --boot order=scsi0 \
+    --ide2 local-lvm:cloudinit
+
+# Configure cloud-init
+qm set 200 --ciuser sdkmanager --cipassword sdkmanager \
+    --ipconfig0 ip=dhcp --sshkeys ~/.ssh/authorized_keys
+
+# Add PCI passthrough for USB controller
+qm set 200 --hostpci0 0000:22:00.3,pcie=1
+
+# Resize disk for JetPack installation
+qm resize 200 scsi0 +30G
+
+# Start VM
+qm start 200
+

3. Critical: USB Networking Kernel Modules + +Link to heading

The Ubuntu cloud image does not include USB networking kernel modules by default. This is critical because when the Jetson boots into initrd mode, it requires the host to have these modules loaded immediately.

Solution: Install and load modules before starting the flash:

# Install extra kernel modules
+apt-get install linux-modules-extra-$(uname -r)
+
+# Load USB networking modules
+modprobe rndis_host
+modprobe cdc_ether
+modprobe cdc_ncm
+modprobe cdc_subset
+
+# Verify modules loaded
+lsmod | grep -E 'rndis|cdc'
+

When the Jetson transitions to initrd mode (0955:7035), the USB network interface (usb0) now appears immediately in the VM’s network namespace.

4. Network Configuration + +Link to heading

The Jetson’s initrd uses IPv6 for USB networking by default:

# Interface appears automatically
+ip addr show usb0
+# Output:
+# usb0: inet6 fc00:1:1::1/64 scope global
+
+# Test connectivity
+ping6 -c 3 fc00:1:1:0::2  # Jetson's IPv6 address
+

The SDK Manager automatically detects and uses IPv6 connectivity for SSH and flash operations.

Flash Process Timeline + +Link to heading

  1. 07:49:38 - Flash component started, 30-second pre-check wait
  2. 07:50:12 - Board detected as jetson-orin-nano-devkit-super
  3. 07:51:25 - System image created (rootfs populated)
  4. 07:52:24 - Converting to sparse image format
  5. 07:54:54 - Device rebooted into initrd mode (0955:7035)
  6. 07:55:05 - USB network interface usb0 appeared immediately
  7. 07:55:16 - SSH connection established via IPv6
  8. 07:55:16-07:59:05 - QSPI flash (boot firmware) written
  9. 07:59:05-08:00:28 - eMMC flash (system partitions) written
  10. 08:00:28 - Flash successful, device rebooted to normal mode (0955:7020)
  11. 08:00:28-08:02:58 - First-boot auto-configuration
  12. 08:03:00 - Installation completed successfully

Total flash time: ~13 minutes

Why PCI Passthrough Succeeded + +Link to heading

  1. Direct Hardware Access: The VM has complete control over the USB controller with no emulation layer
  2. Timing Precision: USB protocol timing is maintained at hardware level
  3. Network Namespace: The VM’s network stack directly handles USB network interfaces
  4. No Virtualization Overhead: USB transactions happen at native speed

Key Lessons Learned + +Link to heading

  1. USB Device Passthrough vs Controller Passthrough: Passing through individual USB devices adds emulation overhead. PCI-level controller passthrough provides native hardware access.

  2. LXC Network Namespace Limitations: LXC containers cannot reliably handle dynamically created USB network interfaces due to network namespace isolation. Even with udev rules to move interfaces, timing and configuration issues persist.

  3. Kernel Module Requirements: USB networking kernel modules must be loaded before the Jetson enters initrd mode. Cloud images and minimal installations often lack these modules.

  4. IPv6 Support: Modern Jetson initrd images prefer IPv6 for USB networking. Ensure the host system has IPv6 enabled and properly configured.

  5. Timing Sensitivity: The Jetson’s initrd flash process has strict timing requirements. USB network interfaces must appear and be configured within seconds of the mode transition.

  6. PCI Passthrough Machine Type: QEMU/KVM requires q35 machine type for PCIe device passthrough. The default i440fx machine type does not support it.

Recommendations + +Link to heading

For flashing Jetson devices in production or automated environments:

  1. Use PCI USB Controller Passthrough: If virtualization is required, pass through the entire USB controller at the PCI level to a VM.

  2. Pre-load USB Networking Modules: Ensure rndis_host, cdc_ether, cdc_ncm, and cdc_subset kernel modules are loaded before starting the flash process.

  3. Verify USB Controller Isolation: Before passthrough, ensure no other critical devices share the USB controller.

  4. Use Physical Machines When Possible: For development and testing, a physical Linux machine provides the most reliable flashing experience.

  5. Monitor USB Device Transitions: Use lsusb and dmesg to monitor device state transitions:

    • 0955:7523 = Recovery mode (APX)
    • 0955:7035 = Initrd flash mode
    • 0955:7020 = Normal operation mode

References + +Link to heading

\ No newline at end of file diff --git a/posts/how-rvq-teaches-llms-to-see-and-hear/index.html b/posts/how-rvq-teaches-llms-to-see-and-hear/index.html index f4954cc..cbe97be 100644 --- a/posts/how-rvq-teaches-llms-to-see-and-hear/index.html +++ b/posts/how-rvq-teaches-llms-to-see-and-hear/index.html @@ -18,4 +18,4 @@ The answer lies in creating a universal language—a bridge between the continuo 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/index.html b/posts/index.html index cfc6b46..eb0276b 100644 --- a/posts/index.html +++ b/posts/index.html @@ -1,6 +1,8 @@ Posts · Eric X. Liu's Personal Page

Posts

Posts

\ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/index.xml b/posts/index.xml index 3cadf97..885ec7d 100644 --- a/posts/index.xml +++ b/posts/index.xml @@ -1,4 +1,25 @@ -Posts on Eric X. Liu's Personal Page/posts/Recent content in Posts on Eric X. Liu's Personal PageHugoenThu, 02 Oct 2025 07:22:54 +0000UniFi VLAN Migration to Zone-Based Architecture/posts/unifi-vlan-migration-to-zone-based-architecture/Mon, 22 Sep 2025 00:00:00 +0000/posts/unifi-vlan-migration-to-zone-based-architecture/<p>Embarking on a network migration to a properly segmented VLAN architecture is a rite of passage for any serious home lab or small business operator. The goal is clear: improve security and organization by separating traffic. However, the path from a flat network to a segmented one is often paved with subtle but critical configuration details that can lead to hours of frustrating troubleshooting.</p> +Posts on Eric X. Liu's Personal Page/posts/Recent content in Posts on Eric X. Liu's Personal PageHugoenThu, 02 Oct 2025 08:34:05 +0000Flashing Jetson Orin Nano in Virtualized Environments: A Technical Deep Dive/posts/flashing-jetson-orin-nano-in-virtualized-environments/Thu, 02 Oct 2025 00:00:00 +0000/posts/flashing-jetson-orin-nano-in-virtualized-environments/<h1 id="flashing-jetson-orin-nano-in-virtualized-environments-a-technical-deep-dive"> + Flashing Jetson Orin Nano in Virtualized Environments: A Technical Deep Dive + <a class="heading-link" href="#flashing-jetson-orin-nano-in-virtualized-environments-a-technical-deep-dive"> + <i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"></i> + <span class="sr-only">Link to heading</span> + </a> +</h1> +<h2 id="introduction"> + Introduction + <a class="heading-link" href="#introduction"> + <i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"></i> + <span class="sr-only">Link to heading</span> + </a> +</h2> +<p>Flashing NVIDIA Jetson devices remotely presents unique challenges when the host machine is virtualized. This article documents the technical challenges, failures, and eventual success of flashing a Jetson Orin Nano Super developer kit using NVIDIA SDK Manager in various virtualized environments, specifically focusing on QEMU/KVM virtual machines and LXC containers on Proxmox VE.</p>OpenWrt: Fix WireGuard Connectivity with MWAN3 by Excluding the VPN Endpoint/posts/openwrt-mwan3-wireguard-endpoint-exclusion/Sun, 28 Sep 2025 00:00:00 +0000/posts/openwrt-mwan3-wireguard-endpoint-exclusion/<h3 id="overview"> + Overview + <a class="heading-link" href="#overview"> + <i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"></i> + <span class="sr-only">Link to heading</span> + </a> +</h3> +<p>When using WireGuard together with MWAN3 on OpenWrt, the tunnel can fail to establish or flap when the peer&rsquo;s IP is routed into the tunnel itself. This is a classic routing bootstrap problem: WireGuard wants to route 0.0.0.0/0 into the tunnel, but the UDP packets to the peer&rsquo;s public endpoint also get captured, so they never reach the Internet to bring the tunnel up.</p>UniFi VLAN Migration to Zone-Based Architecture/posts/unifi-vlan-migration-to-zone-based-architecture/Mon, 22 Sep 2025 00:00:00 +0000/posts/unifi-vlan-migration-to-zone-based-architecture/<p>Embarking on a network migration to a properly segmented VLAN architecture is a rite of passage for any serious home lab or small business operator. The goal is clear: improve security and organization by separating traffic. However, the path from a flat network to a segmented one is often paved with subtle but critical configuration details that can lead to hours of frustrating troubleshooting.</p> <p>This article documents that journey. It details the pitfalls encountered, the core networking concepts that were essential to understand, and the best practices that ultimately led to a stable, secure, and logical network design built on a zone-based firewall model.</p>Quantization in LLMs/posts/quantization-in-llms/Tue, 19 Aug 2025 00:00:00 +0000/posts/quantization-in-llms/<p>The burgeoning scale of Large Language Models (LLMs) has necessitated a paradigm shift in their deployment, moving beyond full-precision floating-point arithmetic towards lower-precision representations. Quantization, the process of mapping a wide range of continuous values to a smaller, discrete set, has emerged as a critical technique to reduce model size, accelerate inference, and lower energy consumption. This article provides a technical overview of quantization theories, their application in modern LLMs, and highlights the ongoing innovations in this domain.</p>Breville Barista Pro Maintenance/posts/breville-barista-pro-maintenance/Sat, 16 Aug 2025 00:00:00 +0000/posts/breville-barista-pro-maintenance/<p>Proper maintenance is critical for the longevity and performance of a Breville Barista Pro espresso machine. Consistent cleaning not only ensures the machine functions correctly but also directly impacts the quality of the espresso produced. This guide provides a detailed, technical breakdown of the essential maintenance routines, from automated cycles to daily upkeep.</p> <h4 id="understanding-the-two-primary-maintenance-cycles"> <strong>Understanding the Two Primary Maintenance Cycles</strong> diff --git a/posts/mixture-of-experts-moe-models-challenges-solutions-in-practice/index.html b/posts/mixture-of-experts-moe-models-challenges-solutions-in-practice/index.html index 82c4c92..ff1fd7c 100644 --- a/posts/mixture-of-experts-moe-models-challenges-solutions-in-practice/index.html +++ b/posts/mixture-of-experts-moe-models-challenges-solutions-in-practice/index.html @@ -44,4 +44,4 @@ The Top-K routing mechanism, as illustrated in the provided ima 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/openwrt-mwan3-wireguard-endpoint-exclusion/index.html b/posts/openwrt-mwan3-wireguard-endpoint-exclusion/index.html new file mode 100644 index 0000000..a049336 --- /dev/null +++ b/posts/openwrt-mwan3-wireguard-endpoint-exclusion/index.html @@ -0,0 +1,101 @@ +OpenWrt: Fix WireGuard Connectivity with MWAN3 by Excluding the VPN Endpoint · Eric X. Liu's Personal Page

OpenWrt: Fix WireGuard Connectivity with MWAN3 by Excluding the VPN Endpoint

+ +5-minute read

Overview + +Link to heading

When using WireGuard together with MWAN3 on OpenWrt, the tunnel can fail to establish or flap when the peer’s IP is routed into the tunnel itself. This is a classic routing bootstrap problem: WireGuard wants to route 0.0.0.0/0 into the tunnel, but the UDP packets to the peer’s public endpoint also get captured, so they never reach the Internet to bring the tunnel up.

This article explains the symptoms, root cause, and a minimal, robust fix: add an MWAN3 rule that forces traffic to the WireGuard peer endpoint IP to go out via a physical WAN policy (not the tunnel). Optionally, assign a metric to the WireGuard interface to keep tables predictable.

Environment + +Link to heading

  • OpenWrt 24.10.x
  • MWAN3 for multi-WAN policy routing
  • WireGuard interface configured with broad allowed_ips covering default route (0.0.0.0/1 and 128.0.0.0/1 or 0.0.0.0/0)

Symptoms + +Link to heading

  • wg show indicates the interface is listening, but transfer: 0 B received persists after bringing the tunnel up.
  • Intermittent reachability to public IPs until routing settles.
  • ip route shows multiple defaults via WANs; a host route to the peer IP may exist but is still overridden by policy routing once MWAN3 applies rules.

Example observations (sanitized):

wg show
+interface: wireguard
+  public key: <redacted>
+  listening port: 39345
+peer: <peer-public-key-redacted>
+  endpoint: 203.0.113.55:51821
+  allowed ips: 0.0.0.0/1, 128.0.0.0/1
+  transfer: 0 B received, 5.6 KiB sent
+
+ip route
+default via 192.0.2.1 dev wan0 proto static src 192.0.2.10
+default via 198.51.100.1 dev wan1 proto static src 198.51.100.10 metric 20
+203.0.113.55 via 198.51.100.1 dev wan1 proto static metric 20
+

Root Cause + +Link to heading

With default-route allowed_ips, WireGuard installs routes so that all outbound traffic prefers the tunnel. MWAN3 then applies policy rules that also match “all traffic,” including the UDP packets to the WireGuard peer’s public IP. If those packets are selected to go via the wireguard interface (or a table whose default is the tunnel), the handshake cannot succeed. This creates a chicken-and-egg dependency.

Fix: Exclude the WireGuard Endpoint from MWAN3 Default Policy + +Link to heading

Force traffic to the WireGuard peer public endpoint to use a physical WAN policy. This guarantees the handshake packets always reach the Internet outside of the tunnel.

Steps:

  1. Resolve the peer endpoint IP (if you only have a hostname)
nslookup vpn.example.com
+# => use the returned A/AAAA address(es) in the rule below
+
  1. Add an MWAN3 rule targeting the endpoint IP

Edit /etc/config/mwan3 and place this rule before the default v4 rule so it takes precedence:

config rule 'wireguard_endpoint'
+    option dest_ip '203.0.113.55'   # peer public IP
+    option proto 'udp'
+    option use_policy 'wan_only'     # a policy that prefers a physical WAN
+    option family 'ipv4'
+

Notes:

  • Use the actual public IP of your WireGuard server. MWAN3 rules match IPs, not hostnames.
  • If you have multiple WAN policies (e.g., wan_only, wphone_only), choose the one that must carry the VPN handshake.
  1. (Optional) Assign a metric on the WireGuard interface

This is not strictly required for the fix but keeps routing behavior deterministic when multiple defaults exist.

Edit /etc/config/network:

config interface 'wireguard'
+    option proto 'wireguard'
+    option private_key '<redacted>'
+    list addresses '192.168.3.2/32'
+    option metric '5'
+
  1. Apply changes
/etc/init.d/network restart && /etc/init.d/mwan3 restart
+

Validation + +Link to heading

Confirm that the endpoint is routed via a physical WAN and that the tunnel is passing traffic.

# Verify policy routing for the endpoint
+ip route get 203.0.113.55
+
+# MWAN3 status should show your WANs online
+mwan3 status | sed -n '1,120p'
+
+# WireGuard should show RX increasing after a few seconds
+wg show
+

Expected results:

  • ip route get <peer-ip> resolves to a physical WAN device/policy, not the wireguard interface.
  • wg show shows non-zero bytes received and a recent handshake time.

Operational Considerations + +Link to heading

  • Endpoint IP changes: If the server endpoint is behind DDNS, you must update the rule when its IP changes. Options include:
    • Use a small script triggered by DDNS updates to modify the MWAN3 rule and reload.
    • Maintain an IP set and populate it from DDNS; match the set in firewall/PBR and keep MWAN3 in sync.
  • IPv6: Repeat the approach with an IPv6 rule if your peer uses IPv6. Ensure family 'ipv6' and the correct policy are set.
  • Multiple peers: Create one rule per peer endpoint IP.
  • Ordering: Keep the endpoint rule above broad default rules so it always wins.

Minimal Example Config Snippets (Sanitized) + +Link to heading

/etc/config/network (relevant parts):

config interface 'wireguard'
+    option proto 'wireguard'
+    option private_key '<redacted>'
+    list addresses '192.168.3.2/32'
+    option metric '5'
+
+config wireguard_wireguard
+    option description 'peer-1'
+    option public_key '<peer-public-key-redacted>'
+    option endpoint_host 'vpn.example.com'
+    option endpoint_port '51821'
+    list allowed_ips '0.0.0.0/1'
+    list allowed_ips '128.0.0.0/1'
+    option route_allowed_ips '1'
+

/etc/config/mwan3 (relevant parts):

config policy 'wan_only'
+    list use_member 'wan_m1_w3'
+    option last_resort 'unreachable'
+
+config rule 'wireguard_endpoint'
+    option dest_ip '203.0.113.55'
+    option proto 'udp'
+    option use_policy 'wan_only'
+    option family 'ipv4'
+
+config rule 'default_rule_v4'
+    option dest_ip '0.0.0.0/0'
+    option use_policy 'wan_only'
+    option family 'ipv4'
+    option proto 'all'
+    option sticky '0'
+

Why This Works + +Link to heading

The explicit MWAN3 rule ensures that traffic to the peer’s public IP bypasses any routes that prefer the tunnel. This breaks the bootstrap loop and guarantees handshake packets traverse a real WAN uplink. Once the tunnel is established, the broad allowed_ips continue to route general traffic through WireGuard as intended.

References + +Link to heading

  • Session log and configs (internal): ~/Downloads/chat-MWAN3 WireGuard Routing Fix 🌐.txt
  • OpenWrt MWAN3 documentation: https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3
  • WireGuard documentation: https://www.wireguard.com/
  • OpenWrt WireGuard (UG): https://openwrt.org/docs/guide-user/services/vpn/wireguard
\ No newline at end of file diff --git a/posts/page/2/index.html b/posts/page/2/index.html index 696a9cc..25f9b13 100644 --- a/posts/page/2/index.html +++ b/posts/page/2/index.html @@ -1,9 +1,11 @@ Posts · Eric X. Liu's Personal Page

Posts

Posts

\ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/ppo-for-language-models/index.html b/posts/ppo-for-language-models/index.html index 2bedbe5..75951ea 100644 --- a/posts/ppo-for-language-models/index.html +++ b/posts/ppo-for-language-models/index.html @@ -25,4 +25,4 @@ where δ_t = r_t + γV(s_{t+1}) - V(s_t)

  • γ (gam 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/quantization-in-llms/index.html b/posts/quantization-in-llms/index.html index bd48f6d..a4c8aaf 100644 --- a/posts/quantization-in-llms/index.html +++ b/posts/quantization-in-llms/index.html @@ -7,4 +7,4 @@ 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/secure-boot-dkms-and-mok-on-proxmox-debian/index.html b/posts/secure-boot-dkms-and-mok-on-proxmox-debian/index.html index a9859bd..dede9c2 100644 --- a/posts/secure-boot-dkms-and-mok-on-proxmox-debian/index.html +++ b/posts/secure-boot-dkms-and-mok-on-proxmox-debian/index.html @@ -59,4 +59,4 @@ nvidia-smi failed to communicate with the NVIDIA driver modprobe nvidia → “K 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/supabase-deep-dive/index.html b/posts/supabase-deep-dive/index.html index 97db3bb..f609804 100644 --- a/posts/supabase-deep-dive/index.html +++ b/posts/supabase-deep-dive/index.html @@ -90,4 +90,4 @@ Supabase enters this space with a radically different philosophy: transparency. 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/t5-the-transformer-that-zigged-when-others-zagged-an-architectural-deep-dive/index.html b/posts/t5-the-transformer-that-zigged-when-others-zagged-an-architectural-deep-dive/index.html index 5421b9c..8d53ac0 100644 --- a/posts/t5-the-transformer-that-zigged-when-others-zagged-an-architectural-deep-dive/index.html +++ b/posts/t5-the-transformer-that-zigged-when-others-zagged-an-architectural-deep-dive/index.html @@ -30,4 +30,4 @@ But to truly understand the field, we must look at the pivotal models that explo 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/transformer-s-core-mechanics/index.html b/posts/transformer-s-core-mechanics/index.html index ee2e6e3..39da4db 100644 --- a/posts/transformer-s-core-mechanics/index.html +++ b/posts/transformer-s-core-mechanics/index.html @@ -36,4 +36,4 @@ In deep learning, a “channel” can be thought of as a feature dimensi 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/unifi-vlan-migration-to-zone-based-architecture/index.html b/posts/unifi-vlan-migration-to-zone-based-architecture/index.html index 8cc19f6..c3bdfab 100644 --- a/posts/unifi-vlan-migration-to-zone-based-architecture/index.html +++ b/posts/unifi-vlan-migration-to-zone-based-architecture/index.html @@ -28,4 +28,4 @@ This article documents that journey. It details the pitfalls encountered, the co 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/posts/useful/index.html b/posts/useful/index.html index e780892..e090810 100644 --- a/posts/useful/index.html +++ b/posts/useful/index.html @@ -9,4 +9,4 @@ One-minute read
    • [cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file diff --git a/sitemap.xml b/sitemap.xml index 630341a..f5630a7 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -1 +1 @@ -/2025-10-02T07:22:54+00:00weekly0.5/posts/2025-10-02T07:22:54+00:00weekly0.5/posts/unifi-vlan-migration-to-zone-based-architecture/2025-10-02T07:22:54+00:00weekly0.5/posts/quantization-in-llms/2025-08-20T06:02:35+00:00weekly0.5/posts/breville-barista-pro-maintenance/2025-08-20T06:04:36+00:00weekly0.5/posts/secure-boot-dkms-and-mok-on-proxmox-debian/2025-08-14T06:50:22+00:00weekly0.5/posts/how-rvq-teaches-llms-to-see-and-hear/2025-08-08T17:36:52+00:00weekly0.5/posts/supabase-deep-dive/2025-08-04T03:59:37+00:00weekly0.5/posts/ppo-for-language-models/2025-10-02T07:22:54+00:00weekly0.5/posts/mixture-of-experts-moe-models-challenges-solutions-in-practice/2025-08-03T06:02:48+00:00weekly0.5/posts/t5-the-transformer-that-zigged-when-others-zagged-an-architectural-deep-dive/2025-08-03T03:41:10+00:00weekly0.5/posts/espresso-theory-application-a-guide-for-the-breville-barista-pro/2025-08-03T04:20:20+00:00weekly0.5/posts/transformer-s-core-mechanics/2025-10-02T07:22:54+00:00weekly0.5/posts/useful/2025-08-03T08:37:28-07:00weekly0.5/about/2020-06-16T23:30:17-07:00weekly0.5/categories/weekly0.5/tags/weekly0.5 \ No newline at end of file +/2025-10-02T08:34:05+00:00weekly0.5/posts/flashing-jetson-orin-nano-in-virtualized-environments/2025-10-02T08:34:05+00:00weekly0.5/posts/2025-10-02T08:34:05+00:00weekly0.5/posts/openwrt-mwan3-wireguard-endpoint-exclusion/2025-10-02T08:34:05+00:00weekly0.5/posts/unifi-vlan-migration-to-zone-based-architecture/2025-10-02T07:22:54+00:00weekly0.5/posts/quantization-in-llms/2025-08-20T06:02:35+00:00weekly0.5/posts/breville-barista-pro-maintenance/2025-08-20T06:04:36+00:00weekly0.5/posts/secure-boot-dkms-and-mok-on-proxmox-debian/2025-08-14T06:50:22+00:00weekly0.5/posts/how-rvq-teaches-llms-to-see-and-hear/2025-08-08T17:36:52+00:00weekly0.5/posts/supabase-deep-dive/2025-08-04T03:59:37+00:00weekly0.5/posts/ppo-for-language-models/2025-10-02T07:22:54+00:00weekly0.5/posts/mixture-of-experts-moe-models-challenges-solutions-in-practice/2025-08-03T06:02:48+00:00weekly0.5/posts/t5-the-transformer-that-zigged-when-others-zagged-an-architectural-deep-dive/2025-08-03T03:41:10+00:00weekly0.5/posts/espresso-theory-application-a-guide-for-the-breville-barista-pro/2025-08-03T04:20:20+00:00weekly0.5/posts/transformer-s-core-mechanics/2025-10-02T07:22:54+00:00weekly0.5/posts/useful/2025-08-03T08:37:28-07:00weekly0.5/about/2020-06-16T23:30:17-07:00weekly0.5/categories/weekly0.5/tags/weekly0.5 \ No newline at end of file diff --git a/tags/index.html b/tags/index.html index 0692448..9ea5e86 100644 --- a/tags/index.html +++ b/tags/index.html @@ -4,4 +4,4 @@ 2016 - 2025 Eric X. Liu -[cc368da] \ No newline at end of file +[832aabc] \ No newline at end of file