"lockdown" NV Param 52 question

[joecool]

I have the 2.2 beta set up and running. While testing the new "lockdown" feature, I seem to be unable to turn lockdown off via local saveNvParam(52, 0). Your firmware 2.2 release notes say:



iv. While in "lockdown" mode, you also cannot write to NV parameter #52 over-the-air (in other words, you cannot bypass the lockdown by remotely turning it off).


Since the unit's Snappy script is not running over-the-air, shouldn't it be able to change this value back to 0? We need to be able to unlock the units in the field by powering them up while a button is pressed.

[kbanks]

Yes, you should be able to turn it off from a script.

Note that you won't be able to turn it off from a script function that is invoked over the air.

I'll check and see if the test in the code is too strict. It is possible that it literally HAS to come in over Packet Serial currently.

If so, it will be fixed in the next posted BETA. These should start coming out approx. every 7 days now that we are in the final stages.

Thanks for the feedback.

[kbanks]

You are right, the lockout is too strict. We are working on a fix.

[joecool]

Okay, here is another thing I don't like...maybe you had technical reasons for doing this: Lockdown does not keep you from moving a node to / from your network. I locked down one of my nodes and then was able to change its network ID, channel AND reboot it remotely using Portal. I was then able to search for nodes, discover this "locked" node, and then move it back to my network - which means anyone with a copy of Portal & a SnapStick could do the same. Shouldn't those functions be disabled if parameter 52 is set to 1?

[kbanks]

No, the current lockdown is for "script related" commands only.

We anticipate that additional types of lockdowns will be added in future releases, which is why I made the new NV parameter a bitfield.

For now, you keep people from "stealing" your nodes by using AES-128.

[joecool]

No, the current lockdown is for "script related" commands only.

We anticipate that additional types of lockdowns will be added in future releases, which is why I made the new NV parameter a bitfield.

For now, you keep people from "stealing" your nodes by using AES-128.

AES-128 is not an option for us since it would require the installer to have Portal running in order to enter the AES128 Key. This product has to be installed without the use of a computer. That is the nature of our industry - the installers deal with pc board assemblies and wires, but asking them to use a computer is really pushing it. Maybe we could come up with another way of enabling AES and entering the key, but it would only add to the cost and complexity of the product.

So correct me if I'm wrong...parameter 52 keeps evil-doers from uploading new scripts, but they can still take your node down by hijacking it. So what is the point? Both accomplish the same thing...your node is no longer doing what it is supposed to be doing. I'll be eagerly awaiting the rest of the bitmapped features. Please make one of them "lock down" the nv parameters from over-the-air changes. Oh, yeah...you'd have to disble the "live" functions that change those, also. For example, no setNetId() from over-the-air (or whatever functions Portal uses to change these settings).

[joecool]

Well, I confirmed you fixed the problem with not being able to clear NVPARAM #52 from a local script.