3.3 is available on cnMaestro now.
Sorry for the delay. It took a bit longer than expected due to Cambium Networks global presence in several time zones in Americas, Europe, Africa and Asia. Anyhow now ePMP release 3.3 is available at cnMaestro cloud service.
Enjoy the download :)
From the release notes, it doesn't look like there's any major changes or improvements unless you're running Elevate or IPv6. Is that accurate?
Hi,
ARP-NAT support has been added.
Forced Smart Antenna option also has been delivered.
With 3.3 Release you can check throughput for particular SM throufh Sector Antenna and through Smart Antenna from Wireless Link Test page.
Thank you.
2 Likes
@dshea wrote:
From the release notes, it doesn't look like there's any major changes or improvements unless you're running Elevate or IPv6. Is that accurate?
Hi dshea, There are some bug fixes too. The most notable was the snmpd crash issue that plagued 3.2.
Thanks,
Sriram
2 Likes
OK, fixing the snmpd crashes makes a good reason to update!
1 Like
I wait some days before using this release in production since the BIG bug of SNMP crash caused me to make a lot of cold reboots over towers... now I'm scared of new undocumented bugs of every new release!!!!
I hope this one will be more stable...
Regards,
Paolo
I hear ya on this one i rolled this out to a tower with a single AP and only 10 Subscribers everything looks good so far.
3 Likes
I've tried to update my Force180 at home, to see how new firmware works...
Well, the new 3.3 version seems to give a lower RSSI signal compared to 3.2.1 or 3.2.2
Here are screenshot of wireless status page:
--------------------------------------------------
Someone else is noticing this problem?
Best regards,
Paolo
There are a number of ways to calculate and estimate RSSI. I assume the method changed from 3.2.1 to 3.3, but it doesn't appear to be chaning the actual signal nor the performance of the links. It appears the SNR is the same across versions, as well as the MCS rates. My guess is that something changed in 3.3 in how it determines noise-floor and its estimation is lower than what it was in previous versions. Now, if you see MCS rates tumble from version to version, then we may have a service affecting issue and not just a (potential) reporting issue.
3 Likes
Well other than "Subscriber Module Target Receive Level" having to be changed on all APs .
Also Network Entry RSSI Threshold will have to be changed.
Hay installers -82 is the new -76 ! Or is it ? Will the connections work well at -82 now ? Lets relearn what the radios will and won't do !
How accurate is the SNR level actually because if it works like it does on Ubiquiti then it doesn't actually look at noise it just looks for other 802.11 sources and uses that to calculate SNR. So if you have interference from something other than 802.11 that the radio doesn't recognize then your SNR number is useless.
Oh and next firmware update RSSI may change again ! Installers love change !
And helpdesk...
Really hope this is just another display bug and they didn't actually change the way they calculate RSSI...
Did you notice if the TX power or UL-MSC on the SMs changed? The screenshot from pftech shows it changed 2db, vs the 5db change in RSSI, but that 2db (or 3db the other way) could just be from normal variation/noise. I could be wrong, but I beleive SNR is the more accurate number and the one that Cambium is acutally using for its calculations. But then I ask myself, why don't they use SNR for "Subscriber Module Target Receilve Level"? Either way, I agree, it seems the RSSI reading is off in 3.3, and to your point, is, if nothing else, confusing to installers.
Hi all,
Actually there were several changes related to RSSI calculation and representation in 3.3 Release.
In previous Releases you might see RSSI difference between ePTP and TDD mode. Issue has been solved in 3.3 Release.
SNR value should be the same in 3.3 in comparison with previous Releases.
ePMP system select rate to operate on on SNR basis, but not RSSI.
So changes should not affect your links performance.
The only issue may appear with RSSI watermarks configuration on SMs.
Sorry for inconveniences.
Thank you.
2 Likes
Actually even beyond SNR, the MCS rate selection is based heavily on packet loss (PER). So whether its RSSI or SNR variation/display on the GUI, your link performance will not change if the environment conditions haven't changed.
brubble1, you make a great point about the thresholds. Yes, that is something you will have to watch out for in 3.3 as the RSSI display in TDD mode was corrected.
2 Likes
I'm seeing that with 3.3 when you run SNMP to check the reboot count it comes back with no value if there have been no reboots since clearing the stats last. Where all other versions send back a 0. Is this a bug?
Mat
Hi Mat,
Thank you for sharing your observation.
I will check it and revert back.
Thank you.
@matkix wrote:
I'm seeing that with 3.3 when you run SNMP to check the reboot count it comes back with no value if there have been no reboots since clearing the stats last. Where all other versions send back a 0. Is this a bug?
Mat
Hi Mat,
I've checked this case and bug is confirmed there.
We will fix it in next Release.
Thank you for your help.
1 Like
I'm seeing a problem with provisioning, specifically relating to Force200 5ghz radios. When we update a new radio to 3.3 firmware, it then refuses to finish applying the config file we upload to it after reboot, the same config file we've uploaded to hundreds of radios on earlier firmware. (complicated by the fact that we push the config file to the new radios via SNMP from a script, and it DOES apply some parts of the config but not others, presumably everything after the first field it doesn't like) Note that this same process (update to 3.3 then push this same config file) worked as expected for a couple dozen Force180s yesterday.
So far I've identified one data field that it barfs on - we use an IP-based QoS classification rule, with a 255.255.255.255 netmask - a single IP address. Prior firmware had no trouble with that, but 3.3 rejects 255.255.255.255 as being an invalid netmask when entered manually in the webUI. I don't know if that has any impact on config import though - as stated the Force180 radios took the config just fine, and show 255.255.255.255 for netmask, though if I manually re-enter 255.255.255.255 it rejects it as invalid.
I don't yet know if other fields are also problematic... Complicating things somewhat is that we use a .bin config file (need passwords included) so I can't manually deconstruct the config easily, will need to push it to an older firmware unit and compare results, upgrade that unit to 3.3, test settings corrections, etc...
j
OK, I updated a Force200 5ghz radio to 3.3 firmware, manually configured it as needed, then downloaded both the .bin and .json config files.
Then I manually updated another Force200 5ghz radio to 3.3 firmware, and it then refuses to apply the .bin config file although it accepts and seems to apply the .json version. (all through webUI)
So it appears limited to the binary config for some reason.
j