v0.1.3

[EHfive]

Highlights

• Fix a bug that might cause silent packet drop, which has been observed on PPPoE interface for large packets.
• Use pure-rust Aya loader by default, einat now has zero native dependency except libc on target platform.
  This should make einat be built more easily especially for cross-compilation.
• Allow attaching eBPF programs with new TCX interface, aya loader only.
• Allow do SNAT for specified internal network only

# do SNAT for internal packets with source of 192.168.1.0/24 only
einat -i extern0 --hairpin-if intern0 lo --internal 192.168.1.0/24

🚀 Features

• Add pure-Rust aya loading backend support
• Add config option to toggle TCX interface usage
• Allow do NAT for specified internal network only
• Add CLI options for snat_internals and bpf_loader

🐛 Bug Fixes

• Workaround an unroll failure
• (ebpf) Always pull first header bytes
• Split EINAT_BPF_CFLAGS args

Improve

• Increase log level of libbpf netlink error to DEBUG
• Describe NAT44 enabling more specifically
• Log eBPF loader used
• Enable bpf_fib_lookup_external by default on kernel>=6.7

---

This discussion was created from the release v0.1.3.

[EHfive]

@muink Ask me here if you have any question porting openwrt-einat-ebpf to einat v0.1.3 .
(Saw your pre changes, thanks in advance for bring this to OpenWrt.)

[EHfive]

@muink

What about running llvm-strip inside openwrt-einat-ebpf or check the content of PATH? llvm-strip could be masked by OpenWrt build system.

[EHfive]

@muink

You can also patch/edit the build.rs like following to run bash command inside Cargo build environment.

diff --git a/build.rs b/build.rs
index 27ebeb0..16c5001 100644
--- a/build.rs
+++ b/build.rs
@@ -68,6 +68,14 @@ fn einat_obj_build() {
         "bpfeb"
     };
 
+    let debug_cmd = "echo PATH: $PATH";
+    let res = Command::new("bash")
+        .arg("-c")
+        .arg(debug_cmd)
+        .status()
+        .unwrap();
+    panic!("{}", res);
+
     cmd.arg("-target")
         .arg(target)
         .arg("-g")

[EHfive]

@muink

Is there any way can specify its path exactly at build time?

Well, just prepend path to the parent directory of llvm-strip to the PATH..

Or just patch/sed the build.rs to replace the string literal llvm-strip.

The PATH approach is standard, and given clang can be located just fine, I think this is more of a misconfiguration of build file there.
(I still think you should try installing package llvm in your actions workflow.. It does not seems to be a sub-dependency of packages you explicitly installed)

Though if you still found it cumbersome, I can make the build script to read command paths from environment variables like EINAT_CLANG_PATH and EINAT_LLVM_STRIP_PATH.

[muink]

PATH: /home/runner/work/packages/packages/SPECIAL_WORKDIR/SDK/staging_dir/target-aarch64_generic_musl/host/bin:/home/runner/work/packages/packages/SPECIAL_WORKDIR/SDK/staging_dir/hostpkg/bin:/home/runner/work/packages/packages/SPECIAL_WORKDIR/SDK/staging_dir/toolchain-aarch64_generic_gcc-12.3.0_musl/bin:/home/runner/work/packages/packages/SPECIAL_WORKDIR/SDK/staging_dir/toolchain-aarch64_generic_gcc-12.3.0_musl/bin:/home/runner/work/packages/packages/SPECIAL_WORKDIR/SDK/staging_dir/host/bin:/home/runner/work/packages/packages/SPECIAL_WORKDIR/SDK/staging_dir/host/bin:/snap/bin:/home/runner/.local/bin:/opt/pipx_bin:/home/runner/.cargo/bin:/home/runner/.config/composer/vendor/bin:/usr/local/.ghcup/bin:/home/runner/.dotnet/tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

[muink]

muink/openwrt-einat-ebpf@0df65bf
Now the llvm of sdk will be used first.

[muink]

Sorry for taking so long to reply to you, because I spent a lot of time on the weekend adapting openwrt 24.10 for other projects.
I just added debug patch and will test it later.

[muink]

The test of installing llvm package for github runner was successful. Is it just because llvm is not installed?
https://github.com/fantastic-packages/packages/actions/runs/11995526943
Waiting for another test

[muink]

The test was successful, I will test it again in production.

[muink]

@EHfive
Production environment test passed https://github.com/fantastic-packages/packages/actions/runs/11996741737
Thank you for continuing to follow this issue and provide help and insights.
The problem is indeed that the necessary host dependencies are not installed.