Inquiring minds want to know... Of the thousands SM's that we have in the air right now, only a hand full are 430/450's. Don't get me wrong, if this isn't going to be on PMP100 this is still good news, but of limited use to us right now.
-- Christopher Tyler MTCRE/MTCNA/MTCTCE/MTCWE Total Highspeed Internet Services 417.851.1107 ----- Original Message ----- From: "Adam Moffett via Af" <af@afmug.com> To: af@afmug.com Sent: Friday, September 19, 2014 7:59:46 AM 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 > *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://<server-IP>/$<ESN>.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 <af@afmug.com <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 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 >
