Differences

This shows you the differences between two versions of the page.

--- docs:techref:ubus [2021/01/06 21:05] – [Access to ubus over HTTP] stokito
+++ docs:techref:ubus [2023/12/22 11:56] (current) – Add required 'Content-type: application/json' to curl examples. mikma
@@ Line 1: / Line 1: @@
 ====== ubus (OpenWrt micro bus architecture) ======
+See also:
+[[https://hackmd.io/@rYMqzC-9Rxy0Isn3zClURg/H1BY98bRw|What is UBUS?]]
-To provide [[wp>Inter-process_communication|Inter-process communication]] between various daemons and applications in OpenWrt a project called ''ubus'' has been developed. It consists of several parts including daemon, library and some extra helpers.
+To provide [[wp>Inter-process_communication|Inter-process communication]] between various daemons and applications in OpenWrt a project called ''ubus'' has been developed.
+It consists of several parts including daemon, library and some extra helpers.
+The heart of this project is the ''ubusd'' daemon.
-The heart of this project is the ''ubusd'' daemon. It provides an interface for other daemons to register themselves as well as sending messages. For those curious, this interface is implemented using Unix sockets and it uses [[wp>Type-length-value|TLV (type-length-value)]] messages.
+It provides an interface for other daemons to register themselves as well as sending messages.
+For those curious, this interface is implemented using Unix sockets and it uses [[wp>Type-length-value|TLV (type-length-value)]] messages.
 To simplify development of software using ''ubus'' (connecting to it) a library called ''libubus'' has been created.
-Every daemon registers a set of paths under a specific namespace. Every path can provide multiple procedures with any number of arguments. Procedures can reply with a message.
+Every daemon registers a set of paths under a specific namespace.
+Every path can provide multiple procedures with any number of arguments.
+Procedures can reply with a message.
 The code is published under [[wp>GNU_Lesser_General_Public_License|LGPL 2.1 license]] and can be found via git at [[https://git.openwrt.org/project/ubus.git]].
 ===== Command-line ubus tool =====
+The ''ubus'' command line tool allows to interact with the ''ubusd'' server (with all currently registered services).
+It's useful for investigating/debugging registered namespaces as well as writing shell scripts.
+For calling procedures with parameters and returning responses it uses the user-friendly JSON format.
+Below is an explanation of its commands.
-The ''ubus'' command line tool allows to interact with the ''ubusd'' server (with all currently registered services). It's useful for investigating/debugging registered namespaces as well as writing shell scripts. For calling procedures with parameters and returning responses it uses the user-friendly JSON format. Below is an explanation of its commands.
+==== Help output ====
-==== Help Output ====
 <code>
-root@OpenWrt:~# ubus
+# ubus
 Usage: ubus [<options>] <command> [arguments...]
 Options:
@@ Line 38: / Line 45: @@
  - monitor				Monitor ubus traffic
 </code>
 ==== list ====
-To find out which services are currently running on the bus simply use the ''ubus list'' command. This will show a complete list of all namespaces registered with the RPC server:
+To find out which services are currently running on the bus simply use the ''ubus list'' command.
+This will show a complete list of all namespaces registered with the RPC server:
-<code>root@OpenWrt:~# ubus list
+<code>
+# ubus list
 dhcp
 dnsmasq
@@ Line 68: / Line 76: @@
 You can filter the list by specifying a service path:
-<code>root@OpenWrt:~# ubus list network.interface.*
+<code>
+# ubus list network.interface.*
 network.interface.lan
 network.interface.loopback
@@ Line 77: / Line 86: @@
 To find out which procedures/methods and their argument signatures a specific service provides add ''-v'' in addition to the namespace path:
-<code>root@OpenWrt:~# ubus -v list network.interface.lan
+<code>
+# ubus -v list network.interface.lan
 'network.interface.lan' @099f0c8b
 	"up": {  }
@@ Line 91: / Line 101: @@
 ==== call ====
 Calls a given procedure within a given namespace and optionally pass arguments to it:
-<code>root@OpenWrt:~# ubus call network.interface.wan status
+<code bash>
+# ubus call network.interface.wan status
 {
 	"up": true,
@@ Line 124: / Line 134: @@
 The arguments must be a valid JSON string, with keys and values set according to the function signature:
-<code>root@OpenWrt:~# ubus call network.device status '{ "name": "eth0" }'
+<code bash>
+# ubus call network.device status '{ "name": "eth0" }'
 {
 	"type": "Network device",
@@ Line 161: / Line 172: @@
 ==== listen ====
+Set up a listening socket and observe incoming events:
-Setup a listening socket and observe incoming events:
+<code bash>
+# ubus listen &
-<code>root@OpenWrt:~# ubus listen &
+# ubus call network.interface.wan down
-root@OpenWrt:~# ubus call network.interface.wan down
 { "network.interface": { "action": "ifdown", "interface": "wan" } }
-root@OpenWrt:~# ubus call network.interface.wan up
+# ubus call network.interface.wan up
 { "network.interface": { "action": "ifup", "interface": "wan" } }
 { "network.interface": { "action": "ifdown", "interface": "he" } }
@@ Line 176: / Line 187: @@
 ==== send ====
 Send an event notification:
-<code>root@OpenWrt:~# ubus listen &
+<code bash>
-root@OpenWrt:~# ubus send foo '{ "bar": "baz" }'
+# ubus listen &
+# ubus send foo '{ "bar": "baz" }'
 { "foo": { "bar": "baz" } }
 </code>
 ===== Access to ubus over HTTP =====
+There is an ''uhttpd'' plugin called ''uhttpd-mod-ubus'' that allows ''ubus'' calls using HTTP protocol.
-There is an ''uhttpd'' plugin called ''uhttpd-mod-ubus'' that allows ''ubus'' calls using HTTP protocol. For example this is used in [[docs:techref:luci2|LuCI2]]. Requests have to be send to the ''/ubus'' URL (unless changed by ''ubus_prefix'' option) using ''POST'' method. This interface uses [[https://www.jsonrpc.org/specification|jsonrpc v2.0]]  There are a few steps that you will need to understand.
+For example this is used in [[docs:techref:luci2|LuCI2]].
+Requests have to be sent to the ''/ubus'' URL (unless changed by ''ubus_prefix'' option) using the ''POST'' method.
+This interface uses [[https://www.jsonrpc.org/specification|jsonrpc v2.0]]  There are a few steps that you will need to understand.
 If uhttpd-mod-ubus is installed, uhttpd automatically configures it and enables it, by default at /ubus, but you can [[docs:guide-user:services:webserver:uhttpd|configure this]]
-Also if you want to use the ''/ubus'' directly from web client you need to specify ''ubus_cors=1'' option.
+Also if you want to use the ''/ubus'' directly from a web client you need to specify ''ubus_cors=1'' option.
-If you are using Nginx then you may try [[https://github.com/Ansuel/nginx-ubus-module|nginx-ubus-module]]
+If you are using Nginx then you may try [[https://github.com/Ansuel/nginx-ubus-module|nginx-ubus-module]].
+For other web servers like Lighttpd you may use the [[https://github.com/yurt-page/cgi-ubus|ubus as CGI]].
 See the [[https://documenter.getpostman.com/view/5972215/TVzNHeej#154b5d84-4065-4887-a5a8-c1f3b51fe9a6|Postman collection]] with some examples of calling UBUS over HTTP
 ==== ACLs ====
+While logged in via ssh, you have direct, full access to ubus.
+When you're accessing the ''/ubus'' url in uhttpd however, uhttpd first queries whether your call is allowed, and whoever is providing the ubus ''session.*'' namespace is in charge of implementing the access control:
-While logged into via ssh, you have direct, full access to ubus. When you're accessing the ''/ubus'' url in uhttpd however, uhttpd first queries whether your call is allowed, and whoever is providing the ubus ''session.*'' namespace is in charge of implementing the access control:
+<code bash>
-<code>
 ubus call session access '{ "ubus_rpc_session": "xxxxx", "object": "requested-object", "function": "requested-method" }'
 </code>
+This happens to be ''rpcd'' at the moment, with the ''http-json'' interface, for friendly operation with browser code, but this is just one possible implementation.
+Because we're using rpcd to implement the ACLs at this time, this allows/requires (depending on your point of view) ACLs to be configured in ''/usr/share/rpcd/acl.d/*.json''.
+The __names__ of the files in ''/usr/share/rpcd/acl.d/*.json'' don't matter, but the top level keys define roles.
+The default ACL, listed below, __only__ defines the login methods, so you can log in, but you still wouldn't be able to do anything.
-This happens to be ''rpcd'' at the moment, with the ''http-json'' interface, for friendly operation with browser code, but this is just one possible implementation.  Because we're using rpcd to implement the ACLs at this time, this allows/requires (depending on your point of view) ACLs to be configured in ''/usr/share/rpcd/acl.d/*.json''.  The __names__ of the files in ''/usr/share/rpcd/acl.d/*.json'' don't matter, but the top level keys define roles.  The default acl, listed below, __only__ defines the login methods, so you can login, but you still wouldn't be able to do anything.
 <code javascript>
 {
@@ Line 219: / Line 237: @@
 An example of a complicated ACL, allowing quite fine grained access to different ubus modules and methods is [[https://git.openwrt.org/?p=project/luci2/ui.git;a=blob;f=luci2/share/acl.d/luci2.json|available in the Luci2 project]]
-An example of a "security is for suckers" config, where a ''superuser'' ACL group is defined, allowing unrestricted access to everything, is shown below. (This illustrates the usage of ''*'' definitions in the ACLs, but keep reading for better examples).
+An example of a "security is for suckers" config, where a ''superuser'' ACL group is defined, allowing unrestricted access to everything, is shown below.
+This illustrates the usage of ''*'' definitions in the ACLs, but keep reading for better examples.
 Placing this file in ''/usr/share/rpcd/acl.d/superuser.json'' will help you move forward to the next steps.
@@ Line 251: / Line 270: @@
 Below is an example of an ACL definition that only allows access to some specific ubus modules, rather than unrestricted access to everything.
 <code javascript>
 {
@@ Line 273: / Line 293: @@
 </code>
-**Note:** Before we leave this section, you may have noticed that there's both a ''ubus'' and a ''uci'' section, even though ubus has a uci method.  The ''uci'' scope is used for the [[docs:techref:uci|uci api]] provided by rpcd to allow defining per-file permissions because using the ubus scope you can only say ''uci set'' is allowed or not, but not specify that it is allowed to e.g. modify ''/etc/config/system'' but not ''/etc/config/network''. If your application/ACL doesn't need UCI access, you can just leave out the UCI section altogether.
+**Note:** Before we leave this section, you may have noticed that there's both a ''ubus'' and a ''uci'' section, even though ubus has a uci method.
+The ''uci'' scope is used for the [[docs:techref:uci|uci api]] provided by rpcd to allow defining per-file permissions because using the ubus scope you can only say ''uci set'' is allowed or not, but not specify that it is allowed to e.g. modify ''/etc/config/system'' but not ''/etc/config/network''.
+If your application/ACL doesn't need UCI access, you can just leave out the UCI section altogether.
 ==== Authentication ====
+Now that we have an ACL that allows operations beyond just logging in, we can actually try this out.
+As mentioned, ''rpcd'' is handling this, so you need an entry in ''/etc/config/rpcd''
-Now that we have an ACL that allows operations beyond just logging in, we can actually try this out.  As mentioned, ''rpcd'' is handling this, so you need an entry in ''/etc/config/rpcd''
+<code bash>
-<code>
 config login
 	option username 'root'
@@ Line 292: / Line 314: @@
         list write lesssuperuser
 </code>
-The ''$p'' magic means to look in ''/etc/shadow'' and the ''$root'' part means to use the password for the root user in that file.  The list of read and write sections, those map acl roles to user accounts.
-So list read * means "the read credential of any group listed in the merged acls".  Write implies read.
-You can also use ''$1$<hash>''which is a [[wp>Crypt_(Unix)|crypt]] hash, using SHA1, exactly as used in ''/etc/shadow''. You can generate these with ''uhttpd -m secret''.
+The ''$p'' magic means to look in ''/etc/shadow'' and the ''$root'' part means to use the password for the root user in that file.
+The list of read and write sections, those map ACL roles to user accounts.
+So ''list read *'' means the read credential of any group listed in the merged ACLs.
+Write implies read.
+You can also use ''$1$<hash>'' which is a [[wp>Crypt_(Unix)|crypt]] hash, using SHA1, exactly as used in ''/etc/shadow''.
+You can generate these with ''uhttpd -m secret''.
 ==== Session management ====
+To login and receive a session id:
-To login and receive a session id:
+<code bash>
-<code>
+$ curl -H 'Content-Type: application/json' -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": [ "00000000000000000000000000000000", "session", "login", { "username": "root", "password": "secret"  } ] }'  http://your.server.ip/ubus
-$ curl -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": [ "00000000000000000000000000000000", "session", "login", { "username": "root", "password": "secret"  } ] }'  http://your.server.ip/ubus
 {"jsonrpc":"2.0","id":1,"result":[0,{"ubus_rpc_session":"c1ed6c7b025d0caca723a816fa61b668","timeout":300,"expires":299,"acls":{"access-group":{"superuser":["read","write"],"unauthenticated":["read"]},"ubus":{"*":["*"],"session":["access","login"]},"uci":{"*":["read","write"]}},"data":{"username":"root"}}]}
 </code>
-The session id ''00000000000000000000000000000000'' (32 zeros) is a special null-session which only has the rights from the ''unauthenticated'' access group, only enabling the ''session.login'' ubus call. A session has a timeout that can be specified when you login, otherwise it defaults to 5 minutes.
+The session id ''00000000000000000000000000000000'' (32 zeros) is a special null-session which only has the rights from the ''unauthenticated'' access group, only enabling the ''session.login'' ubus call.
+A session has a timeout that can be specified when you login, otherwise it defaults to 5 minutes.
 If you ever receive a response like ''{"jsonrpc":"2.0","id":1,"result":[6]}'', that is a valid jsonrpc response, 6 is the ubus code for ''UBUS_STATUS_PERMISSION_DENIED'' (you'll get this if you try and login before setting up the ''superuser'' file, or any file that gives you more rights than just being allowed to attempt logins).
@@ Line 312: / Line 339: @@
 To list all active sessions, try ''ubus call session list''
-The session timeout is automatically reset on every use. There are plans to use these sessions even for luci1, but at present, if you use this interface in a luci1 environment, you'll need to manage sessions yourself.
+The session timeout is automatically reset on every use.
+There are plans to use these sessions even for luci1, but at present, if you use this interface in a luci1 environment, you'll need to manage sessions yourself.
 ==== Actually making calls ====
+Now that you have a ''ubus_rpc_session'' you can make calls, based on your ACLs and the available ubus services.
+''ubus -v list'' is your primary documentation on what can be done, but see the rest of this page for more information.
+For example, ''ubus -v list file'' returns
-Now that you have a ''ubus_rpc_session'' you can make calls, based on your ACLs and the available ubus services.  ''ubus -v list'' is your primary documentation on what can be done, but see the rest of this page for more information.  For example, ''ubus -v list file'' returns
+<code javascript>
-<code>
 'file' @ff0a2c92
 	"read":{"path":"String","base64":"Boolean"}
@@ Line 341: / Line 369: @@
 }
 </code>
-The "id" key is merely echo'ed by the server, so it needs not be strictly unique, it's mainly intended for client software to easily correlate responses to previously made requests. Its type is either a string or a number, so it can be an UUID, sha1 hash, md5 sum, sequence counter, unix timestamp, etc.
+The "id" key is merely echo'ed by the server, so it needs not be strictly unique, it's mainly intended for client software to easily correlate responses to previously made requests.
+Its type is either a string or a number, so it can be an UUID, sha1 hash, md5 sum, sequence counter, unix timestamp, etc.
 An example request to read a file ''/etc/board.json'' which contains device info would be:
-<code>
-$ curl -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": [ "c1ed6c7b025d0caca723a816fa61b668", "file", "read", { "path": "/etc/board.json" } ] }'  http://your.server.ip/ubus
+<code bash>
+$ curl -H 'Content-Type: application/json' -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": [ "c1ed6c7b025d0caca723a816fa61b668", "file", "read", { "path": "/etc/board.json" } ] }'  http://your.server.ip/ubus
 {"jsonrpc":"2.0","id":1,"result":[0,{"data":"{\n\t\"model\": {\n\t\t\"id\": \"innotek-gmbh-virtualbox\",\n\t\t\"name\": \"innotek GmbH VirtualBox\"\n\t},\n\t\"network\": {\n\t\t\"lan\": {\n\t\t\t\"ifname\": \"eth0\",\n\t\t\t\"protocol\": \"static\"\n\t\t}\n\t}\n}\n"}]}
 </code>
@@ Line 354: / Line 385: @@
 To beautify output you can use [[https://stedolan.github.io/jq/|jq]] utility:
-<code>
+<code bash>
-curl -s -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": [ "c1ed6c7b025d0caca723a816fa61b668", "file", "read", { "path": "/etc/board.json" } ] }'  http://your.server.ip/ubus | jq
+curl -s -H 'Content-Type: application/json' -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": [ "c1ed6c7b025d0caca723a816fa61b668", "file", "read", { "path": "/etc/board.json" } ] }'  http://your.server.ip/ubus | jq
 {
   "jsonrpc": "2.0",
@@ Line 368: / Line 399: @@
 </code>
-In the response JSON document in the ''result[1].data'' field contains escaped JSON with the ''model'' and ''network'' objects. To fetch the concrete model name you can parse the response with the [[https://stedolan.github.io/jq/|jq]] program:
+In the response JSON document in the ''result[1].data'' field contains escaped JSON with the ''model'' and ''network'' objects.
+To fetch the concrete model name you can parse the response with the [[https://stedolan.github.io/jq/|jq]] program:
 <code>
-curl -s -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": [ "c1ed6c7b025d0caca723a816fa61b668", "file", "read", { "path": "/etc/board.json" } ] }'  http://your.server.ip/ubus | jq -r '.result[1].data' | jq .model.name
+curl -s -H 'Content-Type: application/json' -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": [ "c1ed6c7b025d0caca723a816fa61b668", "file", "read", { "path": "/etc/board.json" } ] }'  http://your.server.ip/ubus | jq -r '.result[1].data' | jq .model.name
 "innotek GmbH VirtualBox"
 </code>
 As you can see in the example the router model is in fact just a OpenWrt runned on [[docs:guide-user:virtualization:virtualbox-vm|virtual machine in VirtualBox]].
 ===== Lua module for ubus =====
+This is even possible to use ''ubus'' in ''lua'' scripts.
-This is even possible to use ''ubus'' in ''lua'' scripts. Of course it's not possible to use native libraries directly in ''lua'', so an extra module has been created. It's simply called ''ubus'' and is a simple interface between ''lua'' scripts and the ''ubus'' (it uses ''libubus'' internally).
+Of course it's not possible to use native libraries directly in ''lua'', so an extra module has been created.
+It's simply called ''ubus'' and is a simple interface between ''lua'' scripts and the ''ubus'' (it uses ''libubus'' internally).
 <code lua>
@@ Line 420: / Line 452: @@
 ===== Namespaces & Procedures =====
+As explained earlier, there can be many different daemons (services) registered in ''ubus''.
+Below you will find a list of the most common projects with namespaces, paths and procedures they provide.
-As explained earlier, there can be many different daemons (services) registered in ''ubus''. Below you will find a list of the most common projects with namespaces, paths and procedures they provide.
+**Path only contains the first context, e.g. network for network.interface.wan**
-**Path only contains the first context. E.g. network for network.interface.wan**
 ^ path ^ Description ^ Package ^
@@ Line 451: / Line 483: @@
 ==== rpcd ====
+Project [[docs:techref:rpcd|rpcd: OpenWrt ubus RPC daemon for backend server]] is a set of small plugins providing sets of ''ubus'' procedures in separated namespaces.
-Project [[docs:techref:rpcd|rpcd: OpenWrt ubus RPC daemon for backend server]] is a set of small plugins providing sets of ''ubus'' procedures in separated namespaces. These plugins are not strictly related to any particular software (like ''netifd'' or ''dhcp'') so it wasn't worth it to implement them as separated projects. rpcd and the desired plugins must be available or installed via opkg. After installing remember to enable and start the service via ''/etc/init.d/rpcd enable'' and ''/etc/init.d/rpcd start'' .
+These plugins are not strictly related to any particular software (like ''netifd'' or ''dhcp'') so it wasn't worth it to implement them as separated projects.
+rpcd and the desired plugins must be available or installed via opkg.
+After installing remember to enable and start the service via ''service rpcd enable'' and ''service rpcd start'' .
 {{page>docs:guide-developer:ubus:file&nofooter}}
 {{page>docs:guide-developer:ubus:iwinfo&nofooter}}
@@ Line 462: / Line 494: @@
 {{page>docs:guide-developer:ubus:session&nofooter}}
 {{page>docs:guide-developer:ubus:uci&nofooter}}
 ===== What's the difference between ubus vs dbus? =====
+[[wp>D-Bus|D-Bus]] is bloated, its C API is very annoying to use and requires writing large amounts of boilerplate code.
-[[wp>D-Bus|D-Bus]] 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."
+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.
+===== Examples =====
-===== More complete examples =====
 ==== FHEM ====
+=== User mapping ===
-=== User Mapping ===
 In this example we map username ''root'' to ''fhem_acl'' for [[docs:guide-user:services:automation:fhem|FHEM]] server.
 Edit ''/etc/config/rpcd'':
-<code - /etc/config/rpcd>
+<code bash>
+# /etc/config/rpcd
 config login
 	option username 'root'
@@ Line 504: / Line 531: @@
 	list write ''
 </code>
 Then reload rpcd config:
-<code>
-# uci commit rpcd
+<code bash>
+uci commit rpcd
 </code>
 === User ACL ===
 All files under ''/usr/share/rpcd/acl.d/'' will be merge by ''rpcd'' to one config file!!
-<code>
+<code bash>
-# ubus call hostapd.wlan0 get_clients
+ubus call hostapd.wlan0 get_clients
-# ubus call hostapd.wlan1 get_clients
+ubus call hostapd.wlan1 get_clients
 </code>
@@ Line 535: / Line 563: @@
 FHEM Server - show all connected wireless clients:
-<code>
-fhem-server$ python wifi_clients.py
+<code bash>
+$ python wifi_clients.py
 Usage: wifi_clients.py.orig <OpenWrt_Host> <User> <Pass> <WiFi_1> [<WiFi2> ...]
-fhem-server$
+$ python wifi_clients.py 192.168.1.71 fhem fhem wlan0 wlan1
-fhem-server$
-fhem-server$ python wifi_clients.py 192.168.1.71 fhem fhem wlan0 wlan1
 c8:f6:50:e1:a9:10, 2c:f0:a2:e2:c0:15, 8c:a9:82:f1:9c:2a, 7c:c3:a1:b8:d2:1e, 64:9a:be:6a:6c:13, 00:1d:63:a3:8f:4a
-fhem-server$
+</code>
+==== Getting firmware version ====
+Get firmware version with [[https://github.com/openwrt/luci/wiki/JsonRpcHowTo|JSON RPC]].
+<code bash>
+luci_rpc() {
+local LIB="${1}"
+local DATA="${2}"
+local URL="https://${HOST}/\
+cgi-bin/luci/rpc/${LIB}?auth=${TOKEN}"
+curl -s -k -d "${DATA}" "${URL}" \
+| jsonfilter -e "$['result']"
+}
+HOST="localhost"
+USER="root"
+PASS=""
+DATA="{ \"id\": 1, \"method\": \"login\",
+\"params\": [ \"${USER}\", \"${PASS}\" ] }"
+TOKEN="$(luci_rpc auth "${DATA}")"
+DATA="{ \"id\": 2, \"method\": \"exec\",
+\"params\": [ \"ubus call system board\" ] }"
+VERSION="$(luci_rpc sys "${DATA}" \
+| jsonfilter -e "$['release']['version']")"
+echo "${VERSION}"
+</code>
+Get firmware version with ubus RPC.
+<code bash>
+ubus_rpc() {
+local DATA="${1}"
+local URL="https://${HOST}/ubus"
+curl -s -k -d "${DATA}" "${URL}" \
+| jsonfilter -e "$['result']"
+}
+HOST="localhost"
+USER="root"
+PASS=""
+DATA="{ 'jsonrpc': '2.0', 'id': 1, 'method': 'call',
+'params': [ '00000000000000000000000000000000', 'session',
+'login', { 'username': '${USER}', 'password': '${PASS}' } ] }"
+SESSION="$(ubus_rpc "${DATA}" \
+| jsonfilter -e "$[*]['ubus_rpc_session']")"
+DATA="{ 'jsonrpc': '2.0', 'id': 2, 'method': 'call',
+'params': [ '${SESSION}', 'system', 'board', {} ] }"
+VERSION="$(ubus_rpc "${DATA}" \
+| jsonfilter -e "$[*]['release']['version']")"
+echo "${VERSION}"
 </code>