DaLaw2 a419c64aae feat(http): multipart model upload + staging orphan sweep
Backend scaffolding for the admin model-upload UI. Accepts `manifest`
(YAML) + `onnx` (binary) multipart fields, streams each directly to a
fresh `models/.staging/<uuid>/` directory with enforced size caps, and
sanity-checks the ONNX header before ever touching disk. Structural
schema validation against `MLInferenceConfig` — plus the atomic
promote-to-`models/` step — is the next milestone's job; this commit
lands only the upload / staging surface.

New file `adapter/http/model_upload.rs`:
- `POST /api/ml/models/upload` scoped under `/api/ml/models`. Returns
  `{ staging_id, manifest_bytes, onnx_bytes, onnx_filename }` on
  success.
- Streams per-field, never buffers the full `.onnx` in RAM. Per-field
  byte cap enforced inline: 100 MB for onnx, 64 KB for manifest.
  Overflow yields 413 and the staging subdir is torn down before the
  response returns.
- `looks_like_onnx` heuristic rejects empty, all-zero, all-printable,
  and common container magics (ZIP, PNG, PDF, ELF) up front. Positive
  acceptance is handled authoritatively later by tract during
  `build_adapter`.
- `sanitize_filename` keeps the client's suffix but strips traversal
  so the staging dir can never escape.
- `clean_staging_orphans(root, max_age)` sweeps leftover subdirs;
  reused at startup and available for a periodic task later.

Wiring:
- `actix-multipart = "0.7"` and `uuid` (with `v4`) added to
  `net-guardia/Cargo.toml`.
- `system.rs` calls `clean_staging_orphans` once during `run()` before
  the model watcher starts listening, with a 1 h age threshold. Two
  new `SystemLog` variants (`StagingOrphansCleaned` /
  `StagingOrphansSweepFailed`) report results.
- `http_server.rs` registers the new scope inside the existing
  `/api` scope. CSRF / JWT middleware already covers the route; no
  permission table changes needed beyond what I-11 provides.

Tests: 10 new (5 ONNX-sniff edge cases — empty / zero-padded / plain
text / varint tag / length-delimited tag; 3 `sanitize_filename`
cases; 2 orphan-sweep cases including the no-staging-dir short
circuit). 240 pass total. clippy --package net-guardia -- -D warnings
clean.

Closes I-region I-12.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 17:40:33 +08:00

NetGuardia

Project Overview

NetGuardia is a high-performance network security solution that combines eBPF XDP technology with deep learning models to provide advanced network protection. The system operates as a standalone network appliance that can run on any Ubuntu-based system with compatible network hardware.

Core Technologies

  • eBPF XDP Technology - Provides high-performance packet processing directly at the data link layer
  • Deep Learning Models - Identifies and predicts potential network attacks with intelligent threat detection
  • Hardware Integration - Designed to work with Intel i350 T2 and similar enterprise-grade network interface cards

Functional Modules

Resource Overview

Home

  • Real-time control system occupancy rate

Dashboard Overview

Dashboard

  • Real-time network traffic monitoring and visualization
  • Recent traffic statistics and trend analysis

Detailed Traffic Statistics

Statistics

  • Detailed traffic usage information per IP address

Network Access Control

accessControl

  • IPv4/IPv6 whitelist and blacklist management
  • Precise port-level access control

System Features

  • High Performance - Low-latency packet processing with minimal network performance impact
  • User-Friendly - Cross-platform web management interface with intuitive operation
  • Reliability - Hardware-accelerated processing ensures stable operation
  • Scalability - Modular design supports functional expansion

System Requirements

NetGuardia requires the combination of a kernel with eBPF support and a NIC driver that implements AF_XDP on that kernel. There is no single "minimum kernel version" — it depends on which NIC driver you use.

  • Linux with eBPF + AF_XDP support for your NIC driver. Any modern distribution (Ubuntu 22.04+, Debian 12+, RHEL 9+, Fedora recent) is fine as long as the driver matrix below lines up.
  • Dual-port NIC with an AF_XDP-capable driver (see matrix).
  • Root / sudo access for eBPF program loading.

NIC driver / kernel matrix (AF_XDP)

Driver NIC family (examples) Min kernel for AF_XDP
mlx5 Mellanox ConnectX-4/5/6/7 5.x (early)
ixgbe Intel 82599, X520, X540, X550 5.x
i40e Intel X710, XL710, XXV710 5.x
ice Intel E810 5.5+
igb Intel i350 T2 (reference hardware) 6.17
igc Intel I225/I226 6.x
virtio_net QEMU/KVM virtual NICs varies; AF_XDP is limited

If you are using the reference Intel i350 T2, you need Linux 6.17 or newer because igb AF_XDP support landed in that release. On a kernel older than 6.17 the system will still build, but ingress/egress setup will fail at runtime when AF_XDP binding is attempted — check driver support with ethtool -i <iface> and confirm against the matrix above before deploying.

Hardware Compatibility

  • Network Interface: dual-port NIC with an AF_XDP-capable driver on your kernel (see matrix above). Intel i350 T2 is the reference hardware.
  • CPU: multi-core recommended; XDP scales with RX queue count.
  • Memory: 8 GB minimum, 16 GB+ for high-traffic environments.

NetGuardia is not limited to embedded platforms — it runs on standard server hardware, virtual machines, or dedicated appliances as long as the driver/kernel requirement above is met.

Description
NetGuardia is a network defense system that integrates eBPF XDP and deep learning models
Readme 121 MiB
Languages
Rust 96.7%
Shell 2.9%
HCL 0.4%