ePMP Software Release 4.7.1 is now available

Supported Platforms

  • ePMP 11n and ePMP 11ac families
  • Elevate XM and XW

Download the firmware and documentation from:


Primary AP Reconnect
The feature has been developed to cover cases when SM has been disconnected from the Primary AP and connected to the Secondary one and never gets back to Primary that affects APs load and customers’ experience.

The implementation of the 1st Stage of "Primary AP reconnect " feature is available starting 4.7.1 firmware.

Primary AP is the AP which SSID is entered in the first row of the Preferred APs table.
It is considered as the default AP that SMs has to be trying to connect.

If SM has been disconnected from the Primary AP(in case of short-term outage of the Primary AP), it connects to the Secondary AP.

Starting 4.7.1 firmware the new filed “Primary AP Reconnect Period” is available for the configuration. The default value is 60 minutes. It represents the time period when SM initiates the disconnect from the AP that it’s currently connected to if its SSID doesn’t mach the one configured as the Primary AP in the Preferred APs Table.

If SM is connected to the Primary AP the disconnect is not initiated despite of the duration of “Primary AP Reconnect Period” configured.

The 2nd Stage of the feature implementation will include background scanning on the SM to avoid SMs disconnect from the Secondary AP when the Primary AP is not available and the option to configure exact time when SM verifies if it’s connected to Primary AP and disconnects if it’s not.

IPv6 support for ePMP

New firmware release extends IPv6 stack support for ePMP radios.

IPv6 functionality can be enabled on Configuration >> Network >> Advanced section:

The type of IPv6 address assignment can be set in Configuration >> Network >> General section:

4 Options are available:

Local - Interface will automatically configure link-local address. An IPv6 unicast address that uses the link-local prefix FE80::/10 (1111 1110 10) and the interface identifier in the modified EUI-64 format.

Static - Every node can be configured with an IPv6 address manually by an administrator. It is not a scalable approach and is prone to human error.

SLAAC (Stateless Address Autoconfiguration) - It was designed to be a simpler and more straight-forward approach to IPv6 auto-addressing. In its current implementation as defined in RFC 4862.

DHCPv6 (The Dynamic Host Configuration Protocol version 6) - The most widely adopted protocol for dynamically assigning addresses to hosts. Requires a DHCP server on the network and additional configuration.

When an IPv6 node is connected to an IPv6 enabled network, the first thing it typically does is to auto-configure itself with a link-local address. The purpose of this local address is to enable the node to communicate at Layer 3 with other IPv6 devices in the local segment. The most widely adopted way of auto-configuring a link-local address is by combining the link-local prefix FE80::/64 and the EUI-64 interface identifier, generated from the interface’s MAC address.

In NAT/Router mode corresponding configuration appears in Configuration >> Ethernet >> Ethernet interface:

The user now can choose the way how IPv6 address is assigned to the radio Ethernet interface and DHCPv6 options. The built-in DHCPv6 server assigns IPv6 addresses to clients connected to the LAN interface while the device is operating in Subscriber Module mode.

Disabled: The device does not assign local IPv6 addresses and other network settings.

Stateless: The DHCP clients select their own IPv6 addresses (also known as SLAAC). (The DHCPv6 server assigns network settings except for the IP addresses to DHCP clients).

Stateful: The DHCPv6 server assigns IPv6 addresses and other network settings to DHCP clients.

Separate Wireless Management Interface now can be configured with required IPv6 address assignment type:

IPv6 over PPPoE with LAN Prefix Delegation scenario is supported by ePMP. CPE does an IPv6 request with a subnet size (or prefix length that is manually configured) through the PPPoE tunnel and it then assigns IPv6 addresses to the internal network devices.

Wireless IPv6 Assignment specifies how the IPv6 address is obtained. If “PPPoE static” is selected, then the user will enter in Wireless IPv6 Address and Wireless IPv6 Gateway in the General section manually. If “PPPoE auto” is selected, then all necessary fields will be obtained from PPPoE Server. “PPPoE auto” will occur over the wireless interface by default.

Device Default Local IPv6 Address - Default IPv6 address used for accessing ePMP Device from the wired interface (Ethernet) without any prior configuration will be added in the future firmware releases.

Seamless Channel Switching

Switching AP to a different channel always caused disconnection of all Subscriber Modules (SM) for
ePMP platforms that led to services interruption for customers. Sometimes it takes up to 3-5 minutes to
reconnect to the AP depending on number of frequencies are configured in the scanning list on SM.
The Seamless Channel Switching feature is implemented from 4.7.1 firmware that brings no disruption of Internet access for the users if the operator needs to change Channel Bandwidth or Primary Frequency on the AP.
The new feature is available only on 802.11ac devices in TDD and TDD PTP modes. It is enabled by default and no actions are required from user for the configuration.


Starting from System Release 4.7.1 and 5.6.0, the use of HTTPS over HTTP for GUI access is enhanced with the security of the customers environment.

If ssh port forwarding is used to access UI or automation scripts are in action then precautionary measures should be taken before upgrading to releases 4.7.1 and 5.6.0.

Access to the UI can be conducted through HTTP port 80 or HTTPS port 443. In the previous releases,
the default setting uses HTTP and port 80. In the upcoming releases, the default setting is to use HTTPS and port 443. Also the settings to use both protocols simultaneously is introduced to simplify thetransition period.

To change the default settings, navigate to Configuration > System

Screenshot from 2023-07-06 14-40-23

You can update the the certificate automatically or manually.
Access protocol can be configured through the following command:

F325_cs_84>config set webService 1
F325_cs_84>config commit

1 - HTTP,
2 - HTTPS,
3 - HTTP and HTTPS

cnMaestro template can be used to spread the configuration across the network:

  "device_props": {
    "webService": "1"

1 - HTTP,
2 - HTTPS,
3 - HTTP and HTTPS

Defects fixed

Tracking ID Products Description
ACG-15187 Force300-13L, Force300-25L SMs did not detect AP after upgrading software on rare occasions
ACG-15171 All The log file of AP was flooded with “mgtcomd: Incorrect destination address” message.
ACG-15169 All DL Max configured on SM was not applied without re-connect.
ACG-15084 All DHCP Option 43 URL information was missing on the Monitor- Network page.
ACG-15086 All If Radius Server is stopped, SM was not reachable through the Ethernet interface. An SM is de-registered when the EAP-TTLS Authentication was enabled.
ACG-15100 All If HTTP+HTTPS was enabled (by default), downgrade from ePMP Release 4.7.1 was prevented.
CAMBIUM-19513 All ePMP devices were sending the wrong status in cnMaestro if SW Upgrade/Downgrade was initiated but is not allowed.
CAMBIUM-19434 All One elevate device was not allowed to connect without the license to any first generation ePMP non-GPS radio.
ACG-14816 ePMP 3000 Falls Radar was detected under UK country code on ePMP 3000 4x4 Access Points.
ACG-14969 All The RSSI or SNR from ePMP radios were not reported to cnMaestro.
ACG-14985 All Trimmed hostname was reported to DHCP server, if the SM device name contains whitespace.
ACG-15014 ePMP 3000L, Force 300 Stability improvements for ePMP 3000L and Force 300 when SA is enabled.
ACG-15030 All Configuring the same value for Port Begin and Port End in Port Forwarding rules section was not possible.
ACG-15066 All Odd slashes were appearing in the cnMaestro URL field after the configuration is saved.
ACG-8186 ePMP 3000 Ethernet Interface speed OIDs was reporting wrong value on ePMP 3000.
ACG-11287 All Traffic stuck happened occasionally when EAP-TTLS option was enabled.
ACG-13317 All Retransmission Packets counter displayed more than 100% on SM’s Statistics after SM was disconnected.
ACG-13498 All DSCP QoS prioritization did not work for IPv6 with Traffic class.
ACG-13634 All MPLS traffic could not reach the maximal possible trhroughput over ePMP link.
ACG-13813 All EoIP was not balanced between channels on PTP550 when operates in Channel Bonding mode.
ACG-13902 All Registration state of the SM was displayed as 41 number.
ACG-13997 All Low throughput and high latency might be seen on AC generation sector.
ACG-13412 All IPsec connection broken on the rare occasion when established over PTP550 link.
ACG-14552 ePMP 3000 Stability improvements for ePMP 3000.
ACG-14576 All F300-25 could not be upgraded though CNUT.
ACG-14597 All IP address of the device was not present in the SOAP messages with Management VLAN for TR-069.
ACG-14677 All The show wireless command did not return any data in CLI.
ACG-14693 ePMP 3000 Some MAC addresses was missed in bridge table on ePMP 3000 occasionally.
ACG-14762 All DPI Current Speed counter Uplink displayed the DL iperf traffic rate.
ACG-14863 All RSSI was changed after upgrading to 4.7/ on PTP 550 when operating with 10MHz bandwidth.
ACG-14884 Force 300-25 There was no LED indication when Force 300-25 reset to factory default was initiated.
ACG-14894 All AP can switch to the alternative channel that was previously removed from configuration.
CAMBIUM-18691 All Elevate XM and Elevate XW devices were experiencing difficulties to connect to cnMaestro.
CAMBIUM-18741 Force 180 Stability improvements for Force 180.
CAMBIUM-19211 ePMP 2000 Stability improvements for ePMP 2000.
CAMBIUM-19215 All Protection of N generation SMs against the DNS-rebind attack.
CAMBIUM-19341 Force 200L Force 200L was rebooting spontaneously on rare occasion.
CAMBIUM-19378 All N generation SMs did not allow to perform firmware upgrade from cnMaestro without doing the reboot.


Flexible Licensing is disabled in firmware and is not supported anymore.


Looking forward to using the new features

How much this final release differs from 4.7.1-RC24 or is it the same?

It’s 4.7.1-RC24 released as the official firmware.

Please do NOT use this version in production, will cause unreachable stations and a lot of truck rolls to downgrade.
The CRITICAL issue of SM not connecting to AP is NOT solved, i opened 2 tickets for this and nothing has been tested, only pointless questions from Cambium Support.


Does this fix the issue with MCS 1 upload lock and the problem where the SM force190 and force200 was turned on during +70 days it will lose the connection and had to be rebooted manually?

The reboot problem is something i can’t test until 70-80 days pass for obvious reasons, and at the moment i check evey two weeks and reboot from CnMaestro all devices that are turned on for more than 40 days. It’s really a pain in the ass thing to do, this problem was introduced in 4.7.0 version.

I would appreciate it if you can provide ticket numbers please.

Yes, it was fixed in 4.7.1.


I am seeing some wierd issues on 4.7.1 and 4.7.1rc 24 with 3000ls ethernet flapping and rebooting??

Force 300-25L registration still not resolved in this FW

Reason: 24 (LOST INAR) still present

Any idea when 4.7.1 will be available in cnMaestro cloud?


It’s released to cnMaestro Cloud now.
I apologise for the delay.


I decided to check out 4.7.1.
Maybe it’s a coincidence, but it’s dramatic!
Master 300-16 and 3 client antennas 300-13, distance 150-200m.
On everything worked fine.
Now, however, the Invalid Sec key does not connect at all, others connect after such a long time that it’s shocking. On the way that always connects the fastest, throw INAC MISS TIMEOUT.

I have to travel several hundred kilometers to fix it :slight_smile:
I do not recommend installing on such a set.

We would appreciate it if you can provide tech support tiles
We haven’t seen the issue on lab/field test setups and nobody reported the same for any out of 4 Betas released before going to official release either.


After a longer analysis, it turned out that the transmitting antenna was set to a specific frequency. After uploading 4.7.1, it switched to ACS and the channel changing madness began.
It works stably for now, but why does it decide to switch to dynamic mode despite the rigid setting of the 4.7.1 channel?
For me it’s very risky and strange :frowning:

Additionally, this entry is still in the logs, I must admit that I was hoping that it would disappear after leaving BETA.
Jan 14 22:12:56 F300-13_CAW creporterd: kernel process_crash… get_crash_data fail : -1. It blurs all logs and probably indicates an error. I will write again that with there was no such situation.

We’ve updated many hundreds of radios and dozens of AP’s and have not experienced this.

Has this happened more then once? Are you able to reproduce this issue?

This was my first update to 4.7.1.
Maybe it’s a coincidence that this happened in such a set?
I don’t know, but it was a big surprise for me :frowning:

It’s not fine when an update change some settings.
Good to know.

I’m not saying it’s a rule!
This happened to me, but I don’t know what caused it. What’s worse is littering the logs with this “-1” error. This is very annoying :frowning: