olsrd: add new package

[BKPepe]

Adds olsrd 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 plugin SONAME fix (also submitted upstream as OLSR/olsrd#137), the CI test-version.sh and the Makefile cleanup pending in openwrt/routing#1191.

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.

[BKPepe]

@PolynomialDivision Can you please upstream this patch? There is this issue: OLSR/olsrd#106 (comment)

[BKPepe]

This patch was added in openwrt/routing#774 by @PolynomialDivision. Any chance to upstream this?

[openwrt-ai]

Reviewed 1 new commit (c00dcbd, olsrd: add new package). The commit message matches what the diff does, the Makefile follows the indentation conventions (two spaces for metadata blocks, tabs for install recipes, no indentation in conffiles), literal package names are used in the BuildPackage calls, the SUBDIRS list matches the 19 olsrd-mod-* subpackages one-for-one, and test-version.sh avoids grep -q as required. ./src/src/ubus.{c,h} land in the build tree via package-defaults.mk:68 before Build/Patch, so patch 600 applies cleanly against them.

Findings, in the order I'd act on them:

Likely blockers

• olsrd-neigh.sh evals hostnames and IPs that arrive from other mesh nodes via the nameservice plugin — remote command injection.
• olsrd-utils is missing +jshn; the script cannot run at all without it.
• olsrd6.init reads the wrong UCI option name, so respawn_threshold is ignored.
• ubus.c leaves mult->next uninitialized before the pointer is published into a list olsrd traverses.

Worth deciding as part of the move

• The default olsrd_secure_key is a publicly known placeholder shipped as a conffile.
• The unconditional +iptables dependency only feeds firewall3-era chains that firewall4 does not create.

Most of these are inherited from the routing feed rather than introduced here, but a package re-entering this repo seems like the right moment to deal with them. CI is queued/green at this SHA, so nothing to report from there.

---

Generated by Claude Code

[openwrt-ai]

The UCI option is spelled respawn_threshold (no leading underscore) — see files/olsrd6.config:14 and the two config_get lines right below this one. As written the lookup never matches, so a user-configured respawn_threshold is silently ignored and the default 3600 is always used. olsrd4.init:49 has the correct name.

Suggested change

	config_get _respawn_threshold procd _respawn_threshold 3600
	config_get _respawn_threshold procd respawn_threshold 3600

---

Generated by Claude Code

[openwrt-ai]

olsrd-utils ships only olsrd-neigh.sh, whose third line is . /usr/share/libubox/jshn.sh. That file comes from the jshn package (package/libs/libubox/Makefile, Package/jshn/install), which is not pulled in by olsrd → libubus → libubox. Installing olsrd-utils on a minimal image gives olsrd-neigh: not found on the very first line.

Suggested change

	DEPENDS:=olsrd
	DEPENDS:=olsrd +jshn

---

Generated by Claude Code

[openwrt-ai]

Command injection: eval re-parses the string after the quotes have already been consumed by the first expansion pass, so eval IP_1_2_3_4="$hostname" with hostname = x;reboot evaluates as IP_1_2_3_4=x;reboot.

The values come from the nameservice plugin's hosts file (/var/run/hosts_olsr by default), which is populated from hostnames announced by other nodes in the mesh — i.e. a remote, unauthenticated input. $ip is interpolated into the variable name on the same line and is equally unchecked, and line 99 does the same with remoteIP taken from the txtinfo JSON.

Please reject anything that isn't a plain hostname/IP before it reaches eval, e.g. a guard in the [0-9]*) branch:

case "$ip$hostname" in *[!A-Za-z0-9.:_-]*) continue ;; esac

and the same filter on remoteIP before the eval at line 99.

---

Generated by Claude Code

[openwrt-ai]

Three problems in this block:

1. mult->next is never assigned. malloc() does not zero, and only ->addr and ->value are set. cnf->lq_mult is a singly-linked list that olsrd walks with for (mult = ...; mult != NULL; mult = mult->next), so the first traversal follows an uninitialized pointer. Note the preceding *tmp_ifs->cnf = *olsr_cnf->interface_defaults; is a shallow copy, so the defaults' lq_mult head is already in tmp_ifs->cnf->lq_mult at this point — either chain onto it (mult->next = tmp_ifs->cnf->lq_mult;) or terminate the new list explicitly (mult->next = NULL;) before the assignment on the next line. Whichever is intended, it has to be set.

2. orig_lq_mult_cnt++ is inconsistent with replacing the head. The count is inherited from interface_defaults by the shallow copy and then incremented, but lq_mult is overwritten with a one-element list. If the intent is a single multiplier, this should be = 1; if the intent is to prepend, see (1).

3. atof(lqm) on unvalidated ubus input. lqm is an arbitrary caller-supplied string; atof returns 0 on garbage with no way to tell it apart from a legitimate "0", and a negative or very large value makes (uint32_t)(lqm_value * LINK_LOSS_MULTIPLIER) undefined/wrapped. Please use strtod with endptr checking and clamp to the valid 0.0 … 1.0 multiplier range, returning UBUS_STATUS_INVALID_ARGUMENT otherwise.

---

Generated by Claude Code

[openwrt-ai]

This ships a hardcoded, publicly known shared secret (1234567890123456) as the default key for olsrd-mod-secure, and it is registered as a conffile, so it survives upgrades once installed. The whole point of that plugin is authenticating OLSR messages within a routing domain; every device that installs the package with the default in place accepts and produces signatures anyone can forge, which is arguably worse than not loading the plugin at all.

I realise this comes over unchanged from the routing feed, but since the package is being (re-)introduced here it seems worth fixing rather than carrying forward. Two options that avoid shipping a usable-looking default: drop the file from the package and have the plugin fail to start until the admin creates it, or generate a random key in a Package/olsrd-mod-secure/postinst / uci-defaults script. At minimum the file should say in a comment that it is a placeholder that must be replaced.

---

Generated by Claude Code

[DamisDorgon]

I don't use olsrd-mod-secure, but it looks like the key is there as an example placeholder. No one is expected to use it as is. If they want that feature, they are expected to know that some secret key material is going to be needed and to supply it, at least that's what I'd expect. A random key sounds dumb, since it needs to be shared between neighbors (?) and generating local random keys isn't going do that. Also, it is probably bad practice to generate secrets on embedded devices with (in general) not very good entropy sources, although maybe the low entropy will result in neighbors generating the same random key, so maybe it all works in the end.

See: https://github.com/OLSR/olsrd/blob/master/lib/secure/README_SECURE

[openwrt-ai]

Is the hard +iptables / +IPV6:ip6tables dependency still wanted? The only consumer is olsrd_setup_smartgw_rules() in files/olsrd.sh:749-816, and every rule it inserts targets the firewall3 chains forwarding_rule, input_rule and postrouting_rule. firewall4 (default since 22.03) does not create those chains, so on a stock image the inserts fail with "No chain/target/match by that name" while the dependency still drags legacy iptables onto every device that installs olsrd — including the ones that never enable SmartGateway.

If SmartGateway is still expected to work, the rules need an nftables path; if it is effectively dead, the dependency could at least be relaxed so olsrd doesn't pull iptables in unconditionally. Either way it would be good to decide this as part of the move rather than inherit it.

---

Generated by Claude Code

[openwrt-ai]

nit: bool olsrd_add_ubus(); declares an unprototyped function (pre-C23 empty parens accept any arguments) — the sibling declarations below correctly take explicit parameters, and olsrd_ubus_init(void) in ubus.c uses void. Same for the definition at ubus.c:219 and ubus_init_object() at ubus.c:179.

Suggested change

	bool olsrd_add_ubus();
	bool olsrd_add_ubus(void);

nit (separate): neither ubus.c nor ubus.h carries a copyright/licence header, while every other file under olsrd's src/ has the full BSD-3-Clause block that PKG_LICENSE:=BSD-3-Clause refers to. Since these two files are added by this feed rather than coming from the tarball, adding at least an SPDX line would make their licence unambiguous.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

Since c00dcbd the only change is the hunk header in 103-make-set-plugin-SONAME-to-the-installed-filename.patch gaining its LIBS += -lrt function context. That matches what make package/olsrd/refresh produces — OpenWrt's quilt wrapper runs with QUILT_DIFF_OPTS="-p" in include/quilt.mk:173 — so the patch is now consistent with the other two. The context-less hunks remaining in 102 and 600 are all anchored on #include / #define blocks, where diff -p has no preceding line to pick up, so those are correct as-is. The commit subject and body still describe what the diff does.

My earlier comments on olsrd-neigh.sh, olsrd6.init, the +jshn dependency, ubus.c, olsrd_secure_key and the +iptables dependency are untouched by this push and still stand. FormalityCheck is green at this SHA, with the umbrella job still queued.

---

Generated by Claude Code

[BKPepe]

Thanks for the thorough review — that is a genuinely useful list. I have pushed four fixes on top of the move commit, keeping the move itself verbatim so it stays reviewable:

• c8eebee — respawn_threshold lookup in olsrd6.init (the _respawn_threshold typo).
• 4d027db — +jshn for olsrd-utils.
• 1d68696 — mult->next in src/src/ubus.c. I chained the new node onto the existing list rather than terminating it with NULL, which is what the config file parser does for LinkQualityMult in src/cfgparser/oparse.y:123; that also makes the orig_lq_mult_cnt++ on the next line correct, since the entry really is prepended now.
• d47c0f4 — the eval injection in olsrd-neigh.sh, guarded in both places (the hosts file loop and remoteIP from the txtinfo JSON).

Two I would rather not decide unilaterally, both for @PolynomialDivision as maintainer:

olsrd_secure_key — you are right that shipping 1234567890123456 as a registered conffile is worse than shipping nothing, since it looks configured. Generating a random key in a uci-defaults script is the option I would pick (it keeps the package working out of the box while making every node's key unique), but that changes behaviour for existing installations on upgrade, so it needs the maintainer's call rather than mine.

+iptables / +IPV6:ip6tables — agreed the fw3 chains are dead on a fw4 image. Whether to port olsrd_setup_smartgw_rules() to nftables or relax the dependency depends on whether SmartGateway still has users, which I cannot tell from here.

I have deliberately left atof() in ubus.c alone for now — worth hardening as you say, but it is a behaviour change on the ubus API surface rather than a memory-safety issue, so it seemed better kept separate from the move.

[openwrt-ai]

Reviewed 5 new commits (c8eebee … 4715213).

The four fixes themselves look right:

• c8eebee — olsrd6.init:49 now reads respawn_threshold and matches olsrd4.init:49 and olsrd6.config:14.
• 1d68696 — mult->next is set before the node is published, and prepending keeps orig_lq_mult_cnt++ honest. Chaining onto the head inherited from the shallow *tmp_ifs->cnf = *olsr_cnf->interface_defaults; copy is the same aliasing the no-lqm path already has, so nothing new there.
• d47c0f4 — both guards sit on the right side of the trust boundary. $ip and $hostname at olsrd-neigh.sh:60 and $remoteIP at line 110 are the only values consumed by the first expansion pass; the other evals in that loop only expand their values inside the second pass, where a ; in the result is not re-parsed as a separator. Filtering these two covers it.
• 4715213 — passing VERS lets test-version.sh check the real PKG_VERSION (2024.06.09~d72be9ad, per download.mk:13) instead of just the olsr.org banner, and it still avoids grep -q.

One thing to fix before merge, inline on the Makefile: 4715213 silently reverts the +jshn dependency 4d027db added.

4d027db is left with an empty diff at head, so it and 4715213 probably want squashing or rewording either way.

Commit checks

• 4715213 "olsrd: report the packaged version in the binary" — the diff also contains a second, undocumented Makefile hunk reverting olsrd-utils' +jshn dependency. Subject and body describe only the VERS / test-version.sh change.

---

Generated by Claude Code

[openwrt-ai]

The +jshn dependency added by 4d027db is reverted here — the last commit, 4715213 ("olsrd: report the packaged version in the binary"), carries a second Makefile hunk that puts this line back to DEPENDS:=olsrd:

-  DEPENDS:=olsrd +jshn
+  DEPENDS:=olsrd

Nothing in that commit's subject or body mentions it, so it looks like a rebase/amend accident rather than a decision. The effect is that the bug 4d027db fixed is back at head: olsrd-neigh.sh:3 is still the only file olsrd-utils ships and it still sources /usr/share/libubox/jshn.sh, which olsrd → libubus → libubox does not pull in.

Suggested change

	DEPENDS:=olsrd
	DEPENDS:=olsrd +jshn

---

Generated by Claude Code

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

4715213 was amended into e7f24a2, and the only change between the two is the olsrd-utils line going back to DEPENDS:=olsrd +jshn — so the accidental revert of 4d027db is gone and that commit is no longer empty at head. The commit message of e7f24a2 now matches its diff exactly (the VERS flag plus the test-version.sh change), so the commit-check note from my last review is resolved.

test-version.sh greps for $PKG_VERSION unquoted-by--F, which at this SHA expands to 2024.06.09~d72be9ad per download.mk:13; VERS reaches the sub-makes as a command-line variable, and the plugins version their .so files from their own PLUGIN_VER, so the olsrd_*.so.* install globs are unaffected. Still no grep -q.

The open items from the earlier reviews — olsrd_secure_key, the unconditional +iptables, the atof() on ubus input, and the unprototyped olsrd_add_ubus() declaration — are untouched by this push and still stand as maintainer calls. FormalityCheck is green at this SHA; the per-target build jobs are queued.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 1 new commit (605206e, olsrd: record why the version check logs "Terminated").

The commit is comment-only — four tab-indented lines above the olsrd -v pipeline in test-version.sh, matching the file's existing indentation and the case arms below it. Subject and body describe exactly that, the check itself is unchanged, and it still avoids grep -q. Nothing to flag in it.

All 14 checks are green at this SHA, including the ten per-target build jobs; Test x86_64 reports All tests passed with the olsrd-utils version-check override passing.

Reading that job's log did turn up one thing on the moved code, inline on olsrd.sh:627: the WireGuard detection calls ip -details, which BusyBox ip does not implement, so it dumps the applet usage into the log and the interface is skipped.

The earlier open items — olsrd_secure_key shipped as a conffile with a publicly known value, the unconditional +iptables for fw3-era chains, and the atof() on ubus input — are untouched by this push and still stand as maintainer calls.

---

Generated by Claude Code

[openwrt-ai]

BusyBox ip has no -details option, so this branch never matches on a stock image and the applet prints its usage to stderr instead. The runtime test at this SHA shows it — from Test x86_64, during olsrd post-install:

* BusyBox v1.37.0 (2026-01-02 17:07:02 UTC) multi-call binary.
* Usage: ip [OPTIONS] address|route|link|neigh|rule [ARGS]
* OPTIONS := -f[amily] inet|inet6|link | -o[neline]
* olsrd: /etc/init.d/olsrd: olsrd_write_interface() Warning: Interface 'wlan' not found, skipped

The -details output only exists in iproute2's ip-full, which is not in DEPENDS at Makefile:37, so a WireGuard interface listed in config Interface falls through to the "not found, skipped" branch and is left out of the generated config. Reading the netdev kind from sysfs (/sys/class/net/$interface/uevent) would work with either ip applet; at minimum the call wants its stderr redirected so the usage dump stops appearing in the log for every non-WireGuard interface.

Inherited from the routing feed rather than introduced here, so this is a maintainer call on whether it belongs in the move commit or a follow-up — flagging it because the CI log at this head makes it concrete.

---

Generated by Claude Code

[thuehn]

@BKPepe ... you have removed certain essential routing packages from routing feed without having them upstream in packages ... so right now, there are none of those routing packages selectable ... that sounds not correct to me. the workaround is to manually merge your pullrequest in packages to my trunk env in order to get olsrd back working ... but please help to fix this for others by once a routing package is added to the package feed, than remove it from routing feed and add a big HINT to all for the current state of none of the routing packages are in trunk but as PR waiting

[BKPepe]

@thuehn Already replied here: openwrt/routing@925146d#commitcomment-196146204

​It's a snapshot, so things can break. Looking at the automated review here, there are a few things that need to be addressed before merging. Ask the maintainer, not me. Otherwise, we'd be stuck here forever, and we need to move forward. Anyone using this package can review it instead of pointing fingers.

[jonasjelonek]

Ok, here's my review so far: Please move those commits fixing issues to a separate PR for review by people who are able to review it properly, and leave this PR just with the "olsrd: add new package". Then I guess you can merge asap if it just a 1:1 copy.

EDIT: Snapshot doesn't mean "this will be broken on purpose with a commit", rather "it can be broken due to lack of testing".

[BKPepe]

You can't seriously expect me to just merge this "#yolo style", right? :)

I am definitely not taking personal responsibility for merging it as-is, especially considering the remote command injection vulnerability and missing dependencies pointed out here: #30170 (review), that's such a bad approach.

Regarding the year-old issue openwrt/routing#184 (comment) and the complaints about the delay: it is finally getting the attention it deserves. I know that someone e.g like you might not like how it is, but it is what it is.

As you can read in that thread, there were previous attempts to add the packages, but we keep hitting the same wall – we lack the manpower, we lack active maintainers, and essentially, nobody is taking care of it. I understand your perspective and respect it. However, anyone who urgently needs this package can simply compile it from source until we manage to get it into a proper state.

And realistically, if we don't merge it now, this pull request is just going to hang here for a while anyway. Just look at the sheer number of open pull requests compared to the few active people we have.

While I appreciate everyone writing long essays here about how things should be solved, how about we get proactive? It would be much more productive if you guys reached out directly to the maintainers and pushed them to get their act together. :-)

---

It is just two days. Not a big deal.

[DamisDorgon]

If Linus Torvalds was here, he would be screaming about "Do not break userspace". If you don't want to merge something here, the sane alternative is to not remove it from routing feed until it DOES merge here.

[PolynomialDivision]

Keep this PR now as it is. The secure key, SmartGateway/iptables, WireGuard detection and ubus input validation can be handled as follow-ups.

[BKPepe]

If Linus Torvalds was here, he would be screaming about "Do not break userspace". If you don't want to merge something here, the sane alternative is to not remove it from routing feed until it DOES merge here.

Oh, sorry for being rude here, but I like this for newly created account. You should take a look what snapshot, well, master builds and in the OpenWrt documentation, what it means IMHO. And if Linus Torvalds would join the party here, I would really appreciate to be known and recognized by him. :-))

It seems this has turned into a complete shitshow over the removal of just one single package ('cg' from the community feed). I stand by my decision and I know why I did it. You could compile your package yourself, it is not critical or crucial having this on the router.

As I’ve already mentioned, everyone had the opportunity to contribute and help out. That didn't happen. Instead, we're arguing here like kids in a sandbox. It's incredibly frustrating to think about how much time I've spent on this thread instead of doing actual productive work.

I think I already explained all the reasoning and I don't want to repeat myself e.g. saying IF WE WOULD WAIT UNTIL EVERYTHING IS NICE AND POLISHED, WE WOULD NOT GET ANYWHERE.

And also... having this discussion on multiple places just great.

The secure key, SmartGateway/iptables, WireGuard detection and ubus input validation can be handled as follow-ups.

@PolynomialDivision: I certainly don't want them to forget about it, create an issue about it and that you look at it and I won't get it like with bird openwrt/routing#1173 since March we keep coming back to it.

[jonasjelonek]

You can't seriously expect me to just merge this "#yolo style", right? :)

Yet you did the yolo style package removal in the routing feed.

[thuehn]

@BKPepe ... issue on my side fixed @upstream ... so you did triggered attention and multiple people got involved and sholrtly fixed olsrd in my case on trunk ... we are on trunk since years to have mesh wifi & early stuff available and shurely helping out as trunk is to be fixed all time as team effort ...

no hard feeling from my side ... just that I do think your way of moving olsrd routing package from one feed to another is a commit where no maintainer needs to be included (call it yolo style - what was a problem before stays .. what did worked stays as well - untouched) .. and all olsrd code changes can be handeld as PR as usual in the new feed repo ...

I am happy having just build trunk for our Freifunka Mesh network on those 5 out of 110 openwrt mesh routers for the x86 target and all routes are back for proper meshing ;)

Greetz Bluse

[DamisDorgon]

If Linus Torvalds was here, he would be screaming about "Do not break userspace". If you don't want to merge something here, the sane alternative is to not remove it from routing feed until it DOES merge here.

Oh, sorry for being rude here, but I like this for newly created account. You should take a look what snapshot, well, master builds and in the OpenWrt documentation, what it means IMHO. And if Linus Torvalds would join the party here, I would really appreciate to be known and recognized by him. :-))

I've been contributing to OpenWrt since 2006-ish. Not sure it's relevant, but I do know Linus, although barely.

It seems this has turned into a complete shitshow over the removal of just one single package ('cg' from the community feed). I stand by my decision and I know why I did it. You could compile your package yourself, it is not critical or crucial having this on the router.

I ended up just checking out the pre-removal routing feed. I am also a batman-adv user so the deletion of batctl and alfred also popped up on my radar. I do compile the packages myself. However, your deletion-before-merge was unnecessarily disruptive to other people also using OpenWrt. You are hearing about it because of that and because you seem to think that doing so was fine and no problem. Please be more considerate next time, it is not just your personal playground.