ePMP Software Release 5.10.1 is now available

Products ePMP
1

Supported Platforms

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

Download the firmware and documentation from:

Features description

The MU-MIMO is now supported for Split Sector mode for ePMP4500C and ePMP4600.

Problems corrected

Tracking ID Products Description
CAMBIUM-19995 All Fixed the issue where the syslog did not display the hostname.
AXG-12060 All Fixed the issue where PPPoE traffic was not accelerated when VLAN was enabled, which reduced throughput.
AXG-12044 All Fixed the issue where SM in NAT mode crashed when hardware acceleration was disabled.
AXG-12006 All Fixed the issue where VLAN-tagged traffic was not accelerated, which reduced throughput.
AXG-11882 All Fixed the issue where the DHCP request showed a truncated device name if it had spaces.
AXG-11849 All Fixed the issue where enabling asymmetric bandwidth caused downlink MCS degradation.
AXG-11845 All Fixed the issue where MPLS traffic was not accelerated, which reduced throughput.
AXG-11842 All Fixed the issue where MIR limited the uplink rate unexpectedly.
AXG-11834 All Fixed the issue where the ePMP 4500L allowed more than 43 SMs to connect. Improved MU-MIMO performance.
AXG-11744 All Fixed the issue where SMs failed to connect if the AP’s frequency carrier changed while using 40 MHz bandwidth.
AXG-11713 All Improved performance for backward compatibility mode with N-gen SMs.
AXG-11683 All Fixed the issue where some SMs showed DL Quality as 0%.
AXG-10847 All Fixed the issue where SMs with MIR profiles randomly disconnected from the AP.
ACG-15920 All Fixed the issue where the separate management interface MAC address changed to 02:FF:FF:FF:FF:FF after SM reboot.
AXG-12199 All Fixed the issue that caused F4525, F4625, and F4518 devices to crash after switching to Spectrum Analyzer mode.
AXG-12268 All Fixed an issue where IPv6 traffic was not accelerated, resulting in reduced throughput.

Flexible Licensing is disabled in firmware and is not supported.

2 Likes
2

Hi. If I already have RC16 on a sector, is this release version later than that, or is it just RC16 renumbered as a release version? I’m wondering if there is a benefit of upgrading if sectors are already RC16? Thanks.

1 Like
3

Hi @ninedd,

it is the same! We always rename the last published beta into stable.
Thank you very much for participating in our beta testing!

4

@aka I’ve uploaded it and MU-MIMO still says beta quality, when will we have a stable MU-MIMO and beamforming ?

5

Hi @russ007,

it is already stable enough as I see from our customers’ deployments. The badge beta-quality is very subjective. It means that we still may see some environment specific cases and there is a space for improvements.
Thank you!

6

Does this mean we can turn hardware acceleration back on for our 425 links and expect them to function normally with mpls on the network?

2 Likes
7

Hi @aka Thank you for the confirmation, does it still utilize beamforming and can flexible mode be used or must I use fixed frame.

8

Yes, it makes sense to get it enabled. We expect that we finally have cleaned up all the issues related to hardware acceleration when it could affect some traffic types.
Thank you.

9

MU-MIMO is not yet fully optimized for Flexible mode, which is why it’s still labeled as Beta Quality.
For better utilization of MU-MIMO capabilities, I recommend using Fixed Ratio mode.

Thank you.

10

We had multiple links that were having issues with hardware acceleration enabled. After updating to 5.10.1, we’re now able to have it enabled on every radio without issues.

4 Likes
11

What is hardware acceleration? What is its purpose? In which family is it available?

12

Hardware acceleration allows for network traffic to be directly processed by the wifi chipset vs. being processed in software, which can be slower and use more resources. This feature is enabled by default on the ePMP 4000 platform. There’s no reason to disable it unless you’re having issues, and with the fixes in 5.10.1, there’s most likely no reason to disable it going forward.

3 Likes
13

Awesome to hear! I’m curious, have you run into any scenarios where your links actually saw an improvement after re-enabling it? None of ours have been pushed hard enough to really see a difference

14

I haven’t noticed any performance improvements with it enabled vs. disabled, but then again, like you, I don’t believe I’ve pushed them hard enough or are running enough secondary services (like MIR shaping, QoE, DPI, etc) to make a difference.

1 Like
15

Makes sense, thanks as always for the info Eric

16

Beginning with Version 5.4.2 No Corre firmware for EPTP Force 400C had all subsequent firmware in the bridge mode gave a periodic spontaneous fall of the channel not to understand the most, the bridge is used the simplest PTP

17

We have a similar issue. Ruffly every 25 days the AP / Master appears to loss it’s Sec key and will cause the other end to fail its WPA negotiation. Rebooting the Master is the only solution.

18

Hi @anthonyw,
could you elaborate on this? What exactly happens?

19

Not much to ad. It is a 400c PTP operating in DFS channels. Little to no traffic as it is a backup for a Siklu. The error is a failed WPA secret. I don’t not recall seeing any correlation with a DFS event and the described issue. The master just appears to “change” it WPA secret and it remembers it after a reboot.

20

@anthonyw could you PM me a techsupport right after it happened?
Does it put some random password? Or default, or the one you had before?
Is it onboarded to cnMaestro?

The radio does not store old passwords. Default ones can pop up after reset to default only.
There is no method rewriting passwords which can be triggered under the hood by mistake.
If it really gets changed it must be some external configuring.