JANOS Registry Specification (18-May-2021)

Trademarks
Trademarks are the property of their respective holders.
JNIOR, JANOS, and INTEG are registered trademarks of INTEG Process Group, Inc.
Java is a registered trademark of Sun Microsystems/Oracle.
1-Wire is a registered trademark of Dallas Semiconductor/Maxim-IC.

Use Restrictions
This document, all related documents, the JANOS operating system and all software contained in JNIOR are proprietary and copyrighted by INTEG Process Group and may not be copied, reproduced or used in any other context without prior consent from INTEG Process Group, Inc.

The JNIOR Automation Network Operating System (JANOS) and its applications can be configured to suit your needs. Configuration involves choices, and those settings may be stored in a variety of ways. JANOS relies on its Registry system for all operating system configuration. The Registry can also be easily used by applications and web pages for the storage of custom configuration settings. The Registry may also be used to store and share data dynamically.

The JANOS Registry is non-volatile. Its content remains in place even when power is removed. Information is stored as a set of name-value pairs. Each entry is referenced by a unique Registry Key or name. Each entry contains information formatted as a character string representing its value. The content is available to JANOS directly, to external applications and web pages through protocols, and to local application programs through the Java runtime library.

JANOS maintains a backup copy of the Registry in the /flash/jnior.ini file. When content in the Registry is changed this INI file will later be updated to reflect the changes. This backup file is automatically generated and should not be overwritten or modified. JANOS performs this backup every several minutes as needed. The /flash/jnior.ini file may be read and saved as a representation of Registry content. This INI file will reflect changes only after the backup occurs. The backup is automatically performed on reboot.

A copy of the /flash/jnior.ini may be edited and saved under a different filename. This then may be ingested using the REGISTRY -I command as means a performing bulk configuration.

All actions are logged to the jniorsys.log file providing an audit trail for configuration management.

Configuration is likely best performed using the Dynamic Configuration Pages (WebUI). Once the JNIOR is connected to the network the browser can be used to open the WebUI with the unit's IP address. The JNIOR is configured by default to open the WebUI. An administrator login is required to access the Registry. The default username is 'jnior' and the default password for that account is also 'jnior'. It is highly recommended that you change default passwords and deactivate unused accounts. The relevant Console commands are: USERS, USERMOD and PASSWD. Note that there are two default administrative accounts.

In order to use the WebUI the JNIOR must be configured to allow network access from your location. If the JNIOR is on the same network segment there are several ways to locate the unit. If you know the unit's IP address then you use the URL: 'http://[ip-address]' replacing '[ip-address]' with the unit's IP address, 'http://192.168.2.137' for instance. Alternatively you can use the units serial number in the URL: 'http://jr[sn]' replacing '[sn]' with the unit's 9-digit serial number, 'http://jr615010258' for instance. This is the format of the default hostname. If you change the hostname you can also open the unit with the URL: 'http://[hostname]'. With JANOS v2.0 and later the serial number URL format is always available even when that hostname has been changed. The WebUI can also be opened through the Support Tool by right-clicking the unit in the Beacon tab and selecting Tools|Open Web Page.

The 'Configuration' tab of the WebUI provides an organized form-oriented means for adjusting the various configuration settings. In this section you are provided with over a dozen different categories. These settings affect both how the JNIOR operates and how the WebUI displays information. Not all of the valid and useful Registry Keys are presented within this section but only the most common and appropriate settings for each category. Certain advanced settings will need to be made manually by a different means. The unit's 'Network' configuration, for instance, may be easily adjusted here.

The WebUI also provides a 'Registry' tab. This section shows the raw content of the Registry Keys in a form similar to a file explorer. Only those keys with values are shown. You can add, remove or edit any Registry Key using this tab. Here you are required to know specifically what key or keys you want to change. This is most appropriate for advanced administrators. This provides a graphical user interface for Registry Key management.

The 'Console' tab in the WebUI provides access to the JANOS Command Line Console. This is the same command line facility that can be accessed using a Terminal or Telnet application to open the standard Telnet port (port 23) over the network. Even in the absence of a network connection you may open the console by making a serial connection (115.2 Kbaud, 8 data, 1 stop, no parity) to the RS-232/COM port located to the right of the Ethernet/LAN connection on the JNIOR. The COM port is a 3-wire connection using a male (or pin) type DB-9 connector. Pin 2 is data transmitted (Tx) from JNIOR (data source); Pin 3 is data to be received by the JNIOR (connected computer is the source); And, pin 5 is ground (GND). A standard USB-to-serial converter presenting a female (or socket) type DB-9 connector may be used directly. Once you have logged into the console you may use the REGISTRY command and many other commands to configure and administer your JNIOR. Type 'help' for the list of commands. You can type 'help' followed by a space and a command name to get details for the specified command.

If you are working with a Windows based PC you may download and install the INTEG Support Tool. The installer is available from our website at http://jnior.com. Once the Support Tool is opened the 'Beacon' tab will display all of the JNIORs located on the current network segment. If you right-click any JNIOR the resulting context menu will provide access to the unit's web page (WebUI), a Telnet application, and many other useful functions. The Support Tool also provides a 'Registry Editor' tab through which you can add, remove and edit content as needed for the selected JNIOR.

With Series 4 JNIOR, configuration changes are generally made using the WebUI, Support Tool or other application page. From the Command Line the appropriate commands should be used to change settings. For instance the IPCONFIG command should be used for all Network changes. Commands like DATE, NETSTAT, and others have options affecting configuration. These should be used in preference to manually editing Registry content. That being said, there are numerous settings that can only be made by adjusting the Registry directly.

With the original JNIOR predating the Registry feature, configuration changes were made by editing the appropriate INI file. Once the Registry had been introduced in Series 3, that practice was difficult to change. With Series 3 an edited jnior.ini was still automatically ingested. At the same time changes to Registry keys automatically updated the jnior.ini file. The resulting race situation led to a risk of INI changes being lost/ignored and configuration changes not being saved before reboot. The Series 4 does not automatically ingest INI files. In fact, we strongly recommend that you do not alter the jnior.ini file as it serves only as a backup for the Registry. Other INI files can be ingested/imported. That is covered in a later section.

You can use the REGISTRY command, or its shorthand alias REG, at the command line prompt to view, change and remove Registry Keys. The general syntax is described by the command HELP REGISTRY.

This REGISTRY command can be used to display, edit or remove any Registry key or group of keys. It can be used to search the Registry for relevant keys. This is very helpful if you do not recall the exact key needed. You may also export in import (ingest) segments of the Registry for efficient configuration.

You can easily review the content of the Registry using the REGISTRY command from the command line. You simply need to include the Registry Key name on the command line as in the following example. Note we can use the alias for convenience and that commands are not case-sensitive.

Note also that the [TAB] key is useful on the command line in providing auto-completion. When the REGISTRY command is used, known Registry keys are auto-completed by hitting [TAB]. So in the above example the command line can be entered as follows.

This would result in the command shown previously but with less risk of committing a typo even when you are uncertain as to the exact key that you need. If the auto-completion offered is not what you want, repeated use of [TAB] will cycle through other options and eventually return to the original line. Note that Registry keys are not case-sensitive. However, for presentation and formatting when a key is defined the character case used is recorded.

Registry keys known to the system have default values and if those defaults are acceptable the keys need not be explicitly defined. For example, the default WebServer port for secure communications is 443 and this can be altered using the WebServer/SSLPort key. Querying the value of that key which has likely not been altered would give you the following.

Here the response "No matching entries" indicates that a custom setting has not been defined and the key is not present among the available configuration settings. Since it is a System Key its default value is in effect. That response hints at the ability to search for keys.

Wildcards have been in common use since the earliest operating systems. Specifically the period '.' and the asterisk '*' which match any character or group of characters respectively. These can be used with the REGISTRY command to search the main sections of keys. That is, the wildcard match is applied only to the leftmost element of the path. This is useful in listing an entire Registry section. For example:

The REGISTRY command further supports the use of Regular Expressions (RegEx). While these expressions in many applications can be quite complex, here only the simplest are needed. The advantage of a RegEx search is that it is applied to the entire key and the key contents as well. Only those matching the expression are listed. This uses the REGISTRY -E option to indicate the presence of the RegEx. Note that these searches are not case-dependant. For example:

This displays any defined key having something to do with mail. RegEx expressions offer a wide variety of wildcard and logical search capabilities. The RegEx details are beyond the scope of this document. But you can do quite a bit and RegEx is supported by other commands such as EGREP. Here's a more complex search to locate any keys that are explicitly enabled or disabled.

You might notice here that there was one match to a key itself. These are all boolean keys. Boolean keys will return a TRUE condition if they contain "enable", "enabled", "true" or "1". The following are FALSE settings: "disable", "disabled", "false" or "0". These, along with just about anything else, result in the FALSE state and the feature not being enabled. These conditional settings are not case-dependant.

Registry keys are name-value pairs where the name is the key and its value a character string. You can assign just about any key any value. A Registry setting is only useful if some application pay attention to its content. The setting is easily accomplished by equating the key to a value with the equals '=' sign.

When entered as shown above the value must not contain spaces. This is true with any command line entry where the space is seen as a separator between parameters. Care must be taken to use double-quotes when setting values containing spaces. For example:

Numeric values, Booleans, Dates and just about anything else must be assigned to a Registry key in string form. The application, if it needs the value in another form, is responsible for the conversion.

So far you can imagine that the value of a key can be changed just by making a new assignment. This is the case but we can avoid a lot of typing especially when minor changes are involved. Here the [TAB] key auto-completion comes to the rescue. When entering a REGISTRY command and the [TAB] key is hit immediately (no intervening spaces) after the equals '=' sign, JANOS will present the current value for the key including the double-quotes. For instance, if we need to remove the period from the value in the previous example we could expeditiously enter the necessary command as follows:

Then following this, move back with with the LEFT cursor key and use DEL or Backspace as you need and remove the period. Then entering the command the value would be corrected. Note that the original use of case in the first definition will remain. You need not use the identical case in later referencing the key.

The [TAB] auto-completion capability in JANOS becomes quite addicting. The Series 3 JNIORs do not have this feature and that will catch you by surprise. Learning to use the [TAB] key in this fashion on the command line is best accomplished by practice.

Under JANOS v2.0 or later, when a Registry key known to the system is altered, a message is displayed to that effect. You are also notified if a reboot is required before the setting takes effect. This helps to avoid confusion where the reboot might be required and the user had expected some immediate effect. It can also tell you that indeed you likely got the key correct. Here are a couple of examples.

Application programs running on the JNIOR also use the Registry for configuration. The system does not know whether a Registry key is used by an application or not. It does not know if a change in such a key takes effect immediately, at a later time, after a program restart, or after a system reboot. You need to rely on application documentation for that information.

An individual Registry entry is removed by assigning it an empty string value. This is accomplished at the command line by not placing anything after the equal '=' sign. For example:

Once a key is removed its default value (if any) will be used. For the above example the FTP Server is enabled by default. FTP access to the unit will be possible after a reboot. Of course, here we don't know if that key might have already had an "enabled" value. In that case there would be no change in system function but only in the set of defined keys.

The REGISTRY -D option provides another means for key deletion. When this option is specified the key or keys matching that supplied is/are removed. No blank or null string assignment is required. With each matching key the user is given the opportunity to confirm or reject the action. This can be very useful when a number of keys but not all from a section need to be deleted. It is also helpful if not all of the matching keys are from the desired section. For example we can delete the entire Email section as follows:

In this example had we not wanted to delete the Email/Port key we could have refused with a 'No'. Alternatively we could avoid having to confirm each deletion by answering 'All' assuming that we were confident that the correct keys were selected for deletion. Similarly we could use the REGISTRY -DA option combination adding the All option to avoid the need for any user response.

Unlike the File System where you could have an empty folder there are no empty nodes in the Registry. Once you remove all of the keys for a particular node the node itself no longer exists.

A stable configuration is critical for the long term success of the JNIOR in any application. When changes are made the performance of the product will change. Hopefully the change has the desired effect. Often changes are made and the impact of those are not noticed for quite some time. At that point it would helpful to know just exactly what changed for diagnostics purposes. For that reason changes to Registry keys are logged in the System Log (syslog) stored in jniorsys.log.

For example, the following snippet from jniorsys.log shows some of the Registry manipulations that we had done as previous examples. Note that the system knows when a key is added or removed. It also knows when the value has changed. Beginning with JANOS v2.0 we log both the new value and the previous value. This is useful should you want to revert any change.

Note how the backup of the Registry is quickly updated. Do not manually change the /flash/jnior.ini file. It will be quickly overwritten.

The EGREP command can be invaluable in searching LOG files. This command uses a Regex but unlike that used in the REGISTRY command this is a case-sensitive search. You can search without regard for case by including the -I option. In the above commands we simply search for something unique to Registry change entries.

New with JANOS v2.0 is the availability of the Last Modification timestamp. Similar to the File System where files have Last Modification Dates, the Registry records when changes are made. The REGISTRY -M option displays this information. This can tell you when the key had last been added or changed. If you are diagnosing an issue the timing of a change may provide you with a valuable clue. The -M option is simply used when displaying keys. For example:

The timestamp is displayed in the format [YYMMDDHHSS] using the current local timezone. In the above example the JNIOR's IP Address was last changed on [2101311023] or 31-Jan-2021 at 10:23 EST. Time is reported in the 24 hour format. You might note that since DHCP is enabled, this timestamp tells us when a new IP Address had been first leased. The Last Modification Date is only updated when a key is added or its content changes. If you assign a value to a key that matches the existing value the key is not changed. Nothing will be logged and the timestamp will remain unchanged.

Registry keys contain values intended to control the configuration if the System and its Applications as well as external elements such as the WebUI and even the Support Tool. A set of these keys are then known to the system and JANOS (JNIOR's operating system) looks to those for its configuration. Beyond that set of keys JANOS just assumes that the user has some use for them.

With JANOS v2.0 and later the REGISTRY -X option includes the known built-in Registry keys in searches even when there is no value assignment. Undefined keys result in their default values and that depends on their purpose. For example we can see those Email related keys known to the system.

The defaults are listed with each key's description later in this document. JANOS can only list those keys used specifically by the system.

The REGISTRY command provides options for importing (sometimes referred to ingesting) and exporting (or saving) all or portions of the Registry. You may wish to save part of the Registry before changes are made to use as a reference in case you need to restore. You might export part of the Registry so you can transport it to another JNIOR and import it there. This offers a form or bulk configuration.

The REGISTRY -S options generates a snapshot. Just as a Snapshot taken with the Support Tool captures the entire status of a JNIOR, the Registry snapshot performs a backup preserving the Registry's state at that moment. The operation is simple to perform:

This action creates a new unique file in the /flash/registry/ folder. The file is in the INI format and is a version of jnior.ini with a timestamp in its name placed in a common location.

A new file is appended to this folder with each use of the REGISTRY -S option. Once the JNIOR has been configured and tested in a particular application, it may be useful to take a snapshot. Obsolete snapshots should be removed from the folder periodically to conserve Flash storage.

If you at some point import a Registry snapshot you would basically overwrite every key. This would revert the keys, including perhaps some necessary changes that were made, to prior settings. Generally this is not desirable. The REGISTRY -F option allows you to save (export) some portion of the Registry. Using this result as later import would serve only to revert that part of the Registry. The following example saves email related content.

Note that the INI Format is used and that the selection filter is also included in the comments. These files can be freely edited as your application may require.

Any file in the Registry INI format may be imported into the Registry. The REGISTRY -I option imports from the specified file. In the following example we see that there are no email keys defined. We then import the previously saved file and finally confirm the presence of the desired content.

Prior to JANOS v2.0 the file is required to have an INI extension. The main requirement is that the content be in the proper INI Format for Registry use. It is important to note that the keys defined in the file are added to the Registry or if the keys previously existed they are updated. This does not remove keys that are not specifically included in the import. If the imported file is intended to replace the whole section then it must be edited to remove (by assigning to an empty string) keys that are to be eliminated.

Applications can be installed and uninstalled but those are operations best performed by a Support Tool Update Project or possibly a local script. When applications are removed from the JNIOR their configuration data should also be removed from the Registry. The Update Project or local script can use the REGISTRY -DA options to perform the removal. The REGISTRY -U option can also be used to remove all of the keys specified by the referenced INI file.

In the following example we see that we have imported the email keys successfully in the prior example. Now we reverse the operation using REGISTRY -U and confirm that those keys are removed.

This removal process does not restore keys to any prior value. The keys are just removed. If an INI file is inappropriately imported, restoration would only be possible if a snapshot (using REGISTRY -S) had been recently performed. A prior copy of /flash/jnior.ini may be found in an earlier Support Tool Snapshot. If either is available the affected keys may be copied from that INI file into another which then can be imported to restore earlier settings. It is not a bad idea that before any major Registry alteration is attempted that you take a snapshot.

The concept is simple. If you are going to be adjusting configuration on an experimental basis or otherwise it is a good idea to take a snapshot first. Use the REGISTRY -S command to set aside a copy of the Registry for later use should you need to undo what you have done. If not much time has passed and you are certain that no other necessary configuration changes have been made, you can import that snapshot file and restore settings. An important point is that if you have added keys that were not there at the time of the snapshot the import will not remove those. In this case you may have to refer to the syslog in jniorsys.log to identify new keys that may need to be manually deleted.

On a more limited basis, consider exporting the section of the Registry involved in the planned changes. If you are going to reconfigure email for example, save the existing email setup. Later if you need to undo your changes then you know that you can safely use the REGISTRY -D option to remove the section before importing from the saved copy. This will both restore any previous settings and have removed anything new that may have been added. It is not recommended to try to remove the entire Registry before importing a snapshot.

The REGISTRY commands can be used within a batch file. Files with a BAT extension can be executed from the command line. Each line in such a file contains a new command. Such a batch file can be used to execute a series of REGISTRY commands. Consider the following file:

Here the first command removes prior content (if any) from the Email section (also referred to as a node). The subsequent commands add back the Registry keys pertinent to our configuration. The batch file can be run by simply entering its name. Let's do that here:

In this case the Email section was empty to start. The BAT executes each command leaving us with the desired result.

The REGISTRY -B option is designed to support this usage. Below we list some Regsitry keys but include the -B option in the command. Note that the result could be useful in a batch file.

To make this useful we must pipe the output into a file. Here we will create the Email batch file:

The resulting file can be edited to include the REGISTRY -DA command as we had originally. This batch approach works well with everything except passwords. Passwords do not display. Instead a series of asterisks appear. The passwords are included in the INI file as an encrypted digest and from there they can be restored only to the original JNIOR. Each JNIOR has its own encryption key protecting password storage. Sets of REGISTRY commands can be appended to the batch file by using the '>>' append piping.

A Registry key identifies a specific value. The key has a structure much as does a path to a file in the File System. In a similar fashion we use the forward-slash '/' separator to delineate Registry Sections, Nodes, and Names. A key belongs to one Section; It can optionally include Nodes; And, it must have a Name. An example with two Nodes looks like this:

The Value is always a string. It may contain a numeric values, boolean conditions, or simply some text.

Each Registry key should be assigned to a Section. Sections organize keys based up their function. There are a number of built-in sections. An application should define its own section perhaps based upon the name of the application. The following lists the sections currently known to the system.

In proper usage every key is assigned to a Section. If the Section is omitted and a key has only a Name it is stored in the Registry Root. The Root normally should be used only for Dynamic Keys which will be described shortly. Applications are free to create sections as might be appropriate for their purpose.

The parts of a Registry key that are neither Section nor Name are Nodes. A node is an optional part of the key. Many keys use no nodes at all. Nodes are most prevalent in the IO section of the Registry.

The JNIOR has both "Inputs" and "Outputs". It is not surprising then that the first Node encountered in the IO section would be either Inputs or Outputs forming a division based on I/O direction. At this point keys may exist that configure the input or output function generally.

Another Node can appear following the input or output Node. This node defines the specific input or output of the device. On the JNIOR the inputs are referred to as "Digital Inputs" and the associated nodes named din1, din2, din3, and so on. The Model 410 has 8 digital inputs where the Model 414 has 12 inputs and the Model 412 has only 4. Similarly, the JNIOR outputs are relays and are therefore rout1, rout2, rout3, ... and so forth. The Model 410 has 8 relay outputs where the Model 412 has 12 and the Model 414 has only 4.

These input and output nodes specific to channels or points can be extended when external modules are connected.

The rightmost part of the Registry key is the Name. Every Registry key has a Name as it does also have a Value. These are Name-Value pairs after all. A key with no value does not exist. In this case, should the key be queried for a value, a default may be returned.

Some naming standard is appropriate here. Registry names should only include uppercase characters (A-Z), lowercase characters (a-z), and numbers (0-9). While the system will accommodate other characters they serve only to complicate the keys. These names should be easily remembered and a consistent formatting will help.

The dash '-' or underscore '_' should be avoided as word separators. Instead use case to produce readable key names. For instance HourMeter for hour meter values. Or, for another example, SyslogServer when defining an external server to receive system log (syslog) messages.

Since the forward slash '/' is considered a separator in cannot be used in a name. The dollar sign '$' is reserved. It may only used as the first character of a Name and not at all to define Sections or Nodes. Its use will be described below. No other punctuation should be used. Keep names simple and obvious.

Many keys are used to enable or disable some function. These have a logical on/off kind of purpose. JNIOR writes these values as “enabled” meaning "on" or “disabled” meaning "off". The following content will all result in an enabled key:

All other content will be considered “off” or disabled. Typically these would appear as follows:

All Registry values are stored as character strings. While numeric values can be represented in a string, care must be taken to use proper numerical format and to avoid any extraneous characters. A numeric value will later be converted when used. A format error at that point may not lead to the desired result. The application may throw an exception or, perhaps worse, run on using an incorrect value.

There is no numeric validation upon entry. The Registry system does not know that a key is to be numeric. In fact with any Registry key the system does not know, nor care about, its eventual use when it is defined or edited. Numeric values should be entered using standard formats for integers, fixed point decimal values, and floating point numbers of any sign or magnitude. Leading and trailing spaces will be ignored.

Any Registry key name that begins with the ‘$’ character is considered to be a Dynamic Key which is a temporary entry. These keys are not saved to any .INI file or logged. They are not guaranteed to persist through a system reset or reboot. The dollar sign '$' should not be used at any other place in a name or in defining registry sections and nodes.

Certain Dynamic Keys are defined during boot and therefore appear to always be present. These are typically system parameters as documented in the following section. Other Dynamic Keys are created by the system to provide access to frequently changing data. An example of this are the $HourMeter keys which provide usage information such as the amount of time that a particular input is active.

The value of a Dynamic Key may be altered very frequently with no impact on system performance. Changes in non-dynamic keys signal an update to the /flash/jnior.ini backup file. That file is preserved in Flash and updates to the file take time. System performance overall can by impacted. Flash memory also exhibits wear and such use could shorten product life. A Dynamic Key should be used when a value must be made available that either will change frequently or that need not be saved or logged. It is recommend that the update rates still be kept within reason. Processor resources are limited.

Applications can use dynamic keys as a form of inter-process communications. While there are other means available for applications to communicate, one application could set a dynamic key to change the way another performs.

Dynamic keys can be used for debugging and status. An application could set dynamic keys for indicating state and the current values for various variables. If grouped in a specific Section, the user can easily view the values dynamically in the Registry tab of the WebUI. The values displayed change dynamically as the Registry is updated. This can creates a quick and simple debug console.

The following dynamic keys are generated during boot and do not appear in the /flash/jnior.ini file. These are OS related system keys.

This returns a string representing the time according to the JNIOR clock at the completion of the latest power-up boot sequence.

This returns the product serial number as a String. For example: “612080001”

This returns the current Version string for the product release. For example: “v2.0”

This returns a tag uniquely defining the current OS build. These tags will increase with each new build and can be numerically compared.

This returns the last time the system clock was successfully updated from the network using the NTP protocol. For example: “Fri May 12 12:57:51 EDT 2017”

From the beginning every computer system needed a mechanism for non-volatile configuration. A text file consisting of text lines each with one key-value pair soon became the prevalent approach. This proved more manageable and understandable than any text arrangement where settings are in a specific order or position. This configuration file would be organized into sections both to improve readability and to save storage space. This became the INI text file format. It is still used today in most systems and with many applications.

A copy of the JANOS Registry is maintained in the /flash/jnior.ini file as a backup. The Registry itself is resident in memory but in the rare instance where memory might be reset the content can be restored from this backup copy. This is in contrast to the Series 3 JNIOR where the INI file represented the only non-volatile copy of configuration.

The INI file format is standard. It uses Section headings enclosed by ‘[‘ and ‘]’ square brackets. Each section is associated with a specific Node. That is that the section is defined by that portion of the Registry key not associated with its Name (excluding trailing '/' separator). Note that Registry keys are absolute and define the entire key from the Root. A leading forward-slash '/' is optional except when referencing the Root itself where the section heading needs to be [/]. Each section can include 0 or more name-value pairs one per line until a new section heading is encountered. Blank lines are ignored.

Each line in the section starts with the key Name. This is followed by space-equals-space " = ". The balance of the line defines the Value. There is no need for double-quotes even if there are spaces in the value but their use is allowed.

Comments may appear in the INI file. Any text on any line following the ‘;’ semicolon character is considered to be commentary (including the semicolon). In general, leading and trailing white space (one or more spaces or tabs) is ignored.

The following Registry keys are coded into JANOS firmware. These are used for general product configuration. The Registry may contain other keys as assigned by the user or application developer. The WebUI defines settings in order to control presentation. Those are covered in a subsequent section.

There are numerous keys affecting the operation of the JNIOR. Those associated with a specific feature are included in sections appropriate to that capability. The following keys are associated with general device configuration.

The entry provides a textual description for this JNIOR. This might be displayed by WebUI or applications as identification. JANOS will include this description as part of the default email signature if it is defined.

Specifies the local Timezone to be used in displaying date and time. The set of available Timezones may be viewed using the DATE -T command. This setting can be easily done using the DATE command followed by the appropriate Timezone abbreviation.

Specifies the action to be taken when the RESET switch is triggered. The JNIOR provides access to a 2-pin connector for an external Reset Switch. When a reset switch is momentarily activated (pins connected together) the command line command detailed by this Registry key is executed. By default this forces a reboot using the REBOOT -F command and performing a well-behaved controlled restart. Any command may be executed and it need not result in a restart. Note that this reset switch is also used to enter SAFE MODE when it is held through a reboot.

Any number of custom Timezones may be defined or overwritten using the keys in this Registry node.

The clock subsystem is generally configured using the DATE command. JANOS defines a set of Timezones for use in displaying local time. These timezones may or may not utilize Daylight Savings Time (DST).

As there are 24 hours on our clock one might expect that there needs to be only 24 timezones. This is not the case as some areas offset their clocks by just 30 minutes and some areas utilize DST. The following is the default set of timezones with DST rules. This can be displayed using the DATE -T command.

The rules for DST may change from time to time as governments alter their policies. This default list of timezones will likely become incorrect at some point. INTEG encourages users to let us know when corrections to the timezone tables are needed. Meanwhile, JANOS provides a means by which you may define a custom timezone with or without a DST rule. You may even correct an existing timezone. This is accomplished using one or more of the following Registry entries.

The following key format is used to create a new timezone or overwrite an existing timezone. Note that timezones are identified by their standard abbreviation (AbbStd). The timezone for Eastern Standard Time is identified as "EST". In fact, since the default definition of this timezone includes a Daylight Savings Time (DST) rule, the DATE command can also select this timezone using the DST abbreviation "EDT". The <name> portion of the key is arbitrary and serves only to differentiate the key from others. When entering these keys utilize a name relevant to their purpose.

The definition or redefinition of a timezone is straight forward however the specification of the DST rule can be a bit more confusing. The following 13 parameters may be required to get the job done.

<offset>
The offset in minutes from UTC specified in military time in the format HHMM. For example -0500 subtracts 5 hours from UTC. The value 0630 adds six and a half hours to UTC.

<desc>
Supplies a textual description of the timezone. For instance "Universal Coordinated" for UTC.

<AbbStd>
Defines the standard abbreviation for the timezone. This is the identifier that is used with the date and time to specify the current timezone. It is used by the DATE command in setting the current timezone. If this matches an existing timezone the built-in definition will be overwritten. Otherwise a new timezone will be created. This allows you to correct a default timezone should that be needed.

<AbbDst>
Defines an alternate abbreviation for the timezone. This is the identifier that is used with the date and time to specify the current timezone when Daylight Savings Time is in effect. It can be used by the DATE command in setting the current timezone.

<stMon>
Specifies the starting month for DST. A 3-character abbreviation is used: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, or DEC. This field is not case-sensitive although uppercase is recommended by convention.

<stDay>
Specifies the starting day of the month. This is a numeric value where 1 specifies the first day of the month. If it is necessary to specify a certain number of days before the end of the month, a negative value can be entered. Since DST usually begins (and ends) on a specific day of the week, this value is used to select the correct part of the month for that day.

<stDoW>
Specifies the day of the week on which DST starts. A 3-character abbreviation is used: SUN, MON, TUE, WED, THU, FRI, or SAT. This field is not case-sensitive although uppercase is recommended by convention. This defines the day of the week on or after the starting day. If it is necessary to specify the day of the week on or before the starting day, a negative sign may be prepended to the string (e.g. "-SUN").

<stTime>
Specifies the starting time for DST in military time using the format HHMM. For example 0200 indicates 2 o'clock in the morning. This is the point in time when the clocks are to be adjusted.

<endMon>
Specifies the ending month for DST. A 3-character abbreviation is used: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, or DEC. This field is not case-sensitive although uppercase is recommended by convention.

<endDay>
Specifies the ending day of the month. This is a numeric value where 1 specifies the first day of the month. If it is necessary to specify a certain number of days before the end of the month, a negative value can be supplied.

<endDoW>
Specifies the day of the week on which DST ends. A 3-character abbreviation is used: SUN, MON, TUE, WED, THU, FRI, or SAT. This field is not case-sensitive although uppercase is recommended by convention. This is the day of the week on or after the ending day. If it is necessary to specify the day of the week on or before the ending day, a negative sign may be prepended to the string (e.g. "-SUN").

<endTime>
Specifies the ending time for DST in military time in the format HHMM. For example 0200 indicates 2 o'clock in the morning. This is the point in time when the clocks are to be returned to standard time.

<dstOfs>
This defines in minutes the adjustment that occurs when daylight savings time is in effect. Typically this value is 60 indicating that the clocks move ahead an hour for DST.

There are two forms to the key. The simple form requires only the first 3 fields. This defines a timezone that does not use DST. The full format requires 13 fields where the additional entries outline the use of DST in that timezone. The DST definition provides an additional abbreviation, specifies start and end timing, and defines the time offset.

For example, the following Registry command makes an entry that redefines the Eastern Timezone in the United States with an ego-centric description for those of us in Pittsburgh Pennsylvania.

This would not be exactly correct as the EST timezone observes Daylight Savings Time. We need to also include the rule.

And perhaps instead of redefining EST we would prefer to create our own timezone, the entry would change as follows. Note that only the AbbStd need be changed but we alter the AbbDst to be consistent.

These Registry keys are interpreted, and therefore take effect, on boot. The new or modified timezones will appear in the table produced by the DATE -T command. The JNIOR may then be switched to the new timezone which will remain in existence until the Registry key is removed or altered. Note that when time is reported to external systems, a custom timezone may not be recognized if its abbreviation is not common and known to the rest of the world.

A Timezone key will be ignored if it contains a syntax or value error. These errors will be reported to the System Log (syslog) and the file jniorsys.log.

Programs may be initialized and run at boot. Such programs may be developed to handle custom capabilities that would not normally be part of JANOS. The development of these programs is not all that difficult but this is beyond the scope of this document. Contact support at INTEG for further information.

During the boot process JANOS will scan this section of the Registry and attempt to execute programs identified here. The <program> group name is arbitrary and each entry specifies a command line entry identifying the program and any arguments that it may require. For example:

JANOS would execute the program BootStuff as a background process provided that the program file can be located in the file system. The parameters shown would be passed to the program for its use. This key follows the command line syntax. The order in the which the Run keys are processed may vary and cannot be guaranteed.

The program file must be located either in the File System root or in the /flash folder. The program file must either be a JAR file (executable Java program) or a BAT file (batch command file). The system will take the appropriate action in processing the request. Note that virtually any valid command line statement may be executed here.

Only the keys defined in this Registry section regardless of Name will be executed. Any node substructure is ignored. Programs can be enabled or disabled from the Application tab of the WebUI. This uses information registered in the Applications Section to add or remove (respectively) the associated Run key. On boot JANOS searches JAR files in the command search path for a files named AppInfo.ini. These INI files are automatically imported during application registration. For more information contact support at INTEG.

Each program instance has its own environment. This is very similar to a Registry node but unique to each specific process. The program environment contains parameters such as CMDWORKING which defines the current working directory. This is updated when using the CD command at the command line. The Environment may contain an ERRORLEVEL value which is an integer returned by the previous command/program (0 indicating success).

Parameters defined in this Registry section are considered to be default environment values and will appear initially in every environment. From the command line the environment may be listed and modified using the SET command. Applications have programmatic access to the environment and can modify it. So an application can add parameters to the Environment that a subsequent command may access. You can define parameters using the SET command that may modify what an application does when executed.

The following keys work in conjunction with IPCONFIG and HOSTNAME commands in network configuration.

Beginning with the release of JANOS v2.0, JNIORs are shipped with DHCP enabled. Units manufactured prior to this were shipped configured for a 10.0.0.201 IP address. That address was likely not compatible with the customer's network. In general the Support Tool can be used to access an improperly configured unit provided that the unit is on the same network subnet as the personal computer.

A JNIOR with DHCP enabled will pick up a temporary IP address from the DHCP server if available on the network. This would insure that the JNIOR is at least configured compatible with the network. At that point you may be able to reach the unit's WebUI by entering the URL http://jrNNNNNNNNN where the numeric serial number (from the back of the JNIOR) is used. Allow the JNIOR 20-30 seconds after boot to register its hostname with the network.

A JNIOR typically will require that fixed IP addressing be defined using the IPCONFIG command. This registry key may be used to enable DHCP allowing the JNIOR to lease an IP address during boot from the local DHCP server. It is recommended that DHCP be enabled using the IPCONFIG -D command instead of manually through the Registry.

This defines a fixed network IP Address to be used with this JNIOR. The address may be defined using this Registry key or by using the IPCONFIG command. The Registry change takes effect on reboot. Use IPCONFIG to make immediate changes. This key is ignored when DHCP is enabled. Note that the JANOS network stack is designed to maintain connections established with the old IP address when new IP addressing is defined. This is in contrast with other systems and can help reduce the risk of the loss of communications when altering network configuration.

The JNIOR queries for IP address conflicts when establishing its address. If another device responds to the IP address defined here, the unit will log the issue and temporarily adopt an IP address of 0.0.0.0. If the conflicting device is not removed, the JNIOR can be reconfigured through the Beacon tab of the Support Tool or by serial connection to the RS-232 (COM) port.

This defines the network Subnet Mask to be used with this JNIOR. The mask may be defined through changes to this Registry key or by using the IPCONFIG command. Changes take effect on reboot. Use IPCONFIG to make immediate changes. This key is ignored when DHCP is enabled.

This defines the network Gateway IP Address. This address is only required if JNIOR is to communicate outside its home network. This would be the case if JNIOR is to synchronize its clock with an external time server (see IpConfig/NTPServer). Changes take effect on reboot. Use IPCONFIG to make immediate changes. This key is ignored when DHCP is enabled.

This defines the Primary DNS Address used for name resolution on the network. This would be required if JNIOR is to synchronize its clock with an external time server as DNS is used to resolve “clock.isc.org” into the appropriate IP Address for communication (see IpConfig/NTPServer). Changes take effect on reboot. Use IPCONFIG to make immediate changes. This key is ignored when DHCP is enabled.

This defines the Secondary DNS Address used for name resolution on the network should the Primary DNS not be available. Changes take effect on reboot. Use IPCONFIG to make immediate changes. This key is ignored when DHCP is enabled.

This defines a Hostname for the device. This appears in several places. It will be listed as identification in the Beacon tab of the Support Tool. It is used as the command line console prompt. The name may be used in a URL to access the JNIOR if it is on the local network. It is noted in the default signature when emails are sent.

JANOS allows the Hostname to be defined as just about anything. However, it is recommended that it not exceed 15 characters in length and use only alphanumeric characters. You can use underscore '_' and dash '-' if necessary. These limitations allow the hostname to be properly used to access the unit over the network (NetBios). With JANOS v2.0 and later the default Hostname will always be available for network access in addition to any alternative defined by this key. A short name is also best for the command line prompt.

Defines the Domain Name associated with the local network. In general you can usually leave this as the default. It is supplied with email transfers. You may need to use a valid domain in order to satisfy requirements for passing spam filters.

This specifies the address of the SMTP Mail Server that accepts email from the defined email account. This must be specified if JNIOR is going to send email messages. Changes take effect on reboot. Use IPCONFIG to make immediate changes.

Specifies the Username required for SMTP Authentication. This may or may not include the domain as this depends on the requirements of the particular server. SMTP Authentication is used ONLY when a MailHost is defined and when both the Username and Password keys are valid.

The user name must be entered through the WebUI or by the IPCONFIG command. Upon entering or re-entering the user name a password will be requested and confirmed. The password must be encrypted by the system before it is saved. This cannot be done manually.

This key specifies the Password required for SMTP Authentication. The password is encrypted in the Registry and is not displayed by the JNIOR. The login credentials must be entered using the WebUI or IPCONFIG command by first entering the IpConfig/Username. Each JNIOR has its own unique encryption key and therefore passwords cannot be copied through INI file transfer. SMTP Authentication is used ONLY when a MailHost is defined and when both the Username and Password keys are valid.

Specifies the email address used for sending email. This email address should be valid and the one associated with the email account having the defined username and password. This address appears as the sender in most communications. It is also placed in SSL certificates to refer to the device Owner.

This defines the timeout in milliseconds to be used in waiting for a response from configured DNS servers.

JNIOR can synchronize with a network time server supporting Network Time Protocol (NTP). To utilize this capability JNIOR must be properly configured for a network with access to an NTP server. The NTPServer key defines the server using either a domain name or an IP address. An optional parameter may be used to define an alternate port. The format is as follows:

A typical ServerAddress is time.nist.gov or ntp.pool.org although you may define a local NTP server. The standard NTP port number is 123. You may optionally specify a custom port number following the ServerAddress separated by a comma.

Only one server can be specified. If that server is not available then the synchronization will be bypassed. Note that the clock is maintained by a battery during periods without power. Synchronization is not required but useful periodically as the clock will drift in accuracy over long periods. Typical computer hardware clocks (PCs for instance) typically drift by several seconds per day. NTP synchronization is critical in maintaining accurate time.

Time synchronization occurs during boot. Synchronization is attempted every four hours by default to maintain clock alignment. JNIOR may also be commanded to synchronize using the DATE -N command in the Command Console.

JNIOR attempts to synchronize with a network time server every 4 hours (240 minutes) by default. The update period may be adjusted through this Registry key. This defines the period in minutes and can be set for any amount of time 5 minutes or longer. To disable NTP synchronization you can set this key to 0. This configuration setting takes effect on boot.

This Registry key defines the maximum size of packets transmitted over the Ethernet port. The Maximum Segment Size (MSS) is defined as MTU - 40 (40 bytes less than the MTU setting) and no packet will be transmitted with a payload exceeding this size. Regardless of the MTU setting JNIOR will properly receive packets of any size up to the standard network MTU of 1500. The product ignores Jumbo packets upon their arrival.

Valid MTU settings are 400 to 1500 inclusive. A change in MTU setting applies to all Ethernet connections and takes effect upon reboot.

The IpConfig/TTL Registry key defines the lifespan of a network packet. The time-to-live value is a kind of upper bound on the time that an IP datagram can exist in the Internet system. The value is reduced with the passage through a router. If it reaches 0 the packet is discarded.

The TTL setting can be considered to limit the maximum radius (in terms of hops) of the network within reach of the JNIOR. The default setting should allow packets to reach the far end of the globe. A low setting would limit access to the unit as only those in the local vicinity could communicate with it. In this respect the TTL setting can be used to improve device security.

A very low setting of 1 or 2 would constrain the JNIOR to the immediate network. One must consider the need to reach Doman Name Servers (DNS) and Network Time Servers (NTP). There may also be the requirement for email transfers wherein the JNIOR needs to reach out to a SMTP Server. To help determine the minimum setting you may be able to use your PC's TRACERT command to detect the hop count involved in reaching those destinations. The JNIOR does not support a route tracing function.

This defines the address of a Syslog Server that accepts System Log messages. This may be optionally specified to remotely log system status messages. These are typically the information found in the jniorsys.log file. Changes take effect immediately. The format for the IpConfig/SyslogServer key is as follows:

By default the ServerAddress is not set and no syslog transmissions occur. You can set the ServerAddress through the IPCONFIG -L command syntax. The standard Syslog port number is 514. You may optionally specify a custom port number following the ServerAddress separated by a comma. This must be accomplished through the WebUI or by setting the Registry key directly. If you set the syslog server address using the IPCONFIG command the default port will be used.

Typically syslog postings reflect the jniorsys.log entries. You may post manually to the system log file using the LOGGER command or directly to the syslog server with the LOGGER -R syntax. Applications may also optionally post directly to the syslog server.

JANOS will allow you to configure a broadcast address (255.255.255.255). This may be helpful if you want to support multiple syslog destinations or monitor postings to an existing syslog server.

This is the timeout in seconds before JANOS will probe a connection. By default it is set to 5 minutes (300 seconds). A connection will be probed if there has not been packet traffic from the peer in the configured time period.

If there is no response from a probe JANOS will retry after the configured interval. By default this is 30 seconds.

Specifies the number of keep alive retries attempted. By default JANOS will retry the probe 8 times before closing the connection.

By default socket connections initiated by an application will time out after 5 seconds and generate an IOException. This define the time in milliseconds.

The JNIOR by default allocates 512KB of memory for network capture. If network traffic needs to be analyzed, the NETSTAT –C command is used to generate a PCAPNG capture file which can be downloaded and opened with the Wireshark network protocol analyzer (https://www.wireshark.org). This means that there is always recent network history available for capture. The default 512KB can represent minutes or even hours of network operation depending on the amount of network use. Only packets involving the JNIOR are captured. This packet buffer can be increased using this Registry key and can be set for any number KB between 512 and 8192 (8MB Maximum).

Note that the capture buffer is volatile and records network activity while the unit remains powered. The content survives a reboot but is reset when power is removed. The NETSTAT -R command will also reset the capture buffer. This Registry key setting takes effect only on reboot.

Hint: If the network capture is not covering a long enough period of time, we recommend first using a capture filter to limit the content to pertinent activity (see IpConfig/CaptureFilter) before increasing the buffer. An extremely large PCAPNG file can be difficult to upload and process. Similarly the NETSTAT -C command can include a capture filter moving only those packets of interest to the capture file.

By default the network capture collects packets that specifically reference either the JNIOR’s MAC address or IP address either as the source or destination. This then excludes general broadcasts and any other unrelated network traffic that the unit may see.

If you need to see all of the network traffic set this Registry key to true. This will enable Promiscuous Mode and the capture of all network traffic that reaches the JNIOR. Note that changes in this setting do not require a reboot and take effect immediately.

Network switches and routers generally optimize network traffic and present devices with the subset of communications that are specifically addressed for that destination. In Promiscuous Mode you will generally receive additional broadcast packets and packets addressed to other possibly non-existing devices which the switch or router has yet to locate and filter.

The network hub has been obsoleted by the network switch as traffic and bandwidth optimization is a good thing. However the older technology in the hub may be desirable if you need to analyze communications between two other devices. The hub forwards all network traffic to all interconnected devices. The JNIOR in Promiscuous Mode can then capture packet traffic between the other devices. This may be very useful in debugging larger multi-device systems. If you own a hub you should hang onto it as it can be a useful debugging tool when used as a temporary network switch replacement.

The network traffic can be filtered prior to the capture buffer. This can extend the period over which traffic can be collected by limiting the content to only those connections or communications of interest. The syntax used to define a capture filter utilizes logical operations such as NOT, AND, OR and XOR. The filter can include references to MAC addresses, IP addresses (IPv4), and TCP/IP or UDP port numbers. Matters of operation precedence can be handled through the use of parenthesis groups (See Network Filtering). By default the network capture is not filtered.

In a similar fashion packets can be selected from the network capture buffer in creating the PCAPNG file temp/network.pcapng. The filter syntax is the same. You can therefore use the NETSTAT –C command to prototype and test a packet filter before using it to define the incoming filter.

Once you have constructed a valid filter you can install it ahead of the capture buffer by setting the IpConfig/CaptureFilter Registry key. The filter setting (assuming there are no syntax errors) takes effect immediately and does not require a reboot.

The NETSTAT –F command can also be used to set the incoming filter. This command first verifies the filter syntax and if no errors are found it then sets the Registry key IpConfig/CaptureFilter. This is the preferred method in that it includes the syntax check.

An incoming capture filter is non-volatile and will remain in use. To remove the filter you must either remove the Registry key or issue the NETSTAT –F command without further arguments.

Failed Console login attempts, which are failed Telnet login attempts, are logged to the access.log file. This port is a favored target for those seeking malicious access to a device. The log entry shows the remote IP address attempting entry along with the username. When this Registry key is enabled the password tried is also displayed. It is not recommended that this feature be used at length since a typographic error by a legitimate user might reveal the user's password by logging it. This is useful in determining the source of the activity. Bots repeatedly use a sequence of common passwords from a dictionary. A bad actor familiar with the JNIOR would try default passwords. You may wish to know if someone is specifically trying to attack your JNIOR.

You can access the JNIOR using the unit's hostname. The process required to convert the text name into the IP address needed to locate the JNIOR on the network is called Name Resolution. A computer might utilize a local DNS server or attempt a NetBIOS name query to do this. An alternative is Link-Local Multicast Name Resolution or LLMNR. This has not been adopted as an IETF standard. The JNIOR is capable of performing LLMNR and the feature can be enabled by this Registry key.

LLMNR is disabled by default as some systems currently consider it unsafe. When attempting to resolve a name it may be possible for a malicious system to offer an incorrect IP address and thereby intercept communications. At that point a login might be requested and your credentials stolen.

You can access the JNIOR using the unit's hostname. The process required to convert the text name into the IP address needed to locate the JNIOR on the network is called Name Resolution. Most computers will attempt to utilize NetBIOS in resolving a name. By default the JNIOR supports this method. You may need to specifically enable it on some Linux based machines. This Registry key can be used to disable the NetBIOS service.

NOTE: When DHCP is enabled the assigned IP address may remain the stable for a long time but it is subject to change. Access using the Hostname will avoid loss of connectivity.

The NBTSTAT command displays the current NetBIOS status on the JNIOR. Note that the unit registers the Hostname and the default name which is "jr" combined with the Serial number (jr615010258 for instance). The latter is considered to be the unit's birth name. Only the first 15 alphanumeric characters of the current hostname are used and the default birth name is always available. You can use these names in addition to the IP address to reach the JNIOR.

The content of a network capture can be filtered either on the incoming or outgoing side. Using the same filter syntax the remote clients allowed to interact with the JNIOR can be controlled. These filters can be quite simple or, if needed, much more sophisticated.

The IpConfig/CaptureFilter Registry key may optionally define a filter which is applied to incoming packet data prior to capture. There is limited storage for captured information and by filtering you can extend the capture period and the amount of pertinent information collected.

A filter may also be used in generating the /temp/network.pcap capture file from the capture buffer content using the NETSTAT -C command. Here the filter allows you to extract only pertinent information in order to keep file sizes at a manageable level.

The IpConfig/Allow Registry key may optionally define a filter which is applied to incoming connections. In this case the referenced IP addresses refer to the incoming source IP addresses, those of remote clients. Referenced port numbers refer only to destination ports, those available on the JNIOR.

To filter packets referencing a specific IP address you need only include the IP address in the format “nnn.nnn.nnn.nnn” in the filter string. Any packet that references this IP address either as the source or the destination address will be selected for inclusion. All other packets will be excluded unless covered by some other part of the filter. When filtering remote client connections this specifies a specific IP address to allow. Note that this is dangerously limiting as a restriction on remote clients.

To exclude packets referencing a certain IP address you can prepend an ‘!’ exclamation point to the address like this “!nnn.nnn.nnn.nnn”. All packets that do reference the IP address as either a source or destination address will NOT be selected for inclusion. This can also be written as “NOT nnn.nnn.nnn.nnn”. This may be especially helpful to filter your IP address while debugging communications with other devices. In filtering remote client connections, the NOT syntax is ideal for blocking the client based upon IP address.

Note that an IP address is identified by its format, four decimal values between 0 and 255 separated by the ‘.’ period.

The domain syntax allows you to define a range of IP addresses as would be associated with a netmask. The format is “nnn.nnn.nnn.nnn/mm” where ‘mm’ specifies the number of high order bits that would be in the netmask. For example, “10.0.0.0/24” specifies any IP address in the domain that contains IP addresses 10.0.0.1 through 10.0.0.255 and uses a netmask of “255.255.255.0”. This is useful in selecting only local traffic for instance. It would also be perfect for allowing only clients from a specific network to connect to the unit.

Although less often required you can filter on a specific MAC address. The MAC address is included in the filter string in the format “hh:hh:hh:hh:hh:hh”. This is six hexadecimal values (0-9 a-f) not case-sensitive separated by the ‘:’ colon. For instance most INTEG Series 4 JNIORs have MAC address formatted as “9C:8D:1A:hh:hh:hh” where the lower three bytes are assigned in some sequence.

As with IP addressing, packets with MAC addresses may be excluded by writing the filter as “!hh:hh:hh:hh:hh:hh” or “NOT hh:hh:hh:hh:hh:hh”. Again a MAC address is identified by its format. A MAC address would rarely be appropriate in filtering a remote client however.

A port is specified in the filter string as a decimal value between 1 and 65535 inclusive. No punctuation is required. The capture filter does not distinguish between a TCP or UDP port number. A port may be excluded using the negation “!nnn” or “NOT nnn”. When filtering remote client connections the filter logic can use this to block the client from accessing a specific function by port.

There are standard ports assigned for various functions. The capture filter knows some of them by name. Some may be reconfigured through the Registry. As a convenience the port may be specified using its protocol name. The capture will be filtered on the port as configured at the time the filter is compiled (at boot or upon NETSTAT command). JANOS recognizes these port names where the default values are shown in parentheses: SMTP (25), NTP (123), JNIOR (9200), JMP (9220), FTP (21), HTTP (80), HTTPS (443), TELNET (23), and BEACON (4444). These ports may be excluded using the same negation syntax as previously shown.

The capture filter will also recognize the terms TRUE and FALSE. TRUE indicates that the packet is to be included and FALSE otherwise.

To filter on a single IP address, MAC address or port (or to exclude a single item) the filter need only specify the address or port in the proper format. The following would select the communications involved in an email transfer. If this is used as an incoming filter, only email transactions would be captured. If this is used with NETSTAT –C in generating the PCAPNG file, the file would only include email communications.

Note that filters (and also commands) are not case-sensitive. The forms above will create a PCAPNG file with just outgoing email communications. This assumes that you have not reconfigured the SMTP port. If you have set Email/Port to another port (587 for instance) then the first line will extract your email communications and the second will not. Although the second filter might show an application trying to use the incorrect port.

Filters often need to be slightly more complex in order to include the collection of communications needed. The syntax allows you to specify any number of addresses or ports in any combination using AND, OR and XOR logic. As an alternative you may use the notation && and || for AND or OR respectively.

As an example perhaps you want to filter only email communications with the SERVER whose IP address is 10.0.0.4.

If you want to also include BEACON communications you might write the filter as:

But here you might question the order of precedence of the logical operations. The capture filters do not support an order of precedence but perform the operations from left to right. So this would be calculated as follows:

And this would have done what we had said. If there is some question you can use the parentheses in the filter as shown. The following will create the same subset of packets but would not if we were to exclude the parentheses:

A parentheses grouping can be negated as you would expect. The following will create a capture of all activity EXCEPT email communications with the SERVER.

Finally if we had wanted to mask these email communications from the overall capture buffer we can install this filter using the command:

This would result in the following Registry setting and would filter out matching communications until such time as the filter is removed.

JANOS provides for secure communications over public networks using Transport Layer Security (TLS). This is an implementation of secure communications that replaces previous Secure Sockets Layer (SSL) approaches which have been shown to have vulnerabilities. The overall approach however is still often referred to as “SSL Security”.

Various aspects of the secure communications in JANOS may be configured through the Registry. All of these configuration settings are maintained in the SSL section of the registry.

This Registry key defines filtering to be applied to incoming connection requests. This uses the network capture filter syntax (See Network Filtering). This not only provides for the ability to specify IP addresses that are allowed to connect to the JNIOR but gives you the flexibility to block IP addresses. This includes domain ranges and destination ports. This filter can be used to not only control who can access the unit, it can also be used to define what they can access.

Care must be exercised in setting this key remotely. If the capture filter is improperly defined you may prevent your own access. Doing so will require that you subsequently access the unit through the serial COM port and correct the key through the Command Console.

Controls the ability to make TLS secured connections. When set to FALSE this disables the Secure Web Server on Port 443 (HTTPS); Removes the ability to upgrade a JNIOR Protocol, FTP or Telnet connection to the secured state (disables STARTTLS); And, disables the routine Security Update procedure which otherwise is run to update keys.

The CERTMGR command remains fully functional. Security keys and certificates may still be managed while the ability to make secure connections is disabled. This setting takes effect upon reboot.

When TRUE this forces the use of SSL secured connections. No web services are provided on Port 80 (HTTP). All FTP sessions must be secured through the STARTTLS mechanism. The JNIOR Protocol and Telnet connections will close should data be received before the connections are secured. This setting takes effect upon reboot. It is ignored if SSL/Enabled is set to FALSE.

Access to the JNIOR is password controlled. All protocols provide for a means of login which requires the entry of a username and password. If those connections are not secure (such as standard browser access using HTTP as opposed to HTTPS) then both the username and password may be transferred in clear text. These are easily compromised by the simplest of techniques.

NOTE: To insure security, you MUST be sure that ALL protocols are set to require password authentication. Otherwise, even when SSL secure connections are made anyone will be able to alter and/or control your JNIOR.

Not all protocols that are typically used in the industry provide for a standard means of password authentication. MODBUS is an example of this. The JNIOR does extend these protocols providing such a means but this must be specifically enabled through this Registry and may require changes to the connecting client.

Even with care to use both secure connections and password authentication the JNIOR may be easily compromised if the default user accounts are not removed or given unique strong passwords. Surprisingly a large percentage of JNIORs are left with the default user accounts. A common oversight is to change the password on the 'jnior' administrator account while leaving the secondary 'admin' administrator account active and with default credentials.

NOTE: To insure security, you MUST remove any unused user accounts and change the passwords from their defaults on remaining accounts.

The JNIOR may be supplied with two (2) default administrator accounts ‘jnior’ and ‘admin’, a default 'user' account and a default 'guest' account. The default passwords are simply the usernames. JANOS command line functions provide for user management. Use the PASSWD command to alter passwords from their defaults. Use the USERMOD command to disable unused accounts or the USERDEL command to remove accounts. The USERS command is used to list the defined users.

Users typically rely on the 'jnior' account for administration. It is recommended that you remove the 'admin' account. The Support Tool defaults to the 'jnior' account. The 'guest' account should also be disabled using the USERMOD +D command.

The JNIOR comes with two (2) default Administrator accounts. These are the ‘jnior’ and ‘admin’ accounts whose default passwords are ‘jnior’ and ‘admin’ respectively. This represents a significant security risk if either account is left active with the default password. Users often alter the ‘jnior’ account password but neglect to adjust the ‘admin’ account or vice versa. Periodically JANOS will post a warning to the jniorsys.log file if either default account is determined to still be using the default password.

NOTE: If you do forget your administrator password(s), the SAFE_MODE access procedure may be used to regain control of your JNIOR. You can then assign a new password.

If you are comfortable with the risk and would like to continue to use the default accounts and passwords, you can eliminate the warnings by setting this Registry key to TRUE.

Secure communications require RSA keys. 1024-bit or 2048-bit key lengths are typically used today. Longer keys are usually required to protect highly sensitive information and to increase protection as the computer capacity to break (determine the private key associated with a published public key) increases. The JNIOR control is not intended for use in extremely secure environments and its processing capabilities limit it to a maximum 1024-bit key pair.

As shipped the JNIOR is factory configured with a standard 512-bit key. At some point if SSL remains enabled and the JNIOR is connected to an active network, JANOS will initiate the ‘Security Update’ process. This will generate a unique 1024-bit key replacing the default. This procedure will take an hour or more to complete during which time the JNIOR remains fully functional. This can also be interrupted and restarted as you need.

The RSA Key or key pair is required to establish encrypted communications (SSL/TLS). It is the two-part key, with a private part and a public part, that allows two parties to privately exchange information. The key pair is used in creating a Certificate that not only conveys the public part of the key to others but serves as device authentication. Certificates are digitally signed using the RSA key. By default the JNIOR creates, and self-signs, its own Certificate. The CERTMGR -V command can be used to verify the current RSA Key and Certificate.

As can be seen from this, RSA operations are time-consuming. Security calculations are designed to be so. It is the effort in performing the calculations that makes it extremely difficult for others to attempt to decode the private part of the key. You rely on this. Fortunately, the RSA calculation is performed only once in setting up a secure connection to convey a unique one-time shared secret that the two parties will then use to efficiently encrypt and decrypt their communications.

The CERTMGR command may also be used to install an externally generated RSA key pair. This is limited to a 1024-bit key length. The Security Update process will not overwrite an externally loaded key pair. JANOS can work with keys up to 4096-bit should that be in use by the remote party seeking connection. The CERTMGR command also allows you to install and manage an externally generated Certificate.

A TLS secured communications channel requires both the RSA key pair and a SSL Certificate. The CERTMGR command may be used to install an externally generated and signed SSL Certificate that must be associated with the separately installed RSA key pair. Typically the internally generated key pair and certificate are sufficient.

NOTE: A secure connection to the JNIOR may be flagged by browsers as 'NOT SECURE' or 'UNSAFE'. This is only because the the JNIOR's self-signed Certificate has not been obtained from any of the approved Certificate Authorities. The Certificate may be labeled as 'INVALID'. You may rest assured that the connection is still fully encrypted and 'PRIVATE'.

In the absence of a loaded SSL Certificate, JANOS will generate a self-signed certificate using the current RSA key pair. Registry keys are provided which allow you to customize the information provided in this certificate. Since self-signed certificates are not generally recognized as trusted by browsers, users will be confronted by a standard warning. The information in the certificate may be configured so your users may recognize the device and decide on their own to accept the connection. The default values provide for a fully functional connection.

The CERTMGR command may also be used to export the internally generated Certificate. The resulting file may be imported into your computer's Trusted Certificate Store. With this step the browser, recognizing a now trusted certificate, will show a secured connection using some possibly green symbol such a lock.

This text string defines the Country in which the JNIOR is located. By default this field is not included in the internally generated self-signed certificate.

This text string defines the State in which the JNIOR is located. Generally this is not an abbreviation. By default this field is not included in the internally generated self-signed certificate.

This text string defines the Locality, City or Town. By default this field is not included in the internally generated self-signed certificate.

This text string defines the Organization. By default this is “INTEG Process Group”. This field is included in the internally generated self-signed certificate.

This text string defines the Organizational unit, Division, Department or other. By default this is “JNIOR Controllers”. Here we take the opportunity to identify the device. This field is included in the internally generated self-signed certificate.

This text string defines the Common Name or FQDN. For the proper operation of the web site this should reflect the domain in the URL used to reach the JNIOR. For example if one uses http://10.0.0.60 to open the JNIOR at IP address 10.0.0.60 then the CN should be “10.0.0.60”. JANOS by default will set this reflect the current hostname.

Since in addition to the hostname you may address your JNIOR using its IP address or default hostname ('jr' with serial number), the certificate must be made a bit more general. This is accomplished by including the Subject Alternate Name extension. This extension adds the IP address (both in binary and text forms), the hostname, and the default hostname ('jr' with serial number) to every certificate.

Certificates are expected to be created for specific domains and should match the URL used to access the unit. The Common Name or FQDN is by default defined to be the hostname for the JNIOR. Additional identities are included in every certificate. This is accomplished using the Subject Alternate Name extension. This extension adds the IP address (both in binary and text forms), the hostname (if not the defined Common Name), and the default hostname ('jr' with serial number) to every certificate.

If you also want to access the unit using different domain names you can add additional DNS names using this Registry key. One or more names may be added using comma (,) separated list. These will also appear in the Subject Alternative Name extension. Note that you will need to regenerate your certificate if you make changes to SSL/Cert keys. Use the CERTMGR –C command in the JANOS Console.

This text string defines the contact email address. By default this will use the email address defined by IpConfig/EmailAddress. If neither key defines an email address then this field is omitted from the internally generated certificate.

This integer defines the length in days of the period during which the certificate is considered valid. This starts on the date when the certificate is generated or regenerated. By default this is 730 days (2 years). As expiration draws near an internally generated certificate will be automatically renewed for an additional period.

NOTE: An internally generated Certificate is regenerated automatically when it expires, the hostname is changed, or the unit's IP address changes.

If you export the certificate to install in a Trusted Certificate Store, you will need to repeat that procedure when the certificate renews. You may elect to use a much longer period with this Registry key.

The SHA1 cryptographic hash function is no longer considered to be secure. It remains secure for most of the world but those with sufficient resources are assumed now to be capable of breaking it. The JNIOR now uses the SHA256 algorithm (SHA2) as do most of the systems operating around the world. You can disable use of SHA2 if you need to communicate securely with legacy systems or systems that have not yet been upgraded. This is achieved by setting this key to true.

As with most of the settings in this category, changes take effect when the certificate is regenerated.

There are various events which occur during the operation of JNIOR. Some are normal occurrences and others not so normal. JANOS can be configured to perform certain actions when these events occur. The following Registry keys define how JANOS is to respond to such events.

JNIOR monitors events and responds to certain situations depending on the configuration established by the Registry. JNIOR also can generate an audit trail of events and otherwise routinely log changes in data. By default these services are available.

NOTE: Application program startup at boot and email notifications are considered to be EVENTS and are affected by this Registry key. It is recommended that individual events be disabled if necessary as opposed to this setting.

This Registry key can be used to completely disable all such services. A setting of disabled will stop processing without affecting the event configuration. This key takes effect immediately in some cases and a reboot generally stops all services.

This key can be used to globally enable or disable the activities performed at startup (boot). If set to disabled this will globally disable the OnBoot actions. This includes the running of applications defined by Run keys and the boot email notification.

When enabled this instructs JNIOR to send an Email Notification on Boot. This requires that the JNIOR be properly configured for the network with access to an SMTP Email Server. The IpConfig/MailHost must be configured defining that Email Server. The correct username and password for logging into the Email Server must have been set using either the WebUI or IPCONFIG command. The account owner's Email Address must be properly defined by the IpConfig/EmailAddress key. The email capability can be tested from the command line using the SENDMAIL command.

The Boot Notification email can be fully customized. The default message is relatively simple and conveys important system information. This is configured to send the notification to the account owner. The Subject is "Boot Notification" referencing also the JNIOR's Hostname.

NOTE: Beginning with JANOS v2.0 the boot log includes additional information previously only provided over the diagnostic (serial RS-232 COM) port.

The message indicates that the JNIOR has completed booting. The text includes the content of the jniorboot.log file. The current jniorsys.log file is also attached. All of this is very helpful should the reboot come as a surprise.

This key specifies a node in the Registry Email/ section that defines a custom email message. When this key is undefined the Boot Notification email is sent using the default message definition. A custom or named message might optionally be defined using a named block.

Various keys define the recipients, subject, message detail, and attachments. While when appearing in the Email section these define a default, each can be placed in a named block (node) creating a unique email designed for a specific use. The block name is arbitrary but logically should relate to the email's use. The details involved in designing an email are describe in a subsequent section.

During boot applications defined by Run keys are started. Janos is a multi-tasking system and multiple programs can be running simultaneously. This Registry key can be used to temporarily disable program startup on boot.

NOTE: Programs will also not be started if the JNIOR is in SAFE MODE. If an application is responsible for a reboot loop, SAFE MODE may be required to regain control of the unit.

You may want to work with your JNIOR without the added complication of background programs. The PS command can be used to display running processes. The KILL command can be used to stop processes. This Registry key can be used to prevent programs from running in the first place without a need to remove the associated Run keys.

This Registry key can be used to disable all alarm based events. By default the alarm based events are enabled by their individual keys. This provides a global means by which alarm events can be disabled.

This Registry key can be used to disable the Digital Input Counter alarm Type 1 services. These alarms are individually enabled through the IO/inputs/din##/Alarm1 keys where ## specifies the input.

This Registry key can be used to disable the Digital Input Counter alarm Type 2 services. These alarms are individually enabled through the IO/inputs/din##/Alarm2 keys where ## specifies the input.

This Registry key can be used to disable Usage Alarm services. These alarms are individually enabled through the individual IO/Inputs/din##/Usage/OnAlarm and IO/Outputs/rout##/Usage/OnAlarm keys where ## specifies the input or output.

An event occurs when the JNIOR updates the /flash/jnior.ini file in response to changes in the Registry. By default this key enables configuration events.

When settings have been altered in the Registry the /flash/jnior.ini file will be updated. This Registry key can be used to configure the JNIOR to send a Configuration Change Notification email.

When the Configuration Change Notification is enabled the detailed email is described by the settings in the email block defined by this Registry key. By default the block is named "onConfig" although any other block may be used. The details of email design are covered in the following section.

JANOS can send email messages in response to certain events. Any number of unique Email messages can be defined for use as the situation requires. A generic (not situation specific) Email is defined by the following keys. A unique Email construct can be defined and assigned to unique Registry sections or email blocks. These may be separately referenced and used as needed. To create a situation specific email message replace <block> with a unique message identifier in those keys where it appears.

This defines one or more destination email addresses of the form user@domain.com. Multiple addresses are separated by commas.

This defines one or more destination email addresses of the form user@domain.com. Multiple addresses are separated by commas. These addresses will receive the defined message as a CC: recipient.

This defines one or more destination email addresses of the form user@domain.com. Multiple addresses are separated by commas. These addresses will receive the defined message as a BCC: blind recipient.

This defines the Subject line to be used with the message. JNIOR requires that a Subject be defined for all messages although this is not strictly a requirement for email itself. If the Subject key is not given, JNIOR will utilize a default Subject as appropriate to the purpose of the email.

This defines message content to be sent in the email. JNIOR does not require that message content be supplied. This may be used in conjunction with a Message File and the text defined here will appear as a prefix to the content of the file. A default message is used with event notifications.

This defines the file that contains textual Message content to be included in the email. If separate Message text is supplied the content of this file will be appended to that text in the message. For example, the jniorboot.log text file is supplied in the text of the default Boot Notification email.

This lists one or more files to be sent as attachments with the email message. Each file specification is to be separated by a ‘;’ semicolon. For example, the jniorsys.log file is attached to the default Boot Notification email. Attachments may be of any type although some email servers will not accept certain types of attachments.

By default the JNIOR includes a signature line in all emails indicating the model and serial number of the sending unit. The version of JANOS is also included. You may provide a custom signature line overriding the default using this registry entry.

There may be difficulties in delivering an email. By default after an attempt has failed JNIOR will reschedule the delivery of the message. Failures on an initial attempt are typical these days as servers are implementing grey-listing techniques to reduce the amount of unsolicited spam email. In general the Internet is a lossy network and retries are not unusual. Set RetryCount to 0 or 1 to disable retrying.

After a failed email delivery attempt JNIOR will reschedule another delivery at a later time. This key defines the delay period in minutes. Email servers implementing grey-listing my routinely reject initial deliveries. These techniques are designed to cause spammers some difficulty and help to cut down the amount of unsolicited email. The JNIOR should be set to attempt repeated deliveries for at least a couple of hours to increase chances of success.

The Simple Mail Transfer Protocol (SMTP) is used for email delivery. This key may be used to specify a port as may be required by your MailHost. Note that the MailHost and any associated SMTP Authentication settings (Username and Password) are set by the IPCONFIG command.

NOTE: By default JANOS will utilize the STARTTLS capability if offered. The Email/StartTLS Registry key must be enabled.

Port 25 is the standard SMTP port for mail delivery. This port may or may not require authentication (SMTP_AUTH). It may or may not support STARTTLS allowing for the encrypted transfer of content. JANOS will use SMTP_AUTH by default and if STARTTLS is supported will make the secure connection.

Port 587 is the Mail Submission Agent (MSA) port which requires authentication (SMTP_AUTH). This port may also support STARTTLS. If STARTTLS is supported (and generally it is) JANOS will establish an encrypted connection and transfer content securely.

Port 465 is the SMTPS port. This is like the MSA port in that it requires authentication before mail can be submitted. It also requires that a SSL/TLS encrypted connection be established initially. The STARTTLS option is not used. For JANOS to properly transfer mail using this port the Email/SMTPS Registry key must be enabled.

Note that JANOS can successfully post email using any of the above three ports. Generally the email content will be transferred securely using an encrypted connection. That assumes the availability of the STARTTLS option. But if you need to be absolutely certain of a secure transfer, use port 465 and enable the Email/SMTPS key.

Email deliveries that initially begin with a clear text non-encrypted connection are upgraded to secure using the STARTTLS option (when offered). This Registry key should remain enabled to insure proper security. This key can be used to disable SSL/TLS use for email delivery. You should only do so if there are issues with secure connections.

Port 465 can be used for email submission. This uses SMTPS which is essentially SMTP with authentication using SMTP_AUTH. The port also requires an initial SSL/TLS connection. In order for JANOS to know to make that initial secure connection you must set this key to enabled. This should be disabled for email delivery over ports 25 and 587. For either of these ports the Email/StartTLS key should be enabled.

This key is to be enabled when an email is properly designed using HTML structure and content.

The following configuration settings control the WebServer WWW interface to JNIOR. The WebServer simultaneously supports multiple secure connections and Websockets (JMP Protocol).

This Registry key can be used to disable the HTTP Server. This may be desirable if communications with JNIOR will be through some other means and connections to the JNIOR HTTP Port are to be ignored. Note that the WebUI is accessed using the WebServer and your browser. A reboot is required when enabling or disabling the WebServer.

This specifies the TCP/IP port to use for HTTP services. The default is the standard Port 80.

This specifies the TCP/IP port to use for HTTPS secure connections using TLS/SSL. The default is the standard Port 443.

This specifies the folder within the JNIOR file system that represents the root of the website. This is the folder that would contain the unit’s home page and related pages would be located in this folder or in subfolders. The default is /flash/www. This folder must be specified from the root of the file system (starting with a ‘/’), The trailing ‘/’ is optional.

NOTE: Files required for a website may be located in folders under the root or may be completely contained within a ZIP library file with a name creating a virtual folder.

A website located in the root of the WebServer will require a login if WebServer/Login is enabled (default). If the JNIOR is to serve a public site then the index page or home page should be located in the /flash/public folder. This does not require a change to this Registry key. This provides the ability to have a public site while still requiring login for the WebUI. The WebUI being located in /flash/www/config.zip.

This specifies the name of the website’s home page. This is the document that would served if a file is not specified in the URL. Multiple files may be specified separated by a semicolon ';'. The search is from left to right so the files are in priority order. The defaults of index.php and index.html are always included in the search as they are automatically appended to the content of this key.

This is used to specify alternate search paths for web content. The JNIOR first searches the root of the WebServer for the requested page. If the page is not located then each path defined in this key will be searched in sequence. Paths must be specified from the root of the file system starting with a ‘/’ and the trailing ‘/’ is optional. Multiple paths must be separated by a semicolon ‘;’.

Note that the default WebUI is supplied completely enclosed in a single library file named /flash/www/config.zip. A ZIP file creates a virtual folder from which pages may be served. The default for this Registry key is /flash/www/config creating a path to the WebUI. In the absence of a custom website the WebServer looks next to the path specified by this key. With the default it looks for the home page in the folder /flash/www/config and that folder does not exist. Instead it finds the virtual folder created by the ZIP file and in that library it locates a suitable home page. That home page serves the JNIOR WebUI.

By default the Web Server requires a successful login. This is highly recommended. If the JNIOR is connected to a private secure network this login requirement can be removed by setting this Registry key to disabled. When Login is disabled you must also define a user account for anonymous login using the WebServer/Anonymous Registry key. These changes take effect immediately. You will not be logged out of your current session. Note that login may still be required if folder or file permissions are restricted (See CHMOD console command). By default initially all users have access to all folders and files.

If the Login requirement is removed using the WebServer/Login key a user account must be defined for the JNIOR to use. This Registry key must be set to a valid active user account with the entry of either a UserID or Username. With the default set of user accounts, you would set this key to jnior for example. Note that if the anonymous account is invalid or disabled the JNIOR will continue to request login credentials.

The WebServer provides the ability to upgrade a connection to support the Websockets Protocol. JANOS supplies a built-in Websocket interface that supports the JANOS Management Protocol (JMP). This can replace all of the functionality of the legacy JNIOR Protocol while providing much more capability. In addition, application programs can be created as custom Websocket servers.

The Websocket interface fully supports administrative management and data monitoring functions. It requires a successful login. When this service is accessed through a local website served by the WebServer the login credentials used to access the web pages are applied automatically to the Websocket interface. If you have disabled the WebServer login you will need to support the Websockets login or otherwise set this key to disabled. This is not recommended as anyone can then do anything with the JNIOR.

Defines the user name or ID for anonymous logins. When a Websocket connection requires a login (default) the login must reference a defined username using the correct password for that account. In order to accommodate a scheme whereby data monitoring would not require login but control or configuration would, JANOS allows for anonymous login. When the Websocket/Anonymous key is defined (exists) and the Websocket/Login key is set to disabled, anonymous login is allowed. The key must contain a valid user name or ID for a user account with the permissions appropriate for anonymous use. To prevent anonymous login this key should be removed from the Registry.

The built-in Websocket interface supports file management. Files may be listed, read, written, renamed and deleted. Similarly folders can be created, renamed and removed. For additional security this feature can be disabled with this key. This removes the file management function from the interface (after a reboot). The key also signals the WebUI to remove the File Folders tab.

Each connection to the built-in Websocket interface can support a single command line (console) session. For additional security this feature can be disabled by this key. This removes the console functionality from the Websocket interface (after reboot). The key also signals the WebUI to remove the Console tab.

The following are configuration settings for the JANOS Management Protocol (JNP) server.

This can be used to disable the JMP Server. This may be desirable if communications with JNIOR will be through some other means and connections to the JMP Port are to be ignored. Changes take effect on reboot.

This defines the IP port on which JNIOR will listen for JMP connections. The default port is 9220. Changes take effect on reboot.

By default the JMP server requires a successful login. This is achieved as part of the protocol. Login is highly recommended. If the JNIOR is connected to a private secure network this login requirement can be removed by setting this Registry key to disabled. The change takes effect immediately. Note that this requires that JMPServer/Anonymous be set.

Defines the user name or ID applied to anonymous logins. When the JMP server requires a login (default) the login must reference a defined username using the correct password for that account. In order to accommodate a scheme whereby data monitoring would not require login but control or configuration would, JANOS allows for anonymous login. When the JMPServer/Anonymous key is defined anonymous login is allowed. The key must contain a valid User name or ID defining a user account with the permissions appropriate for anonymous use. To prevent anonymous login this key should be removed from the Registry.

The User name or ID for any user account can be found using the USERS command at the command line prompt.

The following are configuration settings for the JNIOR Protocol server. The JNIOR Protocol is the original interface for remotely controlling I/O.

NOTE: This is a legacy binary protocol with limited capability. It is not recommended for new development. Use the JSON based JANOS Management Protocol (JMP) instead.

This entry can be used to disable the JNIOR Server. This protocol should be disabled if the JANOS Management Protocol (JMP) will be used routinely. Changes take effect on reboot.

This defines the IP port on which JNIOR will listen for protocol connections. The default port is 9200. Changes take effect on reboot.

By default the JNIOR protocol requires a successful login. This is achieved through a function as part of the protocol. It is highly recommended that Login be accommodated. If the JNIOR is connected to a private secure network this login requirement may be removed. Set this Registry key to disabled. The change takes effect immediately. Note that this requires that JniorServer/Anonymous be set.

Defines the user name or ID applied to anonymous logins. When the JNIOR protocol requires a login (default) the login must reference a defined username using the correct password for that account. In order to accommodate a scheme whereby data monitoring would not require login but control or configuration would, the JNIOR OS allows for an anonymous login. When this Registry key is defined anonymous login is allowed. The key must contain a valid user name or ID for a user account with the permissions appropriate for anonymous use. To prevent anonymous login this key should be removed from the Registry.

The user name or ID for accounts can be found using the USERS command at the command line prompt.

The JNIOR protocol server can be configured to maintain a outbound connection to an external JNIOR protocol server. This Registry key defines the IP address of the remote connection point. Once defined the connection will be established.

Outbound connections allow JNIOR communications between an Internet server and individual devices behind a firewall or NAT router. This is best accomplished with an application program which can be written to handle custom protocols as may be required for such a system. The JNIOR Protocol is a binary master-slave interface that takes some care in implementation. The protocol includes unsolicited messages as well which are often overlooked.

The JNIOR protocol server can be configured to make an outbound connection to one remote host. This is enabled using the JniorServer/RemoteIP Registry key and the Port number may be specified by the key here.

JANOS supports a fully functional File Transfer Protocol (FTP) server. This FTP Server is one of the methods available for moving files to and from the JNIOR.

This defines the IP port on which JNIOR will listen for FTP command connections. The default port is 21.

The specification for the File Transfer Protocol does not specify the format for directory listings. Originally the detail was only for display and could be in the system’s native format. There are two generally used layouts. Systems based on the Windows operating system provide an MS-DOS style listing while most others provide a Unix format. JANOS provides the MS-DOS style by default.

FTP clients typically now need to interpret the listing for graphical display and tracking of directory/folder content. Most client programs will detect the formatting and process the content as needed. Other clients might expect one style or the other.

If an FTP client has difficulty retrieving the directory listing from the JANOS FTP Server you may set this Registry Key to enabled. The FTP Server will then supply the Unix formatted directory listing when requested.

JANOS supports a Telnet server providing access to the Command Console. Telent simulates serial communications similar to a connection to the RS-232 COM port. Both are a means of working with the command line interface. This is typically used for product configuration, maintenance and diagnostics.

This entry can be used to disable the Telnet Server. Changes take effect on reboot. The Command Console is also available through the WebUI.

The BEACON protocol is used to identify JNIORs on the network, configure IP addressing, and provide some management functions. The protocol allows us to communicate with a JNIOR on the local network segment even when its IP configuration is faulty or set for a foreign network. Changes to Registry settings in this section require a reboot in order to take effect.

For added security this protocol may be disabled using this Registry key. The BEACON protocol is required for the Support Tool. JANOS also uses this protocol to identify peers on its local network segment.

The BEACON protocol by default announces the presence of the JNIOR on the network using a broadcast UDP communication. The Support Tool uses this to list local JNIORs on the Beacon tab. This feature may be disabled by setting this key.

The BEACON protocol announces the JNIOR on boot by default and whenever key configuration settings change. There may be extended periods without an announcement. This feature may be used to monitor the health of the JNIOR. A periodic announcement every 30 seconds can be enabled by setting this key.

Each digital input may be configured in a number of ways to achieve the desired function. The following diagram shows how inputs are handled by JNIOR.

The following keys are associated with the Digital Inputs. Note: In each of the following Keys replace ## with the appropriate channel number 1-4 (Model 412), 1-8 (Model 410) or 1-12 (Model 414).

This Registry key is not specifically used by the operating system. It is used by the WebUI and can be referenced by any other application requiring a description.

This defines the text used to describe the state when the associated input is ON. By default an input is considered to be ON when sufficient voltage is applied to illuminate the LED.

This Registry key is not specifically used by the operating system. It is used by the WebUI and can be referenced by any other application requiring a description of the input state.

This defines the text used to describe the state when the associated input is OFF. By default an input is considered to be OFF when insufficient voltage is applied and the LED is not illuminated.

This Registry key is not specifically used by the operating system. It is used by the WebUI and can be referenced by any other application requiring a description of the input state.

When this Registry key is enabled the JNIOR will invert the sense of the Digital Input. When enabled the input will be considered ON when insufficient voltage is applied to the external circuit and the LED is not illuminated. The input will be considered OFF when sufficient voltage is applied to illuminate the LED. This inversion is applied immediately to the input and affects all other subsequent functions (Debounce, Latching, Alarming, Counting, etc.).

The input state may be conditioned prior to being reported and after all other operations. By default the input state is as reported by the latching or debounce stages (Mode 0). You may configure inversion here or force the input to be always read as 0 (OFF) or 1 (ON). Note that counting and usage metering remain operational even when inputs are forced to a fixed state. The following settings are valid:

Relays and switches have mechanical contacts which physically make or break a circuit. Rarely will the contacts come together solidly or separate decisively without bouncing (briefly making and breaking the circuit). This can raise havoc with digital latching and counting circuits that might be monitoring through the relay/switch contact. It can result in latching at the wrong time (when the relay opens for instance) or in extra counts. Both are undesirable.

By default the JNIOR digital inputs are debounced. An input must remain quiet (not change) for the specified debounce delay before any transition on that input will be processed (latched, counted or logged). This is sufficient to eliminate most all of the issues arising from contact bounce.

A setting of 0 disables the debounce. In this case the JNIOR is capable of counting transitions occurring at rates up to roughly 1,800 per sec.

Enable this Registry key when the associated input is to be latched. When enabled, the input will be considered to remain in the state defined by the LatchState setting after the voltage applied to the external input is changed. If the LatchTime is set to 0 seconds the User must manually reset the input. This can be done through the WebUI or other application.

This defines the time in seconds (0.1 equals 100 milliseconds) that an input remains latched before being automatically reset. A value of 0.0 will require the User to separately reset the latched input.

When Latching is enabled this specifies whether the input is latched in the ON state (1) or in the OFF state. The key is set to 1 or 0 respectively.

This key can be used to disable logging of all of the Digital Inputs regardless of the logging settings for individual inputs. This setting requires a reboot.

This key can be optionally used to disable logging on an input by input basis. If an input is going to be rapidly changing the time spent in the logging process can degrade system performance. In such circumstances it is recommended that logging be disabled for the input.

This dynamic key reports the total number of hours that a digital input has physically been in the state specified by UsageState. This value is non-volatile maintaining content through power loss and until it is specifically reset. It is reported here in hours to the one-hundredth. The Hour Meter is accurate to the millisecond and this high resolution value may be read through the JMP Protocol, the JNIOR Protocol or using the JRMON command.

The associated input will generate a state alarm when this Registry key is enabled. By default the alarm is issued when the input turns ON. This is affected by inversion settings and dependent on the latching status.

Enable this key when the associated input is to alarm upon entering the OFF state. By default the alarm normally is generated when the input turns ON.

This key can enable Email Notifications in response to a Digital Input state change Alarm.

This may be used define a block that creates a unique Email Notification message.

This defines the amount of time in milliseconds that the Digital Input state alarm must remain clear before any subsequent state alarm on this input will be acted upon. The default is 300000 or 5 minutes. When an alarm occurs the services associated with that event are performed. The alarm must reset and remain so for this amount of time before those actions would be performed again. Even at this setting an email notification could be sent once every 5 minutes.

This specifies whether an input transition from OFF to ON is counted (1) or if the transition from ON to OFF is counted. The key is set to 1 or 0 respectively.

This defines the units text to be displayed with the associated input counter. This Registry key is not specifically used by the operating system. It is used by the WebUI and can be referenced by any other application requiring a description of the count units.

When the Count Multiplier is set to 0.0 (default) the absolute counter value is displayed. When a non-zero multiplier is specified then the value is used to scale the counter value for display. The scaled counter value is also used for count alarm trigger points.

Counts accumulate until reset separately by the user threw the WebUI or other application. This is the case when SampleTime is 0.0 (default). When a nonzero time is used the counter displays the total count accumulated during that period. For instance, with the appropriate combination of Multiplier and SampleTime the counter can display RPM for a strobe input. The alarm trigger points may be set to monitor either high or low count ranges.

This defines the trigger point for the count alarm. An alarm (type 1) can be generated with the scaled counter exceeds this value.

This defines the trigger point for the count alarm. An alarm (type 2) can be generated with the scaled counter exceeds this value.

Set this key to enable services related to the occurrence of Digital Input Type 1 Counter Alarms on this input. Counter Type 1 and Type 2 Alarms differ only in the set points used.

This defines the amount of time in milliseconds that the Digital Input counter type 1 alarm must remain clear before any subsequent type 1 alarm on this input will be acted upon. The default is 300000 or 5 minutes. When an alarm occurs the services associated with that event are performed. The alarm must reset and remain so for this amount of time before those actions would be performed again.

This may be used define a block that creates a unique Alarm Type 1 Notification message.

Set this key to enable services related to the occurrence of Digital Input Type 2 Counter Alarms on this input. Counter Type 1 and Type 2 Alarms differ only in the set points used.

This defines the amount of time in milliseconds that the Digital Input counter type 2 alarm must remain clear before any subsequent type 2 alarm on this input will be acted upon. The default is 300000 or 5 minutes. When an alarm occurs the services associated with that event are performed. The alarm must reset and remain so for this amount of time before those actions would be performed again.

This may be used define a block that creates a unique Alarm Type 2 Notification message.

This specifies whether usage time is accumulated with the input in the ON state (1) or in the OFF state (0). The key is set to 1 or 0 respectively.

Set this Registry key to enable an alarm when the associated usage meter reaches a specified number of hours.

Defines the alarm setpoint in hours and fractions of hours. The associated input goes into alarm when the usage meter reported by $HourMeter reaches or exceeds this setpoint.

This may be used define a block that creates a unique Usage Notification message.

This defines the amount of time in milliseconds that the Digital Input usage alarm must remain clear before any subsequent usage alarm on this input will be acted upon. The default is 300000 or 5 minutes. When an alarm occurs the services associated with that event are performed. The alarm must reset and remain so for this amount of time before those actions would be performed again.

This key may be optionally defined to enable services related to Digital Input Usage Alarms

The following keys are associated with the Relay Outputs. Note: In each of the following Keys replace the ## with the appropriate channel number 1 thru 16 depending on the configuration. The Model 410 has 8 relay outputs while the Model 412 has 12 and the Model 414 only 4. Power 4ROUT Expansion Modules may be added to provide additional relays. The first 16 are addressable through the Registry.

This Registry key is not specifically used by the operating system. It is used by the WebUI and can be referenced by any other application requiring a description.

This defines the text shown when the associated relay has been activated and is in the CLOSED state.

This Registry key is not specifically used by the operating system. It is used by the WebUI and can be referenced by any other application requiring a description of the output status.

This key is used to define the initial behavior of relay outputs on boot. The value defines a pulse duration in milliseconds where an entry of 0 indicates infinity. Setting the key to a value of 0 would effectively close the output. Setting the key to a positive integer would cause the output to pulse for the duration defined by the value An undefined or negative value (default) results in no action.

This dynamically reports the total number of hours that the relay output has been in the CLOSED state. This value is non-volatile maintaining content through power loss and until it is specifically reset. It is reported here in hours to the one-hundredth. The Hour Meter is accurate to the millisecond and this high resolution value may be read through the JMP Protocol, the JNIOR Protocol or using the JRMON command.

This specifies whether usage time is accumulated when the relay is in the CLOSED state (1) or in the OPEN state (0). The key is set to 1 or 0 respectively.

Set to enable an alarm when the associated usage meter reaches the Limit specified.

Defines the alarm setpoint in hours and may include a fractional part. The associated relay output goes into alarm when the usage meter reaches or exceeds this setpoint.

This may be used define a block that creates a unique Usage Notification message.

This defines the amount of time in milliseconds that the Relay Output usage alarm must remain clear before any subsequent usage alarm on this input will be acted upon. The default is 300000 or 5 minutes. When an alarm occurs the services associated with that event are performed. The alarm must reset and remain so for this amount of time before those actions would be performed again.

This key may be optionally defined to enable services related to Relay Output Usage Alarms

This key can be used to disable logging of all of the Relay Outputs. This setting requires a reboot.

This key can be optionally used to disable logging on an output by output basis. If an output is going to be rapidly changing the time spent in the logging process can degrade system performance. In such circumstances it is recommended that logging be disabled for the relay output.

The JNIOR supports two serial ports, the COM RS-232 Port and the AUX Serial port. Both ports may be used by application programs to communicate with and control other devices. By default the COM port supports Diagnostic output information which generally reports status during boot. Once the product is up and running the COM port may be used as access to the JANOS Command Line Console. This can be disabled to provide for dedicated communications.

The default communications parameters are 115.2K baud, 8 data bits, 1 stop bit with no parity or handshake. The COM port supports only 3-wire communication. This port does not include hardware handshake lines. The AUX port provides for RTS and CTS handshake signals which may be optionally enabled. In addition the AUX port on the Model 410 may be configured for RS-422 or RS-485 communications. In the latter case the output driver may be software controlled supporting multi-drop serial networks.

The default baud rate is 115.2K baud. The communications baud rate may be modified through this Registry key either directly, by application program or the WebUI. Valid settings are: 250000, 128000, 115200, 57600, 38400, 31250, 28800, 19200, 14400, 9600, 4800, 2400, 1200, 600, 300, 150, and 110. The 250K baud setting is for supporting the DMX512 standard used by stage lighting equipment over RS-485.

The default setting is 8 data bits. Valid settings are 7 and 8. The 7 data bit mode is most often used with either ODD or EVEN parity wherein the parity bit is added maintaining the normal 8 bit stream.

The default setting is 1 stop bit. Valid settings are 1 or 2. The typical asynchronous receiver always recognizes the end of a character using a single stop bit since there can be any amount of time between characters unless the protocol specifically sets a timeout. The transmitter uses this stop bit setting to stretch the minimum time between characters by one extra bit time.

The default setting is for No Parity (NONE or 0). Valid settings are 0, 2 and 3 where 0 means No Parity or NONE, 2 indicates EVEN parity and 3 ODD parity. An additional bit is added to the transmitted stream when EVEN or ODD parity is specified. When either EVEN or ODD is specified the received data is expected to contain a parity bit which is checked and removed. This bit is in addition to that specified by the data bit setting.

The default setting is NO_CONTROL or 0 meaning that no flow control or handshaking either by hardware or software is used. For the AUX port the valid settings are 0 (NO_CONTROL), 1 (RTSCTS_IN), 2 (RTSCTS_OUT), 3 (RTSCTS), 4 (XONXOFF_IN), 8 (XONXOFF_OUT) and 12 (XONXOFF).

The RTSCTS_IN setting uses the available CTS hardware handshake line to control the flow of data from an external source (IN). To hold off incoming data the JNIOR activates the CTS line when internal buffers near capacity. In RTSCTS_OUT mode the AUX port monitors the RTS line and stops transmission when it is activated. The RTSCTS mode employs the handshake bidirectionally.

The XONXOFF_IN handshake transmits the XOFF character (Ctrl-S 0x13) when internal buffers reach capacity to hopefully hold off the incoming data. The XON character (Ctrl-Q 0x11) is later sent to resume communications. Similarly in XONXOFF_OUT mode the AUX port listens for the XOFF character and stops transmission when received. When a subsequent XON character is received the communications resume. Both the XON and XOFF characters are filtered from the stream. The XONXOFF setting applies these rules bidirectionally.

By default the RS485 mode is disabled. RS485 communications are only available with the Model 410 JNIOR. When enabled the RX, TX, RTS and CTS lines are reconfigured. The transmit drivers are disabled and can be controlled by the application program. Originally the JNIOR included internal jumpers allowing the unit to be configured for RS-422 or RS-485 wiring including optional termination resistors. In general these requirements are now achieved with external wiring. Some 410 PCBs have a location for jumpers internally.

The default setting is NO_CONTROL or 0 meaning that no flow control or handshaking is used. For the COM RS-232 port the valid settings are 0 (NO_CONTROL), 4 (XONXOFF_IN), 8 (XONXOFF_OUT) and 12 (XONXOFF). The COM port does not support hardware handshaking.

The XONXOFF_IN handshake transmits the XOFF character (Ctrl-S 0x13) when internal buffers reach capacity to hopefully hold off the incoming data. The XON character (Ctrl-Q 0x11) is later sent to resume communications. Similarly in XONXOFF_OUT mode the COM port listens for the XOFF character and stops transmission when received. When a subsequent XON character is received the communications resume. Both the XON and XOFF characters are filtered from the stream. The XONXOFF setting applies these rules bidirectionally.

The COM port by default supplies reports during the boot process. Once the unit is up and running this port can also be used to access the command line console. When the port is employed in communicating with another device these messages can cause protocol issues. The unwanted messages can be disabled using this Registry key. Note that the application program should also disable the boot dialog and command line capabilities to insure reliable port use. This is done using the COMSerialPort.setBootDialog(true/false) static method. This can also be controlled from the command line using the MODE command.

Diagnostic port information is now included in the jniorboot.log file. This eliminates any advantage to observing the boot through the serial port while debugging. Additionally, the jniorboot.log.bak file now accumulates prior boot detail providing an expanded record of boot detail.

JANOS supports ZIP library files. In fact the WebServer uniquely uses a ZIP library to create a virtual folder allowing an entire website to be contained within a single file. Applications written in Java utilize a JAR library which is nothing more than a renamed ZIP file.

ZIP/JAR files usually contain multiple files in an efficient compressed form. The compression is performed when files are added to a library. While there are optional compression algorithms, JANOS supports the DEFLATE compression. This is compatible with libraries generated by most systems.

The ARC command, and its alias ZIP, can be used at the command line to manage a compressed library file. When adding files the necessary compression is handled by JANOS. There are a couple of options affecting the compression procedure and these are controlled by Registry settings. Changes in these settings do not affect the ability to extract files from libraries generated with other settings by the JNIOR or any remote PC.

The DEFLATE algorithm compresses a file by locating combinations of bytes or characters that repeat. The redundancy is removed and replaced by an efficient pointer to the original grouping. The most efficient compression then would remove any and all redundant groups from an entire file. This is certainly possible for small files. With large files the pointers need to address data further and further away. As the distance grows so do the pointers and efficiency suffers. The solution is to limit the distance using a sliding window through the file.

By default JANOS uses a 16KB (16384 byte) sliding window. This Registry key may be used to adjust the window from a minimum of 2KB (2048) to a maximum of 32KB (32768). In practice there should be no reason to alter this setting. A change in this setting affects the very next compression that is performed.

With each successive character in a file the compressor looks back over the sliding window for groupings where replacement by pointer would provide the greatest compression. This is a time consuming endeavor. As a tradeoff the JANOS routine employs a queue of likely targets in the window for each unique character. This reduces the search effort and the time it takes to perform the compression.

By default the search queue depth is set at 256 entries. Values may range from a minimum of 16 to a maximum of 1024. In practice there should be no reason to alter this setting. A change in this setting affects the very next compression that is performed.

$BootTime
$LastNtpSuccess
$Model
$SerialNumber
$Version
Beacon/Announce
Beacon/AutoAnnounce
Beacon/Enabled
AUXSerial/Baudrate
AUXSerial/Databits
AUXSerial/Flow
AUXSerial/Parity
AUXSerial/RS485
AUXSerial/Stopbits
COMSerial/Baudrate
COMSerial/BootDialog
COMSerial/Databits
COMSerial/Flow
COMSerial/Parity
COMSerial/Stopbits
Device/Desc
Device/ResetAction
Device/Timezone
Email/Attachments
Email/BccAddress
Email/CcAddress
Email/HTML
Email/Message
Email/MessageFile
Email/Port
Email/RetryCount
Email/RetryDelay
Email/Signature
Email/SMTPS
Email/StartTLS
Email/Subject
Email/ToAddress
Email/<block>/Attachments
Email/<block>/BccAddress
Email/<block>/CcAddress
Email/<block>/Message
Email/<block>/MessageFile
Email/<block>/Subject
Email/<block>/ToAddress
Env/<parameter>