OpenWrt/LEDE Project

Welcome to the OpenWrt/LEDE Project bug reporting and issue tracking system

Problems to be reported here are for the OpenWrt/LEDE Project targets, sources, toolchain, core packages, build procedures, distribution and infrastructure. Guidelines for submitting a good bug report can be found at the OpenWrt/LEDE Project website. Problems related to LuCI or OpenWrt packages need to be reported in their repositories:

Notifications of all submissions and task changes are sent to lede-bugs@infradead.org.

OpenedIDCategoryTask TypePrioritySeveritySummaryReported InStatus
21.04.20203030Base systemBug ReportVery LowLowopenvn connections don't start on boot -- libubox probl...TrunkUnconfirmed Task Description

As discussed on IRC, on multiple 19.07.2 devices, openvpn configurations which use /etc/config/openvpn don’t start automatically on boot. They try to but the openvpn command issued ends up being invalid:

# ubus call service list '{ "verbose": true, "name": "openvpn" }'
{
	"openvpn": {
		"instances": {
			"foo": {
				"running": false,
				"command": [
					"/usr/sbin/openvpn"
				],
				"term_timeout": 5
			}
		},
		"triggers": [
			[
				"config.change",
				[
					"if",
					[
						"eq",
						"package",
						"openvpn"
					],
					[
						"run_script",
						"/etc/init.d/openvpn",
						"reload"
					]
				],
				1000
			]
		]
	}
}

As you can see, the arguments for the openvpn command are missing.

The /etc/config/openvpn configuration for this:

# cat /etc/config/openvpn
package openvpn

config openvpn 'foo'
	option nobind '1'
	option float '1'
	option client '1'
	option comp_lzo 'yes'
	option reneg_sec '0'
	option dev 'tun'
	option verb '3'
	option persist_tun '1'
	option persist_key '1'
	option auth_user_pass '/etc/openvpn/userpass'
	option remote 'vpn.example.com 1194'
	option ca '/etc/openvpn/ca.crt'
	option script_security 2
	option up /etc/openvpn/script
	option down /etc/openvpn/script
	#option link_mtu 1542
	option cipher 'AES-256-CBC'
	option enabled '1'
30.01.20202786Base systemBug ReportVery LowLowlibubox: usock: usock_inet_timeout() does not try all s...TrunkUnconfirmed Task Description

usock_inet_timeout() does not try all possible ipv6 and ipv4 server addresses if getaddrinfo() returns multiple records on the same family.

Also, it does not allow one to easily differentiate server-not-found (or other getaddrinfo() issue) from connect timeout, from connect refused.

To try all possible servers, one can either attempt to connect() to all of them in parallel (which seems too aggressive), or try to keep one connect() in progress for each family, replacing it with the next possibility should it return ECONNREFUSED, until the timeout expires.

Defining the use of errno should not be a problem, since it was undefined before so it is backwards-compatible:

If getaddrinfo() returns an error, it would be best to return -1, errno=ENOENT.
If none of the servers connect, return ECONNREFUSED if *at least one of them* returned ECONNREFUSED, or ETIMEDOUT otherwise (i.e. all timed out).

If timeout is zero, we return a socket that is likely to be in-progress and might fail to connect. That’s fine, just try IPv6 first.

30.01.20202784Base systemBug ReportVery LowMediumlibubox: usock: poll_restart() broken, affects usock_in...TrunkUnconfirmed Task Description

on libubox/usock.c:

poll_restart() is trying to use the return of poll() as if it were errno.

This renders the error paths in that function ineffective, and most likely result in errors being hidden. The function will spin around until it times out, and mask the real error.

This impacts the “happy eyeballs” code on usock_inet_timeout(), plus any other users of poll_restart().

21.01.20202758Base systemBug ReportVery LowLowlibubox: lua: cmake forces install prefix TrunkUnconfirmed Task Description

the CMakeLists.txt in libubox/lua is installs to LUAPATH, which is detected via the (badly versioned) raw lua call, which results in an absolute path, so the library destination call ignores the prefix

cmake -DCMAKE_INSTALL_PREFIX:PATH=/home/karlp/.local

eg:
– Installing: /home/karlp/.local/share/libubox/jshn.sh
– Installing: /usr/lib64/lua/5.3/uloop.so «< neither 5.1, nor within /home/karlp/.local

This is just awkward when building local versions of things

git version: 43a103ff17 (side note, tags in this repo wouldn’t hurt)

25.11.20181970Base systemBug ReportVery LowMediumlibubox: Parsing empty blob messages return an errorTrunkUnconfirmed Task Description

Since commit c83a84afbef (fix segfault when passed blobmsg attr is NULL) parsing an empty message, like when “{}” is passed as argument to `ubus call`, return an error, it was working just fine before this commit.

This mean that ubus methods with only optional arguments need to check that blob_len() doesn’t return 0, which is annoying and might break various existing programs. At the very least blobmsg_parse() shouldn’t error out when the blob length is 0, but it might also make sense to accept a NULL message as well, just don’t segfault.

13.11.20181948Base systemFeature RequestVery LowLowlibubox and libubus in C++ codeAllUnconfirmed Task Description

Hello,

we try to develop UBUS and UCI application in C++. For now we are not able to compile our applications without patching ubus and libubox in the following way.

[develict@DCompiler ~]$ tmux att -t 8
--- a/libubus.h
+++ b/libubus.h
@@ -14,6 +14,10 @@
 #ifndef __LIBUBUS_H
 #define __LIBUBUS_H

+#ifdef __cplusplus
+extern "C" {
+#endif
+
 #include <libubox/avl.h>
 #include <libubox/list.h>
 #include <libubox/blobmsg.h>
@@ -414,4 +418,8 @@ static inline int ubus_unregister_event_
     return ubus_remove_object(ctx, &ev->obj);
 }

+#ifdef __cplusplus
+}
+#endif
+
 #endif

Is it possible to use this libraries without its patching?

 


19.02.20181374PackagesBug ReportVery LowHighubox: logd memory leak AllUnconfirmed Task Description

I checked the use of memory with `top` command and saw that the logd was consuming memory disproportionately (around 60MB).

```
PID PPID USER STAT VSZ VSZ %CPU COMMAND
971 1 root S 59768 48% 0% /sbin/logd -S 64
```

- There was no remote log configured.
- I was using logread -f for a long time.
- When doing an /etc/init.d/log restart the consumed memory returned to normality.
- ubox version:

```
PKG_SOURCE_DATE:=2017-09-01
PKG_SOURCE_VERSION:=b1bc8d5fb874cdd22701a08d0fb0de4330f86814
PKG_MIRROR_HASH:=b07e750d941d691e2745aa3a058e504966b15d1db5636162dc686bad275eb296
```


Showing tasks 1 - 7 of 7 Page 1 of 1

Available keyboard shortcuts

Tasklist

Task Details

Task Editing