ePMP Software Release 5.10.0 is now available

Supported Platforms

  • ePMP AX Platforms
  • ePMP AC Platforms
  • ePMP N Platforms

Download the firmware and documentation from:

Features description

Problems corrected

Tracking ID Products Description
CAMBIUM-19866 All Fixed an issue preventing Mac-Telnet from operating on ePMP1000/2000 and Force180/190/200 radios.
ACG-15901 All Fixed abnormal increases in CPU usage.
ACG-15809 All Fixed the UI to accurately reflect the status of Option 66.
ACG-15786 All Fixed a discrepancy where the PPPoE connection was established, but the PPPoE Mode Status incorrectly showed as disabled.
ACG-15715 All Fixed that device names remain consistent after applying a cnMaestro template (requires cnMaestro v5.2.0 or newer).
ACG-15508 All Resolved an issue where Subscriber Modules (SMs) with the Primary AP Reconnect feature enabled couldn’t pass traffic after failing over to a secondary AP with different Data VLAN configurations.
AXG-11363 All Fixed occurrences of frames with invalid MAC addresses (40:00:40:xx:xx:xx) appearing on ePMP device interfaces.
AXG-11263 All Fixed the Mac-Telnet feature functions correctly when the SM is configured in NAT mode.
AXG-11118 All Fixed the issues preventing the OOKLA Speed Test from working through a VPLS tunnel.
AXG-10986 All Fixed the Watchdog feature to operate correctly with the default configuration.
AXG-10907 All Fixed the issue where the GPS Antenna Status was displayed as N/A.
AXG-10885 All Fixed packet loss issues (ping and TCP) occurring after radar detection and subsequent channel switching.
AXG-10847 All Fixed an issue where SMs configured with MIR profiles could experience random disconnections from the AP.
AXG-10707 All Enabled GPS Sync functionality in AP TDD PTP mode for F4600C devices.
AXG-10501 All Fixed rare occurrences of random disconnects with reasons such as AP INITIATED DISCONNECT or INVALID SECURITY KEY.
AXG-8321 All Fixed the Watchdog’s Ethernet restart function affects the AUX port as intended.
AXG-7090 All Fixed the issue Disable Ethernet option was missing on APs.
AXG-6953 All Fixed system crashes with the signature Assertion arq_tx_packet_timeout.c:148 (arqtx_to_pkt_add+0x1c0/0x2c0 [tdd_arq]).
AXG-11571 All Fixed an issue where the SM could not obtain an IP address from the DHCP server when STP was enabled.
AXG-11682 All Fixed an issue where the software upgrade via URL failed on SMs when STP was enabled.
AXG-11496 All Fixed a crash with the signature Crash _HTCPipeIndicateSendComplete + 0x28.
AXG-11493 All Fixed a crash with the signature Assertion failed tlv_type == CAMB_HTT_PPDU_STATS_USR_COMPLTN_COMMON_TLV.
AXG-11093 All Fixed a crash with the signature Crash camb_dp_gather_ppdu_timeout_check_peer, which could occur in Flexible mode with MU-MIMO enabled.
AXG-11814 All Fixed the issue where F300 SM failed to reconnect to ePMP 4500s APs after reconfiguring the frequency carrier with a 40 MHz bandwidth.

Flexible Licensing is disabled in firmware and is not supported.

4 Likes

Does this release fix the issue where the AP->Monitor->Wireless table would randomly show SMs with 0% DL Capacity that I thought someone else reported was there in the latest betas?

No, this doesn’t appear to have been fixed… and yes, this was reported in early 5.10 betas.

I can still select flexible mode, Should I change it to manual to us mu-mimo etc.

Is it the same during/after WLT? On my setup it gets blue as soon as I run some traffic. It is momentary indication. If SM is idle for a long time it can drift to zeros.

The fix is coming in 5.10.1 soon.

Thank you.

1 Like

Apparently, MU-MIMO in flexible mode is still not optimized in 5.10. This will be addressed in upcoming 5.10.1 release.

I updated an epmp3000 and Asymmetric Uplink Bandwidth Support does not appear

This feature can only be enabled on e4k AP’s.

1 Like

PPPoE seems to be broken in 5.10.0 (on AX, I haven’t confirmed whether or not AC is affected yet). If the PPPoE session drops, it doesn’t seem to ever re-connect. I confirmed 5.10.0-RC36 also does this, but it looks like RC35 might not be affected (most of the 5.10.0 final and RC36 clients on the AP weren’t working, but there were a couple on RC35 that were still working, but there were a couple of others working as well, so that could be a coincidence).

For added context, I had this happen on a tower that had some backhaul issues because of storm damage, so it probably was getting significant packet loss, but PPPoE did reconnect on the clients as soon as I rebooted them, so it’s possible that it’s just giving up after too many connection attempts fail, or something like that.

Asymmetric Uplink Bandwidth Support
The Asymmetric Uplink Bandwidth feature is introduced for ePMP 4xxx/Force 4xxx and ePMP 3xxx/Force 3xx devices

Unfortunately, the release notes don’t provide full clarity. The asymmetric feature can only be enabled on e4k AP’s. e3k SM’s connecting to an e4k AP using backwards compatibility mode that have asymmetric feature enabled will ONLY connect at the full channel width… NOT at the reduced uplink channel width.

See this post for guidance on asymmetric features and use cases:

1 Like

So, unless I’m doing something wrong - we have a Backhaul using a Force300 Master to a Force300 Slave which we’re trying 5.10.0 on, and it seems like we need to have ‘Backwards Compatibility’ turned on in the AP configuration for a Force 300 to communicate with a Force 300? It appears that if we don’t, the SM/Slave reports “Failed - SM has no allocation on AP”

Is this behavior as expected? Or maybe I’m doing something else wrong… I’ll go triple check my work.

10 posts were split to a new topic: Can epmp 4k SMs connect to 2k/3k APs?

This will be a poor report (I won’t be able to download or send in the tech support files) but in our graphs, I’m seeing outages on our Force 400c link with 5.10.0, and the link uptimes show that the link is disconnecting occasionally (Gap dropping to Zero at 19:40). FWIW, this 400c link had it’s Spectrum Analyzer left on… which historically does seem to cause weirdness, and but since turning it off, we still see the same unlink-relink happening. This is a poor report because no, I’m not certain if this was or wasn’t happening with 5.9.2 and No, I havent yet tried downgrading.

Signals are -53 – SNR is 44 – radio uptime is 9 days (since upgrading to 5.10.0) but the link uptime is 44 minutes.

Outages on the graphs (gap at 19:40)

Log files on the Slave Side

2025.04.09 21:47:20 kernel: [810196.093549] SM associated with AP[xx:xx:xx:21:1c:ac]
2025.04.09 21:47:19 kernel: [810195.149969] SM disassociated from AP[xx:xx:xx:21:1c:ac] F=5000 11axahe80. Reason: 36 (STA INITIATED DISCONNECT)
2025.04.05 00:44:44 kernel: [388840.014185] SM associated with AP[xx:xx:xx:21:1c:ac]
2025.04.05 00:44:43 kernel: [388839.048509] SM disassociated from AP[xx:xx:xx:21:1c:ac] F=5000 11axahe80. Reason: 36 (STA INITIATED DISCONNECT)
2025.03.31 12:46:59 DEVICE-AGENT: SessionID unavailable, regenerating
2025.03.31 12:45:58 kernel: [ 113.908151] SM associated with AP[xx:xx:xx:21:1c:ac]
2025.03.31 12:45:54 DEVICE-AGENT: Unable to discover cnMaestro URL (re-discover in 63 seconds)

This problem for the 400C device in each new firmware, after the test, you have to roll back to version 5.4.2 where the work is stable, the data provided support, but all the conversations ended in that we have problems in our network, after such statements I stopped with them, but only I observe how users complain and re -send technical information.

Hi @ninedd,
thank you very much for reporting this! It is a bug. We will fix it asap.

1 Like

Last night we updated our Cambium 4625 point-to-point backbone links to the new 5.10.0 firmware (April release), and the results were disastrous.Before the update, the links were performing normally with local ping latencies of around ~0.5 ms and a link capacity close to 900 Mbps.After updating to 5.10.0, we started seeing high and unstable latencies between 1 ms and 70 ms, even when pinging locally, along with significant packet loss.Link capacity also dropped dramatically from ~900 Mbps down to only ~130 Mbps.

We had to roll back to 5.9.0, and immediately everything returned to normal.

Is there any technical clarification regarding this version?Will there be a hotfix soon?At the moment, I would strongly advise caution before upgrading production links to 5.10.0.

Hi @Luis_Espinel ,

by any chance did you grab tchsupport files while on 5.10.0?
Do you run any kind of MPLS, VPLS, EoIP or any other kind of traffic adding overhead?

In general I have positive reports regarding 5.10.0 release. But sometimes it does not work for some costumers. I would like to investigate why it does not work exactly for you.
Please, PM me if we can have a remote session to upgrade the link back to 5.10 and isolate the issue.