.. dann machen wir das jetzt sauber durch. Da
libmnl bereits vorhanden ist und
libnftnl fehlt, beschreibe ich zwei Wege in unbestimmter Form (wie gewünscht):
- So könnte man es in Freetz-NG upstream einbringen (also sauber in den Tree pushen), und
- So könnte man es lokal als Paket hinzufügen (schneller, nur für die eigene Build-Umgebung).
Beide Wege enthalten Schritt-für-Schritt-Anleitungen und Beispiel-Makefiles/Config-Snippets.
1) Möglichkeit A — Paket sauber in Freetz-NG (zum Pushen / PR)
Ziel: libnftnl + nftables als Pakete in den Freetz-NG-Quellbaum einfügen, in make menuconfig sichtbar machen, lokal bauen, und dann per PR in das zentrale Repository einbringen.
Überblick (in groben Zügen)
Man würde
- das Freetz-NG-Repo forken/klonen,
- zwei Paketordner anlegen (make/libnftnl und make/nftables),
- jeweils ein Makefile (+ evtl. eine Kconfig/Config-Datei) anlegen,
- lokal testen (make menuconfig → auswählen → make bauen),
- Build-Ergebnisse und Logs prüfen,
- Änderungen committen, Branch pushen und PR öffnen mit einer Beschreibung + Build-Log.
Schritt-für-Schritt (konkret)
- Repo forken & klonen
- Man könnte das Freetz-NG Repo auf GitHub forken und lokal klonen:
git clone https://github.com/<dein-user>/freetz-ng.git<br>cd freetz-ng<br>git checkout -b feature/nftables<br>
- (So hätte man eine saubere Branch zum Arbeiten.)
- Abhängigkeiten prüfen
- Man würde sicherstellen, dass libmnl als Paket/Library im Tree aktiviert ist
- Für den Build würden noch typische Host-Tools benötigt werden (autoconf, automake, pkg-config) — falls beim Build Fehler kommen, sollte man diese lokal installieren oder die Host-Toolchain in Freetz aktivieren.
- Paketordner anlegen
- Man könnte zwei Ordner anlegen:
make/libnftnl/<br>make/nftables/
- In jedem Ordner würde man ein Makefile und optional eine Config.in/Kconfig (damit das Paket im menuconfig angezeigt wird) anlegen.
- Makefile für libnftnl (Template)
VERSION und SHA256 ersetzen — man würde die aktuelle Version von netfilter.org holen und den Hash berechnen.
include $(TOPDIR)/rules.mk<br><br>PKG_NAME:=libnftnl<br>PKG_VERSION:=<VERSION><br>PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz<br>PKG_SOURCE_URL:=https://netfilter.org/projects/libnftnl/files<br>PKG_HASH:=<SHA256><br><br>include $(INCLUDE_DIR)/package.mk<br><br>define Package/libnftnl<br> SECTION:=libs<br> CATEGORY:=Libraries<br> TITLE:=libnftnl - netfilter nftables userspace library<br> DEPENDS:=+libmnl<br>endef<br><br>define Package/libnftnl/description<br> Userspace library to talk to nftables kernel netlink API.<br>endef<br><br>define Build/Prepare<br> $(call Build/Prepare/Default)<br> # eventuelle Patches kopieren<br>endef<br><br>define Build/Configure<br> cd $(PKG_BUILD_DIR) && \<br> ./configure --host=$(TARGET_HOST) --prefix=/usr<br>endef<br><br>define Build/Compile<br> $(MAKE) -C $(PKG_BUILD_DIR)<br>endef<br><br>define Package/libnftnl/install<br> $(INSTALL_DIR) $(1)/usr/lib<br> $(INSTALL_DIR) $(1)/usr/include<br> $(MAKE) -C $(PKG_BUILD_DIR) DESTDIR=$(1) install<br>endef<br><br>$(eval $(call BuildPackage,libnftnl))<br>
- Man würde vorher die tatsächliche PKG_VERSION und PKG_HASH einsetzen (z. B. wget und sha256sum lokal verwenden).
- Makefile für nftables (Template)
include $(TOPDIR)/rules.mk<br><br>PKG_NAME:=nftables<br>PKG_VERSION:=<VERSION><br>PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz<br>PKG_SOURCE_URL:=https://netfilter.org/projects/nftables/files<br>PKG_HASH:=<SHA256><br><br>include $(INCLUDE_DIR)/package.mk<br><br>define Package/nftables<br> SECTION:=net<br> CATEGORY:=Networking<br> TITLE:=nftables userspace tool<br> DEPENDS:=+libmnl +libnftnl<br>endef<br><br>define Package/nftables/description<br> nft - userspace utility for configuring nftables rules.<br>endef<br><br>define Build/Configure<br> cd $(PKG_BUILD_DIR) && \<br> ./configure --host=$(TARGET_HOST) --prefix=/usr<br>endef<br><br>define Build/Compile<br> $(MAKE) -C $(PKG_BUILD_DIR)<br>endef<br><br>define Package/nftables/install<br> $(INSTALL_DIR) $(1)/usr/sbin<br> $(MAKE) -C $(PKG_BUILD_DIR) DESTDIR=$(1) install<br>endef<br><br>$(eval $(call BuildPackage,nftables))<br>
- (Optional) Kconfig / Config.in hinzufüg
- Man könnte ein kleines Config.in in den Paketordner legen, damit es schöner in make menuconfig auftaucht. Beispiel-Inhalt:
config PACKAGE_NFTABLES<br> bool "nftables (userspace)"<br> help<br> Userspace tool to configure nftables. Depends on libnftnl and libmnl.<br>
- Dann würde man die Top-level Makefiles so anpassen, dass dieses Config.in geladen wird (je nachdem, wie Freetz intern Kconfig verteilt ist).
- make menuconfig prüfen
- Man würde make menuconfig starten und nachsehen, ob libnftnl / nftables unter den Packages auftauchen. Wenn nicht, würde man die Makefile/Kconfig-Pfadstruktur anpassen, bis die Pakete sichtbar werden.
- Build durchführen
- Man könnte make -j4 ausführen (oder make package/nftables/compile), Build-Fehler anschauen, ggf. fehlende Build-Abhängigkeiten ergänzen.
- Falls Autotools/meson/cMake gebraucht werden, würde man entsprechende Build-Tool-Pakte aktivieren.
- Tests
- Nach erfolgreichem Build würde man ein Test-Image bauen, flashen, und auf der Fritzbox prüfen:
nft --version
- Man könnte ein kleines Startscript anlegen, das beim Boot die gewünschte /etc/nftables.conf lädt.
- PR vorbereiten
- Man würde commits sauber dokumentieren (ChangeLog, LICENSE Hinweise), Push zum Fork:
git add make/libnftnl make/nftables<br>git commit -m "Add libnftnl and nftables packages"<br>git push origin feature/nftables<br>
- Auf GitHub würde man einen Pull Request gegen das upstream-Freetz-NG Repo öffnen, Beschreibung und Build-Logs anhängen, erklären dass libmnl bereits vorhanden und als DEPENDS gesetzt ist.
- Wartung & Review
- Man würde auf Review-Kommentare eingehen (CI-Logs, Build-Fehler), evtl. Versionsupdates nachreichen.
Vorteile dieser Variante
- Sauber, wartbar, integrierbar für alle Freetz-NG-User.
- Updates/Verbesserungen können per PR nachgezogen.
Nachteile / Aufwand
- Mehr initialer Aufwand (Makefiles korrekt schreiben, PR-Review, Build-Fixes).
2) Möglichkeit B — Lokal / Manuell (schneller, ohne PR)
Es gäbe zwei Untervarianten: (B1) lokale Paket-Integration in deiner Freetz-Tree (kein PR), oder (B2) Quick & Dirty: statisch kompilierte Binärdatei nach /usr/sbin kopieren.
B1 — Lokales Paket in deinem Freetz-Tree (am schnellsten, robust)
Kurz: Man würde genau die gleichen Paket-Verzeichnisse wie unter 1) anlegen, aber die Änderungen nur lokal belassen (kein Fork/PR). Danach make menuconfig → auswählen → make → flashen.
Schritte (grob)
- Im lokalen freetz-ng-Verzeichnis make/libnftnl und make/nftables anlegen (die gleichen Makefile-Templates verwenden wie oben).
- make menuconfig prüfen, Pakete auswählen.
- make ausführen, Image bauen.
- Image flashen und testen (nft --version, dann die Regeln laden).
Vorteile: schnell, kontrolliert, keine Abstimmung mit Maintainer nötig.
Nachteile: nur lokal verfügbar (kein upstream-Merge).
B2 — Quick & Dirty: statisch bauen und auf Box kopieren
Kurz: Man könnte nft statisch kompilieren (oder mit allen benötigten Libraries bundlen), dann die Binary + Bibliotheken per scp auf die Fritzbox kopieren. Das ist riskanter, kann ABI-Probleme bringen, aber schnell testbar.
Schritte (konkret / beispielhaft)
- Quellen holen
- Man könnte die nftables-Quelle holen:
wget https://netfilter.org/projects/nftables/files/nftables-<VERSION>.tar.xz<br>tar xf nftables-<VERSION>.tar.xz<br>cd nftables-<VERSION><br>
- Cross-Toolchain / static build
- Man würde die Freetz-NG Toolchain oder einen passenden Cross-Compiler benutzen. Falls cross-compile zu aufwändig ist, könnte man versuchen, statisch auf einem kompatiblen System (armeabi) zu bauen — das ist oft schwierig.
- Beispiel (schematisch):
./configure --enable-static --disable-shared --host=arm-linux-gnueabi --prefix=/usr<br>make<br>
- Wenn statisch gebaut werden kann, hätte man eine einzelne nft Binary ohne runtime-abhängigkeit.
- Auf die Fritzbox kopieren
- Man würde die Binary nach /usr/sbin kopieren:
scp nft root@fritzbox:/usr/sbin/nft<br>ssh root@fritzbox "chmod +x /usr/sbin/nft"<br>
- Falls Libraries notwendig sind, würde man die benötigten .so-Dateien ebenfalls nach /usr/lib kopieren (dabei auf soname und ABI achten).
- Test
- Man könnte nft --version ausführen und die Regeln testen.
Vorteile: sehr schnell zum Testen.
Nachteile: unsauber, nicht update-sicher, kann Bibliothekskonflikte erzeugen, schwierig bei Cross-Compile.
Wichtige Hinweise & Tipps (für beide Wege)
- Versions-/Hash-Ermittlung: Man könnte die aktuelle Version von netfilter.org laden und sha256sum einsetzen, z. B. sha256sum nftables-1.x.y.tar.xz und den Hash in das Makefile eintragen.
- Build-Fehler: Häufige Fehler sind fehlende Host-Werkzeuge (pkg-config, autotools) oder fehlende Header (für libmnl, libnftnl). Man könnte vor dem Build prüfen, ob pkg-config die libs finden würde.
- Testen: Man würde die fertige Box zuerst per SSH erreichen und nft --version prüfen. Danach könnte man ein kleines Test-Regelset laden (z. B. nft -f /etc/nftables.conf).
- Persistenz auf FritzBox: Wenn man nur kopiert, wäre es sinnvoll, das Einfügen in die Firmware (via Freetz) final zu machen, sonst gehen Dateien bei manchen Updates verloren.
- Sicherheit: Man würde die nft-Binaries und Libraries nur aus vertrauenswürdigen Quellen/selbst erstellt nutzen.