Where do invalid/discarded settings (e.g. routes) get logged?

Aside: Purely a curiosity topic. Not actually using an actual device here, but some OpenWRT VMs to route between subnets (much basic). And obviously that's kind of a fringe case (else more people would ask for a console/dialog-style uci frontend.)

So I was trying to set up static routes, but made plenty of configuration mistakes. Such as default gateways for the subnet interfaces. And most notably setting a static route with wrong gateway and filtered on the wrong interface:

Nevermind the interface alias or subnet, but the route was assigned to the wrong device (wouldn't reach the fictitious gateway here). Therefore the route wouldn't show up in ip route after save/apply:

10.0.0.0/8 dev eth1 scope link  src 10.0.0.3 
192.168.0.0/16 dev eth2 scope link  src 192.168.0.1 
192.168.56.0/24 dev br-lan scope link  src 192.168.56.13  # VirtualBox-hostonly

So, of course you could either ① set it up correctly, ② use onlink, or ③ apply it ⏷unchecked.
But just for my curiosity, how would I find out the Luci setting got discarded?

There's no uci configcheck. Nor do there seem to be any log messages (logread, dmesg, /var/log/*) for the discarded route setting.

  • Normally you'd expect some RNETLINK error somewhere.
  • But despite conloglevel='8' there is only a stray odhcpd warning (doesn't seem relevant, nor say anything about routes).
  • And wiki:static-routes doesn't tell me much on where to look for errors.

(This was on 23.05rc3, but also 22.03. No difference in UI or logs.)

By comparing persistent and runtime configs:

  • LuCI > Network > Routing
  • LuCI > Status > Routing

Or by using CLI and testing it manually.


Although netifd supports log level customization:

> netifd -h 2>&1 | grep -i -e log
 -l <level>:		Log output level (default: 2)
 -S:			Use stderr instead of syslog for log messages

Those options are not implemented by the init script.

That's a great pointer!
netifd looks exactly like what I was looking for.

Unfortunately it doesn't yield much more (with -l 5 -d 15 -S) for routing misconfig.
Nor does the startup log message ("press [1][2][3][4] for log" only seems to effect udev/procd).

But discovered some uci_validate_route() and /sbin/validate_data along the way. Unfortunately just doing type checks at some stage. Probably also just gets involved for the init scripts.

So, yeah. It seems checking status/active routes is the way to go.