Introduction

If you login to the Mesh Rider Radio's Linux Ash shell (similar to Bash) using SSH, you can run Linux commands. This guide discusses the following types of CLI commands

1. 1. Common CLI Commands
2. 2. UCI
3. 3. UBUS

Ultimately, you may want to run some of these commands remotely over the API. This is discussed in our Remote Management Guide.

Common CLI Commands

The Mesh Rider Radio uses the Almquist shell (commonly known as "Ash", further reading material here https://en.wikipedia.org/wiki/Almquist_shell), which is similar to Bash. If you know Bash, you will find the Mesh Rider Radio CLI very familiar. If not, we recommend going through one of the many online tutorials on Bash. The tables below summarize commands you are likely to use in the course of your Mesh Rider Radio testing.

Real-Time Configuration

The commands below work on-the-fly, but do not survive a network restart or reboot.

Getting Connection Information

Networking Information

System Information

UCI

The UCI system is used for persistent configuration. Most UCI files are found at /etc/config/. This is a slow method of configuration, but changes are saved over a reboot. The general procedure for making a UCI configuration change is

1. 1. To show the existing configuration, run

   uci show

   to show the full UCI configuration or

   uci show wireless

   to shows the wireless configuration (for example).

2. 2. Modify a configuration and commit the change (this saves the change)

   uci set wireless.radio.chanbw=5
   uci set wireless.radio0.txantenna='1'
   uci commit

   This sets the channel bandwidth to 5 MHz. You can save individual sections too. For example uci commit wireless. After committing changes, you need to restart the service.

3. 3. After making configuration changes, restart the relevant service. You can see a list of services by running

   ls /etc/init.d

   After that, restart the service. For example,

   /etc/init.d/socat restart

   will restart the socat service (serial interface). Note that /etc/init.d/network restart will restart all networking related services including the wireless. If you have only made changes to the wireless configuration, you can just run wifi (this is an exception as the wireless config file doesn't have a corresponding init script).

UBUS

Making calls using UBUS

Calls to the JSON-RPC API go through the Openwrt ubus system (further reading here https://openwrt.org/docs/techref/ubus). Before going into the JSON-RPC API, you should become familiar with ubus. In order to run ubus directly, first SSH into the radio. You can view a list of available ubus commands using (result abridged)

root@smartradio:~# ubus list
central-config
dhcp
dnsmasq
file
iwinfo
…

Note that the central-config call is only available after enabling the Central Configuration utility. You can get information about how to use specific ubus calls by running

root@smartradio:~# ubus -v list <CALL>

For example,

root@smartradio:~# ubus -v list iwinfo
'iwinfo' @68374f72
        "devices":{}
        "info":{"device":"String"}
        "scan":{"device":"String"}
        "assoclist":{"device":"String","mac":"String"}
        "freqlist":{"device":"String"}
        "txpowerlist":{"device":"String"}
        "countrylist":{"device":"String"}
        "survey":{"device":"String"}
        "phyname":{"section":"String"}

An example of how to use the iwinfo call is shown below. We replaced "String" with "wlan0" (result abridged).

root@smartradio~# ubus call iwinfo assoclist '{"device":"wlan0"}'
{
        "results": [
                {
                        "mac": "00:30:1A:4E:BB:09",
                        "signal": -47,
…

Parsing the json output

We can filter these results using the jsonfilter utility. Note in the JSON file above that the results property is an array of values, one for each connected station.

root@smartradio:~# ubus call iwinfo assoclist '{"device":"wlan0"}' | jsonfilter -e '@.results[1].mac' -e '@.results[1].signal'
00:30:1A:4E:BB:01
-62

Or if you know the MAC address of the device you want to filter, you can use

root@smartradio:~# ubus call iwinfo assoclist '{"device":"wlan0"}' | jsonfilter -e '@.results[@.mac="00:30:1A:4E:BB:01"].signal'
-62

In general, however, we recommend parsing data on your local machine where it should be easier.

Sense

Sense is the name of our upgraded Central Configuration, Automatic Band / Channel / Bandwidth selection, and Link Recovery utility. Sense was introduced in the July 2023 Beta Resilience Release and heavily updated in the Sept 2023 Sense release. Sense is discussed in more detail here.

Messaging System ( June 2024+)

The following is an example script showing how to use the new messaging system. Central config can no longer be used.  

ubus call message-system chswitch '{"count": 3, "model": "RM-2450-2KM-XW", "frequency": 2412, "bandwidth": 10, "mode_change": 0 }' 

 

# count = number of times to send the message 

# model = submodel to switch to 

# frequency = New operating frequency 

# bandwidth = New operating bandwidth 

# mode_change = 1 or 0 to indicate true or false. A mode change occurs when toggling between a 40-MHz bandwidth setting and any other bandwidth setting. 

Noise scanning over the CLI

The firmware integrates a manual band scanning utility which allows the user to scan specific band/channel/bandwidths for noise. You can modify the list of scanned frequencies by editing the file /etc/scanlist.json. The default is shown below. A limitation of this utility is that the second frequency to be scanned in each submodel must be more than 5-MHz higher than the first (they also must be valid channels). Therefore, you will not be able to scan frequencies 2412 MHz and 2417 MHz in the RM-2450-2L-X submodel. In general, you should scan non-overlapping channels with a wide bandwidth, but scanning the 2.4-GHz band with a 20-MHz bandwidth could lead to incorrect results due to the presence of third-party Wi-Fi devices.

$ cat /etc/scanlist.json
{"scanlist":[
        {"model":"RM-1675-2L-X","bandwidth":"10000","freq":["1650","1670","1690"]},
        {"model":"RM-2245-2L-X","bandwidth":"10000","freq":["2220","2250","2280"]},
        {"model":"RM-2450-2L-X","bandwidth":"10000","freq":["2412","2432","2452"]}
]}

To run a scan, execute the command switch-scan-new.sh. The results will be in a table format at /tmp/scan_results

$ cat /tmp/scan_results
FREQ noise-AVG noise-75% noise-90% noise-MAX num-scans
1650 -102.923950 -97.472015 -94.953606 -83.101387 24
1670 -96.610970 -91.465370 -86.563614 -84.484718 29
1690 -95.679008 -89.701218 -86.749275 -79.336105 24
2220 -103.718758 -97.790871 -93.297089 -88.014229 26
2250 -108.324417 -102.998260 -100.864838 -97.243042 25
2280 -104.529037 -98.920143 -94.081635 -91.797234 27
2412 -97.080002 -89.835823 -83.133896 -71.869949 25
2432 -91.229301 -79.683624 -68.121605 -62.148979 17
2452 -99.396301 -96.636200 -86.066101 -71.173927 27

• FREQ : The frequency being scanned
• noise-AVG : The average noise level over all OFDM sub-carriers
• noise-75% : The noise level which 75% of the OFDM sub-carriers is below
• noise-90% : The noise level which 75% of the OFDM sub-carriers is below
• noise-MAX : The maximum noise level of any sub-carrier
• num-scans : The number of scans performed at this frequency

Typically, the noise-75% column is a good reference as the radio uses Forward-Error Correction (FEC) to correct for some percentage of the bit errors. You can sort the table using awk. For example, to sort the table by the noise-75% level, run

$ cat /tmp/scan_results | awk '{print $3" "$1}' | sort -n -r | awk '{print $2" "$1}'
FREQ noise-75%
2432 -79.683624
2412 -89.835823
1690 -89.701218
1670 -91.465370
2452 -96.636200
2220 -97.790871
1650 -97.472015
2280 -98.920143
2250 -102.998260

As a scan at a single frequency is very brief, it will not capture intermittent sources of noise that are not present at the time of the scan. You can see how the noise in a particular channel is changing over time by simply repeating it in the scan list. For example,

$ cat /etc/scanlist.json
{"scanlist":[
        {"model":"RM-1675-2L-X","bandwidth":"10000","freq":["1650","1650","1650","1650","1650","1650","1650","1650","1650","1650","1650","1650"]}
]}

•  

• Linkstate 

The linkstate daemon now saves the most current report at /tmp/linkstate_current.json. This could be used by customers who want to pole the linkstate from an external application. The latest linkstate json format is shown below. Important changes are in blue. We now report the LNA status (1 means it is ON, and 0 means it is OFF). We also report the RSSI for each antenna, and we report the number of bytes transmitted to each peer instead of the number of packets. 

'{ 

  "sysinfo": { 

    "cpu_load": [ 

      5088, 

      11072, 

      16800 

    ], 

    "freemem": 14684160, 

    "localtime": 1651760076 

  }, 

  "oper_chan": 12, 

  "oper_freq": 915, 

  "chan_width": "26", 

  "noise": "-98.808556", 

  "activity": 1, 

  "lna_status": "1", 

  "sta_stats": [ 

    { 

      "mac": "00:30:1a:50:3b:a0", 

      "inactive": 30, 

      "rssi": -49, 

      "rssi_ant": [ 

        -51, 

        -54 

      ], 

      "pl_ratio": 0.0804505, 

      "tx_bytes": 1242, 

      "tx_retries": 1, 

      "tx_failed": 0, 

      "mcs": 13 

    }, 

  ], 

  "mesh_stats": [ 

    { 

      "orig_address": "00:30:1a:50:3b:a0", 

      "tq": 255, 

      "hop_status": "direct", 

      "last_seen_msecs": 400 

    }, 

  ] 

}' 

Creating a Bootup Script

The Mesh Rider Radio uses Openwrt's procd system for init scripts:
(https://openwrt.org/docs/guide-developer/procd-init-script-example).

Example

We will create a simple script to echo a message to the system logs every 5 seconds.

Save the following listing as /usr/bin/my_startup_script.sh

#!/bin/sh

while (sleep 5) do
        logger -t "My Message" "Hello"
done

You now have to make the script executable. Run

chmod +x /usr/bin/my_startup_script.sh

You can use the following basic listing for a startup script. Save the file in your Mesh Rider Radio as /etc/init.d/my_init_script.

#!/bin/sh /etc/rc.common

USE_PROCD=1
START=99
PROG="/usr/bin/my_startup_script.sh"

start_service() {
        procd_open_instance
        procd_set_param command $PROG -p $PORT
        procd_set_param respawn 0 5 0
        procd_close_instance
}

After creating the file, make it executable, and then enable and start the init script.

chmod +x /etc/init.d/my_init_script
/etc/init.d/my_init_script enable
/etc/init.d/my_init_script start

You can also follow the system log messages from my_startup_script.sh by running

logread -f "My Message"