ePMP Release 4.6.1 is now available

This feature is only for e3k. EDIT: will work on e1k GPS and e2k AP’s made after Aug 2019.

Actually it applies to every ePMP radio with 3rd generation of GPS chip.

Thank you.

1 Like

Ahhh OK. I checked all my e1k GPS and e2k AP’s that were updated to 4.6.1 and none of them displayed the GPS type (internal/external) in the GUI. I guess you have to have a e1k GPS or e2k made after Aug 2019.

Im trying to use that “Max MCS Downlink” feature and it kinda works. On a F300-25, im setting it to DS MCS 3 but from performance page it sort of limits it. SM would get up to DS MCS 7. I went ahead and rebooted SM and now it appears its being limited to DS MCS 5.

On status page MCS never rises above DS 4. I would guess the Performance page is more accurate. See attached for tech support file.
ePMP-Tech-Support.zip (1.1 MB)

Dear Fedor

I have an epmp 2000 base radio that I have upgraded both the firmware and the GPS firmware to the latest version But still yet the AP is still loosing GPS sync. Kindly help me what can I do?
Currently I still have an installed external GPS antenna puck to the base radio and it is open to the sky. Yet it is not working kindly advice what else can I do?

I can’t seem to find any documentation for DHCP option 66 for ePMP SMs.
We are constantly running into issues with field techs not using proper base config templates or just missing some settings. This isn’t much of an issue on our Canopy gear since we use RADIUS to push “Cambium-Canopy-ConfigFileImportUrl”=“tftp://serverIP/golden.cfg”. It would be wonderful if we could do the same for ePMP. If not a similar RADIUS VSA, then fallback to DHCP option 66 could be a usable solution, but what is the format? If the SM will only make a request for it’s ESN/MAC and we cannot do a ‘golden’ config file like Canopy, that would be a real bummer.

Why cant you push a config to epmp? We use per client VSAs to push the specific settings to each SM but when we onboard a SM we apply a “golden” template to the SM. Option 66 is also available though it is not documented but is noted as available in the user guide. The SM looks for a file at the location the DHCP server specifies. The file format is the same as the template format from cnMaestro or the config backup (same thing), infact you can make a clean config from an SM and download it, then delete the SM network name and mac addresses from the config file to make universal to the platform, ie only for epmp. Then specify this file in DHCP option 66 with a mac address filter to ensure it doesnt try to apply to a canopy radio.

Force 300-25 running 4.6.1 has problems with ePMP 1000 AP running 4.4.3. Frequent drops and wild speed fluctuations. Resolved by downgrading SM to 4.4.3 or 4.5. Does have me concerned about rolling this release out. If the ePMP 1000 AP was running 4.6.1 would I still have this issue? Scared to roll out 4.6.1 at this point. Ugh.

It’s best to have AP and SM running the same firmware. Why would you downgrade SM instead of upgrading AP?


Gosh - why are you mixing firmware versions? That’s going to cause weird problems quite likely. :slight_smile: We’ve always found that the best results are with the AP and all SM’s to have the same firmware versions.

If you think about it, the only reason to come out with new firmware, is:

  1. Need new features, or
  2. Discovered bugs or shortcomings in older version.

So - 4.6.1 resolved bugs and added features not found in 4.6.0 or 4.5.6 or 4.4.3… then upgrading only 1/2 of the radios to the bug free version isn’t likely going to work very well. :slight_smile: I’d strongly recommend having the AP and its SM’s on the same firmware. For us, 4.6.1 is deployed on everything (AP’s SM’s 5Ghz & 2.4Ghz PTP550 and all Force300 Backhauls - and no issues showing up for us.


We have found that the v4.x firmware is NOT mix and match… having just a single SM with a different version of 4.x.x will very often cause problems that affect the client or the AP.

We have customers move in to places we already have service installed and plugging in radios that haven’t been online for many many months sometimes. Since 4.x.x firmware this causes all kinds of problems sometimes.

It seems the higher the version the less friendly it is with anything other than itself.


Thank you for reporting that. We will check and revert to you.

Thank you.

Could you please attach the screenshot of Monitor → GPS page?

Thank you.

I agree. But I dont usually update all APs immediately after a release comes out. I find that to be kindly dangerous on a large network. And it just so happened we had some SMs our installers were trying to use that were on 4.6.1. I can surely work towards getting all APs & SMs on the same version but it wouldve been nice if it had been disclosed this was a requirement to use 4.6.1.

1 Like

So many reasons there would be a radio that isn’t running the same firmware as the others on the AP.

For whatever reason installer not able to use radio provided for the install and uses one that has been on the truck for a while and wasn’t updated to current version of software.

Installer ends up installing customer on tower other than the one radio was set up for. The new tower is running a different version (because we roll out firmware updates slowly, cautiously and one tower at a time at first).

Customer’s service was off for a long time then one day they plug the radio back in (especially fun when it’s the magical combination of mixed versions that cause the AP to start rebooting…)

Sometimes a customer radio just manages to slip through the cracks. For example customer radios that refuse to take updates, gets hung during updates, won’t reboot after an update, can’t be accessed via HTTP or SSH.

Or now since even the CPE’s have two copies of firmware the AP or the CPE can be running a different version if either reverts to the backup bank (assuming you like to live dangerously and the backup bank had a different version). So now two reasons to make sure both banks have the same version of the firmware.

1 Like

Hi. If you’re replying to me - I was only suggesting making sure that this one AP and it’s SMs are on the same version. Different AP’s can be different versions if you don’t want to upgrade the whole network at once - that’s fine, that’s up to you. We ran all our older ePMP1000/2000 & ePMP 2.4Ghz stuff on 3.5.6 for a long time, with just the 3000s/F300’s on 4.x latest versions.

I just just saying that with pretty much any gear from any brand, if they discover a bug in version X.5 of the firmware, and they come out with X.6 to fix it… then applying that fix to either just the APs or just the SMs is probably only ‘half fixing’ the problem. It’s usually recommended to apply it to BOTH the AP and it’s SM’s. Even if that’s just 1 AP to start… that’s cool… but apply it to both the AP and the SM’s connected to that AP for the most consistent results.

1 Like

I am agreeing with Brubble and Ninedd, this is a sector thing not a network thing. Dumping the latest FW on a network is dangerous and disruptive. We have a couple towers to start with (no business clients makes a good target) after we test on the bench first. Nothing like abusing a new FW to show the behavior first. Then we push to the target tower, target sector SMs then AP. wait a couple days while logging everything to ensure that its stable in the wild. Most of us old hats have been doing this a long time and have been burned by firmware updates that kill a section of the network forcing a truck roll to go fix it, we have learned to be slow and methodical.

1 Like

I hate to be ‘that guy’ again, but I don’t see R4.6.1 on cnArcher…

2 posts were split to a new topic: Cacti bandwidth usage changes on 4.6.1

We are updating our network from 4.5.5 to 4.6.1 today and have had a few ePMP2000 APs that are not accepting clients until we switch the antenna selection from AUTO to Forced sector. Once we start to see clients reconnect, we are able to switch back to AUTO and clients come back online as normal.

1 Like