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 <[email protected] <mailto:[email protected]>> 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>[email protected]
<mailto:[email protected]>] On Behalf Of George
Skorup (Cyber Broadcasting) via Af
Sent: Thursday, September 18, 2014 12:56 PM
To: [email protected] <mailto:[email protected]>
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>[email protected]
<mailto:[email protected]>] 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
