ePMP Release 3.3 is now available.

Products ePMP
21

Hi Mat,

Thank you for sharing your observation.
I will check it and revert back.

Thank you.

22
@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
23

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

24

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

25
@newkirk wrote:

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

Hi J, 

We had another customer report this as well. But in his case, the GUI threw an error saying "“Configuration restore failed” but this was a false error and the .bin did get imported correctly. Is this what you are seeing or does it outright not accept the configuration?

We have reproduced the false error and will be fixing it in 3.4. Workaround is to ignore the false error or use the .json like you said.

If you are not seeing a false error, will you be willing to share your .bin and .json file with us so we can investigate? Send it to my email at sriram {at} cambiumnetworks {dot} com. 

Thanks,

Sriram

26

I have seen a similar issue, but the config seems to restore we just get the error saying it failed.

27
@matkix wrote:

I have seen a similar issue, but the config seems to restore we just get the error saying it failed.

Yes, this is the false error that we will fix in 3.4. Can you confirm that this happens only with the .bin file?

Thanks,

Sriram

28

Sriram - will email in a few minutes, it is definitely not applying most of the config file.  The password gets changed but most of the other settings do NOT.

I normally push the config via SNMP and don't see error messages.  When I tried manually via webUI I did get the message "Configuration restore failed.  Restored."

Same thing happened just now with a 2.4GHz Force200.

I just configured that 2.4 manually after updating to 3.3, then rebooted and downloaded both JSON and bin configs.  It then refuses to allow me to restore the same binary config I JUST downloaded from the SAME RADIO.

j

29

Also, separately, the recent change to refuse 255.255.255.255 as a valid netmask for QoS rules is irritating...

One other gripe I have about the webUI in the newest firmware releases, best illustrated by an example:

I click on the IP address field.  Enter an IP.  Hit tab to go to the next field and start typing a subnet mask.  Then about 2 seconds after I exited the first field, the changes I've already typed into the new field get wiped out.  Happens all over the UI, IP address is just a handy example.  (e.g., I type in our cnmaestro URL, hit tab, and have already typed 'cnmaestro_' when it wipes it out, leaving the field as the characters 'on_premises' that I'd typed afterwards)

Not sure when it started doing this, I think it might have been 3.1.  But it drives me nuts that I have to type in an entry, hit tab, then deliberately wait for 5 seconds or so before typing anything into the next field.

j

30
@newkirk wrote:

Also, separately, the recent change to refuse 255.255.255.255 as a valid netmask for QoS rules is irritating...

One other gripe I have about the webUI in the newest firmware releases, best illustrated by an example:

I click on the IP address field.  Enter an IP.  Hit tab to go to the next field and start typing a subnet mask.  Then about 2 seconds after I exited the first field, the changes I've already typed into the new field get wiped out.  Happens all over the UI, IP address is just a handy example.  (e.g., I type in our cnmaestro URL, hit tab, and have already typed 'cnmaestro_' when it wipes it out, leaving the field as the characters 'on_premises' that I'd typed afterwards)

Not sure when it started doing this, I think it might have been 3.1.  But it drives me nuts that I have to type in an entry, hit tab, then deliberately wait for 5 seconds or so before typing anything into the next field.

j

Hi newkirk,

Issue with invalid netmask validation in QoS rules has been confirmed and will be fixed in 3.4 Release.

UI issue is already known one and also will be fixed in 3.4 Release.


Sorry for inconveniences.

Thank you.

31

I started a POC yesterday with one ePMP AP 2000 Lite and two FORCE 200. The AP acts as a Repeater (nothing connected at the ethernet port) and all the traffic flows from CPE-1 to CPE-2 via the AP. 

The throughput is very low - internet DL at point 1 is 40Mbps and at point 2 17Mbps but more seriously CPE 1 crashes everytime a start a OKLA Speedtest.

The units were upgraded to 3.3 prior to the installation.

32

Hi,

I have sent email to you.

I would be really appreciate it if we could discuss and troubleshoot issues you have faced with.

Thank you.

33

Just a nit I needed to pick - With firmware 3.3 on an ePMP2000 AP, the browser title when not logged in is "ePMP 1000".  ;)

j

34

I remember we have changed it to ePMP2000. It could be cache issue, please try to clear cache and check it again. Anyway we will double check title.

Thank you for your help, Joel.

35

Well, I double-checked on two different APs.  It looks like it gives me "ePMP 1000" at first, but when it logs me out idle the title becomes "ePMP 2000".  If I then shift-reload that login page it goes back to "ePMP 1000" - and one of those radios is the only thing that's ever lived at its IP address, reducing the chance that it's cache-related.  (the other one is defaulted on the bench)

j

36
@newkirk wrote:

Well, I double-checked on two different APs.  It looks like it gives me "ePMP 1000" at first, but when it logs me out idle the title becomes "ePMP 2000".  If I then shift-reload that login page it goes back to "ePMP 1000" - and one of those radios is the only thing that's ever lived at its IP address, reducing the chance that it's cache-related.  (the other one is defaulted on the bench)

j

Hi Joel.

Unfortunately I cannot reproduce issue with 3.3 FW.

I would be appreciate it if you could attach screenshot where issue is reproducible.

Thank you.

37

Connected to AP with Dolphin browser on my tablet (never used to connect to that AP) and the title on the login page (http title, the window/tab title, not the header within the page view) shows "ePMP" while loading, then "ePMP 1000" while awaiting login.  Once logged in it changes to the assigned name of the radio.  When I log out it then shows "ePMP 2000" with login prompt, and assigned radio name in the header.  Reload and it's back where it started.

Three screenshots attached.

j

1 Like
38

Oh, I see.

Thank you very much.

We will fix this issue asap.

Thank you.

39

Anyone else having issues with this release. We have over 100 units that were upgraded and most all seem to exhibit re-booting at random times now. if we roll abck to 3.2.2 problem goes away. in doing so we have rolled back on a couple units and they faild to come back up like the donwngrade failed and had to replace the radios!

WHATS GOING ON HERE??? we are now afraid to even downgrade to 3.2 for fear of bricking radios now.

40
@accelwireless wrote:

Anyone else having issues with this release. We have over 100 units that were upgraded and most all seem to exhibit re-booting at random times now. if we roll abck to 3.2.2 problem goes away. in doing so we have rolled back on a couple units and they faild to come back up like the donwngrade failed and had to replace the radios!

WHATS GOING ON HERE??? we are now afraid to even downgrade to 3.2 for fear of bricking radios now.

Hi Martin,

We haven't heard regarding such issue from other customers with 3.3 Release.

Are units re-booting in TDD mode? Are only AP or SMs or both affected?

Could you please let us know whether crashlog has been saved after spontaneous reboots?

Thank you.