-
-
Software Guides
-
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. Common CLI Commands
- 2. UCI
- 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.
Command | Purpose |
---|---|
iw wlan0 set txpower fixed 2000 |
Sets the TX power to 20 dBm. Note that the power is measured in millibels, so divide by 100 to get decibels. |
iw wlan0 set txpower auto |
Sets the TX power to auto (highest power) |
iw wlan0 set bitrates ht-mcs-2.4 <RATE> |
Fixes the bitrate. is the MCS rate between 0 and 15 where 0-7 are single-stream rates, and 8-15 are dual-stream rates. |
iw wlan0 set bitrates |
Sets the MCS rate to auto |
iw dev wlan0 mesh chswitch <CHANNEL> <# BEACONS> |
Sends a channel switch announcement to all MESH nodes to switch to after sending <# BEACONS> beacons. |
hostapd_cli chan_switch <# BEACONS> <FREQ> ht |
Sends a channel switch announcement to all WDS Client nodes to switch to after sending <# BEACONS> beacons. |
Getting Connection Information
Command | Purpose |
---|---|
iw wlan0 station dump OR iw wlan0 station get <MAC> |
Gets information about all connected stations or an individual station. |
iwinfo wlan0 assoclist |
Information on all associated stations |
iw wlan0 info |
Get information about the current wireless settings |
iw wlan0 survey dump |
Get channel usage statistics |
batctl |
See a list of commands for mesh interface information and configuration |
batctl o |
See information about connected mesh nodes including preferred hop (*), last-seen time, transmit quality (#/255)… |
Networking Information
Command | Purpose |
---|---|
ifconfig br-wan |
Show information about the WAN bridge |
ip a show br-wan |
Show information about the WAN bridge |
route -n |
Show the routing table |
netstat -tuapn |
Show socket connection information |
arp |
Show the address resolution protocol table. |
ip a |
Show information about IP addresses |
fw3 print |
fw3 is a front end to iptables and can be used to configure the firewall. |
cat /proc/net/nf_conntrack |
See exiting network connections |
bmon -b OR bmon -b -p wlan0 |
Network usage information |
System Information
Command | Purpose |
---|---|
dmesg |
See kernel messages |
cat /var/log/messages OR logread |
See system log messages |
top |
Check processor load |
free |
Check memory usage |
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. 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. Modify a configuration and commit the change (this saves the change)
uci set wireless.radio.chanbw=5
uci set wireless.radio0.txantenna='1'
uci commitThis 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. 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 thewireless
configuration, you can just runwifi
(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 periodically checks the link state every 2 seconds. The linkstate can be read using the following command.
ubus listen linkstate
The linkstate daemon also saves the most current report at /tmp/linkstate_current.json
. This could be used by customers who want to poll the linkstate from an external application. The latest linkstate json format is shown below. Check this link for an explanation of the fields.
'{
"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
},
]
}'
Bandswitching.sh Script
The band switching script allows the user to switch to a different band, frequency or channel bandwidth. It requires a bit of additional information to use.
Here is the usage of this script
/usr/share/simpleconfig/band_switching.sh ${SUBMODEL} ${CHANNEL} ${BW}
It has the following parameters: SUBMODEL, CHANNEL, BANDWIDTH
SUBMODEL: Multi-band radios list the bands they cover as submodels. There are additional scripts on the radio to help determine these submodels.
Determining the current model
fes_model.sh get
Determining the parent model.
fes_model.sh get parent
Getting a list of submodels from parent.
cat /usr/share/.doodlelabs/fes/${PARENT}
The following is an example with the MB-2025-2KM-XW which covers 6 bands each represented by a submodel.
root@smartradio:~# fes_model.sh get parent
MB-2025-2KM-XW
root@smartradio:~# cat /usr/share/.doodlelabs/fes/MB-2025-2KM-XW
sub_model0="RM-1675-2KM-XW"
sub_model1="RM-1815-2KM-XW"
sub_model2="RM-2065-2KM-XW"
sub_model3="RM-2245-2KM-XW"
sub_model4="RM-2350-2KM-XW"
sub_model5="RM-2455-2KM-XW"
sub_model6="RM-2450-2KM-XW"
Switching to a different band
/usr/share/simpleconfig/band_switching.sh ${SUBMODEL}
CHANNEL
To find all the support frequencies/channels in the current band. Run the following command.
iwinfo wlan0 freqlist
BANDWIDTH
The available inputs for bandwidth are
Available Inputs | Channel Bandwidth |
0 | 20 MHz |
3 | 3 MHz |
5 | 5 MHz |
10 | 10 MHz |
26 | 20 MHz |
Example Usage of band_switching.sh
The following example is for frequency = 1.718 GHz, channel BW= 5MHz.
1. Switch to desired band
root@smartradio:/# /usr/share/simpleconfig/band_switching.sh RM-1675-2KM-XW
Selected interface 'wlan0'
OK
2. Determine your channel of interest
root@smartradio:/# iwinfo wlan0 freqlist
1.720 GHz (Channel 6)
1.719 GHz (Channel 7)
1.718 GHz (Channel 8)
1.717 GHz (Channel 9)
...
3. Run band_switching.sh with the band, channel and channel bw. (The previous two command were not necessary, it was ran to demonstrate how to find the channel of interest.)
root@smartradio:/# /usr/share/simpleconfig/band_switching.sh RM-1675-2KM-XW 88 5
Selected interface 'wlan0'
OK
Blacklisting Submodels
In multiband Mesh Rider radios, it is possible to blacklist different bands. This is useful if the country that the radio is to be deployed in does not allow particular bands, and they should not be exposed to the end user. Blacklisting can only be done through the CLI, and a blacklisted model is not reinstated through a factory reset. It can only be reinstated using the same blacklisting script. Blacklisting is handled through the blacklist.sh utility.
Usage
blacklist.sh <parent model> [<submodel1> <submodel2> ...]
You can undo blacklisting using
blacklist.sh <parent model>
An example of how to blacklist a particular sub-model is
blacklist.sh MB-0001-2KM-XW RM-1675-2KM-XW
This blacklists the sub-model RM-1675-2KM-XW when the parent model is MB-0001-2KM-XW. You can find the parent model using
fes_model.sh get parent
You can see a list of supported sub-models using
cat /usr/share/.doodlelabs/fes/$(fes_model.sh get parent)
Calibration Check
Calibration Check is an application introduced in firmware 2024-06. It allows the user to check the calibration of their radio. The calibration for the Mesh Rider Radio is handled by a microcontroller(MCU) with factory tuned calibration data. A back up of the MCU calibration is stored in /opt/picfailsafe/PIC_FLASH_DUMP.
dl-pical-check -c
Validates the MCU calibration on the current channel.
To see if it passes calibration look for "No issue with current band"
dl-pical-check -a
Checks the validity of the calibration backup.
This command will fail if/opt/picfailsafe/PIC_FLASH_DUMP doesn't exist or corrupt.
dl-pical-check -w
Copies the backed-up calibration to the MCU. A power cycle is required for the calibration to take place. This command will fail if /opt/picfailsafe/PIC_FLASH_DUMP doesn't exist.
As of the firmware 2024-10.0, the program output is not JSON friendly.
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"