@Cambium_Lena - are there any changes from RC27 to this release version? Or was RC27 simply deemed to be Release Ready as was previously discussed? The reason I asked is that I just just finished updating the whole network to 4.6.1-RC27 (except for our Force 400/425’s on V5 of course) and if this is the same software, I won’t rush to re-upgrade… but if there are differences from RC27, then I’ll go ahead and re-up everything.
And yeah Eric - what a fabulous flurry of fantastic features & fixes!
There were few minor fixes after RC27.
Thank you.
EoIP still slowly…
Thanks
ACG-4998
Does it work on AP 1000 and AP 2000?
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.
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 4.6.0.1. 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. 
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:
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. 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.
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.
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.