Re: [AFMUG] RM5AC-PMP Embargo lifted..

[Aaron Schneider via Af]

So do we.  :D

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Ben Moore via Af
Sent: Thursday, December 11, 2014 10:48 AM
To: af@afmug.com
Subject: Re: [AFMUG] RM5AC-PMP Embargo lifted..

We have a whole wall for you... ;)

On Thu, Dec 11, 2014 at 9:46 AM, Josh Luthman via Af 
mailto:af@afmug.com>> wrote:
Oh god has my white board turned into a black board?


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Thu, Dec 11, 2014 at 11:43 AM, Ben Moore via Af 
mailto:af@afmug.com>> wrote:
We have a running Mike list ;)

On Thu, Dec 11, 2014 at 9:40 AM, Mike Hammett via Af 
mailto:af@afmug.com>> wrote:
Hey, hey, hey.

I may have been very vocal about wanting a change of direction on something 
(and countless other things, I'm sure). Wait, do you have a count there? A 
whiteboard with tally marks for each time I've been "bold" regarding some UBNT 
position or product? Hrm..  Anyway, but I also commend when good and when the 
one thread kept going after we had the concession from Robert... I asked 
everyone (more than once) to close the thread. We got what we wanted, now shut 
up.

As you noticed, I'm like that to other manufacturers a well.  ;-)


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com


From: "Ben Moore via Af" mailto:af@afmug.com>>
To: af@afmug.com
Sent: Thursday, December 11, 2014 10:36:53 AM
Subject: Re: [AFMUG] RM5AC-PMP Embargo lifted..
Does it matter if he asked?  Mike has been naughty this year...  ;-)

On Thu, Dec 11, 2014 at 9:30 AM, CBB - Jay Fuller via Af 
mailto:af@afmug.com>> wrote:

Have you asked Santa? :)
- Original Message -
From: Mike Hammett via Af
To: af@afmug.com
Sent: Thursday, December 11, 2014 8:39 AM
Subject: Re: [AFMUG] RM5AC-PMP Embargo lifted..

I want a bigger AF5. :-\


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com


From: "Keefe John via Af" mailto:af@afmug.com>>
To: af@afmug.com
Sent: Thursday, December 11, 2014 8:36:35 AM
Subject: Re: [AFMUG] RM5AC-PMP Embargo lifted..

Maybe it could be an integrated solution with only one 'dish' vs the dogbone 
design.  I'm sure a lot of people would appreciate a smaller AF5--even if it 
had less throughput/distance.

Keefe
On 12/11/2014 8:29 AM, Mike Hammett via Af wrote:
via license?  *ducking*

It could be lower end hardware, though I don't know how the costs of design and 
manufacture change. Lower throughput may allow for smaller, cheaper processors. 
Smaller processors use less power, so smaller power supply? I'm no engineer, so 
I can't tell you how much this would or would not change the price.

Something that only does 10 MHz wide?

I don't know their cost to manufacture, so I don't know how low they can go 
with the existing hardware and still make money.



On the license front, I think people don't like the Cambium license system 
because the base unit is too slow and there are too many units. I think Gino's 
got something with a $1k 200 meg unit. Would be great for (business) customer 
installs. Maybe just one license to go from Lite to Full? Two things to keep 
track of, not several.


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com


From: "Gino Villarini via Af" 
To: af@afmug.com
Sent: Thursday, December 11, 2014 8:20:01 AM
Subject: Re: [AFMUG] RM5AC-PMP Embargo lifted..
I asked this and got a negative response… UBNT should work o AF24 2 with 1 Gig 
capacity and a AF24Lite for 200-500 Mbps capacity for $1k link



Gino A. Villarini
President
Aeronet Wireless Broadband Corp.
www.aeronetpr.com
@aeronetpr



From: "af@afmug.com" mailto:af@afmug.com>>
Reply-To: "af@afmug.com" 
mailto:af@afmug.com>>
Date: Thursday, December 11, 2014 at 9:27 AM
To: "af@afmug.com" mailto:af@afmug.com>>
Subject: Re: [AFMUG] RM5AC-PMP Embargo lifted..

Could they increase the QAM on the current AF24 to match that of the AF5 and at 
least do 1 gigabit FDX on the current shipping hardware? Not sure how 
increasing QAM levels work in FPGA land.


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com


From: "Colin Stanners via Af" mailto:af@afmug.com>>
To: af@afmug.com
Sent: Wednesday, December 10, 2014 11:19:46 PM
Subject: Re: [AFMUG] RM5AC-PMP Embargo lifted..
I'm sure they'll do a 24ghz AF 2/Duo/Super/Ultra with 1024QAM. In the 100mhz 
channels both ways that'll allow around 1280mbit FD - so a 2.5gbit backhaul...  
I'm assuming 3.65 will come as well.

On Wed, Dec 10, 2014 at 11:10 PM, Josh Reynolds via Af 
mailto:af@afmug.com>> wrote:
I'd guess there's going to be... a least 3 AirFiber products released in the 
next 12-18 months.

Re: [AFMUG] 13.3 Open Beta

[Aaron Schneider via Af]

Better way late than never, right?  :)



From: Af [mailto:af-boun...@afmug.com] On Behalf Of Josh Luthman via Af
Sent: Wednesday, December 03, 2014 11:43 AM
To: af@afmug.com
Subject: Re: [AFMUG] 13.3 Open Beta


Config file!  Not already!!!

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Dec 3, 2014 12:41 PM, "Aaron Schneider via Af" 
mailto:af@afmug.com>> wrote:
It is definitely being considered and your voices are being heard.  I just 
can’t comment on it just yet. :)

From: Af [mailto:af-boun...@afmug.com<mailto:af-boun...@afmug.com>] On Behalf 
Of George Skorup (Cyber Broadcasting) via Af
Sent: Wednesday, December 03, 2014 11:39 AM
To: af@afmug.com<mailto:af@afmug.com>
Subject: Re: [AFMUG] 13.3 Open Beta

I really hope you guys will consider testing and releasing this for FSK. We 
still use a lot of it. The config file will definitely be helpful. And there's 
still no resolution for 2.4 FSK None frequency issue.

On 12/3/2014 10:44 AM, Jonathan Mandziara via Af wrote:
AF Community,

Please visit the Cambium Networks webpage to down load the Open Beta version of 
13.3 for PMP450 and PTP450 radios.

https://support.cambiumnetworks.com/files/pmp450/beta
https://support.cambiumnetworks.com/files/ptp450/beta

  *   PMP320 Co-location (5ms Frame support) (This will work on all bands, but 
intended for 3.5 and 3.65 at this time.)
  *   7MHz Channel Bandwidth for 3.5 and 3.65 radios
  *   Removal of the PTP450 Map for faster link speeds
  *   SNMPv3
  *   HTTPS
  *   Ability to turn off Telnet, FTP and TFTP
  *   Read-Only Accounts for Admin, Install, and Tech
  *   Sector SA
  *   Export of Sessions Status Page
  *   Config File export/Import for AP/BHM and SM/BHS
NOTE: PMP320 co-location works best when both the PMP450 and PMP320 are on CMM 
synch sources.  Cambium is writing a paper on how to adjust the radios to best 
deal with other synch sources, although the radios will still work together 
without adjustment with some impact to throughput.
We look forward to you feedback on this release either in this forum or at:
http://community.cambiumnetworks.com/t5/PMP-Beta/bd-p/forums_pmp_beta

Best,
Cambium Jonathan

Re: [AFMUG] 13.3 Open Beta

[Aaron Schneider via Af]

It is definitely being considered and your voices are being heard.  I just 
can’t comment on it just yet. :)

From: Af [mailto:af-boun...@afmug.com] On Behalf Of George Skorup (Cyber 
Broadcasting) via Af
Sent: Wednesday, December 03, 2014 11:39 AM
To: af@afmug.com
Subject: Re: [AFMUG] 13.3 Open Beta

I really hope you guys will consider testing and releasing this for FSK. We 
still use a lot of it. The config file will definitely be helpful. And there's 
still no resolution for 2.4 FSK None frequency issue.

On 12/3/2014 10:44 AM, Jonathan Mandziara via Af wrote:
AF Community,

Please visit the Cambium Networks webpage to down load the Open Beta version of 
13.3 for PMP450 and PTP450 radios.

https://support.cambiumnetworks.com/files/pmp450/beta
https://support.cambiumnetworks.com/files/ptp450/beta

  *   PMP320 Co-location (5ms Frame support) (This will work on all bands, but 
intended for 3.5 and 3.65 at this time.)
  *   7MHz Channel Bandwidth for 3.5 and 3.65 radios
  *   Removal of the PTP450 Map for faster link speeds
  *   SNMPv3
  *   HTTPS
  *   Ability to turn off Telnet, FTP and TFTP
  *   Read-Only Accounts for Admin, Install, and Tech
  *   Sector SA
  *   Export of Sessions Status Page
  *   Config File export/Import for AP/BHM and SM/BHS
NOTE: PMP320 co-location works best when both the PMP450 and PMP320 are on CMM 
synch sources.  Cambium is writing a paper on how to adjust the radios to best 
deal with other synch sources, although the radios will still work together 
without adjustment with some impact to throughput.
We look forward to you feedback on this release either in this forum or at:
http://community.cambiumnetworks.com/t5/PMP-Beta/bd-p/forums_pmp_beta

Best,
Cambium Jonathan

Re: [AFMUG] 13.3 Open Beta

[Aaron Schneider via Af]

They are all told to run it simultaneously and while the SMs are doing it, the 
AP shuts itself up and runs a scan during that time.



From: Af [mailto:af-boun...@afmug.com] On Behalf Of Gino Villarini via Af
Sent: Wednesday, December 03, 2014 11:37 AM
To: af@afmug.com
Subject: Re: [AFMUG] 13.3 Open Beta

Woaw! Nice Is the Sector SA runs on the SMS at the same time or 1 by 1?



Gino A. Villarini
President
Aeronet Wireless Broadband Corp.
www.aeronetpr.com
@aeronetpr



From: "af@afmug.com" mailto:af@afmug.com>>
Reply-To: "af@afmug.com" 
mailto:af@afmug.com>>
Date: Wednesday, December 3, 2014 at 1:24 PM
To: "af@afmug.com" mailto:af@afmug.com>>
Subject: Re: [AFMUG] 13.3 Open Beta

Gino,

Great questions!

Sector SA is a feature that runs a SA on the AP and all the SMs registered to 
it at the same time to get a true picture of the RF environment the AP and the 
SMs are seeing without the influence of the APs energy.

The removal of the MAP in the PTP450 will give around an increase of  3.2 Mbps 
on each Channel Bandwidth.

Best,

Cambium Jonathan

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Gino Villarini via Af
Sent: Wednesday, December 03, 2014 11:20 AM
To: af@afmug.com
Subject: Re: [AFMUG] 13.3 Open Beta

What is Sector SA? And removal of PT450 MAP?



Gino A. Villarini
President
Aeronet Wireless Broadband Corp.
www.aeronetpr.com
@aeronetpr



From: "af@afmug.com" mailto:af@afmug.com>>
Reply-To: "af@afmug.com" 
mailto:af@afmug.com>>
Date: Wednesday, December 3, 2014 at 12:44 PM
To: "af@afmug.com" mailto:af@afmug.com>>
Subject: [AFMUG] 13.3 Open Beta

AF Community,

Please visit the Cambium Networks webpage to down load the Open Beta version of 
13.3 for PMP450 and PTP450 radios.

https://support.cambiumnetworks.com/files/pmp450/beta
https://support.cambiumnetworks.com/files/ptp450/beta
?PMP320 Co-location (5ms Frame support) (This will work on all bands, 
but intended for 3.5 and 3.65 at this time.)
?7MHz Channel Bandwidth for 3.5 and 3.65 radios
?Removal of the PTP450 Map for faster link speeds
?SNMPv3
?HTTPS
?Ability to turn off Telnet, FTP and TFTP
?Read-Only Accounts for Admin, Install, and Tech
?Sector SA
?Export of Sessions Status Page
?Config File export/Import for AP/BHM and SM/BHS
NOTE: PMP320 co-location works best when both the PMP450 and PMP320 are on CMM 
synch sources.  Cambium is writing a paper on how to adjust the radios to best 
deal with other synch sources, although the radios will still work together 
without adjustment with some impact to throughput.
We look forward to you feedback on this release either in this forum or at:
http://community.cambiumnetworks.com/t5/PMP-Beta/bd-p/forums_pmp_beta

Best,
Cambium Jonathan

Re: [AFMUG] 13.3 Open Beta

[Aaron Schneider via Af]

13.3 is for PMP450 and PTP450 only.  ;)

That being said, we are close to having a 13.2.1 ready that fixes the issues 
reported with 13.2 including the PTP230 reboot issue.  We have found that the 
problem is VLAN related and only affects PTP230.

Regards,
-Aaron

-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Jonathan Mandziara via Af
Sent: Wednesday, December 03, 2014 11:28 AM
To: af@afmug.com
Subject: Re: [AFMUG] 13.3 Open Beta

Matt,

Another great question.

At this time, 13.2 is for PMP450 and PTP450 Only.

The fix for PTP230 is coming soon.

Best,

Jonathan

-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Matt via Af
Sent: Wednesday, December 03, 2014 11:27 AM
To: af@afmug.com
Subject: Re: [AFMUG] 13.3 Open Beta

Is the PTP230 constant reboot issue fixed?

> Please visit the Cambium Networks webpage to down load the Open Beta 
> version of 13.3 for PMP450 and PTP450 radios.
>
> https://support.cambiumnetworks.com/files/pmp450/beta
>
> https://support.cambiumnetworks.com/files/ptp450/beta
>
> PMP320 Co-location (5ms Frame support) (This will work on all bands, 
> but intended for 3.5 and 3.65 at this time.)

Will this work with Purwave wimax?  How much throughput do we gain?

> 7MHz Channel Bandwidth for 3.5 and 3.65 radios Removal of the PTP450 
> Map for faster link speeds

How much faster?

> SNMPv3
> HTTPS
> Ability to turn off Telnet, FTP and TFTP Read-Only Accounts for Admin, 
> Install, and Tech Sector SA

This is really cool reading release notes.  Wish we had it on FSK as well.

> Export of Sessions Status Page
> Config File export/Import for AP/BHM and SM/BHS
>
> NOTE: PMP320 co-location works best when both the PMP450 and PMP320 
> are on CMM synch sources.  Cambium is writing a paper on how to adjust 
> the radios to best deal with other synch sources, although the radios 
> will still work together without adjustment with some impact to throughput.
>
> We look forward to you feedback on this release either in this forum or at:
>
> http://community.cambiumnetworks.com/t5/PMP-Beta/bd-p/forums_pmp_beta

Re: [AFMUG] 13.3 Open Beta

[Aaron Schneider via Af]

Eric –

We are looking at our options for bringing another release to FSK but I can’t 
comment on that just yet.

-Aaron

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Eric Muehleisen via Af
Sent: Wednesday, December 03, 2014 11:25 AM
To: af@afmug.com
Subject: Re: [AFMUG] 13.3 Open Beta


  *   Read-Only Accounts for Admin, Install, and Tech

ABOUT TIME! We needed this 10 years ago. Any chance of getting this implemented 
on the Canopy FSK platform?


On Wed, Dec 3, 2014 at 10:44 AM, Jonathan Mandziara via Af 
mailto:af@afmug.com>> wrote:
AF Community,

Please visit the Cambium Networks webpage to down load the Open Beta version of 
13.3 for PMP450 and PTP450 radios.

https://support.cambiumnetworks.com/files/pmp450/beta
https://support.cambiumnetworks.com/files/ptp450/beta

  *   PMP320 Co-location (5ms Frame support) (This will work on all bands, but 
intended for 3.5 and 3.65 at this time.)
  *   7MHz Channel Bandwidth for 3.5 and 3.65 radios
  *   Removal of the PTP450 Map for faster link speeds
  *   SNMPv3
  *   HTTPS
  *   Ability to turn off Telnet, FTP and TFTP
  *   Read-Only Accounts for Admin, Install, and Tech
  *   Sector SA
  *   Export of Sessions Status Page
  *   Config File export/Import for AP/BHM and SM/BHS
NOTE: PMP320 co-location works best when both the PMP450 and PMP320 are on CMM 
synch sources.  Cambium is writing a paper on how to adjust the radios to best 
deal with other synch sources, although the radios will still work together 
without adjustment with some impact to throughput.
We look forward to you feedback on this release either in this forum or at:
http://community.cambiumnetworks.com/t5/PMP-Beta/bd-p/forums_pmp_beta

Best,
Cambium Jonathan

Re: [AFMUG] 13.3 Open Beta

[Aaron Schneider via Af]

When running Sector Spectrum Analyzer (SA), once the sector is done, you'll be 
able to go through the scan results for the AP as well as all of the SMs (via 
the Remote SA page).

For the PTP Map removal, Jonathan is correct in the throughput improvement.  
But be aware that you MUST upgrade the "far" end first as it is an 
incompatibility in the air interface.

Regards,
-Aaron

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Jonathan Mandziara via Af
Sent: Wednesday, December 03, 2014 11:24 AM
To: af@afmug.com
Subject: Re: [AFMUG] 13.3 Open Beta

Gino,

Great questions!

Sector SA is a feature that runs a SA on the AP and all the SMs registered to 
it at the same time to get a true picture of the RF environment the AP and the 
SMs are seeing without the influence of the APs energy.

The removal of the MAP in the PTP450 will give around an increase of  3.2 Mbps 
on each Channel Bandwidth.

Best,

Cambium Jonathan

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Gino Villarini via Af
Sent: Wednesday, December 03, 2014 11:20 AM
To: af@afmug.com
Subject: Re: [AFMUG] 13.3 Open Beta

What is Sector SA? And removal of PT450 MAP?



Gino A. Villarini
President
Aeronet Wireless Broadband Corp.
www.aeronetpr.com
@aeronetpr



From: "af@afmug.com" mailto:af@afmug.com>>
Reply-To: "af@afmug.com" 
mailto:af@afmug.com>>
Date: Wednesday, December 3, 2014 at 12:44 PM
To: "af@afmug.com" mailto:af@afmug.com>>
Subject: [AFMUG] 13.3 Open Beta

AF Community,

Please visit the Cambium Networks webpage to down load the Open Beta version of 
13.3 for PMP450 and PTP450 radios.

https://support.cambiumnetworks.com/files/pmp450/beta
https://support.cambiumnetworks.com/files/ptp450/beta
?PMP320 Co-location (5ms Frame support) (This will work on all bands, 
but intended for 3.5 and 3.65 at this time.)
?7MHz Channel Bandwidth for 3.5 and 3.65 radios
?Removal of the PTP450 Map for faster link speeds
?SNMPv3
?HTTPS
?Ability to turn off Telnet, FTP and TFTP
?Read-Only Accounts for Admin, Install, and Tech
?Sector SA
?Export of Sessions Status Page
?Config File export/Import for AP/BHM and SM/BHS
NOTE: PMP320 co-location works best when both the PMP450 and PMP320 are on CMM 
synch sources.  Cambium is writing a paper on how to adjust the radios to best 
deal with other synch sources, although the radios will still work together 
without adjustment with some impact to throughput.
We look forward to you feedback on this release either in this forum or at:
http://community.cambiumnetworks.com/t5/PMP-Beta/bd-p/forums_pmp_beta

Best,
Cambium Jonathan

Re: [AFMUG] v13.2 - ptp230

[Aaron Schneider via Af]

Mathieu - have you sent these into anyone yet?  if not, please send to me off 
list.

Thanks,
-Aaron

aa...@cambiumnetworks.com

-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Mathieu via Af
Sent: Wednesday, November 19, 2014 9:53 AM
To: af@afmug.com
Subject: Re: [AFMUG] v13.2 - ptp230

that's what I've done. I made CNUT captures before the downgrade, while in 
13.2, if the support needs them.


Mathieu




Le 19/11/2014 16:45, Matt via Af a écrit :
> Tried test pair on shop floor.  Updated from 13.1.3 to 13.2 without 
> any issues and they seemed to work fine on 13.2.  Hear from others on 
> list that in the field they don't like to have traffic on 13.2 but 
> seem fine without traffic.  Plugging each one directly into laptop and 
> downgrading may be your best fix now.
>
>
> On Wed, Nov 19, 2014 at 9:36 AM, Ryan Mano via Af  wrote:
>> Looks like my port is flapping on my switch
>>
>>
>>
>> From: Af [mailto:af-boun...@afmug.com] On Behalf Of Ryan Mano via Af
>> Sent: Wednesday, November 19, 2014 10:32 AM
>> To: 'af@afmug.com'
>> Subject: Re: [AFMUG] v13.2 - ptp230
>>
>>
>>
>> Just tried it on ptp 230 5.7Ghz and both sides never came back 
>> up…updated the slave side first never registered back so I upgraded 
>> the master side can’t even ping that anymore
>>
>>
>>
>> From: Af [mailto:af-boun...@afmug.com] On Behalf Of Mathieu via Af
>> Sent: Wednesday, November 19, 2014 10:16 AM
>> To: af@afmug.com
>> Subject: [AFMUG] v13.2 - ptp230
>>
>>
>>
>> Hi,
>>
>> Has anyone tried v13.2 on a ptp230 5.4GHz link ?
>>
>> This link goes down regularly since the upgrade, and I'm seeing 
>> events like this :
>>
>>
>> CPU Utilization (Cur/Max): (100%/100%) Total Time : 1975809 us
>>
>> TASK TASK % RT Tot TASK Tot S T A C K Task PC NAME PRI RT MAX Cyc 
>> Preempt CtxSw (Sz/Cur%/Max%)OV Status Addr
>> -
>>  SYNC 4 ( 0%) 834 6725 0 9 (12284/ 2%/30%) 
>> PendEvFlgGrp 0x67ed4 WDOG 5 ( 0%) 51 243 0 6 (12284/ 2%/ 8%) Ready 
>> 0xa29b1c LEDT 6 ( 0%) 72 347 0 6 (12284/ 2%/ 9%) Ready 0x67ed4 DIAG 
>> 10 ( 0%) 0 0 0 0 (12284/ 2%/10%) PendEvFlgGrp 0x67ed4 APMT 11 ( 0%) 0 
>> 0 0 0 (12284/ 2%/ 9%) PendEvFlgGrp 0x67ed4 trap 14 ( 0%) 0 0 0 0 
>> (12284/ 2%/32%) PendEvFlgGrp 0x67ed4 SESS 15 ( 0%) 0 0 0 0 (12284/ 
>> 2%/47%) PendEvFlgGrp 0x67ed4 SOCK 16 ( 0%) 235 757 4 8 (12284/ 
>> 6%/26%) Suspend 0x67ed4 COMM 17 ( 0%) 67 67 0 1 (12284/ 2%/29%) 
>> PendEvFlgGrp 0x67ed4 VLAN 20 ( 0%) 0 0 0 0 (12284/ 2%/10%) 
>> PendEvFlgGrp 0x11 APPT 22 ( 0%) 0 0 0 0 (12284/ 2%/ 9%) PendEvFlgGrp 
>> 0x67ed4 ctic 23 ( 0%) 534 3666 8 28 (12284/ 2%/ 9%) Ready 0x67ed4 
>> Inet 24 ( 0%) 0 0 0 0 (12284/ 2%/24%) Suspend 0x67ed4 BDMT 27 ( 0%) 
>> 51 96 0 2 (12284/ 2%/ 9%) PendEvFlgGrp 0x67ed4 BDQT 28 ( 0%) 474 2146 
>> 0 20 (12284/ 2%/12%) PendEvFlgGrp 0x67ed4 AUTH 31 ( 0%) 0 0 0 0 
>> (12284/ 3%/11%) PendEvFlgGrp 0x67ed4 SNMP 32 ( 0%) 0 0 0 0 (12284/ 
>> 3%/40%) Suspend 0x67ed4 teln 34 ( 0%) 66 213 0 4 (12284/ 6%/25%) 
>> Suspend 0x67ed4
>> TEL1 35 ( 0%) 0 0 0 0 (12284/ 2%/ 8%) Suspend 0x67ed4
>> TEL2 36 ( 0%) 0 0 0 0 (12284/ 2%/ 8%) Suspend 0x67ed4
>> TEL3 37 ( 0%) 0 0 0 0 (12284/ 2%/ 8%) Suspend 0x67ed4
>> TEL4 38 ( 0%) 0 0 0 0 (12284/ 2%/ 8%) Suspend 0x67ed4 FTPs 39 ( 0%) 
>> 53 199 0 4 (12284/ 7%/27%) Suspend 0x67ed4 ROOT 46 ( 0%) 0 0 0 0 
>> (12284/ 2%/40%) Suspend 0x67ed4 UPDM 47 ( 0%) 0 0 0 0 (12284/ 2%/11%) 
>> PendEvFlgGrp 0x67ed4 UPDT 48 ( 0%) 0 0 0 0 (12284/ 2%/ 9%) 
>> PendEvFlgGrp 0x67ed4 HTTP 50 ( 0%) 53 206 0 4 (12284/ 7%/27%) Suspend 
>> 0x67ed4 PROX 51 ( 0%) 278 633 0 4 (12284/ 7%/27%) Suspend 0x67ed4
>> TFT0 53 ( 0%) 0 0 0 0 (12284/ 2%/ 8%) PendQ 0x67ed4 nvrm 55 ( 0%) 0 0 
>> 0 0 (12284/ 2%/ 9%) PendEvFlgGrp 0x67ed4 PING 56 ( 0%) 0 0 0 0 
>> (12284/ 2%/ 8%) Suspend 0x67ed4 LLDT 57 ( 0%) 185 350 0 2 (12284/ 2%/ 
>> 9%) PendEvFlgGrp 0x67ed4 STAT 60 (16%) 19251 341146 6 24 ( 8192/ 
>> 3%/14%) Ready 0x67ed4 IDLE 61 (80%) 49944 1619015 68 68 ( 
>> 8192/523272%/14%) Ready 0x67cb4 PRI PC ID
>>
>>
>>
>>
>> or
>>
>> **System Startup**
>> System Reset Exception -- Watchdog Reset Software Version : CANOPY 
>> 13.2 BHUL-DES Board Type : P11 Device Setting : 5.4GHz SISO OFDM - 
>> Backhaul - Timing Slave -
>> 0a-00-3e-b0-48-35
>> FPGA Version : 082914
>> FPGA Features : DES, Sched;
>> 01/01/2011 : 00:00:02 UTC : : Bridge/OS Core : FatalError() NULL 
>> exception reset
>> 01/01/2011 : 00:00:02 UTC :
>> Stack Dump information:
>> Current context Task: IDLE
>> Current Stack: 3%
>> Max Stack: 14%
>>
>>
>>
>> then
>>
>>
>>
>> **System Startup**
>> System Reset Exception -- Watchdog Reset Software Version : CANOPY 
>> 13.2 BHUL-DES Board Type : P11 Device Setting : 5.4GHz SISO OFDM - 
>> Backhaul - Timing Slave -
>> 0a-00-3e-b0-48-35
>> FPGA Version : 082914
>> FPGA Features : DES, Sched;
>> 11/19/2014 : 15:06:07 UTC : : Bridge/OS Core : Time Set
>>
>>

Re: [AFMUG] System Release 13.2 is Official

[Aaron Schneider via Af]

Hi Matt

This is what most customers use the primary/secondary/tertiary color codes for. 
 That in conjunction with the rescan timers will automatically make the sms 
rescan to try to get back on a primary color code if they had to use a backup 
to register.

Regards,

Aaron


Sent from my Verizon Wireless 4G LTE smartphone
Any typos or strange word placement aren't my fault!


 Original message 
From: Matt via Af
Date:11/17/2014 2:35 PM (GMT-06:00)
To: af@afmug.com
Subject: Re: [AFMUG] System Release 13.2 is Official

> If we know about this issue before release and documented it in the release 
> notes, it could have been spun as
> a "feature", but that opportunity is gone now :)
>
> The concern is how long it takes the SM to scan for the AP on each boot up, 
> right? How about a flag that tell that
> SM that when it is rebooted, it should first try to connect with the AP it 
> was connected to prior to reboot, and to initiate
> the scan only if that fails? Or do you need a button that says "turn off all 
> 2.5 center frequencies"?

Not so sure on this.  We use same color code on all AP's currently.
Occasionally an SM will get on a non-ideal signal AP in the cluster
etc and stick there.  To fix this every night a perl script scans all
SM's in the system and logs signal strength etc.  If the MAC of the AP
an SM is registered too has changed it reboots the SM and waits for it
to register again and records the MAC of the AP it registered too.

It sure would be nice if there was a SNMP command to trigger a new AP
Eval scan instead of reboot but there is not.  Would sure also be nice
if there was SNMP command to trigger a link test from the SM rather
then just the AP.

I see a better solution as a primary scan list and a secondary scan
list.  Primary list is the small list of frequencies and channel sizes
we use 95 percent of time.  The secondary list is the full list we
scan when we try X seconds and cannot connect.  Such as the situation
when interference moves in and we can only find a couple 5mhz channel
remotely clean.


> Not promising to make any enhancements as we try to make a bugfix release for 
> the 13.2 issues,
> but definitely looking for feedback on the best way(s) to reduce the scan 
> time.

Re: [AFMUG] System Release 13.2 is Official

[Aaron Schneider via Af]

What beta version is on the AP?  There was an issue with early beta release and 
RF speedtest that was addressed in later (should have been 28 and onward) beta 
loads.

Please get your sector all up onto 13.2 official if you are on the beta, then 
retry the scenario and if it still happens, please send me a CNUT capture of 
the SM.

Regards,
-Aaron

From: Af [mailto:af-boun...@afmug.com] On Behalf Of timothy steele via Af
Sent: Friday, November 14, 2014 4:36 PM
To: af@afmug.com
Cc: af@afmug.com
Subject: Re: [AFMUG] System Release 13.2 is Official

I think someone else already said this but 13.2 final on SM with beta on AP the 
SM will reboot it self when you do a cap test this is the same bug I reported 
on build 35

—
Sent from Mailbox<https://www.dropbox.com/mailbox>


On Fri, Nov 14, 2014 at 4:46 PM, Aaron Schneider via Af 
mailto:af@afmug.com>> wrote:
There was a decision made when we added 2.5 center channels that on upgrade we 
wouldn’t automatically check the 2.5 centers unless the scan list was in a 
default (all checked) state.  We didn’t want to add a ton of new scan options 
on an upgrade which increased the scanning time.   When setting a unit that is 
on a load that supports 2.5M centers to default, then all (including 2.5 
centers) should be selected.


We are still investigating, but likely this has something to do with what Ryan 
was seeing when others weren’t seeing the same behavior.


-Aaron


From: Af [mailto:af-boun...@afmug.com] On Behalf Of George Skorup (Cyber 
Broadcasting) via Af
Sent: Friday, November 14, 2014 12:58 PM
To: af@afmug.com<mailto:af@afmug.com>
Subject: Re: [AFMUG] System Release 13.2 is Official


I'm trying to remember.. did the 2.4 450 have 2.5 centers from day one? I think 
the last time I got some new SMs in, they had either 12.0.x or 12.1.x on them 
and none of the 2.5 centers were checked after updating to 13.x. So maybe the 
safest approach from now on is to enable everything in the scan list 
automatically during/after update? Then tell everyone in the release notes 
about it. You'd be surprised at how many of us fully read the release notes 
now. OK, at least I do.

On 11/14/2014 11:28 AM, Rajesh Vijayakumar via Af wrote:
Its good to get confirmation of multiple successful upgrades with 2.4 GHz.
We have not been able to recreate the problem yet. The test team is trying a 
number of combinations of upgrade/downgrade.
--Rajesh Vijayakumar
Cambium Networks


On Fri, Nov 14, 2014 at 11:01 AM, Eric Muehleisen via Af 
mailto:af@afmug.com>> wrote:
Any changes/improvements in the Rate Adapt?


On Fri, Nov 14, 2014 at 10:54 AM, Bill Prince via Af 
mailto:af@afmug.com>> wrote:
As mentioned in another thread, we upgraded a bunch of PMP430 installations 
last night.   Something that I wasn't expecting was an immediate improvement in 
the SNR (typical example below).  This was pretty much across the board 
excepting installations that already had really good SNR.

Thanks Cambium!



bp




On 11/13/2014 5:12 AM, Matt Mangriotis via Af wrote:
It is here!

We released 13.2 this morning officially.  Come to our forum to discuss 
anything about it.

http://community.cambiumnetworks.com/t5/PMP-450/System-Release-13-2-Now-Avaialable/m-p/36254/thread-id/278

Download the software from the usual place on our support site:

https://support.cambiumnetworks.com/files/pmp450/

Thanks to all of you that Beta tested this software with us, and helped to make 
it stronger and better than ever.  Now that this is here, we’re hard at work on 
delivering the next round of enhancements (code name 13.3 (pretty original, 
huh?)) which are right around the corner.

The momentum is building on the PMP 450 platform.

Thanks again,

Matt

Re: [AFMUG] Issue with SNMP OID .1.3.6.1.4.1.161.19.3.2.1.1.0

[Aaron Schneider via Af]

Hi John –

The complete list of OIDs affected by this problem are:

1.3.6.1.4.1.161.19.3.2.1.1   rfScanListDisplayString
1.3.6.1.4.1.161.19.3.2.1.79  pppoeAccessConcentrator   DisplayString
1.3.6.1.4.1.161.19.3.2.1.80  pppoeServiceName  DisplayString
1.3.6.1.4.1.161.19.3.2.1.81  pppoeUserName DisplayString

Doing a SET on any of these will cause the SM crash to occur.  We can make a 
fix available if you would like, and are working on a Field Support Bulletin.

The devices are not being shipped with 13.2, so we suggest you program your 
devices on the shipped version and then upgrade them after setting these values 
with 13.1.3 SW.

-Aaron


From: Af [mailto:af-boun...@afmug.com] On Behalf Of John Babineaux via Af
Sent: Friday, November 14, 2014 3:26 PM
To: af@afmug.com
Subject: Re: [AFMUG] Issue with SNMP OID .1.3.6.1.4.1.161.19.3.2.1.1.0

That is a huge problem to use b/c that is how we preprogram all our SMs before 
deployment

Also check the PPPoE username snmp
.1.3.6.1.4.1.161.19.3.2.1.81.0

John Babineaux
System Administrator
REACH4 Communications | Website: www.REACH4Com.com
Phone: 337-783-3436 x105 | Email: 
john.babine...@reach4com.com
927 N Parkerson Ave, Crowley, LA 70526



From: Af [mailto:af-boun...@afmug.com] On Behalf Of Jonathan Mandziara via Af
Sent: Thursday, November 13, 2014 7:10 PM
To: af@afmug.com
Subject: [AFMUG] Issue with SNMP OID .1.3.6.1.4.1.161.19.3.2.1.1.0
Importance: High

13.2 Users,

There is an issue with the following SNMP OID to set the frequency list on an 
SM.

.1.3.6.1.4.1.161.19.3.2.1.1.0

For Example:
snmpset -v 2c -c "Canopy" 169.254.1.1 .1.3.6.1.4.1.161.19.3.2.1.1.0 s "548000"

If this OID is used to set aa frequency on an SM, it will cause the SM to 
crash.  After the SM reboots, the list of frequencies listed the SNMP set will 
not be set on the SM.

We have carefully reviewed the code, and this is the only OID effected.

This issue is being tracked under Issue Number "CPY-10392" and is slated to 
13.3 for repair.

We apologize for any inconvenience that this may have caused.

Sincerely,

The Cambium Team

Re: [AFMUG] System Release 13.2 is Official

[Aaron Schneider via Af]

There was a decision made when we added 2.5 center channels that on upgrade we 
wouldn’t automatically check the 2.5 centers unless the scan list was in a 
default (all checked) state.  We didn’t want to add a ton of new scan options 
on an upgrade which increased the scanning time.   When setting a unit that is 
on a load that supports 2.5M centers to default, then all (including 2.5 
centers) should be selected.

We are still investigating, but likely this has something to do with what Ryan 
was seeing when others weren’t seeing the same behavior.

-Aaron

From: Af [mailto:af-boun...@afmug.com] On Behalf Of George Skorup (Cyber 
Broadcasting) via Af
Sent: Friday, November 14, 2014 12:58 PM
To: af@afmug.com
Subject: Re: [AFMUG] System Release 13.2 is Official

I'm trying to remember.. did the 2.4 450 have 2.5 centers from day one? I think 
the last time I got some new SMs in, they had either 12.0.x or 12.1.x on them 
and none of the 2.5 centers were checked after updating to 13.x. So maybe the 
safest approach from now on is to enable everything in the scan list 
automatically during/after update? Then tell everyone in the release notes 
about it. You'd be surprised at how many of us fully read the release notes 
now. OK, at least I do.

On 11/14/2014 11:28 AM, Rajesh Vijayakumar via Af wrote:
Its good to get confirmation of multiple successful upgrades with 2.4 GHz.
We have not been able to recreate the problem yet. The test team is trying a 
number of combinations of upgrade/downgrade.
--Rajesh Vijayakumar
Cambium Networks

On Fri, Nov 14, 2014 at 11:01 AM, Eric Muehleisen via Af 
mailto:af@afmug.com>> wrote:
Any changes/improvements in the Rate Adapt?

On Fri, Nov 14, 2014 at 10:54 AM, Bill Prince via Af 
mailto:af@afmug.com>> wrote:
As mentioned in another thread, we upgraded a bunch of PMP430 installations 
last night.   Something that I wasn't expecting was an immediate improvement in 
the SNR (typical example below).  This was pretty much across the board 
excepting installations that already had really good SNR.

Thanks Cambium!

[cid:image001.png@01D00022.1CB0A0D0]


bp




On 11/13/2014 5:12 AM, Matt Mangriotis via Af wrote:
It is here!

We released 13.2 this morning officially.  Come to our forum to discuss 
anything about it.

http://community.cambiumnetworks.com/t5/PMP-450/System-Release-13-2-Now-Avaialable/m-p/36254/thread-id/278

Download the software from the usual place on our support site:

https://support.cambiumnetworks.com/files/pmp450/

Thanks to all of you that Beta tested this software with us, and helped to make 
it stronger and better than ever.  Now that this is here, we’re hard at work on 
delivering the next round of enhancements (code name 13.3 (pretty original, 
huh?)) which are right around the corner.

The momentum is building on the PMP 450 platform.

Thanks again,

Matt

Re: [AFMUG] System Release 13.2 is Official

[Aaron Schneider via Af]

Hi Eric –

Yes, there were great improvements to the hysteresis of the rate adapt and 
improving the backoff algorithms.   You will no longer see a penalty when not 
being able to get to the next higher tier rate as you did with previous 
releases.

Also, MIMO-A is just another Rate Adapt level that will be moved to seamlessly 
as conditions require.   We demoed that at Wispapalooza, and I think people 
were surprised at the quick response both going to MIMO-A (we fully attenuated 
each path alternately) and recovering back into MIMO-B.

Perhaps we’ll look at doing a short web clip of that demo (over at the forum ☺) 
if anyone who didn’t see it is interested.

Regards,
-Aaron


From: Af [mailto:af-boun...@afmug.com] On Behalf Of Eric Muehleisen via Af
Sent: Friday, November 14, 2014 11:01 AM
To: af@afmug.com
Subject: Re: [AFMUG] System Release 13.2 is Official

Any changes/improvements in the Rate Adapt?

On Fri, Nov 14, 2014 at 10:54 AM, Bill Prince via Af 
mailto:af@afmug.com>> wrote:
As mentioned in another thread, we upgraded a bunch of PMP430 installations 
last night.   Something that I wasn't expecting was an immediate improvement in 
the SNR (typical example below).  This was pretty much across the board 
excepting installations that already had really good SNR.

Thanks Cambium!

[cid:image001.png@01D0.1FFC68E0]


bp




On 11/13/2014 5:12 AM, Matt Mangriotis via Af wrote:
It is here!

We released 13.2 this morning officially.  Come to our forum to discuss 
anything about it.

http://community.cambiumnetworks.com/t5/PMP-450/System-Release-13-2-Now-Avaialable/m-p/36254/thread-id/278

Download the software from the usual place on our support site:

https://support.cambiumnetworks.com/files/pmp450/

Thanks to all of you that Beta tested this software with us, and helped to make 
it stronger and better than ever.  Now that this is here, we’re hard at work on 
delivering the next round of enhancements (code name 13.3 (pretty original, 
huh?)) which are right around the corner.

The momentum is building on the PMP 450 platform.

Thanks again,

Matt

Re: [AFMUG] 13.2 Issue (Removing frequency checkboxes)

[Aaron Schneider via Af]

Please see my previous note on two specific 5.7 SM scan frequencies that were 
fixed on the SM.  That could cause those two to come back unchecked, but they 
were never possible to use as they were always wrong.  We'll look at that as to 
having the values fixed and keep them checked if they previously were, but the 
change should not have caused any sm outage.

I think that was the only 5.x frequency issue and was reported at the same time 
as the 2.4 issue.  They are not related.

Regards,

Aaron




 Original message 
From: timothy steele via Af
Date:11/14/2014 6:29 AM (GMT-06:00)
To: af@afmug.com
Cc: af@afmug.com
Subject: Re: [AFMUG] 13.2 Issue (Removing frequency checkboxes)

Ok so sounds like that was just a fluke but why do the 5ghz 450 SM have a bunch 
of frequencys unchecked after upgrading to 13.2 final? I did not notice that in 
beta

—
Sent from Mailbox<https://www.dropbox.com/mailbox>



On Fri, Nov 14, 2014 at 6:18 AM, Kurt Fankhauser via Af 
mailto:af@afmug.com>> wrote:

I updated some 2.4Ghz 450 stuff overnight (previously on build 22) and did not 
loose any of the 2.5mhz channelson SM's


Kurt Fankhauser

Wavelinc Communications

P.O. Box 126

Bucyrus, OH 44820

http://www.wavelinc.com<http://www.wavelinc.com/>

tel. 419-562-6405

fax. 419-617-0110

On Fri, Nov 14, 2014 at 2:54 AM, Rajesh Vijayakumar via Af 
mailto:af@afmug.com>> wrote:
George,
Glad to see it upgraded successfully. And thanks for bravely trying it.

Ryan,
We are continuing our investigation. I will post an update to the list tomorrow 
morning. Please contact me 
(rajesh.vijayaku...@cambiumnetworks.com<mailto:rajesh.vijayaku...@cambiumnetworks.com>)
 or Cambium support off list. We will get to the root of this as soon as 
possible.

Rajesh Vijayakumar
Cambium Networks


On Fri, Nov 14, 2014 at 1:14 AM, George Skorup (Cyber Broadcasting) via Af 
mailto:af@afmug.com>> wrote:
I just got done with that sector and everything went fine. Checked all of the 
SM scan lists before (all running 13.1.3) and after they updated to 13.2. They 
all look like this still:

<2.4_scan.png>


On 11/14/2014 12:30 AM, George Skorup (Cyber Broadcasting) via Af wrote:
I know I said I was done for the night, but I'm going to update a 2.4 450 
sector here shortly. It's on 2460/20MHz, so hopefully nothing bad happens.

On 11/14/2014 12:25 AM, Rajesh Vijayakumar via Af wrote:
We looked at all the recent changes than went in to 13.2 but did not find 
anything that would explain this behavior. Also tried to recreate it in the lab 
on a 2.4 GHz setup, but the SM kept all the checked frequencies after upgrade 
from 13.1.3 to 13.2.

Has anyone else upgraded a 2.4 GHz sector and run into this issue (or did not 
run into this issue)?

Rajesh Vijayakumar
Cambium Networks


On Thu, Nov 13, 2014 at 10:45 PM, Aaron Schneider via Af 
mailto:af@afmug.com>> wrote:
We are investigating the other issues, but with respect to 5767.5 and 5807.5, 
those two were affected by a bug fix, in that pre-13.2, 5767.5 was actually 
enabling 5767.20, due to an obvious typo in the scan list code, and 5807.5 was 
actually enabling 5807.00, due to another typo bug in the code. So correcting 
these two items may have left them unchecked on an upgrade to 13.2, but they 
weren’t valid scan frequencies anyways.

These two updates didn’t make the release notes due to an oversight.  These two 
frequency updates are in no way related to what is being reported for the 
2.5MHz center channels coming back unchecked for 2.4.  we are investigating.

-Aaron

From: Af [mailto:af-boun...@afmug.com<mailto:af-boun...@afmug.com>] On Behalf 
Of George Skorup (Cyber Broadcasting) via Af
Sent: Thursday, November 13, 2014 9:25 PM
To: af@afmug.com<mailto:af@afmug.com>
Subject: Re: [AFMUG] 13.2 Issue (Removing frequency checkboxes)

13.2 on the SM definitely does not jive with build 32 on the AP. So.. don't do 
that. I forgot I still had that AP on build 32 until it was too late. SMs would 
pop in session for about 2 seconds and go down again. Luckily updating the AP 
to 13.2 official fixed it.

I'm also seeing 5GHz SMs losing freqs. But it's funny, like 99% of them only 
lose 5767.5 and 5807.5. I try to avoid the 2.5 centers whenever I can since 
I've noticed exactly what you guys are seeing here in the past, ALL of the 2.5 
centers disappear. I don't use 5MHz bandwidth, and I usually lock the scan list 
on the SM down to the band the AP is operating in. So maybe that's why I was 
losing only a couple freqs.

On 11/13/2014 9:12 PM, Ryan Ray via Af wrote:
It's crazy. No warning, no release notes about it. How does this come out of 
all the betas and you lose your SM's because a frequency isn't checked...

On Thu, Nov 13, 2014 at 7:09 PM, timothy steele via Af 
mailto:af@afmug.com>> wrote:
Yeah I noticed that same with 5Ghz looks like they unchecked the rarely 

Re: [AFMUG] 13.2 Issue (Removing frequency checkboxes)

[Aaron Schneider via Af]

We are investigating the other issues, but with respect to 5767.5 and 5807.5, 
those two were affected by a bug fix, in that pre-13.2, 5767.5 was actually 
enabling 5767.20, due to an obvious typo in the scan list code, and 5807.5 was 
actually enabling 5807.00, due to another typo bug in the code. So correcting 
these two items may have left them unchecked on an upgrade to 13.2, but they 
weren’t valid scan frequencies anyways.

These two updates didn’t make the release notes due to an oversight.  These two 
frequency updates are in no way related to what is being reported for the 
2.5MHz center channels coming back unchecked for 2.4.  we are investigating.

-Aaron

From: Af [mailto:af-boun...@afmug.com] On Behalf Of George Skorup (Cyber 
Broadcasting) via Af
Sent: Thursday, November 13, 2014 9:25 PM
To: af@afmug.com
Subject: Re: [AFMUG] 13.2 Issue (Removing frequency checkboxes)

13.2 on the SM definitely does not jive with build 32 on the AP. So.. don't do 
that. I forgot I still had that AP on build 32 until it was too late. SMs would 
pop in session for about 2 seconds and go down again. Luckily updating the AP 
to 13.2 official fixed it.

I'm also seeing 5GHz SMs losing freqs. But it's funny, like 99% of them only 
lose 5767.5 and 5807.5. I try to avoid the 2.5 centers whenever I can since 
I've noticed exactly what you guys are seeing here in the past, ALL of the 2.5 
centers disappear. I don't use 5MHz bandwidth, and I usually lock the scan list 
on the SM down to the band the AP is operating in. So maybe that's why I was 
losing only a couple freqs.

On 11/13/2014 9:12 PM, Ryan Ray via Af wrote:
It's crazy. No warning, no release notes about it. How does this come out of 
all the betas and you lose your SM's because a frequency isn't checked...

On Thu, Nov 13, 2014 at 7:09 PM, timothy steele via Af 
mailto:af@afmug.com>> wrote:
Yeah I noticed that same with 5Ghz looks like they unchecked the rarely used 
channels in SM with 13.2 programmer was probably thinking he was helping but 
lots are going to complain

—
Sent from Mailbox


On Thu, Nov 13, 2014 at 10:06 PM, Ryan Ray via Af 
mailto:af@afmug.com>> wrote:
Just did a >200 group of SM's and the upgrade has removed frequencies that were 
previously checked. I followed the guide and did the SM's first and AP's last. 
Luckily the majority of these can see another AP but what the fuck...

About half of these SM's were on 13.2(34) and the other half were on 13.1.3...

This is what it looks like after an update




Pre update they were all




URG

Re: [AFMUG] System Release 13.2 is Official

[Aaron Schneider via Af]

Thank you very much for all of you that helped with Open Beta.  It was a very 
long release, but there were lots of things found and fixed as a result of 
having you helping us with access to your systems.

I’d like to highlight here, for those of you that don’t read the release notes, 
due to the MIMO-A changes and isolated issues seen during the upgrade procedure 
at some customers sites, we are recommending an SM-first upgrade when going to 
13.2.  Most customers were able to do the normal AP-first upgrade without 
issues.  But there were some changes in the Air Interface PHY that could 
potentially cause SMs to have a hard time registering when you have mixed 
versions between 13.2 and earlier (13.1.3).   Even doing an SM-first (reverse) 
upgrade, most, if not all, of the SMs should come back in session, so it isn’t 
a downtime upgrade (where the SMs don’t register until the AP is upgraded).

There is more information in the release notes as well as instructions on how 
to do this type of upgrade as well as help to switch procedures if you have 
already started a normal upgrade and have SMs having trouble registering.

We saw no issues with registration (we actually saw improvements due to MIMO-A 
control messages) in SM registration once the sector was fully on 13.2.  This 
last problem is a big part of the final 2-3 week delay.   Also we were able to 
fully fix the 13.2 Open Beta nagging Ethernet lockup detection problem.

Please enjoy 13.2, it has been a long time in the making!

For the questions about 13.2 being for PMP100, the answer is no.  And I can’t 
comment quite yet on any possible upcoming releases for the PMP100.

Regards,
-Aaron

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Matt Mangriotis via Af
Sent: Thursday, November 13, 2014 7:13 AM
To: af@afmug.com
Subject: [AFMUG] System Release 13.2 is Official

It is here!

We released 13.2 this morning officially.  Come to our forum to discuss 
anything about it.

http://community.cambiumnetworks.com/t5/PMP-450/System-Release-13-2-Now-Avaialable/m-p/36254/thread-id/278

Download the software from the usual place on our support site:

https://support.cambiumnetworks.com/files/pmp450/

Thanks to all of you that Beta tested this software with us, and helped to make 
it stronger and better than ever.  Now that this is here, we’re hard at work on 
delivering the next round of enhancements (code name 13.3 (pretty original, 
huh?)) which are right around the corner.

The momentum is building on the PMP 450 platform.

Thanks again,

Matt

Re: [AFMUG] 13.2(Build 35) Open Beta

[Aaron Schneider via Af]

Sean – I do see a reply there from Jonathan that was posted yesterday afternoon.

Hit me offlist if you can, he is requesting some more information.

Thanks,
-Aaron

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Aaron Schneider via Af
Sent: Thursday, October 30, 2014 6:56 PM
To: af@afmug.com
Subject: Re: [AFMUG] 13.2(Build 35) Open Beta

Hi Sean -

Saw you at Wispapalooza but didn’t get a chance to talk to you!  We’ve been 
deep down working on the release blocking bugs that have been holding up the 
release.

I’ll take a look and find out where that ended up and get a reply to you.

Regards,
-Aaron

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Sean Heskett via Af
Sent: Thursday, October 30, 2014 5:15 PM
To: af@afmug.com<mailto:af@afmug.com>
Subject: Re: [AFMUG] 13.2(Build 35) Open Beta

Aaron, I submitted a sessions status page bug on the beta forum but never saw 
any reply???



On Thursday, October 30, 2014, Aaron Schneider via Af 
mailto:af@afmug.com>> wrote:
Build 35 took care of the AP Ethernet hangup, which was the main one being 
worked during Wispapalooza.  There will be a Build 36 put on Open Beta probably 
tomorrow in which we were able to fix for some of the old nagging rare and 
random crashes that have been seen in previous releases.

Our current plan is to release next week.

Regards,
-Aaron


From: Af 
[mailto:af-boun...@afmug.com]
 On Behalf Of timothy steele via Af
Sent: Thursday, October 30, 2014 4:50 PM
To: af@afmug.com
Cc: af@afmug.com
Subject: Re: [AFMUG] 13.2(Build 35) Open Beta

There still working on 1 bug only 1 company is seeing last I heard build 35 is 
the most stable firmware I've seen so I'm sure official will not be too much 
longer but probably faster if more would test build 35 on AP's to track down 
this 1 bug

—
Sent from Mailbox<https://www.dropbox.com/mailbox>


On Thu, Oct 30, 2014 at 12:57 PM, Matt via Af 
> wrote:

Are we going to get 13.2 official this week?

Re: [AFMUG] 13.2(Build 35) Open Beta

[Aaron Schneider via Af]

This is still possible to have an SM not realize the other side dropped the 
link since if there is no data, there is nothing to drive the normal 
disconnection mechanism (VC Error).  Link Test is a quick way to do that.  
However, for this problem, if I understand your request correctly, George is 
correct in that the Forced BER feature in 13.2 should help.  The SM’s receive 
power level will be precise now in absence of data and it won’t go stale.

-Aaron




From: Af [mailto:af-boun...@afmug.com] On Behalf Of timothy steele via Af
Sent: Thursday, October 30, 2014 5:05 PM
To: af@afmug.com
Cc: af@afmug.com
Subject: Re: [AFMUG] 13.2(Build 35) Open Beta

Arron awesome to hear..

I have not tested this on build 35 but has the issue of the SM not showing a 
dropped link until a link capacity test due to there was no data flowing been 
addressed yet? If not can we get a sight survey mode that dose a continuas link 
capacity test at the same time showing you real time signal so we can properly 
install antenna's?

Thanks,

—
Sent from Mailbox<https://www.dropbox.com/mailbox>


On Thu, Oct 30, 2014 at 5:54 PM, Aaron Schneider via Af 
mailto:af@afmug.com>> wrote:
Build 35 took care of the AP Ethernet hangup, which was the main one being 
worked during Wispapalooza.  There will be a Build 36 put on Open Beta probably 
tomorrow in which we were able to fix for some of the old nagging rare and 
random crashes that have been seen in previous releases.


Our current plan is to release next week.


Regards,
-Aaron




From: Af [mailto:af-boun...@afmug.com] On Behalf Of timothy steele via Af
Sent: Thursday, October 30, 2014 4:50 PM
To: af@afmug.com<mailto:af@afmug.com>
Cc: af@afmug.com<mailto:af@afmug.com>
Subject: Re: [AFMUG] 13.2(Build 35) Open Beta


There still working on 1 bug only 1 company is seeing last I heard build 35 is 
the most stable firmware I've seen so I'm sure official will not be too much 
longer but probably faster if more would test build 35 on AP's to track down 
this 1 bug

—
Sent from Mailbox<https://www.dropbox.com/mailbox>



On Thu, Oct 30, 2014 at 12:57 PM, Matt via Af 
mailto:af@afmug.com>> wrote:

Are we going to get 13.2 official this week?

Re: [AFMUG] 13.2(Build 35) Open Beta

[Aaron Schneider via Af]

Hi Sean -

Saw you at Wispapalooza but didn’t get a chance to talk to you!  We’ve been 
deep down working on the release blocking bugs that have been holding up the 
release.

I’ll take a look and find out where that ended up and get a reply to you.

Regards,
-Aaron

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Sean Heskett via Af
Sent: Thursday, October 30, 2014 5:15 PM
To: af@afmug.com
Subject: Re: [AFMUG] 13.2(Build 35) Open Beta

Aaron, I submitted a sessions status page bug on the beta forum but never saw 
any reply???



On Thursday, October 30, 2014, Aaron Schneider via Af 
mailto:af@afmug.com>> wrote:
Build 35 took care of the AP Ethernet hangup, which was the main one being 
worked during Wispapalooza.  There will be a Build 36 put on Open Beta probably 
tomorrow in which we were able to fix for some of the old nagging rare and 
random crashes that have been seen in previous releases.

Our current plan is to release next week.

Regards,
-Aaron


From: Af 
[mailto:af-boun...@afmug.com]
 On Behalf Of timothy steele via Af
Sent: Thursday, October 30, 2014 4:50 PM
To: af@afmug.com
Cc: af@afmug.com
Subject: Re: [AFMUG] 13.2(Build 35) Open Beta

There still working on 1 bug only 1 company is seeing last I heard build 35 is 
the most stable firmware I've seen so I'm sure official will not be too much 
longer but probably faster if more would test build 35 on AP's to track down 
this 1 bug

—
Sent from Mailbox<https://www.dropbox.com/mailbox>


On Thu, Oct 30, 2014 at 12:57 PM, Matt via Af 
> wrote:

Are we going to get 13.2 official this week?

Re: [AFMUG] 13.2(Build 35) Open Beta

[Aaron Schneider via Af]

Build 35 took care of the AP Ethernet hangup, which was the main one being 
worked during Wispapalooza.  There will be a Build 36 put on Open Beta probably 
tomorrow in which we were able to fix for some of the old nagging rare and 
random crashes that have been seen in previous releases.

Our current plan is to release next week.

Regards,
-Aaron


From: Af [mailto:af-boun...@afmug.com] On Behalf Of timothy steele via Af
Sent: Thursday, October 30, 2014 4:50 PM
To: af@afmug.com
Cc: af@afmug.com
Subject: Re: [AFMUG] 13.2(Build 35) Open Beta

There still working on 1 bug only 1 company is seeing last I heard build 35 is 
the most stable firmware I've seen so I'm sure official will not be too much 
longer but probably faster if more would test build 35 on AP's to track down 
this 1 bug

—
Sent from Mailbox


On Thu, Oct 30, 2014 at 12:57 PM, Matt via Af 
mailto:af@afmug.com>> wrote:

Are we going to get 13.2 official this week?

Re: [AFMUG] 13.2(Build 35) Open Beta

[Aaron Schneider via Af]

If you aren't seeing it on build 34, you are unlikely to need the fix, but you 
are still at risk.  The customer who was seeing it readily would see it mostly 
occur during the CNUT upgrade phase when using AP as the file server.  Once the 
upgrade was done, the event log recovery message very rarely showed up.

If you can, I would go to build 35 just because that is what would become the 
release build if we are able to proceed next week.

Thanks,
-Aaron

-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Matt via Af
Sent: Friday, October 24, 2014 6:43 PM
To: af@afmug.com
Subject: Re: [AFMUG] 13.2(Build 35) Open Beta

> Changes in this build include an updated fix for the remaining 13.2 
> release blocker.  As I discussed with many of you at Wispapalooza, 
> that issue was related to the “Ethernet Tx Ring stall” message that 
> may show up in the event log, where very rarely, the recovery didn’t 
> recover.  Because that non-recovery condition led to an AP that had to 
> be remotely rebooted, we

Should we update all all our build 34 to 35 to avoid this or is it unlikely to 
happen if build 34 is running fine?  Just updated to 34.


> were unable to release.  Over the past couple of weeks we have been 
> able to get this reproduced at will internally and verify a fix that 
> took care of the problem.  This build has been running a customer site 
> for a couple of days that saw the issue readily on previous loads, and 
> the issue has not been seen.
>
>
>
> This build also contains a fix for the SM’s color code rescan timer 
> display (which is new to 13.2) and an update to help with some registration 
> issues.
>
>
>
> This is a release candidate build and we are hoping to have the 
> release available next week.  Please load it and send feedback if you can.

Re: [AFMUG] 13.2(Build 35) Open Beta

[Aaron Schneider via Af]

All –

Changes in this build include an updated fix for the remaining 13.2 release 
blocker.  As I discussed with many of you at Wispapalooza, that issue was 
related to the “Ethernet Tx Ring stall” message that may show up in the event 
log, where very rarely, the recovery didn’t recover.  Because that non-recovery 
condition led to an AP that had to be remotely rebooted, we were unable to 
release.  Over the past couple of weeks we have been able to get this 
reproduced at will internally and verify a fix that took care of the problem.  
This build has been running a customer site for a couple of days that saw the 
issue readily on previous loads, and the issue has not been seen.

This build also contains a fix for the SM’s color code rescan timer display 
(which is new to 13.2) and an update to help with some registration issues.

This is a release candidate build and we are hoping to have the release 
available next week.  Please load it and send feedback if you can.

Thank you for your patience!

Regards,
-Aaron

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Jonathan Mandziara via Af
Sent: Friday, October 24, 2014 6:12 PM
To: af@afmug.com
Subject: [AFMUG] 13.2(Build 35) Open Beta

Wispa Community,

The Open Beta refresh of 13.2 is now available for download on our Open Beta 
Site.

Please download it and tell us what you think.

Best,

Cambium Jonathan


Sent from my Verizon Wireless 4G LTE smartphone

 Original message 
From: Rickie D Hickox via Af
Date:10/13/2014 5:22 PM (GMT-06:00)
To: af@afmug.com
Subject: Re: [AFMUG] Tornadoes

Amen to that.


-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of George Skorup (Cyber 
Broadcasting) via Af
Sent: Monday, October 13, 2014 4:35 PM
To: af@afmug.com
Subject: [AFMUG] Tornadoes

All of you guys are out in Vegas and we have this crap to deal with back here. 
Nothing bad up this way yet, but Southern IL has a few tornado warnings 
already. Hopefully this isn't going to be a repeat of Oct/Nov last year.

Re: [AFMUG] ptp 450

[Aaron Schneider via Af]

Hi Ryan -

This version was only used for shipping devices and we don't plan on making it 
available.  It is actually based on a branch from 13.2 (Build 27) on a PTP 
branch so that we could get the product shipping.

Please contact me offlist 
(aa...@cambiumnetworks.com) for help to 
understand why you need this firmware.

Thanks
-Aaron


From: Af [mailto:af-boun...@afmug.com] On Behalf Of Ryan Mano via Af
Sent: Wednesday, October 22, 2014 8:21 PM
To: af@afmug.com
Subject: [AFMUG] ptp 450


does anyone have firmware 13.1.4 for ptp 450?...its not on cambium support page 
only beta 13.2



thanks

Re: [AFMUG] 13.2 (Build32) Beta Software is Now Available!‏‏

[Aaron Schneider via Af]

Since the last Open Beta load (Build 30), this also contains:


  *   Fix for negative VC count on home page
  *   New OID to see NAT table size in use
  *   Fix for Active FTP with NAT
  *   PPPoE Control Message High Priority with VLAN Enabled

·Added missing OIDs for IPv6 packet filtering configuration

We are very close to release, so please give this load a try!

Regards,

-Aaron

From: Af [mailto:af-boun...@afmug.com] On Behalf Of John Mehling via Af
Sent: Friday, October 03, 2014 6:10 PM
To: af@afmug.com
Subject: [AFMUG] 13.2 (Build32) Beta Software is Now Available!‏‏


Folks,

Software version 13.2(Build32) has been added to the Cambium Open Beta program 
for PMP450, PMP430, and PTP230.

Please go here: https://support.cambiumnetworks.com/beta if you would like to 
test the new load and offer feedback on the Beta Forum.

 Fixes in this release include:
• Fix for Motorola Binary GPS based devices (CMM2, SyncPipe, etc)
• Fix for PTP450 link test with small packets causing session drop 
and/or invalid readings

This version also adds OID support for IPv6 packet filtering.

As always, we look forward to your feedback.  Thank you!

-John


John Mehling
Senior Engineer - Support

Cambium Networks
3800 Golf Rd.,  Suite 360
Rolling Meadows, IL 60008
www.cambiumnetworks.com

[v_large_blue_noBG.png]

Re: [AFMUG] PMP450 AP stopped responding

[Aaron Schneider via Af]

Forwarding this on, someone should be in touch if they haven’t already.



From: Af [mailto:af-bounces+aaron.schneider=cambiumnetworks@afmug.com] On 
Behalf Of Ryan Ray via Af
Sent: Friday, September 26, 2014 4:12 PM
To: af@afmug.com
Subject: Re: [AFMUG] PMP450 AP stopped responding

I will try loading the beta as soon as I get my dump from the AP. I phoned in 
and created a support case as well.

I tried to run the gather support info and I get the following.

Launching: java -cp C:\Canopy\NetworkUpdater\tools\CNUTSupportInfoTool.jar null
Start Time: September 26, 2014 2:04:34 PM PDT
java.lang.NoClassDefFoundError: null
Caused by: java.lang.ClassNotFoundException: null
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
Could not find the main class: null.  Program will exit.
Exception in thread "main"

Tool Complete with exit status:1
End Time: September 26, 2014 2:04:35 PM

He also said I would be getting an email with information about submitting the 
dump and I haven't got that either.



On Fri, Sep 26, 2014 at 1:44 PM, Aaron Schneider via Af 
mailto:af@afmug.com>> wrote:
Hi Ryan –

While I can’t say for certain what caused the Ethernet Core to get stuck, there 
are two things in 13.2 that will help with this.  First off, there was a bug in 
this reporting mechanism that wasn’t allowing a recovery to take place.  That 
recovery should have been an AP reboot but the logging itself was preventing 
that.  Secondly, for PMP450, in 13.2, there were architectural changes made 
such that this type of a problem can’t happen anymore.  Those changes are 
related to the speed improvements gained with the 13.2 release on PMP450.  
PMP430 could still be susceptible to this type of a condition, but the first 
point I mentioned will correct the recovery in that it won’t let the device sit 
there unresponsive, it will reset itself if it gets stuck in this kind of 
condition.

Please try the 13.2 Build 30 beta if you can.  We are close to the 13.2 general 
release.

Regards,
-Aaron

From: Af 
[mailto:af-bounces+aaron.schneider<mailto:af-bounces%2Baaron.schneider>=cambiumnetworks@afmug.com<mailto:cambiumnetworks@afmug.com>]
 On Behalf Of Ryan Ray via Af
Sent: Friday, September 26, 2014 3:17 PM
To: af@afmug.com<mailto:af@afmug.com>
Subject: [AFMUG] PMP450 AP stopped responding

About 30 minutes ago I had a 2.4 AP loaded on 13.1.3 just quit responding. CTM 
said there was still normal power draw, link was up up on the cisco switch with 
no errors. No traffic.

Reset the port from the CTM and it came back. I have another AP up there right 
beside it on the same software that I haven't seen issues yet. Anyone ever seen 
this before? I saw this on the bootup log.

**System Startup**
System Reset Exception --
Software Version : CANOPY 13.1.3 AP-DES
Board Type : P12
Device Setting : 2.4GHz MIMO OFDM - Access Point -
No valid accounts configured. Using default user account - 2460.0 MHz - 20.0 
MHz - 1/16 - CC 4
FPGA Version : 011514
FPGA Features : DES, Sched, US/ETSI;
12/31/2010 : 17:00:24 PDT : Bridge Core : Acquired sync pulse from Power Port.
09/25/2014 : 01:18:10 PDT : : Bridge Core : Time Set
12/31/2010 : 17:00:00 PDT : : Bridge Core :
01/01/2011 : 00:00:00 UTC : : Bridge Core : Time Set
12/31/2010 : 17:00:00 PDT : Bridge Core :
**System Startup**
System Reset Exception -- Watchdog Reset
Software Version : CANOPY 13.1.3 AP-DES
Board Type : P12
Device Setting : 2.4GHz MIMO OFDM - Access Point - No valid accounts 
configured. Using default user account - 2460.0 MHz - 20.0 MHz - 1/16 - CC 4
FPGA Version : 011514
FPGA Features : DES, Sched, US/ETSI;
12/31/2010 : 17:00:24 PDT : Bridge Core : Acquired sync pulse from Power Port.
09/25/2014 : 15:03:05 PDT : : Bridge Core : Time Set
09/26/2014 : 13:10:02 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:05 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:09 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:12 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:16 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:20 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:23 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:27 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:31 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:34 PDT : : Bridge Core : Ethernet Core failing to repor

Re: [AFMUG] PMP450 AP stopped responding

[Aaron Schneider via Af]

That can be ignored and is fixed already.  It has no bearing on operation, just 
a display issue.

From: Af [mailto:af-bounces+aaron.schneider=cambiumnetworks@afmug.com] On 
Behalf Of RanchBoss via Af
Sent: Friday, September 26, 2014 5:27 PM
To: af@afmug.com
Subject: Re: [AFMUG] PMP450 AP stopped responding

Seeing -237 and such VC counts on the first page of 5.4 450 APs. Other types 
seem to count correctly.  13.2B30

Allen

Sent from my Ranch Phone

On Sep 26, 2014, at 3:44 PM, Aaron Schneider via Af 
mailto:af@afmug.com>> wrote:
Hi Ryan –

While I can’t say for certain what caused the Ethernet Core to get stuck, there 
are two things in 13.2 that will help with this.  First off, there was a bug in 
this reporting mechanism that wasn’t allowing a recovery to take place.  That 
recovery should have been an AP reboot but the logging itself was preventing 
that.  Secondly, for PMP450, in 13.2, there were architectural changes made 
such that this type of a problem can’t happen anymore.  Those changes are 
related to the speed improvements gained with the 13.2 release on PMP450.  
PMP430 could still be susceptible to this type of a condition, but the first 
point I mentioned will correct the recovery in that it won’t let the device sit 
there unresponsive, it will reset itself if it gets stuck in this kind of 
condition.

Please try the 13.2 Build 30 beta if you can.  We are close to the 13.2 general 
release.

Regards,
-Aaron

From: Af [mailto:af-bounces+aaron.schneider=cambiumnetworks@afmug.com] On 
Behalf Of Ryan Ray via Af
Sent: Friday, September 26, 2014 3:17 PM
To: af@afmug.com<mailto:af@afmug.com>
Subject: [AFMUG] PMP450 AP stopped responding

About 30 minutes ago I had a 2.4 AP loaded on 13.1.3 just quit responding. CTM 
said there was still normal power draw, link was up up on the cisco switch with 
no errors. No traffic.

Reset the port from the CTM and it came back. I have another AP up there right 
beside it on the same software that I haven't seen issues yet. Anyone ever seen 
this before? I saw this on the bootup log.

**System Startup**
System Reset Exception --
Software Version : CANOPY 13.1.3 AP-DES
Board Type : P12
Device Setting : 2.4GHz MIMO OFDM - Access Point -
No valid accounts configured. Using default user account - 2460.0 MHz - 20.0 
MHz - 1/16 - CC 4
FPGA Version : 011514
FPGA Features : DES, Sched, US/ETSI;
12/31/2010 : 17:00:24 PDT : Bridge Core : Acquired sync pulse from Power Port.
09/25/2014 : 01:18:10 PDT : : Bridge Core : Time Set
12/31/2010 : 17:00:00 PDT : : Bridge Core :
01/01/2011 : 00:00:00 UTC : : Bridge Core : Time Set
12/31/2010 : 17:00:00 PDT : Bridge Core :
**System Startup**
System Reset Exception -- Watchdog Reset
Software Version : CANOPY 13.1.3 AP-DES
Board Type : P12
Device Setting : 2.4GHz MIMO OFDM - Access Point - No valid accounts 
configured. Using default user account - 2460.0 MHz - 20.0 MHz - 1/16 - CC 4
FPGA Version : 011514
FPGA Features : DES, Sched, US/ETSI;
12/31/2010 : 17:00:24 PDT : Bridge Core : Acquired sync pulse from Power Port.
09/25/2014 : 15:03:05 PDT : : Bridge Core : Time Set
09/26/2014 : 13:10:02 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:05 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:09 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:12 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:16 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:20 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:23 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:27 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:31 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:34 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:38 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:42 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:45 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:49 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:52 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:56 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:11:00 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:11:03 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:11:07 PDT : : Bridge Core : Ethernet Core failing to report.

Cheers

Re: [AFMUG] PMP450 AP stopped responding

[Aaron Schneider via Af]

Hi Ryan –

While I can’t say for certain what caused the Ethernet Core to get stuck, there 
are two things in 13.2 that will help with this.  First off, there was a bug in 
this reporting mechanism that wasn’t allowing a recovery to take place.  That 
recovery should have been an AP reboot but the logging itself was preventing 
that.  Secondly, for PMP450, in 13.2, there were architectural changes made 
such that this type of a problem can’t happen anymore.  Those changes are 
related to the speed improvements gained with the 13.2 release on PMP450.  
PMP430 could still be susceptible to this type of a condition, but the first 
point I mentioned will correct the recovery in that it won’t let the device sit 
there unresponsive, it will reset itself if it gets stuck in this kind of 
condition.

Please try the 13.2 Build 30 beta if you can.  We are close to the 13.2 general 
release.

Regards,
-Aaron

From: Af [mailto:af-bounces+aaron.schneider=cambiumnetworks@afmug.com] On 
Behalf Of Ryan Ray via Af
Sent: Friday, September 26, 2014 3:17 PM
To: af@afmug.com
Subject: [AFMUG] PMP450 AP stopped responding

About 30 minutes ago I had a 2.4 AP loaded on 13.1.3 just quit responding. CTM 
said there was still normal power draw, link was up up on the cisco switch with 
no errors. No traffic.

Reset the port from the CTM and it came back. I have another AP up there right 
beside it on the same software that I haven't seen issues yet. Anyone ever seen 
this before? I saw this on the bootup log.

**System Startup**
System Reset Exception --
Software Version : CANOPY 13.1.3 AP-DES
Board Type : P12
Device Setting : 2.4GHz MIMO OFDM - Access Point -
No valid accounts configured. Using default user account - 2460.0 MHz - 20.0 
MHz - 1/16 - CC 4
FPGA Version : 011514
FPGA Features : DES, Sched, US/ETSI;
12/31/2010 : 17:00:24 PDT : Bridge Core : Acquired sync pulse from Power Port.
09/25/2014 : 01:18:10 PDT : : Bridge Core : Time Set
12/31/2010 : 17:00:00 PDT : : Bridge Core :
01/01/2011 : 00:00:00 UTC : : Bridge Core : Time Set
12/31/2010 : 17:00:00 PDT : Bridge Core :
**System Startup**
System Reset Exception -- Watchdog Reset
Software Version : CANOPY 13.1.3 AP-DES
Board Type : P12
Device Setting : 2.4GHz MIMO OFDM - Access Point - No valid accounts 
configured. Using default user account - 2460.0 MHz - 20.0 MHz - 1/16 - CC 4
FPGA Version : 011514
FPGA Features : DES, Sched, US/ETSI;
12/31/2010 : 17:00:24 PDT : Bridge Core : Acquired sync pulse from Power Port.
09/25/2014 : 15:03:05 PDT : : Bridge Core : Time Set
09/26/2014 : 13:10:02 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:05 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:09 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:12 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:16 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:20 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:23 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:27 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:31 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:34 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:38 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:42 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:45 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:49 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:52 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:10:56 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:11:00 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:11:03 PDT : : Bridge Core : Ethernet Core failing to report.
09/26/2014 : 13:11:07 PDT : : Bridge Core : Ethernet Core failing to report.

Cheers

Re: [AFMUG] Dear Cambium

[Aaron Schneider via Af]

--- [ Aaron Schneider  wrote ]:
---
Hmm, this is odd - yours and Sean's messages came in as an attachment to an 
empty message...

Anyways, yes, we are well aware that FSK is never going away, we've been the 
ones keeping it going for this long!  We took a break from releasing FSK 
version from 11.2 to 12.1 and the next refresh release from that was 13.1.   I 
don't think there has been any full decision on the fate of future FSK releases 
but we are concentrating 13.2 and 13.3 on the 430/450 products and will see 
then.   I'll see if we can get a point release with the couple of minor 
(meaning to fix, not meaning "minor impact") items such as missing the None 
frequency.

George you need to talk your boss into letting you go to Vegas.  Imagine the 
discussions you can have once you get some libations in you and go on tilt at 
the blackjack table. :)

-Aaron




-Original Message-
From: Af [mailto:af-bounces+aaron.schneider=cambiumnetworks@afmug.com] On 
Behalf Of George Skorup (Cyber Broadcasting) via Af
Sent: Friday, September 19, 2014 1:06 PM
To: af@afmug.com
Subject: Re: [AFMUG] Dear Cambium

--- [ "George Skorup (Cyber Broadcasting)"  wrote ]:
---

Re: [AFMUG] Dear Cambium

[Aaron Schneider via Af]

13.3 is currently only planned for PMP450/430 and PTP450/230, as is 13.2.   
PMP/PTP100 were brought up in line with 13.1.3 but won't be getting 13.2 or 
13.3 at this point.


From: Af [mailto:af-bounces+aaron.schneider=cambiumnetworks@afmug.com] On 
Behalf Of Adam Moffett via Af
Sent: Friday, September 19, 2014 8:00 AM
To: af@afmug.com
Subject: Re: [AFMUG] Dear Cambium


Can you tell us which platforms will get these features?  PMP100 and up, or 
just the 430/450?
You'll have to wait for WISPAPALOOZA for more details. :)


From: Af [mailto:af-bounces+aaron.schneider=cambiumnetworks@afmug.com] On 
Behalf Of George Skorup (Cyber Broadcasting) via Af
Sent: Thursday, September 18, 2014 9:57 PM
To: af@afmug.com<mailto:af@afmug.com>
Subject: Re: [AFMUG] Dear Cambium

OK, so clarify the option 66 URL part. What makes sense to me is a single 
option 66 statement on the DHCP server like I said below. The SM will fill in 
its ESN/MAC as the file name to pull from the HTTP or TFTP server. This is how 
most VoIP handset/ATA provisioning works. On the PBX or switch, your station 
config files would reside in some directory and the handset would request 
001122334455.cfg or 00-11-22-33-44-55.cfg. This is exactly how zero-touch 
auto-provision works, at least with the VoIP crap I've messed with. What I'm 
looking for is how to tie X device to X customer in say a 
billing/support/provisioning system. And if the SM dies, then rename the file 
with the new ESN.

So if this is not the way the option 66 mechanism will function, then yeah, 
RADIUS VSA for the URL will be the only other way. I think it would be easier 
to just do RADIUS attributes for all of the config, but we've had that 
discussion before.

Off my rocker now? :)

On 9/18/2014 8:46 PM, Aaron Schneider via Af wrote:
You are securely attached to your rocker and very comfortable.

That's pretty much how it will go but the dhcp server will provide the filename 
via option66 string within the url itself.

Another option would be radius profiles with config file url delivered via a 
VSA. �Not sure that will get into first release. But we are working on it.

You are correct on ICC operation, once a non default CC config is in place, ICC 
will never be used on SM even if it is left enabled. �But you can very easily 
set ICC to disabled in the config file.

Aaron


 Original message 
From: "George Skorup (Cyber Broadcasting) via Af"
Date:09/18/2014 6:48 PM (GMT-06:00)
To: af@afmug.com<mailto:af@afmug.com>
Subject: Re: [AFMUG] Dear Cambium

I'm guessing it's going to work like this: 13.3 SM registers via ICC. It 
switches on DHCP and looks for Option 66. Then it contacts the HTTP/TFTP server 
with a request string like http:///$.cfg just like it works 
with IP phones and things like that.

ICC doesn't do random stupid things anymore. That was with v11.1. Once the SM 
is configured with color codes other than CC1=0 and the reset zero and 
disabled, ICC is effectively disabled.

The second part is, if your default SM registered to my AP via ICC, I wouldn't 
have a config file for its ESN to send it. Well, maybe I could, but why.

I'm sure there's always a way for things to go wrong. But I need a much faster 
and automated way to do provisioning. I'd like to give the guys a basic 
template that they keep on their field PCs to load into new radios to set up 
things like default QoS, protocol filters, admin password, etc. RADIUS handles 
only basic stuff like QoS and VLAN.

Maybe I'm completely off my rocker here.

On 9/18/2014 6:21 PM, That One Guy via Af wrote:
so if a device connects to icc, it will turn on dhcp client? �so if we are 
using this, we will want to remember to have part of the dump config be to 
disable ICC or if a deployed unit happenned to hit ICC on a different AP, as 
has been the case in the past, it will become defaulted, or at least defaulted 
to the configured default configuration? This could be problematic, stranding a 
subscriber if a competitor is also running option 66 via ICC couldnt it? or is 
there a way to mitigate that?

On Thu, Sep 18, 2014 at 6:04 PM, George Skorup (Cyber Broadcasting) via Af 
mailto:af@afmug.com>> wrote:
That is freakin awesome! I think Matt said something about a RADIUS VSA option 
too. RADIUS and DHCP option 66. Both are good with me.


On 9/18/2014 4:41 PM, Aaron Schneider via Af wrote:
Hi George -

I know this was a long time ago (and has been an even longer time coming), but 
attached is what I sent after AF2014.

What we have now is the file format, it will be JSON based and there will be a 
published spec.� It will also work with DHCP Option 66.� For Zero Touch 
Config type of operation, we are leveraging the ICC feature in that once a 
radio is on 13.3, if a radio registers via ICC, it will turn on DHCP and 
request Option 66.� That option can be populated with a URL to th

Re: [AFMUG] Dear Cambium

[Aaron Schneider via Af]

You'll have to wait for WISPAPALOOZA for more details. :)


From: Af [mailto:af-bounces+aaron.schneider=cambiumnetworks@afmug.com] On 
Behalf Of George Skorup (Cyber Broadcasting) via Af
Sent: Thursday, September 18, 2014 9:57 PM
To: af@afmug.com
Subject: Re: [AFMUG] Dear Cambium

OK, so clarify the option 66 URL part. What makes sense to me is a single 
option 66 statement on the DHCP server like I said below. The SM will fill in 
its ESN/MAC as the file name to pull from the HTTP or TFTP server. This is how 
most VoIP handset/ATA provisioning works. On the PBX or switch, your station 
config files would reside in some directory and the handset would request 
001122334455.cfg or 00-11-22-33-44-55.cfg. This is exactly how zero-touch 
auto-provision works, at least with the VoIP crap I've messed with. What I'm 
looking for is how to tie X device to X customer in say a 
billing/support/provisioning system. And if the SM dies, then rename the file 
with the new ESN.

So if this is not the way the option 66 mechanism will function, then yeah, 
RADIUS VSA for the URL will be the only other way. I think it would be easier 
to just do RADIUS attributes for all of the config, but we've had that 
discussion before.

Off my rocker now? :)

On 9/18/2014 8:46 PM, Aaron Schneider via Af wrote:
You are securely attached to your rocker and very comfortable.

That's pretty much how it will go but the dhcp server will provide the filename 
via option66 string within the url itself.

Another option would be radius profiles with config file url delivered via a 
VSA. �Not sure that will get into first release. But we are working on it.

You are correct on ICC operation, once a non default CC config is in place, ICC 
will never be used on SM even if it is left enabled. �But you can very easily 
set ICC to disabled in the config file.

Aaron


 Original message 
From: "George Skorup (Cyber Broadcasting) via Af"
Date:09/18/2014 6:48 PM (GMT-06:00)
To: af@afmug.com<mailto:af@afmug.com>
Subject: Re: [AFMUG] Dear Cambium

I'm guessing it's going to work like this: 13.3 SM registers via ICC. It 
switches on DHCP and looks for Option 66. Then it contacts the HTTP/TFTP server 
with a request string like http:///$.cfg just like it works 
with IP phones and things like that.

ICC doesn't do random stupid things anymore. That was with v11.1. Once the SM 
is configured with color codes other than CC1=0 and the reset zero and 
disabled, ICC is effectively disabled.

The second part is, if your default SM registered to my AP via ICC, I wouldn't 
have a config file for its ESN to send it. Well, maybe I could, but why.

I'm sure there's always a way for things to go wrong. But I need a much faster 
and automated way to do provisioning. I'd like to give the guys a basic 
template that they keep on their field PCs to load into new radios to set up 
things like default QoS, protocol filters, admin password, etc. RADIUS handles 
only basic stuff like QoS and VLAN.

Maybe I'm completely off my rocker here.

On 9/18/2014 6:21 PM, That One Guy via Af wrote:
so if a device connects to icc, it will turn on dhcp client? �so if we are 
using this, we will want to remember to have part of the dump config be to 
disable ICC or if a deployed unit happenned to hit ICC on a different AP, as 
has been the case in the past, it will become defaulted, or at least defaulted 
to the configured default configuration? This could be problematic, stranding a 
subscriber if a competitor is also running option 66 via ICC couldnt it? or is 
there a way to mitigate that?

On Thu, Sep 18, 2014 at 6:04 PM, George Skorup (Cyber Broadcasting) via Af 
mailto:af@afmug.com>> wrote:
That is freakin awesome! I think Matt said something about a RADIUS VSA option 
too. RADIUS and DHCP option 66. Both are good with me.


On 9/18/2014 4:41 PM, Aaron Schneider via Af wrote:
Hi George -

I know this was a long time ago (and has been an even longer time coming), but 
attached is what I sent after AF2014.

What we have now is the file format, it will be JSON based and there will be a 
published spec.� It will also work with DHCP Option 66.� For Zero Touch 
Config type of operation, we are leveraging the ICC feature in that once a 
radio is on 13.3, if a radio registers via ICC, it will turn on DHCP and 
request Option 66.� That option can be populated with a URL to the config 
file (HTTP or TFTP) that will be retrieved and applied and if a reboot is 
required, the reboot will be applied.� Once the SM comes back if it had to 
reboot, it will be on the new configuration.

You will also be able to backup/restore the file via the webpage and SNMP and 
read it and edit it.

Again, this is coming in 13.3 release and we'll be discussing some things at 
WISPAPALOOZA related to this.� Obviously an SM needs to be on 13.3 to support 
this, so the fully promise of Zer

Re: [AFMUG] Dear Cambium

[Aaron Schneider via Af]

You are securely attached to your rocker and very comfortable.

That's pretty much how it will go but the dhcp server will provide the filename 
via option66 string within the url itself.

Another option would be radius profiles with config file url delivered via a 
VSA.  Not sure that will get into first release. But we are working on it.

You are correct on ICC operation, once a non default CC config is in place, ICC 
will never be used on SM even if it is left enabled.  But you can very easily 
set ICC to disabled in the config file.

Aaron



 Original message 
From: "George Skorup (Cyber Broadcasting) via Af"
Date:09/18/2014 6:48 PM (GMT-06:00)
To: af@afmug.com
Subject: Re: [AFMUG] Dear Cambium

I'm guessing it's going to work like this: 13.3 SM registers via ICC. It 
switches on DHCP and looks for Option 66. Then it contacts the HTTP/TFTP server 
with a request string like http:///$.cfg just like it works 
with IP phones and things like that.

ICC doesn't do random stupid things anymore. That was with v11.1. Once the SM 
is configured with color codes other than CC1=0 and the reset zero and 
disabled, ICC is effectively disabled.

The second part is, if your default SM registered to my AP via ICC, I wouldn't 
have a config file for its ESN to send it. Well, maybe I could, but why.

I'm sure there's always a way for things to go wrong. But I need a much faster 
and automated way to do provisioning. I'd like to give the guys a basic 
template that they keep on their field PCs to load into new radios to set up 
things like default QoS, protocol filters, admin password, etc. RADIUS handles 
only basic stuff like QoS and VLAN.

Maybe I'm completely off my rocker here.

On 9/18/2014 6:21 PM, That One Guy via Af wrote:
so if a device connects to icc, it will turn on dhcp client?  so if we are 
using this, we will want to remember to have part of the dump config be to 
disable ICC or if a deployed unit happenned to hit ICC on a different AP, as 
has been the case in the past, it will become defaulted, or at least defaulted 
to the configured default configuration? This could be problematic, stranding a 
subscriber if a competitor is also running option 66 via ICC couldnt it? or is 
there a way to mitigate that?

On Thu, Sep 18, 2014 at 6:04 PM, George Skorup (Cyber Broadcasting) via Af 
mailto:af@afmug.com>> wrote:
That is freakin awesome! I think Matt said something about a RADIUS VSA option 
too. RADIUS and DHCP option 66. Both are good with me.


On 9/18/2014 4:41 PM, Aaron Schneider via Af wrote:
Hi George -

I know this was a long time ago (and has been an even longer time coming), but 
attached is what I sent after AF2014.

What we have now is the file format, it will be JSON based and there will be a 
published spec.  It will also work with DHCP Option 66.  For Zero Touch Config 
type of operation, we are leveraging the ICC feature in that once a radio is on 
13.3, if a radio registers via ICC, it will turn on DHCP and request Option 66. 
 That option can be populated with a URL to the config file (HTTP or TFTP) that 
will be retrieved and applied and if a reboot is required, the reboot will be 
applied.  Once the SM comes back if it had to reboot, it will be on the new 
configuration.

You will also be able to backup/restore the file via the webpage and SNMP and 
read it and edit it.

Again, this is coming in 13.3 release and we'll be discussing some things at 
WISPAPALOOZA related to this.  Obviously an SM needs to be on 13.3 to support 
this, so the fully promise of Zero Touch Config won't be there until SMs are 
shipping with 13.3 on them.

That is the update we have to give you at this point.

Regards,
-Aaron




-Original Message-
From: Af 
[mailto:af-bounces+aaron.schneider<mailto:af-bounces%2Baaron.schneider>=cambiumnetworks@afmug.com<mailto:cambiumnetworks@afmug.com>]
 On Behalf Of George Skorup (Cyber Broadcasting) via Af
Sent: Thursday, September 18, 2014 12:56 PM
To: af@afmug.com<mailto:af@afmug.com>
Subject: Re: [AFMUG] Dear Cambium

I know a TFTP config download kind of thing was talked about before. But it 
would be nice if we could manually apply a config template file directly 
through the SM GUI, so I can have the guys get new or recovered radios set up 
without having to mess with too many things (AP, TFTP server, etc), just upload 
file.. apply, reboot, whatever.

On 9/18/2014 10:00 AM, Aaron Schneider via Af wrote:
Hi Bill -

1) coming in 13.2
2) coming in 13.2, NAT table size is configurable from 1024 - 8192
entries, there is a configuration OID,  and will be a current table
size oid
3) possibly coming in 13.3, can't promise that yet
4) coming in 13.3, planning to have something at WISPAPALOOZA to demo, more 
than just a config file.  I sent some information about this awhile back.
5) we are working on an external frame calc tool but not sure of the 

Re: [AFMUG] Dear Cambium

[Aaron Schneider via Af]

If it registers via ICC, DHCP will be enabled automatically to try to retrieve 
a config via Option 66.   This is a change to the default behavior of ICC, but 
it enables this feature to work out of the box.  The SM still won’t be allowed 
to bridge traffic to/from the customer until it registers on a valid Color 
Code, which theoretically will happen once the config file is retrieved and 
applied.

-Aaron

From: Af [mailto:af-bounces+aaron.schneider=cambiumnetworks@afmug.com] On 
Behalf Of That One Guy via Af
Sent: Thursday, September 18, 2014 4:51 PM
To: af@afmug.com
Subject: Re: [AFMUG] Dear Cambium

but wouldnt you have to turn on dhcp through the gui for this to pull down?

On Thu, Sep 18, 2014 at 4:41 PM, Aaron Schneider via Af 
mailto:af@afmug.com>> wrote:
Hi George -

I know this was a long time ago (and has been an even longer time coming), but 
attached is what I sent after AF2014.

What we have now is the file format, it will be JSON based and there will be a 
published spec.  It will also work with DHCP Option 66.  For Zero Touch Config 
type of operation, we are leveraging the ICC feature in that once a radio is on 
13.3, if a radio registers via ICC, it will turn on DHCP and request Option 66. 
 That option can be populated with a URL to the config file (HTTP or TFTP) that 
will be retrieved and applied and if a reboot is required, the reboot will be 
applied.  Once the SM comes back if it had to reboot, it will be on the new 
configuration.

You will also be able to backup/restore the file via the webpage and SNMP and 
read it and edit it.

Again, this is coming in 13.3 release and we'll be discussing some things at 
WISPAPALOOZA related to this.  Obviously an SM needs to be on 13.3 to support 
this, so the fully promise of Zero Touch Config won't be there until SMs are 
shipping with 13.3 on them.

That is the update we have to give you at this point.

Regards,
-Aaron




-Original Message-
From: Af 
[mailto:af-bounces+aaron.schneider<mailto:af-bounces%2Baaron.schneider>=cambiumnetworks@afmug.com<mailto:cambiumnetworks@afmug.com>]
 On Behalf Of George Skorup (Cyber Broadcasting) via Af
Sent: Thursday, September 18, 2014 12:56 PM
To: af@afmug.com<mailto:af@afmug.com>
Subject: Re: [AFMUG] Dear Cambium
I know a TFTP config download kind of thing was talked about before. But it 
would be nice if we could manually apply a config template file directly 
through the SM GUI, so I can have the guys get new or recovered radios set up 
without having to mess with too many things (AP, TFTP server, etc), just upload 
file.. apply, reboot, whatever.

On 9/18/2014 10:00 AM, Aaron Schneider via Af wrote:
> Hi Bill -
>
> 1) coming in 13.2
> 2) coming in 13.2, NAT table size is configurable from 1024 - 8192
> entries, there is a configuration OID,  and will be a current table
> size oid
> 3) possibly coming in 13.3, can't promise that yet
> 4) coming in 13.3, planning to have something at WISPAPALOOZA to demo, more 
> than just a config file.  I sent some information about this awhile back.
> 5) we are working on an external frame calc tool but not sure of the timeline 
> of that.   Will make sure to add this idea to that list (point to an AP to 
> use as a "starting point").
>
> I'll send more details on #4 soon and we will be publishing the config file 
> format.
>
> Regards,
>
> -Aaron
>
>
> -Original Message-
> From: Af
> [mailto:af-bounces+aaron.schneider<mailto:af-bounces%2Baaron.schneider>=cambiumnetworks@afmug.com<mailto:cambiumnetworks@afmug.com>]
>  On
> Behalf Of Bill Prince via Af
> Sent: Wednesday, September 17, 2014 6:31 PM
> To: Motorola III
> Subject: [AFMUG] Dear Cambium
>
>
> Please let us know if:
>
>   1. The femtocell fix is in the pipe (or not)  2. There will be a trap on 
> NAT table full, or at least an OID that
>  shows the number of entries in the NAT table  3. As an alternative to 
> #2, perhaps a way to limit the number of MAC
>  addresses allowed behind an SM
>   4. A text-based configuration file
>   5. A "do this timing" that lets us just set an AP to match some other
>  AP as closely as possible by specifying the appropriate frame
>  dimensions (or maybe just the other APs IP address (now that would
>  be cool)
>
> TNX
>
>
> --
> bp
>



--
All parts should go together without forcing. You must remember that the parts 
you are reassembling were disassembled by you. Therefore, if you can't get them 
together again, there must be a reason. By all means, do not use a hammer. -- 
IBM maintenance manual, 1925

Re: [AFMUG] Dear Cambium

[Aaron Schneider via Af]

Hi George -

I know this was a long time ago (and has been an even longer time coming), but 
attached is what I sent after AF2014.  

What we have now is the file format, it will be JSON based and there will be a 
published spec.  It will also work with DHCP Option 66.  For Zero Touch Config 
type of operation, we are leveraging the ICC feature in that once a radio is on 
13.3, if a radio registers via ICC, it will turn on DHCP and request Option 66. 
 That option can be populated with a URL to the config file (HTTP or TFTP) that 
will be retrieved and applied and if a reboot is required, the reboot will be 
applied.  Once the SM comes back if it had to reboot, it will be on the new 
configuration.

You will also be able to backup/restore the file via the webpage and SNMP and 
read it and edit it.

Again, this is coming in 13.3 release and we'll be discussing some things at 
WISPAPALOOZA related to this.  Obviously an SM needs to be on 13.3 to support 
this, so the fully promise of Zero Touch Config won't be there until SMs are 
shipping with 13.3 on them.  

That is the update we have to give you at this point.

Regards,
-Aaron




-Original Message-
From: Af [mailto:af-bounces+aaron.schneider=cambiumnetworks@afmug.com] On 
Behalf Of George Skorup (Cyber Broadcasting) via Af
Sent: Thursday, September 18, 2014 12:56 PM
To: af@afmug.com
Subject: Re: [AFMUG] Dear Cambium

I know a TFTP config download kind of thing was talked about before. But it 
would be nice if we could manually apply a config template file directly 
through the SM GUI, so I can have the guys get new or recovered radios set up 
without having to mess with too many things (AP, TFTP server, etc), just upload 
file.. apply, reboot, whatever.

On 9/18/2014 10:00 AM, Aaron Schneider via Af wrote:
> Hi Bill -
>
> 1) coming in 13.2
> 2) coming in 13.2, NAT table size is configurable from 1024 - 8192 
> entries, there is a configuration OID,  and will be a current table 
> size oid
> 3) possibly coming in 13.3, can't promise that yet
> 4) coming in 13.3, planning to have something at WISPAPALOOZA to demo, more 
> than just a config file.  I sent some information about this awhile back.
> 5) we are working on an external frame calc tool but not sure of the timeline 
> of that.   Will make sure to add this idea to that list (point to an AP to 
> use as a "starting point").
>
> I'll send more details on #4 soon and we will be publishing the config file 
> format.
>
> Regards,
>
> -Aaron
>
>
> -Original Message-
> From: Af 
> [mailto:af-bounces+aaron.schneider=cambiumnetworks@afmug.com] On 
> Behalf Of Bill Prince via Af
> Sent: Wednesday, September 17, 2014 6:31 PM
> To: Motorola III
> Subject: [AFMUG] Dear Cambium
>
>
> Please let us know if:
>
>   1. The femtocell fix is in the pipe (or not)  2. There will be a trap on 
> NAT table full, or at least an OID that
>  shows the number of entries in the NAT table  3. As an alternative to 
> #2, perhaps a way to limit the number of MAC
>  addresses allowed behind an SM
>   4. A text-based configuration file
>   5. A "do this timing" that lets us just set an AP to match some other
>  AP as closely as possible by specifying the appropriate frame
>  dimensions (or maybe just the other APs IP address (now that would
>  be cool)
>
> TNX
>
>
> --
> bp
>

--- Begin Message ---
What isn't completely defined is the actual format of the file, we are 
determining that now and looking at XML and JSON.  What is determined is that 
you will have the following capabilities:



*Straight backup of everything from a radio, including Calibration 
values and feature keys.  This backup can only be fully reapplied to the radio 
that it was pulled from, since it contains calibration and feature key that is 
tied to that specific device

*Backup of a general configuration that includes everything else.  This 
backup can be used as a "golden config" where you set all of your common 
settings and can then reapply this backup to any radio of the same model.

*Retrieval of this configuration file via DHCP Option 66 and/or a new 
RADIUS VSA.  This would point to the file to download and the full 
configuration would be applied during registration (RADIUS) or DHCP.

o   Can be used in conjunction with the ICC feature to allow vanilla radios to 
be installed, get their config, and then re-register with the proper 
configuration

*The general backup file will be readable and editable, (and 
generateable, is that a word?) so that you can modify it or generate it on the 
fly for general configuration items (i.e. not device specific items like 
calibration/feature key/etc, but everything else).

*The format and interface of the file will be published 

Re: [AFMUG] Dear Cambium

[Aaron Schneider via Af]

Hi Bill -

1) coming in 13.2
2) coming in 13.2, NAT table size is configurable from 1024 - 8192 entries, 
there is a configuration OID,  and will be a current table size oid
3) possibly coming in 13.3, can't promise that yet
4) coming in 13.3, planning to have something at WISPAPALOOZA to demo, more 
than just a config file.  I sent some information about this awhile back.  
5) we are working on an external frame calc tool but not sure of the timeline 
of that.   Will make sure to add this idea to that list (point to an AP to use 
as a "starting point").

I'll send more details on #4 soon and we will be publishing the config file 
format.

Regards,

-Aaron


-Original Message-
From: Af [mailto:af-bounces+aaron.schneider=cambiumnetworks@afmug.com] On 
Behalf Of Bill Prince via Af
Sent: Wednesday, September 17, 2014 6:31 PM
To: Motorola III
Subject: [AFMUG] Dear Cambium


Please let us know if:

 1. The femtocell fix is in the pipe (or not)  2. There will be a trap on NAT 
table full, or at least an OID that
shows the number of entries in the NAT table  3. As an alternative to #2, 
perhaps a way to limit the number of MAC
addresses allowed behind an SM
 4. A text-based configuration file
 5. A "do this timing" that lets us just set an AP to match some other
AP as closely as possible by specifying the appropriate frame
dimensions (or maybe just the other APs IP address (now that would
be cool)

TNX


--
bp