opengnb: add opengnb 1.6.8 to openwrt

[charleschan2006-alias]

Update opengnb package to the latest version 1.6.8.

📦 Package Details

PKG_MAINTAINER:= Charles Chan hollidgelongsun157@gmail.com
opengnb: add version 1.6.8 to openwrt

Description:
OpenGNB is an open source P2P decentralized Software Defined Virtual Network with extreme intranet penetration capability,Allows you to combine your company-home network into a direct-access LAN.

All code related to the GNB project is released as open source, and the currently released source code supports the following platforms: FreeBSD Linux OpenWRT Raspberrypi OpenBSD macOS

GNB Features
Intranet penetration P2P VPN
No public IP required
Extreme link capability
Unlimited speed effects
Data Security
Reliable authentication between GNB nodes based on elliptic curve digital signature
Multi-platform support
GNB is developed in C language. It does not need to refer to third-party library files when compiling. It can be easily ported to the current popular operating systems. Currently supported operating systems and platforms include Linux_x86_64, Windows10_x86_64, macOS, FreeBSD_AMD64, OpenBSD_AMD64, Raspberry Pi, OpenWRT; as big as server environment, desktop system, as small as OpenWRT router with only 32M memory can run GNB network very well.

🧪 Run Testing Details
**OpenWrt Version:OpenWrt SNAPSHOT, r35007-9f385a71a7
**OpenWrt Target/Subtarget:x86/x86_64
**OpenWrt Device:intel NUC 11

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

[BKPepe]

Previous PRs: #29797, #28956
Why there is need to open new pull requests, when you can use your existing ones?

[Copilot]

Pull request overview

Adds the opengnb package to the OpenWrt packages feed at version 1.6.5, enabling users to build/install OpenGNB (P2P decentralized virtual network/VPN) from the feed.

Changes:

• Introduces net/opengnb/Makefile defining the new package metadata, source fetch, and build/install steps.
• Builds OpenGNB using the upstream Makefile.openwrt and installs gnb, gnb_crypto, and gnb_ctl into /usr/sbin.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[namedlock]

deeply need this feature, hope it can be accepted

[gnbdev]

thanks

[gnbdev]

These test errors are all occurring within Docker, mentioning:
natpmpc: No executables in the package provided version 20230423
natpmpc: Generic tests failed. Here, "executables" refers to executable files, right? The key point is that GNB doesn't actually call any of the natpmpc executable files; it only depends on related libraries.

[openwrt-ai]

Reviewed 2 new commits. CI (FormalityCheck) passes on the head commit; the earlier natpmpc test failures were resolved by dropping the miniupnpc/libnatpmp dependencies in the 1.6.6 update. Commit messages match their diffs. Two minor nits inline (file mode, series hygiene); no blocking issues found.

---

Generated by Claude Code

[openwrt-ai]

nit: This Makefile is committed with executable mode 100755. Package Makefiles in this tree are non-executable (100644) — 1446 of them are 644 and only 3 are 755. Please reset the mode:

chmod 644 net/opengnb/Makefile

then amend the commit.

---

Generated by Claude Code

[charleschan2006-alias]

done.

[openwrt-ai]

Reviewed 1 new commit; no new issues found. The two prior nits are resolved: the Makefile is now committed with mode 100644, and history was squashed into a single opengnb: add version 1.6.6 commit with the PR title/description updated to match PKG_VERSION. FormalityCheck CI passes on the head commit.

---

Generated by Claude Code

[charleschan2006-alias]

Hi all, I have fixed the license identifiers according to the guidelines and double-checked the package via local compilation. The CI is passing and it is ready for review. Could someone take a look when available? Thanks!

[gnbdev]

Reviewed 2 new commits. CI (FormalityCheck) passes on the head commit; the earlier natpmpc test failures were resolved by dropping the miniupnpc/libnatpmp dependencies in the 1.6.6 update. Commit messages match their diffs. Two minor nits inline (file mode, series hygiene); no blocking issues found.

Generated by Claude Code

Is there anything else that needs to be done?

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

net/opengnb/Makefile:45

• Build/Compile overrides CFLAGS but drops $(TARGET_CPPFLAGS) and hard-codes staging include/library paths. In this tree, manual-make packages typically pass both CFLAGS and CPPFLAGS (e.g. net/pixiewps/Makefile sets CFLAGS and CPPFLAGS separately) so target sysroot include paths and hardening defines are preserved. Recommend moving -I.../-D... into CPPFLAGS, include $(TARGET_CPPFLAGS), and avoid explicit -I$(STAGING_DIR)/usr/include / -L$(STAGING_DIR)/usr/lib unless strictly required.

define Build/Compile
	$(MAKE) -C $(PKG_BUILD_DIR) \
		$(TARGET_CONFIGURE_OPTS) \
		CFLAGS="$(TARGET_CFLAGS) -I. -I./src -I./libs -I$(STAGING_DIR)/usr/include -DWITHOUT_MINIUPNPC -D_GNU_SOURCE -DNO_GZIP=1 -DGNB_OPENWRT_BUILD=1" \
		LDFLAGS="$(TARGET_LDFLAGS) -L$(STAGING_DIR)/usr/lib -lz -pthread" \

[openwrt-ai]

Reviewed 1 new commit (385836d), which replaces the previously reviewed 1.6.6 state with 1.6.7.

What I verified as correct:

• PKG_HASH matches the upstream opengnb-1.6.7.tar.gz release asset (c2e4aa17…f0443), and PKG_RELEASE:=1 is right for a version bump.
• The Build/Compile simplification holds up. 1.6.7's Makefile.openwrt now sets GNB_CFLAGS=$(CFLAGS) -I./src -I./libs -D_GNU_SOURCE -DNO_GZIP=1 -DWITHOUT_MINIUPNPC -DGNB_OPENWRT_BUILD=1 itself, so dropping those flags here is not a behaviour change, and -DWITHOUT_MINIUPNPC is still applied — the missing miniupnpc/libnatpmp dependencies stay correct.
• Dropping the explicit all goal is safe: all is the first target in Makefile.openwrt and the included Makefile.openwrt.inc defines only variables, no rules, so all remains the default goal.
• Removing -I$(STAGING_DIR)/usr/include / -L$(STAGING_DIR)/usr/lib is fine — $(TARGET_CPPFLAGS) and $(TARGET_LDFLAGS) already carry them. Dropping -lz -pthread from LDFLAGS is also fine: upstream adds them on the gnb and gnb_es link lines, and gnb_ctl / gnb_crypto pull in neither zlib nor pthread. This addresses the earlier Copilot remark on the flag handling.
• The commit message matches its diff.

Two substantive findings inline: gnb_es is linked without $(TARGET_LDFLAGS) because upstream shadows it with GNB_ES_LDFLAGS, so that binary ships without OpenWrt's hardening/linker flags; and all four binaries embed __DATE__/__TIME__, which upstream lets you switch off with a single define. I'd call the gnb_es link the one worth fixing before merge; the timestamp one is a reproducibility improvement rather than a blocker. The other two comments are optional nits.

On CI: only FormalityCheck has reported on this head commit and all three of its checks are green. The multi-arch test build has not posted a result yet, so there is nothing to read into it either way.

---

Generated by Claude Code

[openwrt-ai]

$(TARGET_LDFLAGS) never reaches the gnb_es link. Upstream's Makefile.openwrt links that one binary with GNB_ES_LDFLAGS, which is a fresh assignment that does not reference $(LDFLAGS):

GNB_ES_LDFLAGS=-Wl,--gc-sections
...
$(GNB_ES): $(GNB_ES_OBJS) $(CRYPTO_OBJS)
	$(CC) -o $(GNB_ES) $(GNB_ES_OBJS) $(CRYPTO_OBJS) $(GNB_ES_LDFLAGS) -pthread

gnb, gnb_ctl and gnb_crypto all link through GNB_LDFLAGS=$(LDFLAGS) and are fine, so of the four binaries installed below, gnb_es is the only one built without the flags OpenWrt puts in TARGET_LDFLAGS: -zrelro / -znow and the PIE specs from hardening.mk, plus -fuse-ld=$(TARGET_LINKER), -zmax-page-size, the toolchain -L paths and the LTO linker plugin when CONFIG_USE_LTO is set.

A variable set on the $(MAKE) command line overrides the makefile's own assignment, so passing it here is enough (-Wl,--gc-sections is kept explicitly because TARGET_LDFLAGS only picks it up when CONFIG_USE_GC_SECTIONS is enabled):

Suggested change

	LDFLAGS="$(TARGET_LDFLAGS)" \
	LDFLAGS="$(TARGET_LDFLAGS)" \
	GNB_ES_LDFLAGS="$(TARGET_LDFLAGS) -Wl,--gc-sections" \

---

Generated by Claude Code

[openwrt-ai]

All four installed binaries embed a compile timestamp, which makes the package non-reproducible — the same source built twice yields different binaries. src/gnb_version.h in the 1.6.7 tarball has:

#ifndef GNB_SKIP_BUILD_TIME
#define GNB_BUILD_STRING  "Build Time ["__DATE__","__TIME__"]"
#else
#define GNB_BUILD_STRING  "Build Time [Hidden]"
#endif

and GNB_BUILD_STRING is referenced from src/cli/gnb.c, gnb_ctl.c, gnb_crypto.c and gnb_es.c, so every one of them is affected. Upstream already provides the opt-out, so defining it here is the whole fix. Feed packages handle build stamps the same way — see net/ratched/Makefile:17 (-DBUILD_TIMESTAMP_UTC="\"unknown\"") and net/socat/Makefile:83 (BUILD_DATE=$(SOURCE_DATE_EPOCH)).

Suggested change

	CFLAGS="$(TARGET_CFLAGS) $(TARGET_CPPFLAGS)" \
	CFLAGS="$(TARGET_CFLAGS) $(TARGET_CPPFLAGS) -DGNB_SKIP_BUILD_TIME" \

---

Generated by Claude Code

[openwrt-ai]

nit (cosmetic, optional): the padding before the continuation backslash on this line is a mix of 7 spaces, 2 literal tabs and 15 more spaces, so the \ lands well past the column the next three lines align to and the block renders ragged at any tab width. The other three lines pad with spaces only. Harmless to the build — the continuation just folds into the recipe as whitespace — but it looks unintentional:

Suggested change

	$(MAKE) -C $(PKG_BUILD_DIR) \
	$(MAKE) -C $(PKG_BUILD_DIR) \

---

Generated by Claude Code

[charleschan2006-alias]

fixed.

[openwrt-ai]

nit / question: gnb is a long-running daemon, but the package installs only the four binaries — there is no /etc/init.d/opengnb and no /etc/config/opengnb, so nothing starts the VPN at boot and there is no UCI surface to configure it. The feed's convention for daemons is a procd init script (#!/bin/sh /etc/rc.common, USE_PROCD=1, start_service()), with any shipped config registered in define Package/opengnb/conffiles.

I can't tell from the diff whether this is deliberate. Worth noting the 1.6.7 tarball ships only a systemd unit (scripts/opengnb@.service) and a examples/node_config_example tree, so there is nothing to install verbatim — an init script would have to be written for this package. Is that planned as a follow-up, or is manual invocation the intent for the initial submission?

---

Generated by Claude Code

[openwrt-ai]

Reviewed 1 new commit (6d18701), which replaces the previously reviewed 1.6.7 state with 1.6.8. Nothing blocking; one optional cosmetic nit inline.

What I verified:

• PKG_HASH:=4c6a6030…f829 matches the upstream opengnb-1.6.8.tar.gz release asset (downloaded and hashed independently), and PKG_RELEASE:=1 is correct for a version bump.
• Both substantive findings from my 1.6.7 review are fixed upstream in 1.6.8, so no change is needed in this Makefile for either. Makefile.openwrt now reads GNB_ES_LDFLAGS=$(LDFLAGS) (was -Wl,--gc-sections), so gnb_es finally links with $(TARGET_LDFLAGS) like the other three binaries; and GNB_CFLAGS gained -DGNB_SKIP_BUILD_TIME=1, so none of the four binaries embeds __DATE__/__TIME__ any more (src/gnb_version.h now resolves GNB_BUILD_STRING to "Build Time [Hidden]"). The two corresponding inline threads from the last review are stale and can be resolved.
• The full 1.6.7 → 1.6.8 upstream diff is confined to the per-platform Makefile.*, src/gnb_version.h and version — no new sources and no new library usage — so DEPENDS:=+kmod-tun +libpthread +zlib is still accurate: gnb still links -lz -pthread, and -DWITHOUT_MINIUPNPC is still set, so the miniupnpc/libnatpmp dependencies stay correctly absent.
• Omitting an explicit make goal is still safe: all remains the first target in Makefile.openwrt, and Makefile.openwrt.inc still defines only object-list variables, no rules.
• The commit message matches its diff, carries a Signed-off-by, and the file is committed with mode 100644.

CI: the three FormalityCheck jobs are green on the head commit. The multi-arch test build has not reported on this commit yet, so there is nothing to read into it either way.

Still open from the previous round: the question about whether a procd init script (/etc/init.d/opengnb) and a UCI config are planned, since gnb is a long-running daemon and the package currently installs binaries only. That thread has not been answered.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 1 new commit (403d211); no new issues found.

The only change since the previously reviewed state is the cosmetic alignment nit from my last round: the LDFLAGS="$(TARGET_LDFLAGS)" continuation line now pads with a single space like the three lines around it, so the whole Build/Compile block is consistent. Nothing else in net/opengnb/Makefile moved — PKG_VERSION/PKG_RELEASE/PKG_HASH, DEPENDS, the recipe body and the install block are byte-identical to what I verified at 1.6.8, the file is still committed with mode 100644, and the commit subject matches its diff.

Housekeeping on the older inline threads, so the list reflects reality:

• The gnb_es / $(TARGET_LDFLAGS) thread and the __DATE__/__TIME__ reproducibility thread are both stale — 1.6.8 fixes each upstream (GNB_ES_LDFLAGS=$(LDFLAGS) and -DGNB_SKIP_BUILD_TIME=1 in Makefile.openwrt), so no change is needed here. They can be resolved.
• Still unanswered from two rounds ago: whether a procd init script (/etc/init.d/opengnb) and a UCI config are planned. gnb is a long-running daemon and the package currently installs binaries only, so nothing starts it at boot. Not a blocker for an initial submission if that is the intent — it would just be good to say so on the record.

---

Generated by Claude Code

[gnbdev]

Reviewed 1 new commit (403d211); no new issues found.

The only change since the previously reviewed state is the cosmetic alignment nit from my last round: the LDFLAGS="$(TARGET_LDFLAGS)" continuation line now pads with a single space like the three lines around it, so the whole Build/Compile block is consistent. Nothing else in net/opengnb/Makefile moved — PKG_VERSION/PKG_RELEASE/PKG_HASH, DEPENDS, the recipe body and the install block are byte-identical to what I verified at 1.6.8, the file is still committed with mode 100644, and the commit subject matches its diff.

Housekeeping on the older inline threads, so the list reflects reality:

• The gnb_es / $(TARGET_LDFLAGS) thread and the __DATE__/__TIME__ reproducibility thread are both stale — 1.6.8 fixes each upstream (GNB_ES_LDFLAGS=$(LDFLAGS) and -DGNB_SKIP_BUILD_TIME=1 in Makefile.openwrt), so no change is needed here. They can be resolved.
• Still unanswered from two rounds ago: whether a procd init script (/etc/init.d/opengnb) and a UCI config are planned. gnb is a long-running daemon and the package currently installs binaries only, so nothing starts it at boot. Not a blocker for an initial submission if that is the intent — it would just be good to say so on the record.

Generated by Claude Code

OpenGNB does not require a configuration file; the daemon process can be started directly via a command in the terminal window.
For modes that require a configuration file, users must manually generate their own public and private keys. Currently, there is no web interface available for user operations.
Therefore, no /etc/init.d/opengnb script is currently included.