Technical Deep Dive

This page documents the architecture, engineering decisions, and reproducible logic behind NetAccel WiFi Edition.

1. Architecture Overview

        ┌───────────────────────────────────────────┐
        │                 NetAccel                  │
        │          (WiFi Edition / H618)            │
        └───────────────────────────────────────────┘
                          │
                 ┌────────┴────────┐
                 │                 │
        ┌────────▼────────┐ ┌──────▼────────┐
        │  System Layer   │ │ Network Layer │
        │ (DTB + Kernel)  │ │ (AP + Bridge) │
        └─────────────────┘ └───────────────┘
                 │                 │
        ┌────────▼────────┐ ┌──────▼─────────────┐
        │ Security Layer  │ │ Visibility Layer    │
        │ (LUKS + Keys)   │ │ (Beacon / Rendezvous) │
        └─────────────────┘ └─────────────────────┘

NetAccel consists of four layers: System, Network, Security, and Visibility — each kept minimal and deterministic.

2. DTB Trimming

NetAccel disables unused hardware at the Device Tree level:

• Bluetooth (UART + LPM + power domains)
• Audio codec + machine + platform
• Camera/CSI (intentionally not enabled)

Principles:

• Keep only the hardware paths actually used
• Reduce kernel module loading
• Remove boot-time noise and wakeups
• Ensure predictable, quiet hardware behavior

3. Kernel & Systemd Minimalism

All Bluetooth-related modules are blacklisted:

blacklist bluetooth
blacklist btusb
blacklist aic_btusb

Systemd services:

• bluetooth.service → masked
• no automatic modprobe for removed modules

Effects:

• clean boot logs
• no background daemons
• lower idle CPU usage
• fully silent system

4. Network Layer (AP + Bridge)

Network behavior is strictly deterministic. Components:

• wlan0 (AP mode via hostapd)
• eth0 (uplink)
• br0 (transparent bridge via systemd-networkd)

client device
    │ WiFi (hostapd)
    ▼
wlan0 ──────────┐
                │ bridge (br0)
eth0 ───────────┘
                ▼
       upstream router

NetAccel never takes over DHCP. dnsmasq is restricted:

• port=0 (no DNS listening)
• DHCP disabled

This ensures coexistence with any router without collision.

5. nftables (Minimal, Deterministic)

nftables provides:

• basic firewalling
• controlled forwarding
• broadcast suppression
• managed beacon traffic

The rule set is fully readable, reproducible, and hand-written.

6. Security Layer (LUKS + Key Derivation)

The root filesystem is encrypted via LUKS. The encryption key is derived from:

1. H618 SID (hardware-unique)
2. TF card serial number (media-unique)
3. Lab key (64-bit secret)

This guarantees:

• a cloned TF card cannot decrypt the system
• firmware leakage does not expose rootfs
• initramfs generates keys upon first boot

A lightweight, hardware-bound protection model designed for small lab devices.

7. Visibility Layer (Beacon / Rendezvous)

This is a read-only, minimal observability layer:

• device sends periodic UDP or HTTP beacons
• server logs only the latest heartbeat
• user scans QR code to view status
• no remote commands, no telemetry

Beacon includes:

• serial number
• IP address
• subnet (24-bit)
• runtime mode
• version

Visibility without control — essential for autonomy.

8. Engineering Principles

• Reproducible
• Explainable
• Verifiable
• No hidden state
• No remote control
• No data collection

Every technical decision follows these principles.

Closing

NetAccel’s technical structure is not complicated — it is simply the result of careful refinement, aiming to provide a reliable base for learning, research, and engineering practice.