netifd (Network Interface Daemon) – Technical Reference

Project's git
netifd is available in OpenWrt since R28499 (trunk) and published under the GPLv2.
commits to OpenWrt trunk regarding netifd
Design of netifd

What is netifd?

netifd is an RPC-capable daemon written in C for better access to kernel APIs with the ability to listen on netlink events. Netifd has replaced the old OpenWrt-network configuration scripts, the actual scripts that configured the network, e.g.

/lib/network/*.sh,
/sbin/ifup
some scripts in /etc/hotplug.d.)

netifd is intended to stay compatible with the existing format of /etc/config/network, the only exceptions being rare special cases like aliases or the overlay variables in /var/state (though even most of those can be easily emulated).

Help with the development of netifd

test what has been ported
review of the code
help porting more of our protocol handler scripts (so far, static, ppp, pppoe, pppoa and dhcp are supported)

Why do we want netifd?

One thing that netifd does much better then old OpenWrt-network configuration scripts is handling configuration changes. With netfid, when the file /etc/config/network changes, you no longer have to restart all interfaces. Simply run /etc/init.d/network reload. This will issue an ubus-call to netifd, telling it to figure out the difference between runtime state and the new config and apply only that. This works on a per-interface level, even with protocol handlers written as shell scripts.

It boils down to the fact that the current network and interface setup mechanisms (via network configuration scripts) are rather constrained and inflexible:

lack of statefulness
tendency for raceconditions
inability to properly nest protocols
limited featureset of the ash shell which will not allow for complex interface operations like e.g. calculating ULAs
you name it

Netifd will be able to manage even complex interface configurations with a mix of bonding, vlans, bridges, etc. and handle the dependencies between interfaces properly - and of course all that without adding unnecessary bloat. AFAIK there are no alternatives to netifd, e.g. connman seems to be centered around one specifific use case only: having a mobile device access the internet through multiple connections.

OpenWrt – operating system architecture

Whereas desktop distributions use glib and dbus (and udev) OpenWrt uses libubox and ubus (and hotplug2). This provides some pretty awesome functionality without requiring huge libraries with huge dependencies (*cough* glib).

	Desktop Distributions		OpenWrt		Android	Replicant	mer-based
Typical main memory size	128 MiB to 16 GiB (or more)		32 MiB to 512 MiB¹⁾		min 92 MiB for Android 2.1 min 340 MiB for Android 4.0		?
Supported instruction sets	almost anything		almost anything		x86, 86-64, ARM, MIPS32
non-volatile storage space	100 MiB		8 MiB²⁾		150MiB for Android 2.1 512MiB for Android 4.0		?
kernel	`Linux kernel`
kernel	FOSS and binary drivers		FOSS drivers: e.g. 802.11; Iaccess		Android binary drivers
C standard library	glibc		uClibc		bionic	glibc + libhybris	eglibc 2.15
init	init Upstart Initng	`systemd`	busybox-initd	`procd`	Android init-fork		`systemd`
	rsyslog / syslog-ng		busybox-klogd, busybox-syslogd
	watchdog		busybox-watchdog
	udev		hotplug2	ubox?
	cron		`busybox-crond`
	atd		na
	D-Bus		ubus		Binder	?	D-Bus
network configuration	NetworkManager + GUI		`netifd`		ConnectivityManager (not ConnMan = ConnectionManager!)	?	ConnMan
	GLib (GObject, Glib, GModule, GThread, GIO)		libubox		?	?	Qt-based?
	PulseAudio		PulseAudio (optional)		PulseAudio	PulseAudio	PulseAudio
Package management system	dpkg/APT RPM/yum portage pacman …		`opkg`		apk	?	RPM

Dependencies of LuCI2

The idea for LuCI2 and its different components started a long time ago: http://luci.subsignal.org/trac/browser/luci2; Code is being developed here;

libubox (~ 12KiB) is a general purpose library which provides things like an event loop, binary blob message formatting and handling, the Linux linked list implementation, and some JSON helpers. The functions in libubox are used to write the other software in LuCI2
ubus (~ 13KiB) is an RPC daemon similar to D-Bus but with a much friendlier C API

ubox
mountd
rpcd

PulseAudio does not depend on GLib and does not seem to depends on D-Bus neither: LFS
FOSDEM2013: Can Linux network configuration suck less?

What's the difference between ubus and dbus?

dbus is bloated, its C API is very annoying to use and requires writing large amounts of boilerplate code. In fact, the pure C API is so annoying that its own API documentation states: "If you use this low-level API directly, you're signing up for some pain."

ubus is tiny and has the advantage of being easy to use from regular C code, as well as automatically making all exported API functionality also available to shell scripts with no extra effort.

"Of course, NetworkManager should be renamed to "unetwork", dbus to "ubus", PulseAudio to "usound", and X.Org-Server/Wayland-Compositor to "udisplay"; and then indescribable happiness would come down to all people of this world." – Lennart Poettering

→file_system / flash.layout
→internal.layout
→preinit_mount/process.boot/requirements.boot.process

¹⁾ yes, heavily stripped OpenWrt can run on 16 or even 8MiB

²⁾ yes, 4MiB and 2MiB possible

OpenWrt netifd

Table of Contents