Do you really expect it on 100 and 430? I would be very surprised. But I
guess unexpected good stuff happens. Not to me, though. I have been
accused of being a pessimist, but if that's true, shouldn't I be pleasantly
surprised all the time?
-----Original Message-----
From: Christopher Tyler via Af
Sent: Friday, September 19, 2014 10:02 AM
To: af@afmug.com
Subject: Re: [AFMUG] Dear Cambium
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
