babeld: add new package by BKPepe · Pull Request #30162 · openwrt/packages

BKPepe · 2026-08-06T08:10:00Z

Adds babeld from the openwrt/routing feed — the routing packages are being moved into openwrt/packages one by one, as discussed in openwrt/routing#184.

Includes the small MAKE_FLAGS cleanup pending in openwrt/routing#1197.

The content matches the current routing feed master. Once this is merged, the package will be removed from the routing feed (a coordinated removal PR is prepared there).

Maintainer: @PolynomialDivision

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Babel is a loop-avoiding distance-vector routing protocol for IPv6 and IPv4 with fast convergence properties (RFC 8966). Moved from the openwrt/routing feed, as discussed in openwrt/routing#184. Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

BKPepe · 2026-08-06T09:52:06Z

+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Nick Hainke <vincent@systemli.org>
+Date: Thu, 17 Dec 2020 12:41:32 +0100
+Subject: [PATCH] add ubus bindings


@PolynomialDivision This is your patch, please take a look if it can be upstreamed or what to do with this one

openwrt-ai

Reviewed 1 new commit; the commit message matches the change. Packaging looks sound — conffiles layout, the procd init script, the 2-space/tab indentation split in the Makefile, and the literal BuildPackage,babeld all match the feed conventions, and src/ubus.c/ubus.h land in the build dir via the default Build/Prepare, so no explicit prepare step is needed.

The only finding I'd call a real defect is the uninitialized metric in babeld_ubus_add_filter() — one line, and worth fixing while the code is being moved rather than after. The unvalidated filter type next to it is a question, not a blocker. The rest are marked nit:, plus one non-blocking heads-up about this feed's generic runtime version check, which the routing feed does not run.

I left the patch's missing Signed-off-by/upstream reference alone since you've already raised the upstreaming question with @PolynomialDivision on that file.

Generated by Claude Code

openwrt-ai · 2026-08-06T09:58:55Z

+  struct blob_buf b = {0};
+  struct filter *filter = NULL;
+  char *ifname;
+  int metric, type;


metric is only assigned when tb[FILTER_METRIC] is present, but it is read unconditionally at filter->action.add_metric = metric; (ubus.c:109). metric is optional in filter_policy — only ifname and type are rejected when missing — so ubus call babeld add_filter '{"ifname":"eth0","type":0}' installs a filter whose metric is whatever was on the stack. In babeld a filter's add_metric of INFINITY means "deny", so a garbage value can silently turn an allow-filter into a deny-filter.

Suggested change

int metric, type;

int metric = 0, type;

Generated by Claude Code

openwrt-ai · 2026-08-06T09:59:04Z

+  if (!tb[FILTER_TYPE])
+    return UBUS_STATUS_INVALID_ARGUMENT;
+
+  type = blobmsg_get_u32(tb[FILTER_TYPE]);


type is taken straight from the ubus message and handed to add_filter(filter, type) without a range check, even though ubus.h:5-10 documents only 0..3 (FILTER_TYPE_INPUT … FILTER_TYPE_INSTALL) as valid.

I can't see babeld's add_filter() from this diff to confirm what it does with an out-of-range type — if it ends its if/else chain in abort() (as several babeld dispatchers do), an unexpected value from a ubus caller would take the daemon down rather than return an error. Would it be worth rejecting out-of-range values with UBUS_STATUS_INVALID_ARGUMENT here, so the validation doesn't depend on upstream's internals?

Generated by Claude Code

openwrt-ai · 2026-08-06T09:59:09Z

+# Babeld reads options from the following files (the last one takes precedence
+# if an option is defined in several places):
+# - the file defined by the option conf_file (default: /etc/babeld.conf),
+# - *.conf files in the directory defined by conf_dir (default: /tmp/babel.d/),


nit: the documented default directory disagrees with the init script. babeld.init:10 sets OTHERCONFIGDIR="/tmp/babeld.d/" (with a d), so a user who follows this comment and drops *.conf files into /tmp/babel.d/ gets them silently ignored. The init script is the authority here, so the comment is the side to fix:

Suggested change

# - *.conf files in the directory defined by conf_dir (default: /tmp/babel.d/),

# - *.conf files in the directory defined by conf_dir (default: /tmp/babeld.d/),

Same typo on line 26 below (# option 'conf_dir' '/tmp/babel.d/').

Generated by Claude Code

openwrt-ai · 2026-08-06T09:59:16Z

+             local_notify_neighbour_1(&local_sockets[i], neigh, kind);
+     }
+    if(ubus_bindings)
+	    ubus_notify_neighbour(neigh, kind);


nit: this added line indents with a tab followed by four spaces, while babeld indents with four spaces per level throughout (the if(ubus_bindings) line right above it is at four spaces). Since you're asking whether this patch can go upstream, it's worth normalising before it's sent:

Suggested change

+ ubus_notify_neighbour(neigh, kind);

+ ubus_notify_neighbour(neigh, kind);

Same tab+spaces indentation on lines 111 and 120 below (ubus_notify_xroute and ubus_notify_route). The line count is unchanged, so no patch refresh is needed.

Generated by Claude Code

openwrt-ai · 2026-08-06T09:59:22Z

+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=babeld
+PKG_VERSION:=1.13.1


Heads-up rather than a defect: this feed's CI runs a generic runtime check that executes each installed binary with version/help flags and expects PKG_VERSION in the output — the routing feed doesn't run that, so it's new surface for this package.

Two things make it worth a look before merge: babeld's own option parser is short-option based, and 600-add-ubus.patch rewrites generate-version.sh to emit "$version-ubus-mod". The suffix itself is harmless (1.13.1-ubus-mod still contains 1.13.1), but if $version resolves to unknown when building from the release tarball rather than a git checkout, the printed string won't contain 1.13.1 at all. If the check doesn't pass, the fix is a net/babeld/test-version.sh that returns 0 for this package. The multi-arch jobs were still queued when I looked, so I couldn't confirm either way.

Generated by Claude Code

The metric is optional in filter_policy: only ifname and type are rejected when missing, so `ubus call babeld add_filter '{"ifname":"eth0","type":0}'` reaches filter->action.add_metric = metric; with metric never assigned, i.e. whatever was left on the stack. In babeld an add_metric of INFINITY means "deny", so an uninitialized read can silently turn an allow filter into a deny filter. Initialize it to 0, which is the neutral value the filter would have had if the caller had passed it explicitly. Reported-by: openwrt-ai[bot] Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

openwrt-ai

Reviewed 1 new commit; no new issues found.

fc5110b does exactly what its message says — int metric = 0, type; in babeld_ubus_add_filter() — and closes the uninitialized-read path I flagged. Nothing else changed.

Two follow-ups from the previous round, for the record:

The generic runtime version check I warned about is answered: all ten Feeds Package Test Build jobs are green on fc5110b, so no net/babeld/test-version.sh is needed and the -ubus-mod version suffix is not a problem in practice.
Still open, both non-blocking and unchanged since they live in the moved-as-is code: the unvalidated filter type handed to add_filter(), the /tmp/babel.d/ vs /tmp/babeld.d/ typo in files/babeld.config, and the tab+spaces indentation in 600-add-ubus.patch. None of these need to hold up the move from the routing feed — they can be follow-ups here just as easily.

Generated by Claude Code

The package has been moved to the openwrt/packages feed, as discussed in openwrt#184. See openwrt/packages#30162. Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Copilot AI lite review requested due to automatic review settings August 6, 2026 08:10

openwrt Bot added Add package not following guidelines labels Aug 6, 2026

Copilot AI reviewed Aug 6, 2026

BKPepe mentioned this pull request Aug 6, 2026

treewide: remove packages moved to openwrt/packages openwrt/routing#1198

Merged

BKPepe force-pushed the add-babeld branch from d44f7c6 to 93f3f3d Compare August 6, 2026 09:36

openwrt Bot removed the not following guidelines label Aug 6, 2026

BKPepe commented Aug 6, 2026

View reviewed changes

openwrt-ai reviewed Aug 6, 2026

View reviewed changes

BKPepe assigned PolynomialDivision Aug 18, 2026

Navigation Menu

Uh oh!

babeld: add new package - #30162

babeld: add new package#30162
BKPepe wants to merge 2 commits into
openwrt:masterfrom
BKPepe:add-babeld

BKPepe commented Aug 6, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

BKPepe Aug 6, 2026

Uh oh!

openwrt-ai left a comment

Uh oh!

openwrt-ai Aug 6, 2026

Uh oh!

openwrt-ai Aug 6, 2026

Uh oh!

openwrt-ai Aug 6, 2026

Uh oh!

openwrt-ai Aug 6, 2026

Uh oh!

openwrt-ai Aug 6, 2026

Uh oh!

openwrt-ai left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

	# - *.conf files in the directory defined by conf_dir (default: /tmp/babel.d/),
	# - *.conf files in the directory defined by conf_dir (default: /tmp/babeld.d/),

	+ ubus_notify_neighbour(neigh, kind);
	+ ubus_notify_neighbour(neigh, kind);

Uh oh!

Conversation

BKPepe commented Aug 6, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

BKPepe Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

openwrt-ai left a comment

Choose a reason for hiding this comment

Uh oh!

openwrt-ai Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

openwrt-ai Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

openwrt-ai Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

openwrt-ai Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

openwrt-ai Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

openwrt-ai left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants