PMP450x Release 15.1 is now available

Products PMP
1

PMP450x release 15.1 is now available at:  https://support.cambiumnetworks.com/files

2

Thanks - Which of the Betas, if any, does this incorporate?

3

Luis,

This is same as BETA-8 which was posted last Wedneday.

--Rajesh

4

Thanks Rajesh

5

QoS adhearing quite nicely in NAT mode  -  Up & Down - Thanks

Now can we please work the sorting problems...  

They are getting worse with each release.  Some pages no longer sort at all.  

Please, please please,please, please! Restore the sort function and use the device name NOT the LUID.

1 Like
6

Did we break table sortig with 15.1? Can you point out which page(s)?

We will put the device name first in the display string, so it actually gets sorted by name.

7

Yes (?), I didn't notice any sorting problems on the Statistics/Data VC or Throughput pages prior to the 15. Betas.

With 15.1 B7, sorting was 100% broken - I didn't load 15.1 B8.

I use Chrome and normally run with AP Webpage Auto Update at 1 sec.  I only have PMP450 APs.

I was able to duplicate using Firefox as well

With the Official release, sorting consistently breaks when:

Webpage Auto Update setting is not 0 - Disabled

And

Sorting on any column other than Subscriber and LUID  

I am able to recover sorting by clearing the browser data (cache) and reloading the page.

Maybe add a pop-up to disable Webpage Auto Update and/or automatically disable Auto Update while sorting by any dynamic field.

This hick-up not withstanding, sorting by Subscriber on these two pages works as expected.  That is, sorts by Device Name not LUID.  I expect this to be the norm on any page displaying a "Subscriber" column, namely Home/ Session Status/Session Status List/Device, Session, Power and Configuration pages.

The Tools/Link Status page auto sorts the Subscriber column by LUID not Device name; eventhough the device name is listed first. 

Hope this helps

8

I upgraded a PMP 450 3ghz AP from 14.1 to 15.1. I then enabled SM auto update. I am using radius for bandwith authentication. User authentication is set to local. With the SMs running 15.1 radius authentication is broken.  I had to disable authentication to get the SMs to register.  I am forced to use radius for everything now?

9

Hello Myke,

We apologize for the inconvenience. 

Can you please tell us if you are using wisptoolbox for radius server? We are investigating this issue at the moment as high priority. Is it possible for you to try a different radius server to see if issue gets resolved? I can totally understand if setting up differnt radius is not possible. However do let us know if you are using Wisptoolbox version for radius server. 

While we investigate this issue, please do not load 15.1 build if you are using AAA. We will post a reply as soon as we have more information. There are lot of folks already using 15.1 with radius and have not seen any issues. 

Dhaval

1 Like
10

http://community.cambiumnetworks.com/t5/PMP-Known-Issues/System-Release-15-1-issues-update/m-p/72983/highlight/true#M27

Adding the 320 CA cert to radius (WispToolBox), as suggested in the above post, resolved the issue. 

Thanks!

1 Like
11

Thanks very much for updating this thread and for referencing the post with the solution!

It's users like you that make this community stronger.

Thanks again.

Matt

12

Hi

Deployed two new 450 Medusa's yesterday on 15.1 - previous deployments on 15.0.2.1.

Notice on the Link Status page there is a new column under Downlink Statistics for MU-MIMO Rate.

We started moving SU's to the new AP and this column had quite poor readings at first: SU-MIMO was 8x/6x or better but MU-MIMO was 8x/2x or even MIMO-A.

After getting about 40 SU's onto the AP we notice a big improvement in link status - all showing 8x/6x or better, much like the SU-MIMO column.

What does this column represent? Can't see anything in the release notes for 15.1.

Thanks

Colin

13

Hi Colin,

The new MU-MIMO column represents the rate that VC is getting when part of a MU-MIMO group (as we will be forming beams to several VCs in this condition it may be worse than the SU-MIMO case, or in extreme cases it may not be possible to form part of a MU-MIMO group).

As to why the rate seemed very much worse for MU-MIMO at the start, I covered this in a post a couple of days ago

MUMIMO link

Until the 450M is being loaded more heavily the MU-MIMO won't be called upon and it will stick with SU-MIMO. As you brought more SMs on line it was more likely to be worth the 450M forming MU-MIMO groups. There is a seperate rate adapt for SU-MIMO and MU-MIMO, only once MU-MIMO is called in to use will this adapt up to the higher rates.

A way to quickly get the VCs to get to highest rates in MU-MIMO would be to run the 'link test to multiple VCs' from the 450m 'Tools' page a few times.

Hope that's a bit clearer, as you mentioned any 'new' things should really get a mention in the user guide.

best regards,

Andy.

1 Like
14

This veersion and the future 15.1.1 will solve Medusa that have problems if there're more than 100 VC (more or less)?

15

Hi,

There are no issues with higher VC counts in 15.1 that I'm aware of. Although not specifically a 450M feature release it includes several bug fixes over 15.0.3 which should make it more stable. We've had it running with other customers without problems.

best regards,

Andy.

1 Like
16

Thank you Andy!

I ask that because we have some problems with a 450M (i've already opened a case yesterday) but don't seems this kind of problem as I tought before