mPower Software 7.x.x Release Notes
These release notes cover updates to the mPower software starting with major release 7.0.0.
Note: Releases are cumulative. For example, if your device has mPower 7.1.0, this version also includes the 7.0.0 enhancements and bug fixes (and those of the releases that came before).
For further details on a specific change, view the mPower user guide or device software configuration guide.
Release Dates:
- 7.0.0 – October 2024
- 7.1.0 – July 2025
Models Impacted:
- rCell 300 (MTR3)
mPower 7.1.0
Expand each item for more information on a specific update.
Enhancements
General
Yocto Kirkstone and Linux Kernel
- Updated Yocto Kirkstone and Linux Kernel to the latest versions:
- The Yocto Kirkstone version is 4.0.23.
- The Linux Kernel version is 5.15.173.
SSH Configuration
- Improved Secure Shell (SSH) functionality by moving settings to a new page and adding new features and changes to the default configuration:
- SSH session idle timeout
- SSH brute force prevention
- Public Key Authentication support
- UI changes to support new features (idle timeout, user lockout and Public key authentication)
- SSH configuration and secure settings
UBIFS Volumes (Partitions) Details
- Implemented the following changes to the unsorted block images file system (UBIFS) volumes (partitions), so now you can:
- View active and inactive volume (partition) details
- Send volume details to MultiTech Cloud
- Switch manually to an inactive volume
- Replicate device configuration with improved behavior
- Persist the corrupted or invalid db.json if it defaults
- Ensure system reliability and recovery with improved partitioning fallback behavior
- Optimize boot time
System Statistics
- The Statistics page shows information regarding the Firmware Release (marketing version) and Engineering version of the firmware.
- Previously, the release label “Firmware Information” displayed the engineering version and the timestamp, which corresponded to the Version and Date in the /etc/issue file.
- Changed the label “Firmware Information” to now say “Engineering Version,” and only the engineering version is shown without the timestamp.
Security Requirements
- Verified and confirmed the mPower code meets these requirements:
- Randomly generates and signs (as relevant) Web authentication session IDs used with device services, using only dedicated libraries designed for authentication session ID generation and handling.
- Uses all secure web service authentication session IDs directly with or by the device, which it exchanges and manages with the client-side using cookies or a comparable secure method. It also has the cookie “Secure,” “HTTP-Only,” and “SameSite=Strict” attributes set on them, as applicable.
- API uses OpenSSL EVP tool, to generate md5 encrypted token. In Web UI you can see the cookie has the attributes “Secure” and “HTTP-Only” set to true, and “SameSite=Strict.” See the picture below as an example. Picture: mPower R.7.1.0 – Cookie attributes example
- Updated various security requirements on compiled binaries in the firmware image:
- Hid the authorized token previously kept in device logs, so the HTTP confidential cookie will not be stored in a cleartext in logs.
- Authenticated blind command injection in the Generate Certificates page to correct a vulnerability
- The API endpoint ‘/api/certificate/create’ that is used to generate a new X.509 certificate on the MultiTech product, now accepts command injections. The server receives a command and executes it.
- This release resolves this vulnerability for MTR3 firmware.
- The next release will resolve this vulnerability for MTCAP3 firmware.
Custom App Improvements
Implemented the following features and improvements are in Custom App functionality:
- Multiple PIDs support
- Custom App – Extra Version support
- View Application Details pop up window
- General Custom App Improvements
- Set environment variables when the custom app starts and stops
- Integration with MT Cloud: Status Update – Sent custom app details (PIDs and Extra Version) to MT Cloud
Hostname Configuration and Use
- Changed the default hostname to <machine>-<deviceId>
- Previously, the default hostname value was equal to the machine type and it was the same on all devices, for example, mtr3, mtcap3, etc.
- mPower devices provide the “deviceHostname” value to MultiTech Cloud every check in and it’s also present in the status.json file.
- The “deviceHostname” is not reset to default when performing an upgrade to R.7.1.0. To see the default hostname, use the reset to default feature.
- Device hostname resolves on the device locally using an entry in /etc/hosts
- The hostname value in the /etc/hosts for the IP address 127.0.1.1 corresponds to the hostname that is configured as the device hostname in the Hostname Configuration page.
- When updating the device hostname, the changes are immediately applied to /etc/hosts.
- It is possible to ping the device hostname from the device console (SSH or debug).
- DHCP client provides the device hostname when requesting a lease from the DHCP server (the feature is applicable to Ethernet interfaces only.)
- In mPower R.7.1.0 the DHCP client provides the device hostname when requesting a lease from the DHCP server.
- This change allows the DHCP server to associate the hostname provided by the mPower device with the IP, MAC address, and other data listed in the lease entry on the DHCP server.
- This would make it easier for the customer to find their device in the lease listings on the DHCP server.
- The picture below demonstrates an example of the request to DHCP server that MTR3 sends. The requests includes the actual device hostname.
Remote Management and MultiTech Cloud
- Make the new features and configuration settings added in this release available in MT Cloud.
- Updated the status-schema.json file to reflect the implemented changes.
- Made most of the changes in the custom application and LoRaWAN details.
- The latest version of the status-schema.json is status-schema_v1.3.json.
- The Allow Radio Firmware Upgrade setting is not present on the Remote Device Management configuration page.
- Hid this feature in the mPower Web UI because it is not implemented in MT Cloud server.
Ethernet Connections Transition from UDHCPC to DHCPCD
- The transition from UDHCPC to DHCPCD resolves issues identified with Ethernet connections. (Support Portal Case #5117691)
- For example where the system did not update a DHCP address when a different Ethernet cable was connected, until the lease of the originally assigned IP address expired.
- This transition affects only Ethernet connections managed by the lanup package within the meta-mts-device layer.
- The changes do not affect Cellular (ppp0) and Wi-Fi (wlan0) interfaces.
During testing, it was confirmed that dhcpcd successfully detects changes in Ethernet connection states when the Ethernet port has a standard configuration and is not part of a VLAN. - When the Ethernet port is added to a VLAN, detecting changes in Ethernet cable state requires disconnecting and reconnecting all interfaces that belong to the VLAN.
rCell 300 (MTR3)
- None
Bug Fixes
General
- None
rCell 300 (MTR3)
- None
mPower 7.0.0
Expand each item for more information on a specific update.
Enhancements
General
New Hardware Support
- Python updated to 3.10.13
- OpenSSL updated to 3.0.13
- OpenSSH update to v.9.7p1
- Security: Upgrade OpenSSH to 9.8p1 or later to address CVE-2024-6387
- Migrated mPower code to Yocto Kirkstone 4.0.17
New Services
- NTP – The system uses NTP daemon for time synchronization in and NTP replaced the SNTP service previously present
- Remote Device Management – Service responsible for communication with MT Cloud. This replaces the Remote Management service (annex client) that was responsible for DeviceHQ support.
Cellular Configuration and Profiles
- The system is able to recognize the SIM replacement on the fly, s0 you do not need to reboot when swapping SIM cards
- Improved Connection Monitoring and Connection Recovery to give you more control over the actions the system must perform in case of connection failure
- Cellular Configuration includes Cellular Profiles where you can add Provider and SIM Profiles
- If the system detects the current provider is Verizon, the Verizon Configuration page displays, but is otherwise hidden.
Device Remote Management
- Replaces Remote Management via DeviceHQ, as MT Cloud is the supported cloud solution from this release forward
- Checks-in to MT Cloud and reports device status and details
- Uploads its configuration to MT Cloud (happens automatically when checking-in)
- Supports commands to:
- Update configuration
- Upgrade firmware
- Request logs
- Reboot
- Install App
Custom Apps
- System retrieves all Custom App details such as App Name, Version and Description from the manifest.json and displays details in the system
- User must specify the App ID only when installing the Custom App locally
- Implemented Upload Application Configuration as a new feature where you can upload one or many configuration files for installed Custom Apps
Conduit AP 300 (MTCAP3)
Payload Management Updates
- Updated the Payload Management main menu:
- Reordered and modified menu items to improve design
- Added a Logs menu item (Payload Management logs were previously under Status & Logs menu)
- Updated the following BACnet Device Settings:
- Device Object Name: Increased from 25 to 128 Characters
- Device Description: Increased from 64 to 128 Characters
- Device Location: Increased from 64 to 128 Characters
- Made the following improvements to the Sensor Definitions page:
- Moved the Sensor Definitions page under the Definitions and Templates menu item
- Combined the Current, Default, Custom and Import pages
- Added icons to identify custom and default sensor definitions
- Added a Delete icon next to custom sensor definitions and a Delete All button to the Sensor Definitions page to remove all custom sensor definitions
- Added an Add Sensor icon next to each sensor definition the system is currently using
- Added an ? icon next to default sensor definitions replaced with custom sensor definitions, which also do not display the Add Sensor icon
- Updated the Filter By field to filter by Source, Manufacturer, Sensor Type and Description
- Added an Import button to the Sensor Definitions page that opens a pop-up window
- Included the same fields as were previously on the Import page
- Combined the previous BACnet Objects and Managed Sensors menu items under Sensors
- Included pages for both Sensors and BACnet Objects under the Sensors menu item
Made the following improvements to the Sensors page:
- Included all previous functionality, with some improvements:
- Sensors list with Device EUI, Source, Manufacturer, Type and Options columns
- Filter by field to filter sensors by key data
- Delete icon next to each sensor or Delete All option to remove all sensors
- Download option to download a Sensors Map to a JSON file
- Import option to import sensors from a JSON file
- Add Sensor option to add a sensor manually
- Added Apply Template option to apply Sensor Type Templates to sensors
- Added an Edit icon under Options to view and edit sensor details
Made the following updates to the BACnet Objects page:
- Included all previous functionality, with some improvements:
- BACnet Objects Map list with ID, Name, Property, Sensor ID and Options columns
- Filter by field to filter BACnet Objects by Type, ID, Name, Sensor ID, or Property
- Delete icon next to each BACnet Object or Delete All option to remove all BACnet Objects
- Download option to download BACnet Objects Map to a JSON file
- Import option to import BACnet Objects Map from a JSON file
- Edit icon under Options to view and edit BACnet Object details
- Add Object option to add a BACnet Object manually
- Added support for sensors with applied Sensor Type Templates
You create BACnet Objects for a particular sensor. This release allows you to see all BACnet Objects for a selected sensor in one screen.
Add BACnet Objects by either:
- Clicking Edit to update a sensor’s details on the Sensors page
- Clicking Add Object on the BACnet Objects page
For both options, the system opens a pop-up window where you choose a sensor by Device EUI. The system shows all BACnet Objects for the sensor with the selected Device EUI. You can then add, delete or edit the sensor’s corresponding BACnet Objects.
- To add a BACnet Object, select or enter values in the following fields:
- Property
- Type
- Identifier
- Name
- Description (optional)
- Click OK to create the BACnet Object
- Update a BACnet Object by clicking the Edit icon for a property, either on the BACnet Objects Map page or in the Managed Sensor Details window
A sensor definition may contain uplink and downlink properties:
- The system recognizes a downlink property if the Downlink field is set to true.
- If the Downlink field is not present or set to false, the system considers the object an uplink.
- The BACnet Objects Map does not store information regarding uplinks or downlinks.
- The system uses the sensor definition file to distinguish uplink and downlink properties.
- Supported BACnet object types are different for uplink and downlink properties. The tables below list the supported objects types for each property type.
Note: The first type in the list is the default one.
Implemented Sensor Type Template feature to:
- Simplify adding multiple LoRaWAN sensors of the same type to the system
- Add LoRaWAN devices of the same type to the Local Join Server (Local End-Device Credentials), the Managed Sensors list, and the same set of BACnet Objects for each sensor.
By default, there are no pre-defined templates in the system, so users must:
- Create new templates before using them.
- Specify the following data in the template:
- Template Name
- Sensor Definition
- LoRa WAN Device Details:
- Class
- Device Profile
- Network Profile
- BACnet Objects
The system automatically:
- Adds ALL properties with a corresponding default Object Type to the BACnet Objects List when users select a sensor definition
- This list changes if users choose another sensor definition
- Generates the BACnet Object Name
- The name consists of PropertyName and BACnet Object Type abbreviation separated by a hyphen
- To add a BACnet Object to the template, specify:
- Property
- Type
- Name
- Review the resulting BACnet Object Name, which includes the four last digits from the sensor Device EUI.
The system allows:
- Editing or deleting BACnet Objects added automatically
- Adding BACnet Objects manually
- Adding any number of BACnet objects to the template
The Apply Template option is:
- Available on the Sensors page
- Disabled if there are no Sensor Type Templates in the system
- To apply a Sensor Type Template, choose a sensor type template from the drop-down list.
- Specify the BACnet Object ID Start Value.
- The system will increment the value for each new BACnet object added while applying the template.
- If the ID was already used, the system skips it and applies another value.
- Add sensor details manually (Device EUI, App EUI, and App Key) or upload data from a CSV file.
- Click Submit.
- The system allows using a CSV file with or without a header:
- If the CSV file does not have a header, you must add the sensor details in this order:
- DevEUI
- AppEUI
- AppKey
- If the CSV file has a header, the system will search for these values.
- The system parses the file and retrieves only the values needed.
- If the CSV file does not have a header, you must add the sensor details in this order:
- When applying a Sensor Type Template to a specified list of sensors, the system makes the following changes:
- Adds Local End-Device Credentials (LoRaWAN Network Server > Key Management page)
- Adds sensors to the Manages Sensors list (Payload Management > Sensors page)
- Adds a set of BACnet Objects for each sensor from the list
- The system adds Local End-Devices credentials only if you enable the Local Join Server.
- The system does not add Local End-Devices and displays a warning message if:
- You do not enable the Local Join Server
- There is at least one sensor with a DevEUI that already exists in the Local End-Devices list
- The system does not add Local End-Devices and displays a warning message if:
- The system adds sensors to the Managed Sensors list and:
- Creates BACnet Objects even if it skips adding Local End-Devices
- Uses the sensor definition specified in the template
- The system displays an error message and stops adding sensors and BACnet objects if there is at least one sensor with a DevEUI that already exists in the Managed Sensors list
- Users can delete duplicated sensors and try adding them again
- After the system applies the template and creates the corresponding sensors and BACnet objects, there are no dependencies or connections between the created items and the template.
- Users can change or delete templates without affecting the items created via the templates.
rCell 300 (MTR3)
This new release includes feature enhancements, security updates, and interoperability improvements.
Bug Fixes
General
- None (New Release)
Conduit AP 300 (MTCAP3)
- None (New Release)
rCell 300 (MTR3)
- None (New Release)