Openwrt NETIFD Ubus Analysis

Original address: http://xinliang.me/blog/?p=149

OpenWrt creates a separate PROJECT,NETIFD for network interface management and configuration. Unlike other distributions that are used for the same problem areas, NETIFD's goal is to be more suitable for use on embedded Home-gateway, and therefore has some features. Package composition

The NETIFD contains the following components:

1. Shell script:/sbin/ifup,/sbin/ifdown (link to ifup),/sbin/ifstatus,/sbin/devstatus
2. INIT.D Script:/etc/init.d/network
3. HOTPLUG2 script:/etc/hotplug.d/iface/00-netstate,/etc/hotplug.d/iface/10-sysctl
4. UDHCPC Script:/usr/share/udhcpc/default.script
5. NETIFD Daemon binary:/SBIN/NETIFD

These components are analyzed in order to understand the basic working mechanism of NETIFD.

Shell Script/sbin/ifup

As mentioned earlier, Ifdown is actually a symbolic link to ifup, so the two scripts are implemented ifup the same file. Here's the syntax:

1234

Syntax:/sbin/{ifup|ifdown} [-A] [-W] [interface]-a option indicates that the same operation is performed on all interfaces, at which time interface is ignored. This parameter defaults to the FALSE-W option to specify whether to perform a WiFi up operation. If this parameter is specified, the WiFi up operation will not be executed. If not specified, the WiFi up will be executed interface the target interface for the specified down/up operation when ifup

In Ifup's script, the operation on WiFi is performed through the/sbin/wifi script, so it is not discussed here for the time being. With respect to the if down/up operation of Normal, this script is implemented by the Ubus command. Here is a if_call () function:

123456

If_call () {local interface= "$" for mode in $modes; Doubus call $interface $modedone}

You can see that this function has a parameter, is interface, and then also uses a global parameter, modes, is defined in the Ifup script, as follows:

12345678

Case "In*ifdown") modes=down;; *IFUP) modes= "Down Up" setup_wifi=1; *) echo "Invalid command: $ A";; Esac

Therefore, when the Ifdown LAN is executed, the corresponding Ubus command is "Ubus call Network.interface.lan down"; When you execute Ifup LAN, the Ubus command is two, first execute "Ubus call Network.interface.lan down ", then" Ubus call Network.interface.lan up ".

Ubus & UBUSD

OPENWRT provides a ubus system that resembles the Dbus of a desktop Linux system and is intended to provide system-level IPC and RPC. Ubus is fundamentally consistent with Dbus in design concepts, with a simplified API and a concise model to suit the special environment of embedded router.
Basically, OpenWrt's ubus consists of the following components:

2. UBUSD, this is the Ubus system background process, is responsible for registering UNIX domain sockets, dispatching Ubus messages and events, etc.;
4. Ubus, which is a CLI utility, can access the Ubus system through it. Ubus's help information is as follows:
   

   1234567891011

   Usage:ubus [Options] <command></command> [arguments ...] Options:-s:set the UNIX domain socket to connect to-t: Set The timeout (in seconds) for a command to complete-s: Use Si  Mplified output (for scripts)-v:more verbose outputcommands:-list [] list Objects-call [] Call an object Method-listen [...] Listen for Events-send [] Send an event

   
   Ubus provides 4 types of command: list, call, listen & Send, with these four command, access to the services registered to the Ubus system
6. The last is the various applications that use Ubus. These applications can register RPC interfaces in the Ubus system and provide the appropriate services. Other programs can use these interfaces to access these services.

Ubus RPC Interface for NETIFD

NETIFD is registered in the Ubus system with the following object:

12345678910111213141516171819202122232425262728293031323334353637383940

[email protected]:/# ubus list-v ' network '  @25a06dad "restart":  { } "reload":  { } "add _host_route ": { " target ": " String ", " V6 ": " Boolean " }" Get_proto_handlers ":  { } ' Network.device '  @9d97d655 "status": {  "name":  "String"  } "Set_alias":  {   "Alias":  "(unknown)",  "Device":  "String"  } "Set_state": {  "name":  " String ", " defer ": " Boolean " } ' Network.interface.lan '   @f9e7258b" up ":  { }" Down ":  { } "status":  { } "prepare":  { } "Add_device": {  "name":  "String"  } "Remove_device": {  "name":  "String"  } "Notify_proto":  { } "Remove":  {  } "Set_data":  { } ' Network.interface.loopback '  @6d026db0 "up":  { } "down":  {  } "status":  { } "prepare":  { } "Add_device": {  "name":  "String"  } " Remove_device ":   {  "name":  "String"  } "Notify_proto":  { } "remove":  { } "Set_data":  {  } ' Network.interface.wan '   @ade92c65 "up":  { } "down":  { } "status":  { } " Prepare ":  { }" Add_device ": { " name ": " String " }" Remove_device ": { " Name ": " String " }" Notify_proto ":  { }" remove ":  { }" Set_data ":  { }

The RPC interface name provided by each object, as well as the interface parameter type, can be obtained by Ubus

Netifd Interface RPC

NETIFD registers a set of identical methods for each interface object, as follows:

static struct Ubus_method iface_object_methods[] = {{. Name = ' Up ',. Handler = Netifd_handle_up}, {. name = "Down",. Han Dler = Netifd_handle_down}, {. name = "Status",. Handler = Netifd_handle_status}, {. name = "Prepare",. Handler = NETIFD _handle_iface_prepare}, Ubus_method ("Add_device", Netifd_iface_handle_device, Dev_policy), UBUS_METHOD ("remove_ Device ", Netifd_iface_handle_device, Dev_policy), {. Name =" Notify_proto ",. Handler = Netifd_iface_notify_proto}, {. na me = "Remove",. Handler = Netifd_iface_remove}, {. name = "Set_data",. Handler = Netifd_handle_set_data},};

1234567891011

static struct ubus_method iface_object_methods[] =  {{ .name =  "Up",  .handler = netifd_handle_up },{ .name =   "Down", .handler = netifd_handle_down },{ .name =  "status",  . handler = netifd_handle_status },{ .name =  "Prepare", .handler =  Netifd_handle_iface_prepare },ubus_method ("Add_device",  netifd_iface_handle_device, dev_policy  ), Ubus_method ("Remove_device", netifd_iface_handle_device, dev_policy ), { .name  =  "Notify_proto",  .handler = netifd_iface_notify_proto },{ .name =   "Remove", .handler = netifd_iface_remove },{ .name =  "Set_data",  .handler = netifd_handle_set_data },};

It can then be found that NETIFD also has a concept of protocol handler, that is, to different interface protocol, can provide different handler to respond to various possible events. The most common type of static protocol, built into the NETIFD. Dhcp,pppoe and other types of protocols are provided in shell script form.

NETIFD protocol Handler plug-in

NETIFD's protocol handler plug-in is located in the/lib/netifd/proto/directory, with the name unified to *.sh.

Openwrt NETIFD Ubus Analysis