Re: [AFMUG] Dear Cambium

Simon Westlake via Af Fri, 19 Sep 2014 06:41:51 -0700

I cannot give you any specifics right now, but if you come by thePowercode booth at WISPAPALOOZA, I can guarantee we will have some veryinteresting things to show you.


On 9/18/2014 10:03 PM, That One Guy via Af wrote:

Simon? Simon? Will we get to play with this simon?

On Thu, Sep 18, 2014 at 9:57 PM, George Skorup (Cyber Broadcasting)via Af <af@afmug.com <mailto:af@afmug.com>> wrote:


    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

--

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


--
Simon Westlake
*Powercode* - The smart choice in ISP billing and OSS
powercode.com <http://powercode.com>
P: 920-351-1010
E: si...@powercode.com

Re: [AFMUG] Dear Cambium

Reply via email to