Miles WardandClaude Opus 4.8
4f193cac05
Mirrors the worthwhile device-support wins from iVentoy 1.0.24→1.0.35 onto our
(very different) proxy-DHCP + iPXE-chainload architecture. iVentoy's other
changes are inapplicable (arm64-server / distro-display fixes live in its
injected Linux, which we don't have), niche (iSCSI), or closed-source
(Matrix Boot).
iPXE refreshed (mirrors 1.0.35 "Update iPXE")
- Pin the from-source build to ipxe/ipxe master @ 2026-06-09
(95ffbf4745553e8a207922389929e1943c0237c0) — newer NIC drivers + EFI fixes.
The pin also busts the cached ipxe-build Docker layer so the release
actually recompiles iPXE; build-ipxe.sh now shallow-fetches an exact SHA.
Automatic NIC driver fallback (mirrors 1.0.34 "driver/boot-file mode" — but
no operator toggle, per request)
- New DriverMode {Firmware, Builtin} in core; ClientArch::ipxe_bootfile_mode
maps each arch to either the firmware-net build (snponly/undionly, default)
or the all-drivers build (ipxe.efi/ipxe.pxe/ipxe-i386.efi/ipxe-arm64.efi).
- The DHCP proxy serves Firmware by default — byte-for-byte unchanged, so
hardware that boots today never regresses. A new DriverEscalation state
machine watches for the tell-tale failure: a MAC re-PXE-boots (fresh
firmware DISCOVER) without ever completing the iPXE-user-class handoff that
proves the firmware NIC stack worked. That MAC is automatically escalated to
iPXE's own NIC drivers, and the choice is sticky after a confirmed handoff
(debounced for the :67/:4011 same-boot pair, TTL-pruned, capped). It just
works — no settings, no UI.
- All-drivers binaries fetched per arch (ipxe.pxe + i386/arm64 native EFI;
x86_64 ipxe.efi already built from source with PNG); ipxe-assets embeds
*.pxe and logs availability per (arch, mode).
Core principles intact: DHCP-proxy-only, container-first, Rust-focused (the
logic is all Rust; only the iPXE fetch/build stays shell), Windows hard-rules
untouched (this never goes near Windows boot).
Validation: clippy clean; full workspace test suite green (core 99 incl. new
DriverMode tests, dhcp-proxy +4 escalation tests, http-api 31+68, iso-store
61, tftp 6, bin 2); fmt-clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
26 lines
1.2 KiB
Rust
26 lines
1.2 KiB
Rust
//! DHCP proxy (RFC 4578 "PXE Boot Server Discovery").
|
|
//!
|
|
//! Listens on UDP/67 (broadcast) and UDP/4011 (PXE boot server). Never
|
|
//! assigns IPs — only returns boot parameters (siaddr, option 66 TFTP server,
|
|
//! option 67 boot filename, and the mandatory option 60 "PXEClient" echo).
|
|
//!
|
|
//! Key decisions (see architecture memory for rationale):
|
|
//! - Single code path handles both 67 and 4011; distinguished by port.
|
|
//! - We set `SO_REUSEADDR` + `SO_BROADCAST` and enable `IP_PKTINFO` so we can
|
|
//! (a) learn the destination interface for multi-homed pods and (b) reply
|
|
//! back through the correct interface. This lets us run behind host-network
|
|
//! in OpenShift without needing `SO_BINDTODEVICE` (which requires NET_RAW).
|
|
//! - Classification is: option 77 user-class `iPXE` → serve HTTP script URL;
|
|
//! option 60 starts `HTTPClient` → serve HTTP URL directly (UEFI HTTP boot);
|
|
//! otherwise → TFTP + arch-specific iPXE binary.
|
|
//! - We MUST echo `option 60 = "PXEClient"` (or `"HTTPClient"`) in replies or
|
|
//! clients silently drop them.
|
|
#![forbid(unsafe_code)]
|
|
|
|
pub mod escalation;
|
|
pub mod reply;
|
|
pub mod server;
|
|
|
|
pub use escalation::DriverEscalation;
|
|
pub use server::DhcpProxyServer;
|