[netifd] sbin/uci: Invalid argument

For Developers
1

{"kernel":"5.4.45","hostname":"OpenWrt","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"OpenWrt","version":"SNAPSHOT","revision":"r13533-69f6fc7b15","target":"mvebu/cortexa9","description":"OpenWrt SNAPSHOT r13533-69f6fc7b15"}}

Having debugging enabled for netid the log exhibits

netifd: Interface 'wan_6' is now up
netifd[1904]: /sbin/uci: Invalid argument

This happens after WAN connectivity is established and apparently non-fatal but perhaps something is not right nonetheless. Is there a way to find out what this about?

2

As far as I could gather this gets printed by https://git.openwrt.org/?p=project/uci.git;a=blob;f=lua/uci.c;hb=ec8d3233948603485e1b97384113fac9f1bab5d6#l340

but I do not comprehend the check being done here

if (!lua_isfunction(L, 3 + offset) || !package)

that leads to the output?

lua_isfunction seems to be related to neighbor_dump(lua_State *L) in https://git.openwrt.org/?p=project/luci.git;a=blob;f=libs/luci-lib-ip/src/ip.c;hb=b39754907ce904747bc03cd5f7b08d682f8fc5e3#l1466

Wondering whether a LUA package is potentially missing?

opkg list-installed *lua*
libiwinfo-lua - 2020-06-03-2faa20e5-1
liblua5.1.5 - 5.1.5-7
liblua5.3-5.3 - 5.3.5-4
liblucihttp-lua - 2019-07-05-a34a17d5-1
libubox-lua - 2020-05-25-66195aee-1
libubus-lua - 2020-02-05-171469e3-1
lua - 5.1.5-7
lua-cjson - 2.1.0-2
lua-lzlib - 0.4.3-1
lua-openssl - 0.7.4-1
lua-sha2 - 0.2.0-1
lua5.3 - 5.3.5-4
luac5.3 - 5.3.5-4
luaexpat - 1.3.0-1
luasocket - 2019-04-21-733af884-1
luasocket5.3 - 2019-04-21-733af884-1
uhttpd-mod-lua - 2020-06-03-939c281c-1
3

Is there no way debug those UCI calls?

I suspect the calls are related to ip.c's routines .callback = lua_isfunction for

  • route_dump
  • neighbor_dump

though there is no issue with it in LuCI.

4

None of the netifd protocol handlers uses any Lua code. It would help to know how your WAN interface is configured... DHCP, PPPoE etc. to limit the search scope.

5

I reached there by looking at the UCI code base that potentially prints

which appeared to be

config interface 'wan'
	option proto 'pppoe'
	option layer '1'
	option username ''
	option password ''
	option keepalive '6 10'
	option ifname 'eth2'
	option ipv6 'auto'
	option pppd_options 'passive debug kdebug 7'
	option padi_timeout '20'
	option peerdns '0'
6

Some proto handler script or some hotplug script indirectly invoked produces a faulty uci command line. You could move /sbin/uci to /sbin/uci.real and replace it with a wrapper script that passes its command lines to syslog:

mv /sbin/uci /sbin/uci.real
cat <<EOT > /sbin/uci
#!/bin/sh
logger -t uci-debug "\$@"
exec /sbin/uci.real "\$@"
EOT
chmod +x /sbin/uci

Reproduce the message and check logread to see which commands were invoked.

To restore, simply run mv /sbin/uci.real /sbin/uci.

1 Like
7

thank you for the little helper, which produces

netifd: Interface 'wan_6' is now up
uci-debug: revert network.wan_6.up
uci-debug: set network.wan_6.up=1
netifd[3598]: /sbin/uci.real: Invalid argument
uci-debug: revert network.wan_6.ifname
uci-debug: set network.wan_6.ifname=pppoe-wan
netifd[3598]: /sbin/uci.real: Invalid argument
8

ifstatus wan_6 produces an output as does uci show network.wan however

uci show network.wan_6
uci: Entry not found

whilst

ubus list network.interface.wa*
network.interface.wan
network.interface.wan_6
9

The warning is caused by /etc/hotplug.d/iface/00-netstate which sets uci state variable for backwards compatibility with very old applications.

Since both uci state variables in general, and the interface up and ifname state variables in particular are long deprecated, we should probably drop this hotplug script.

The root cause is that the hotplug script attempts to set state variables for a virtual interface which is not backed by uci configuration, hence the invalid argument error.

1 Like
10

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.