Specifications

No encryption will be used if:
• NV parameter #50 is set to a value other than 1 or 2.
• NV parameter #50 is set to 1 in a node that does not have AES-128 encryption available in its
firmware.
• The encryption key in NV parameter #51 is invalid.
When you are establishing encryption for a network of nodes, it is important that you work “from the
outside in.” In other words, begin by setting up encryption in the nodes farthest from Portal and work
your way in toward your nearer nodes. This is necessary because once you have configured a node for
encrypted communications, it is unable to network with an unencrypted node.
Consider a network where you have Portal talking through a bridge node (named Alice), and Alice is
communicating with nodes Betty, Carla, and Daphne. If you configure Alice for encryption before you
configure Betty, Carla and Daphne, Alice will no longer be able to reach the other three nodes to set
up encryption in them. They will still be able to communicate with each other, but will not be able to
talk to (or through) Alice (and therefore will not be able to report back to Portal).
In the same environment, if you are relying on multiple hops in order to get messages to all your
nodes, if any intermediate node is encrypted all the unencrypted nodes beyond that one are essentially
orphaned. If Daphne relays messages through Carla, and Carla relays messages through Betty to Alice
(and thus to Portal), and you configure Carla for encryption before you configure Daphne, you will not
be able to reach Daphne to set the encryption type or encryption key.
As with all NV parameters, the changes you make will only take effect after the node is rebooted.
If you lose contact with a node as a result of a mistyped or forgotten encryption key, you will have to
use Portal to reset the node back to factory parameters. This will set NV Parameter #50 back to 0 and
NV Parameter #51 back to “” to disable encryption. Simply making a serial connection to the node to
reset the encryption key will not be sufficient, as serial communications as well as over-the-air
communications are encrypted.
Recovering an Unresponsive Node
As with any programming language, there are going to be ways you can put your nodes into a state
where they do not respond. Setting a node to spend all of its time asleep, having an endless loop in a
script, enabling encryption with a mistyped key, or turning off the radio and disconnecting the UARTs
are all very effective ways to make your SNAP nodes unresponsive.
How to best recover an unresponsive node depends on the cause of the problem. If the problem is the
result of runaway code (sleeping, looping, or disabling UARTS) and “Erase SNAPpy Image” from the
Node Info pane doesn’t work, you can usually use Portal’s “Erase SNAPpy Image...” feature from the
Options menu to regain access to your node. In the case of a lost encryption key or an unknown
channel/network ID, or one of many other combinations that may arise, Portal’s “Factory Default NV
Params...” feature, also from the Options menu, resets the node back to the state it was in when
delivered. (If you have intentionally changed any parameters, such as node name, channel, network
ID, various timeouts, etc., you will need to reset them once you have access to the node.) If these fail
SNAP Reference Manual Document Number 600-0007K Page 41 of 202