Series 4

Accessing Java Applets On Series 3 JNIORs

The series 3 JNIORs used the Java Applet as a GUI. Years ago the browsers stopped supporting Java Applets due to security concerns. You are no longer able to open the series 3 Java Applet GUI in most browsers. You can still access it by launching it locally since it is installed as part of the JNIOR Support Tool. The security concerns over java applets are not present when launching the Java Application locally. Here is how to access the Java Applet for a JNIOR.

NOTE: The Java Applet GUI should only be used with series 3 JNIORs.

First, make sure you have the JNIOR support tool downloaded. Here is a link for it.

Name Version Release Date Size MD5
JNIOR Support Tool v7.10 Jul 15 2020 13 MB 4fd5a1b0617a59a7f6802663ec3f789e

Once you have downloaded the Support Tool, you’ll want to open it and find the JNIOR you wish to access the Java Applet for in the Beacon tab. Then by right clicking it, you’ll then go to Tools/Classic Monitor, Configuration, Control Application option and select it.

After selecting this for, the Java Applet for your JNIOR should open.

By | On July 28, 2020 2:12 pm | No Comments |

Create or Open a Workspace in Tasker

Workspaces are files that contain configuration for Tasker. Tasks, Devices, Loggers, Signals, Triggers, and Schedules are all saved in a Workspace file.

Multiple Workspace files can be loaded on the JNIOR at the same time allowing you to load more complex logic. Using multiple Workspaces allows you to logically group the features together that rely on each other.

Tasker will not have any Workapces loaded when it is first loaded. You will be presented with a screen alerting you to that fact and telling you that you must create a new Workspace.

You can click the green button to Create a new Workspace or use the New option in the File menu.

Once a Workspace is created and saved the screen will appear differently the next time you visit Tasker. Here we have created two Workspaces to illustrate this.

You can now click on of the Workspace files or use the Open option in the File menu.

The above post was a brief explanation covering how to create and open Workspaces in Tasker. If you have any additional questions you can check out the Tasker Knowledgebase.

By | On April 30, 2020 3:35 pm | No Comments |

Sending a SNMP Trap with a Custom Message via Tasker

This feature is available in Tasker v3.1 and later.

Having the JNIOR send a SNMP Trap is great. The SNMP application offers built-in Traps when the digital inputs and relay outputs change. Tasker takes this further allowing you to send a SNMP Trap as a part of a Task. The value of the Trap can be custom and dynamic based on the message building rules of Tasker.

The first thing we need to do is make sure that SNMP is running. The feature covered in this post is available in SNMP v2.6 and greater. Once we know that SNMP is running we can Create or Open a Tasker Workspace.

To send a SNMP Trap we will need to add the SNMP Trap action to a Task. You can create a new Task for this action or add it to an already existing Task. The action will ask for the SNMP OID (Object Identifier), the message to send and the device to send the Trap to. The device to receive the Trap can be the built-in Trap Host that is defined in the SNMP application or a new one can be defined in the Devices Tab.

Upon selecting the SNMP Trap action you will be presented with the following

Here is what it will look like after entering some information

Without defining a SNMP Device, the Trap will be sent to the Trap Host that is defined in the SNMP application. You can optionally define a new Trap Host by clicking + Add Device in the Devices Tab.

You will be presented with a Dialog asking for a Device Name and the Device Type. Enter any name and select SNMP Device from the Device Type drop down.

Now you can enter the Trap Host information as shown here.

Now back in our Task Action we will see this Device as an option.

Save the Workspace in the File menu and your Custom Trap will be able to be sent!

Advanced Usage

You can send a dynamic message. A dynamic message is one that has different data based on our message building rules. Here we will send the current temperature.

A defined Signal could also be used here instead of temp[1].f and a Trigger could be used to cause the Trap to get sent as described in the using signals and triggers post.

By | On April 30, 2020 3:19 pm | No Comments |

Tasker Message Building Rules

To build dynamic messages you will use the text replacer syntax. Using {{ }} will allow the message engine to find the appropriate portion of the text and replace it with the value of the evaluated text that is contained within the {{ }} syntax.

Available Conditionals

Internal I/O

din[#].state din[#].counter din[#].usagemeter
rout[#].state rout[#].usagemeter

Temperature Sensor

temp[#].fahrenheit or temp[#].f for short
temp[#].celsius or temp[#].c for short

Environmental Sensor

env[#].fahrenheit or env[#].f for short
env[#].celsius or env[#].c for short
env[#].humidity

Registry

registry("key_name")or reg("key_name") for short. Just replace key_name with the registry key name.

Date

date.currentmillis where the value is the number of milliseconds since January 1st 1970. date.format("format_string") where the format_string is of the following format:

MM two digit month
dd two digit day
yy two digit year
yyyy four digit year
HH two digit 24 hour
hh two digit 12 hour
mm two digit minute
fff milliseconds
aa am / pm
zzz timezone string

for example. date.format("MM-dd-yyyy HH:mm:ss.fff")

Examples

drop
By | On April 30, 2020 3:18 pm | No Comments |

SunEquation Application

This application was made in order to find out what time during the day that sunrise and sunset will occur. Once these times are found, actions can be set to activate at those times.

When using the SunEquation application, it needs to be configured after it is updated to a JNIOR. Updating a JNIOR with the application creates new registries in the AppData registry folder. Within the SunEquation registry folder, two registry keys are found, which are latitude and longitude. These need to be filled out with the location information of where the JNIOR will be installed. It uses this information in order to calculate what time the sun will rise and set.

Two macros command will be sent to the Cinema application, at sunrise and sunset. These need to be called “sunrise” and “sunset” when created in the support tool. Here the macros can be configured to complete whatever the user wishes to occur on the JNIOR during those times. Even though the application is set to create macros commands, it can be made to complete other actions instead of macros if needed. If you’d like different actions to occur at sunrise and sunset, contact INTEG support and we’ll alter the application to suit your needs.

The SunEquation application creates a log called sunriseandsunset.log that you can find in the folder tab of your JNIOR’s DCP. In this log, you can view when actions are completed at sunrise and sunset. You can also see at midnight when the it calculates the times for sunrise and sunset for that day. Any errors the application is having can also be viewed in this log, which can help troubleshoot those issues.

By | On April 9, 2020 9:36 am | No Comments |

Securing a unit with Non-Factory Username and Password

Leaving any device set with a factory Username and Password is a big security risk. The JNIOR comes with two factory Administrator accounts. The usernames jnior and admin both have administrative privileges.

It is recommended that the users be modified on the JNIORs to secure them. This is vital for units that are on the open network and have public access. Public access does not mean that they are supposed to be open to the public but rather that they are accessible from anywhere.

List the Users

To see the current users and their privileges, you will use the users command. This command will show you the usernames, their assigned user id and the privileges that they possess.

Change the password for the current user

The simplest change that you can make to secure your unit is to change the password of one of the factory administrator accounts. To do this you will log in to the one you want to change and use the passwd command. You will be prompted for the current password and then twice for the new password. The password requirement is very relaxed but you are encouraged to create a strong password.

Create a new user

We need to create a new administrator account so that we can disable the factory users. Using the useradd command with the -a option will create a new user with administrator privileges. You will be prompted for the new password twice. The password requirement is very relaxed but you are encouraged to create a strong password. After the user is created you can execute the users command again to see the results.

Disable the Admin account

To disable an account you will use the usermod command. This command modifies the privileges for the given user. To disable the admin account you will type usermod +d admin. Then you can execute the users command again to see the result.

Change the current user

After creating the new user you will want to switch to it so that modifications can be made to the user account that was logged in while the new user was created. You will do this by closing the command line connection. This will log you out from the current user. Then reconnect using the new user and the new credentials. You can see what the current user account is by using the whoami command. Next, you can then modify the privileges of the user that was used to create the new account.

Things to watch out for

You MUST have at least one admin account on the JNIOR. If you try to do so, you will simply be told that you cannot remove that user.

You also cannot remove admin privileges from the user that you are logged in as while performing that operation. If you try to do that you will be told that you cannot alter the current account.

By | On March 31, 2020 9:19 am | No Comments |

Sending MQTT Messages Using The Message Pump

This post explains how to send and receive messages from a System Message Pump. There is a previous post showing how to create a System Message Pump. This example uses the additional applications the previous example did and should be included when the project for this application is created. That post can be accessed here. Please look over that post first as this one uses code from and references that post. 

package mqttmessagepump;

import com.integpg.system.JANOS;
import com.integpg.system.MessagePump;
import com.integpg.system.SystemMsg;
import java.util.Json;
import java.util.Vector;
import java.util.logging.Level;
import java.util.logging.Logger;

public class MQTTMessagePump implements Runnable {

    private static final MQTTMessagePump THIS = new MQTTMessagePump();
    private static final MessagePump MESSAGE_PUMP = new MessagePump();
    private static final Vector LISTENERS = new Vector<>();

    private static Thread _thread;

    /**
     * Singleton constructor
     */
    private MQTTMessagePump() {
    }

    /**
     * adds a listener that will be alerted of all received messages. The
     * listener will be responsible for determining if the message has meaning
     * to them
     *
     * @param listener
     */
    public static void addListener(MessagePumpListener listener) {
        synchronized (LISTENERS) {
            LISTENERS.addElement(listener);
        }
    }

    /**
     * starts our message pump engine.
     */
    static void start() {
        if (null == _thread) {
            _thread = new Thread(THIS);
            _thread.setName("message-pump-engine");
            _thread.setDaemon(true);
            _thread.start();
        }
    }
    
    //completes the message 1600 after being sent from the MQTT application
    
    public static void completeMessage1600 (String recievedJsonInfo) {
        
        Json holdinginfo = new Json(recievedJsonInfo);
        String[] arrayofkeys = holdinginfo.keyarray();
        String subscribecheck = holdinginfo.getString(arrayofkeys[0]);
        String topicscheck = holdinginfo.getString(arrayofkeys[1]);
        String infocheck = holdinginfo.getString(arrayofkeys[2]);
        System.out.println(arrayofkeys[0] + ": " + subscribecheck + ", " + arrayofkeys[1] + ": " + topicscheck + ", " + arrayofkeys[2] + ": " + infocheck);
 
    }
    
    //creates the message that will be sent to the other program to complete
    
    public static SystemMsg createMessage (int messageType, byte [] messageInfo) {
        
        SystemMsg returnMsg = new SystemMsg();
        returnMsg.type = messageType;
        returnMsg.msg = messageInfo;
        
        System.out.println(returnMsg);
        return returnMsg;
        
    }
    
    //adds a value to the Json object that we be sent as part of the message to the other program
    
    public static Json addToJson(Json Jsonadd, String valuename, Object jsonvalue) {
    
        Jsonadd.put(valuename, jsonvalue);
        return Jsonadd;
        
    }
    
    @Override
    public void run() {
        System.out.println("open the message pump and start monitoring.\r\n");
        MESSAGE_PUMP.open();

        for (;;) {
            // read all messages from the message pump
            SystemMsg systemMsg = MESSAGE_PUMP.getMessage();

            // we must repost as fast as we can
            MESSAGE_PUMP.postMessage(systemMsg);

            // notify all of our listeners

            if (systemMsg.type == 1600) {

                System.out.println();
                System.out.println("Recieved command 1600.\n");
                String jsoninfo = new String(systemMsg.msg);
                completeMessage1600(jsoninfo);           

            }
            
             Json thirdjson = new Json();
             addToJson(thirdjson, "Message", "publish"); 
             addToJson(thirdjson, "Topic", "jnior/(Your JNIOR's Serial Number)/set/digital/outputs/1/state");
             addToJson(thirdjson, "Payload", "true");
             SystemMsg returnMsg = createMessage(1600, thirdjson.toString().getBytes());
             MESSAGE_PUMP.postMessage(returnMsg);    
            try {
                Thread.sleep(1000);
            } catch (InterruptedException ex) {
                Logger.getLogger(MQTTMessagePump.class.getName()).log(Level.SEVERE, null, ex);
            }

        }

    }

    /**
     * Exposes the postMesssage method of the System MessagePump
     *
     * @param msg the message the will be sent to the system message pump
     */
    public static void postMessage(SystemMsg msg) {
        MESSAGE_PUMP.postMessage(msg);
    }

}

To start, before we can create an application to talk with the MQTT application, we need to configure the MQTT application to hook up with a broker. Here is a download for the MQTT application update project. An online broker is needed in order to use the MQTT protocol. Free ones can be found online, but for this example the free hivemq broker is being used. This broker is public and if you want to use MQTT protocols outside this example, a secure one should be used. The only information you need to have in the MQTT application is the host URL and the port number. Then click connect and make sure the MQTT application is running on the JNIOR.

Once the MQTT application is properly configured, the MQTT coding can be made. After creating a Message Pump program that could send messages to and from another application, the next step is to create and receive messages between the message pump and the MQTT application using the MQTT protocol. To start, we can create a new program that will interact with the MQTT application. We’ll call this program our MQTTMessage program. This sample program will only send a message to toggle an output, but could be edited to do more.

For this example, only the application containing the message pump from the previous example is needed. In the previous example, the message being sent between the applications are Json Objects. The message that needs to be created for this example is formatted as this:

{
  "Message" : "publish",
  "Topic" : STRING,
  "Payload" : STRING
}

The MQTT application also uses Json Objects to communicate through the messages. Looking at the for loop when creating the message to send, the message has to be “published”, because when you are sending a message to the MQTT application, you are publishing information on a specified topic. The topic is the keyword that other devices are subscribed to. If a device is subscribed to that topic, then the device will receive the payload of the message. The payload is the actual data of the message that any device subscribed to the related topic will receive.

The run function in the previous example’s MessagePumpEngine application is replaced with a new for loop. When creating the message, it needs to be reformatted to match the Json message the MQTT application needs to receive. The message ID number has to be 1600, since that is the message ID the MQTT application is listening to. In this example, the Json object is created as:

{
  "Message" : "publish",
  "Topic" :jnior/"Your JNIOR's IP"/set/digital/outputs/1/state,
  "Payload" : true
}

The topic is to specify the JNIOR, what channel you want to toggle, and if its opened or closed. The payload sets that channels state to true, closing that output.

for (;;) {
            // read all messages from the message pump
            SystemMsg systemMsg = MESSAGE_PUMP.getMessage();

            // we must repost as fast as we can
            MESSAGE_PUMP.postMessage(systemMsg);

            // notify all of our listeners

            if (systemMsg.type == 1600) {

                System.out.println();
                System.out.println("Recieved command 1600.\n");
                String jsoninfo = new String(systemMsg.msg);
                completeMessage1600(jsoninfo);           

            }
            
             Json thirdjson = new Json();
             addToJson(thirdjson, "Message", "publish"); 
             addToJson(thirdjson, "Topic", "jnior/(Your JNIOR's Serial Number)/set/digital/outputs/1/state");
             addToJson(thirdjson, "Payload", "true");
             SystemMsg returnMsg = createMessage(1600, thirdjson.toString().getBytes());
             MESSAGE_PUMP.postMessage(returnMsg);    
            try {
                Thread.sleep(1000);
            } catch (InterruptedException ex) {
                Logger.getLogger(MQTTMessagePump.class.getName()).log(Level.SEVERE, null, ex);
            }

        }

The if statement checking the (systemMsg.type == 1600) is there because the JNIOR being used to publish the message is also listening the for messages on the message pump too, and those messages will have the same message ID 1600. 

if (systemMsg.type == 1600) {

                System.out.println();
                System.out.println("Recieved command 1600.\n");
                String jsoninfo = new String(systemMsg.msg);
                completeMessage1600(jsoninfo);           

            }

Inside that if statement is a call to the completeMessage1600() function. That function will grab the data out of the Json object from the message and print it out for you to see.

public static void completeMessage1600 (String recievedJsonInfo) {
        
        Json holdinginfo = new Json(recievedJsonInfo);
        String[] arrayofkeys = holdinginfo.keyarray();
        String subscribecheck = holdinginfo.getString(arrayofkeys[0]);
        String topicscheck = holdinginfo.getString(arrayofkeys[1]);
        String infocheck = holdinginfo.getString(arrayofkeys[2]);
        System.out.println(arrayofkeys[0] + ": " + subscribecheck + ", " + arrayofkeys[1] + ": " + topicscheck + ", " + arrayofkeys[2] + ": " + infocheck);
 
    }

With these changes to the previous message pump application and MQTT application configuration, after running this example program you should be able to create and send messages through the MQTT application using the MQTT protocol.

By | On January 29, 2020 4:27 pm | No Comments |

Command Outputs to Close or Pulse on Boot

At some point you may want your JNIOR to always have an output close or pulse, and when you reboot a JNIOR, they get reset. This post will show you how to have your JNIOR automatically close outputs from startup. If you’re looking for different information on the DCP, or don’t know how to access it, you can look here.

To start, make sure you are able to access the DCP (Dynamic Configuration Page) of your JNIOR. Then you’ll want to go to the Configuration tab of the DCP. Here we will be accessing the outputs section.

Here is where you can close or pulse outputs on startup. Simply add a zero to the Initial Action section for whichever channel you wish to close, and it will now always close that input on startup. To pulse the output on startup, simply add any positive value and it will pulse for that many milliseconds instead.

By | On January 22, 2020 5:08 pm | No Comments |

Troubleshoot: PHP error

There is a chance you will see the following PHP error. For this to be seen you must have a Series 4 JNIOR that had JANOS version 1.6 or older and you just updated to a new JANOS version

Why did this happen?

The older JNIORs had a different web page than we have now. The main web page used to be served out of the flash/www folder. Now the DCP, the newer web page, is served out of the flash/www.zip file. If the flash/www/index.php file is still found then the web server will process it and serve it instead of the index.php in the www.zip file.

How do we fix it?

To fix this we need to remove the old flash/www/index.php file. This will allow JANOS to look in the flash/www.zip file. This should be a step in the All-In-One update project. You can do it manually with a Telnet connection like this…

By | On November 21, 2019 11:29 am | No Comments |

GDC to JNIOR connection not working

If the JNIOR series 4, models 410, 412 or 414, is not working with the GDC Cinema Server then check to make sure MODBUS is enabled. The built-in library for the JNIOR on the GDC server uses MODBUS.

MODBUS communicates on port 502.

The series 3 enabled the MODBUS server by default. The MODBUS server is an optional application that needs to be enabled on the series 4. You can look at the following links for more information

By | On November 6, 2019 4:19 pm | No Comments |

Upgrading Cinema from a Series 3 to a Series 4

There are many reasons to upgrade a series 3 JNIOR to a series 4. While we believe the experience and reliability are much better with the newer hardware and software we understand that in most cases the “if it isn’t broke, don’t fix it” rule applies.

When you are ready, use the following steps to help the transition go smoothly.

Can I just perform a backup from the series 3 and restore onto the series 4?

You can perform a backup and restore. BUT, this will copy over the cinema.jnior application. This file will not run on the series 4. There is a specific cinema file, cinema.JAR, that will run on the series 4.

If the cinema.jnior file gets copied over there will only be one small issue. A restore will set that file to run on boot. Every time the JNIOR boots it will throw an error regarding the cinema.jnior file being there and being the incorrect format.

The procedure

1. Update the Series 4 Operating System

Make sure the new series 4 JNIOR’s Operating System and Cinema application are up to date. You can find those applications on the All Downloads page.

The Cinema update will ensure that the Cinema application is present that will run on the Series 4. The version of the application that is loaded on the Series 3 will NOT run on the Series 4.

2. Take a Snapshot of the series 3 JNIOR to wish to replace

3. Extract the Snapshot

Open the Snapshot zip file and extract the macro file, devices file and flash/jnior.ini file.

4. Upload the macro and devices files to the destination series 4 JNIOR

5. Edit the jnior.ini file

The configuration is stored in the flash/jnior.ini file. Before you upload it we will need to remove two sections from the file. We will remove the [ipConfig] section so that the IP Address remains and the [run] section so that cinema.jnior does not try to start on boot.

6. Upload the updated jnior.ini file

To upload the file you have two options. You can use your favorite FTP client or use the DCP. If you use the DCP you will want to go to the Folders Tab. From there you can simply drag and drop your ini file to the temp/ folder. I recommend the temp/ folder for the upload so the file gets cleaned up after a reboot.

7. Ingesting the new configuration

To ingest the new configuration we will run the reg -i command from a command-line connection. Again you have multiple options for making the command-line connection. You can use an application like Putty, The JNIOR Command Line tool that is part of the JNIOR Support Tool or the Console tab in the DCP. If you use the DCP your command will look like this.

8. Enable MODBUS Server (If you are using a GDC Cinema Server)

The MODBUS server ran by default in the series 3 operating system. It is a separate application on the Series 4 that must be enabled to provide MODBUS connectivity.

You can enable MODBUS via the DCP. http://JNIOR_IP_ADDRESS in your browser.

9. Reboot the JNIOR again.

Your new Series 4 should be running the Cinema application with the configuration and settings from your previous series 3 JNIOR.

By | On September 4, 2019 12:00 pm | No Comments |

Cinema.jar 3.6
Name Version Release Date Size MD5
Cinema.jar - Update Project v3.6 Aug 14 2019 335 KB d96d4ae9b9adc4f0b8cdaf9bd87518f3

+ Adding web handlers for getDevice without a device for internal io getAll.

Cinema.jar 3.5 June 2, 2019

Name Version Release Date Size MD5
Cinema.jar - Update Project v3.5 Jun 02 2019 327 KB 57a834f2c5ac177b7b19b6dec52350ce

+ Added HTTP POST method to Macro Actions.

+ Added the ability the use HTTPS for GETs and POSTs

Cinema.jar 3.4.1 May 29, 2019

  Cinema.jar - Update Project v3.4.1 [ May 28 2019, 320 KB, MD5: 74f51ea7ccb40962eb2118bf16457c50 ]

  • Released May 28 2019

! Fixed a bug where the watchdog was no longer working. In the Cinema application crashed it would not be restarted.

Cinema.jar 3.4.0 May 16, 2019

  Cinema.jar - Update Project v3.4 [ May 16 2019, 320 KB, MD5: 63b627ede9c8a79710ddb3d7fd3ca852 ]

  • Released May 16 2019

+ Allow you to query the temperature sensor via a HTTP Request.  A JSON representation of the device will be returned.

As of now the only available devices are Type28 and Type7E...

Type28 is the temperature probe and Type7E is the environmental sensor.

To enable this you will need to set the AppData/Cinema/WebServer/Port registry key. The JNIOR will need to be rebooted after this key has been changed. In this example I chose 8081. Port 80 or 443 is normally the default web server port. This web server port is an additional web server that cinema is hosting to handle these types of requests.

By | On August 14, 2019 3:27 pm | No Comments |

Troubleshoot: The dangers of IpConfig/Allow

The IpConfig/Allow registry key can be powerful to help secure your JNIOR.  It can successfully thwart unauthorized access and prevent DOS attacks.

The danger comes in when the registry key is mis-configured. It can be a typo or not fully configured, something simple, but when this happens it can prevent legitimate attempts to access the unit.

If this happens a USB-to-Serial cable is needed to access the unit via the RS-232 port. Make sure to use the correct serial settings of 115200, 8 data bits, 1 stop bit and no parity. Once connected you can issue the reg command.

Above you can see that the IpConfig/Allow key is set for 10.0.0.0/24. This states that the first 24 bits of the address must match for a network connection to be accepted. If, for some reason, this was mistyped then legitimate connections would not be allowed. This would basically render the network port useless. The user might not have noticed what the error was.

Using the Serial to USB cable is the only way to access the unit. The key can then either be fixed or removed to regain access over the network.

By | On August 13, 2019 2:25 pm | No Comments |

JMP Protocol

Pronounced “jump”, the JMP protocol is the JANOS Management Protocol. It will be available in JANOS 1.8.

The JMP protocol shares the messaging JSON structure that is used by the DCP (Dynamic Configuration Page) and the web-socket protocol but on port 9220, by default.

To make processing easier we wrapped the JSON message in a two element JSON Array.

[ number, object ]

Where number is the size in bytes/characters of the JSON object that follows.

Doing this relieves us of needing to count braces to see when an entire JSON message was received. To parse the structure we can do the following:

  1. Look for the opening ‘[‘.
  2. Then process numeric values until a ‘,’ is found. White-space is ignored.
  3. White-space is again ignored and N bytes are read.
  4. Finally remaining white-space is ignored and the trailing ‘]’ confirmed.

If the numeric value is invalid, the comma missing or the trailing ‘]’ bracket not found, the entire message is to be ignored. The extracted JSON Object can then be validated as well.


By | On May 8, 2019 10:04 pm | No Comments |

Resetting a JNIOR to Factory (Sanitize)

Sometimes a JNIOR gets re-purposed.  A JNIOR was performing one task and now it is going to perform a new one.  You may want to clean up the JNIOR before configuring it for the new operation.  In this case we will want to sanitize the JNIOR.  To complete this task there will be two steps that will need to be performed.

First, we will need to “erase” the unit.  To do this we will execute the following command;

reboot -eraseall

After confirmation the JNIOR will erase itself.  It will be completely blank.  Only the operating system will be present.  All other software will be removed.  The title says reset to factory but the OS will still be the currently loaded version and will not revert to the version that was shipped.  The IP Address will also remain unaffected.  All other user configuration including the hostname will be cleared.

That leads into the second step.  You will need to get the software package that you wish to install and update the unit with that code.  Use the support tool and the Update tab to do this.

By | On January 17, 2019 8:31 am | No Comments |

Registry Key Assignments

The Registry Key Assignments document is now distributed as part of the Dynamic Configuration Pages (DCP) package. You access that built-in documentation using the F1 key in the DCP or the link displayed at the bottom of the DCP. This is distributed with every JNIOR.

If you do not have access to the DCP then your JNIOR needs to be updated.

I will try to maintain the current Registry document on our HoneyPot JNIOR which is located on the open network. Yes, this JNIOR is not behind a firewall or NAT router. I have placed the Registry documentation in the public file area on that unit. Here is the link:

http://honeypot.integpg.com/RegistryDoc.html

(Hint: Hold the Ctrl key when you click a link if you want it to open in a new tab.)

By the way, this Registry document is indexed and if you want to refer to a specific Key you can add it to the URL. For example if you want to see the documentation for the Device/Timezone Regsitry Key use the following custom link.

honeypot.integpg.com/RegistryDoc.html#device.timezone

Try it!
http://honeypot.integpg.com/RegistryDoc … e.timezone

And since this documentation is built into the DCP you can retrieve it from you own JNIOR. Just reference your JNIOR instead. Note that in this case since the DCP is not public you will have to log into your JNIOR.

http://[IP Address]/RegsitryDoc.html

I will try to keep the most current version of the document on the HoneyPot though. That since most JNIORs probably need to be updated (which is highly recommended).

By | On October 27, 2017 3:20 pm | No Comments |

Time Zones & Daylight Saving

As we approach the moment when we adjust the clocks as we head into winter it seems appropriate to point out the date and time tools that JANOS has to offer.

bruce_dev /> date -v
 utc: 1509109889
 Fri Oct 27 09:11:29 EDT 2017
 Current Timezone is EST for the America/New_York area.
 Abbreviated EDT when Daylight Savings is in effect.
 DST begins at 02:00 on Sun on or after Mar 8th.
 DST ends at 02:00 on Sun on or after Nov 1st.
 When in effect DST sets clocks ahead by 1 hour.
 DST is currently in effect.

bruce_dev />

The DATE -V command (V for verbose) offers a description of the current time status. Here we see that I have incorrectly referred to DST as “Daylight Savings Time” when in fact it is Daylight Saving Time. So, before posting this I’ll just update the JANOS code to correct that. My bad.

It is in fact Daylight Saving Time and it is designed to capture an hour of sunshine that we would otherwise be sleeping through in the morning. To do this we set our clocks ahead an hour in the Spring at a point when the Sun insists on rising an hour before we want to get up. Remember “Spring ahead. Fall back.” DST is in effect during the Summer. So instead of it being 6:00 AM when the Sun blares into the room and pisses you off by waking you early, it will be 7:00 AM and maybe you should get up. That hour of daylight then is shifted to the end of the day. So it could be almost 10:00 PM before you have to put that lawnmower away. :?

Seems like a reasonable thing to do. Well of course it causes all kinds of issues. Making matters worse not all timezones observe DST and some do but use a different set of rules. And although the rules haven’t been changed recently governments have been known to make adjustments. Sometimes DST usage is temporarily altered say for when we may be in an energy crisis. Then there are the cities or areas of a timezone that decide to not follow DST like the rest of their timezone. All of this makes it difficult for a device to cope.

By the way, I’ve fixed my problem. You’ll have to wait for JANOS v1.6.3 for this. Sorry. :)

bruce_dev /> date -v
 utc: 1509110646
 Fri Oct 27 09:24:06 EDT 2017
 Current Timezone is EST for the America/New_York area.
 Abbreviated EDT when Daylight Saving Time is in effect.
 DST begins at 02:00 on Sun on or after Mar 8th.
 DST ends at 02:00 on Sun on or after Nov 1st.
 When in effect DST sets clocks ahead by 1 hour.
 DST is currently in effect.

bruce_dev />

Did you ever notice in windows that your file last modification times all change when you enable or disable DST?

Windows apparently applies timezone and current DST status to any time it displays. So if DST is in effect every time you see is adjusted even if DST wasn’t in effect at that point in the past. So if I save a file today (October) it will show the file was created today at such and such a hour. But if I check that file date next month (November) after we leave DST it would have been created an hour earlier that I did it. Perhaps even before I got into work. Show your boss that and tell him that all summer long you consistently made it in early and deserve a bonus. ;)

Well the times will be off by an hour but trying to figure whether the times would be an hour earlier or later makes my head hurt.

JANOS has been programmed differently and perhaps correctly at least in my opinion. When a time is displayed JANOS uses DST if and only if DST was in effect at that past moment. So when DST is enabled or disabled the file times remain consistent. You know, if you have written a Windows application that uses a file’s last modification time to check if the file were changed, you’ll go nuts. Twice a year you would think that batches of files suddenly have changed. Yeah I know Windows keeps a changed flag that you can and maybe need to use. But in general the file times seem like a reasonable indication of a change (or different version). You should use UTC anyway.

Of course if you change the DST rules or your timezone for that matter the reported file times will naturally all change. It’s all no big deal anyway.

We’ve also somehow moved from selecting your timezone to specifying a nearby city for getting your clock to display correctly. Well there are hundreds of major cities and that database becomes quite large given there is a lot of repetition (there a multiple major cities in a single timezone). Meanwhile the JNIOR is just a small device and doesn’t have the luxury of wasting storage space that you’ve spent your hard earned dollars on.

In JANOS you select the timezone using its abbreviation and there is a short list of timezones included by default.

bruce_dev /> date -t
Available timezones:
  IDLW (-1200) Date_Line                  WST  (-1100) Pacific/Midway
  HST  (-1000) Pacific/Honolulu           AKST (-0900) America/Anchorage(1)
  PST  (-0800) America/Los_Angeles(1)     MST  (-0700) America/Denver(1)
  CST  (-0600) America/Chicago(1)         IET  (-0500) America/Indianapolis
  EST  (-0500) America/New_York(1)        PRT  (-0400) America/Caracas
  CNT  (-0330) America/St_Johns(1)        AGT  (-0300) Argentina/Buenos_Aires
  BET  (-0300) Brazil/Brasilia            MAT  (-0200) Atlantic/Mid
  CAT  (-0100) Atlantic/Cape_Verde        GMT  (+0000) Greenwich_Mean
  UTC  (+0000) Universal_Coordinated      WET  (+0000) Western European(5)
  CET  (+0100) Central European(4)        EET  (+0200) Eastern European(3)
  EAT  (+0300) Asia/Riyadh                MET  (+0330) Iran/Tehran
  NET  (+0400) Russia/Moscow              AFT  (+0430) Afghanistan/Kabul
  PLT  (+0500) Russia/Ural_Mountains      IST  (+0530) India
  ALMT (+0600) Asia/Alma-Ata              CIT  (+0630) Burma
  VST  (+0700) Mongolia/West              AWST (+0800) Australia/Perth
  JST  (+0900) Japan                      ACST (+0930) Australia/Adelaide(2)
  AEST (+1000) Australia/Sydney(2)        LHT  (+1030) Lord Howe Island
  SST  (+1100) Russia/East                NIT  (+1130) Norfolk Island
  NST  (+1200) Pacific/Fiji             

Note 1:
 DST begins at 02:00 on Sun on or after Mar 8th. Clocks move forward by 60 minutes.
 DST ends at 02:00 on Sun on or after Nov 1st.
Note 2:
 DST begins at 02:00 on Sun on or after Oct 1st. Clocks move forward by 60 minutes.
 DST ends at 03:00 on Sun on or after Apr 1st.
Note 3:
 DST begins at 03:00 on Sun on or before Mar 31st. Clocks move forward by 60 minutes.
 DST ends at 04:00 on Sun on or before Oct 31st.
Note 4:
 DST begins at 02:00 on Sun on or before Mar 31st. Clocks move forward by 60 minutes.
 DST ends at 03:00 on Sun on or before Oct 31st.
Note 5:
 DST begins at 01:00 on Sun on or before Mar 31st. Clocks move forward by 60 minutes.
 DST ends at 02:00 on Sun on or before Oct 31st.

bruce_dev />

We’ve recently adjusted this list having learned of some additional DST rules. If you find that none of these standard timezones work for your location, tell me about it. I can add a new timezone (or fix an error) as easily as I changed “Daylight Savings Time” above.

If this doesn’t do it for you, you can define a custom timezone. This is all described in the Registry Key Assignments document the current version of which is built into the DCP and distributed with every JNIOR.

You can open the DCP by pointing your browser to your JNIOR and use the F1 key to bring up the documentation. A whole section on Custom Timezones and Timezone Corrections can be found in the Table of Contents.

In fact I can put the current version of RegistryDoc.html and RegistryDoc.css (and also inputs.png) in the public web area on the HoneyPot unit. The HoneyPot is a JNIOR Model 410 that we have connected directly to the Internet for security testing. That means that you can also retrieve pages from it. I’ll try to remember to keep that copy current.

Here’s a link to the Timezone section.

http://honeypot.integpg.com/RegistryDoc … e.timezone

So now on the HoneyPot we have the Registry Key Assignments document: http://honeypot.integpg.com/RegistryDoc.html and an application that maps all of the illegal login attempts that mostly result from malicious bots like that Mirai Botnet: http://honeypot.integpg.com/map.php

By | On October 27, 2017 3:00 pm | No Comments |

Analyzing Network Traffic

The JNIOR captures network traffic continuously. A large queue is established at boot and a record of network packets is kept. Once the queue fills the oldest packets are dropped. Depending on your network usage that queue might contain the past hour of traffic or much more.

The NETSTAT -C command generates a network capture file /temp/network.pcapng on demand containing the content of the capture queue. For example:

HoneyPot /> netstat -c
LAN connection active (100 Mbps)
 generating capture file...
 /temp/network.pcapng created
 collected 4791 packets from the previous 16 minutes
HoneyPot />

You can download this file to your personal computer. If you have Wireshark installed you will likely be able to double-click this PCAPNG file and it will open right up for viewing and analysis.

By the way you can download Wireshark for free from https://www.wireshark.org/.

Notice that in my example only the past 16 minutes were captured. First of all the capture begins at boot. So if your JNIOR has only been up for 16 minutes that is all that you will get. This, I think, was the case here.

It is important also to note that when you access the DCP you are also using the network. That means that all of the packets involved with your browser access will also be captured. If you leave the DCP up to monitor the status of your JNIOR all of that traffic takes up space in the capture buffer. If you are interested in analyzing the JNIOR interaction with another device that DCP traffic will limit the amount of information you can capture relative to that other device.

One solution is to not use the network to monitor the JNIOR by using the RS-232 (COM) port. But for that you have to be physically at the JNIOR and have the ability to use a serial connection. A better solution is to use capture filtering.

With the JNIOR you can both filter the packets that are to be retained in the capture buffer and filter the packets that you extract into the /temp/network.pcapng file. For example I will set this JNIOR up to ignore HTTP (Port 80) traffic and capture everything else. I can then use the DCP without loading the capture buffer with packets that we are not interested in.

HoneyPot /> netstat -f !80
LAN connection active (100 Mbps)
 capture filter set
HoneyPot />

This tells JANOS to only accept packets into the capture buffer that DO NOT reference port 80. This takes effect immediately (provided there isn’t a syntax error). The next /temp/network.pcapng file that I generate will no longer contain HTTP communications and therefore nothing to do with the DCP. There will be many more packets from a longer period of time all pertaining to other communications that might help with my debugging.

The NETSTAT -F command basically sets the IpConfig/CaptureFilter Registry key. If you mouseover that key in the Registry tab of the DCP and hit F1 you will see the documentation for filtering and the syntax for these filters. These details are in the Registry Key Assignmentsdocumentation. The current version of that documented is distributed as part of the DCP. It will be present on every Series 4 JNIOR that is up to date.

Network Filtering

The content of a network capture or the network clients allowed to interact with the JNIOR can be controlled through dynamic filtering. 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 network.pcap capture file from the capture buffer. Here the filter allows you to extract only pertinent information and otherwise 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 clients. Referenced port numbers refer only to destination ports, those available on the JNIOR.

IP Address Filters

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.

To exclude packets referencing a certain IP address you can prefix a ‘!’ 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”.

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 a range of IP addresses associated with a netmask to be specified. The format is “nnn.nnn.nnn.nnn/mm” where ‘mm’ specifies the number of high order bits 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 would be useful in selecting only local traffic for instance.

MAC Address Filters

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”. The format is six hexadecimal values (0-9a-f or 0-9A-F) 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.

TCP/UDP Port Filters

A port is specified in the filter string as a decimal value between 1 and 65535 inclusive. No punctuation is used. 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”.

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), FTP (21), HTTP (80), HTTPS (443), TELNET (23), and BEACON (4444). These ports may be excluded using the same negation syntax as previously shown.

Boolean Constants

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

Logical Operations

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 associated 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.

            NETSTAT –C SMTP
            netstat –c 25

Note that filters (and also commands) are not case-sensitive. Either form above will create a PCAPNG file with just 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.

            netstat –c 10.0.0.4 && smtp

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

            netstat –c 10.0.0.4 AND smtp OR beacon

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:

            netstat –c (10.0.0.4 && SMTP) || BEACON

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:

            netstat –c BEACON || (10.0.0.4 && SMTP)

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.

            netstat –c !(10.0.0.4 && smtp)

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

           netstat –f !(10.0.0.4 && smtp)

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

            IpConfig/CaptureFilter = !(10.0.0.4 && smtp)

The JNIOR will only capture packets that are addressed to it. That would include broadcasts.

Ok. Well perhaps it is undocumented (and you didn’t hear it from me) but you can set the IpConfig/Promiscuous Registry Key to true. The JNIOR then will capture (subject to any filtering) all traffic including packets not addressed to the JNIOR. But for this to be of any use you will need to be using a Network Hub instead of a Network Switch. There is a difference. The latter “switch” will only pass packets to the JNIOR that are addressed to it in addition to any broadcasts. If you are interested in other traffic you need to use the “hub” which passes all traffic to all connected devices.

The Series 4 JNIOR with a hub then can be a valuable network debugging tool useful in sniffing traffic between two other devices (connected via hubs). It would allow you to remotely use the features of Wireshark.

By | On October 26, 2017 2:57 pm | No Comments |

Afraid to Update? Don’t See the Need?

 
If it is not broke... Don't fix it!

I fully understand this mentality. Believe me. I am still using the Summer 9 version of Altium to layout PCBs here at INTEG. It’s like a half dozen years old. Meanwhile that company continues to generate updates and new versions. They are also painfully charging for them. How many times have you paid for an update and except for the version number you don’t see any difference or don’t need what happens to be new? Meanwhile Microsoft updates your PC overnight and the next day something isn’t working. And now you need to pay monthly for something that you had bought years before. I could rant on. But there is no reason to be phobic and rollback your JNIORs to older versions of JANOS just because you have not had the time to test.

But the Series 4 JNIOR updates are a different matter. In addition to the hardware, JANOS and its updates are my responsibility. Trust me there is a good reason we recommend that you update. Every new version of JANOS corrects a handful of critical bugs. There are often performance enhancements. New features augment what you already have. Everything that ran before will run now as legacy compatibility is paramount. And we DO NOT charge a dime for updates.

Just this morning I corrected a memory leak. A memory leak is when a piece of memory is allocated to store some information and once that information is no longer needed the memory is left to collect dust. Meanwhile the process repeats using up another block of memory. Eventually your JNIOR would run out of available memory and ultimately crash. In the short term everything tests out 100%. Your controller runs perfectly. But there is a ticking time bomb. Luckily, not everyone uses the function at fault in this latest leak. We discovered it in testing here. But if you believe that your JNIORs should be setting records for up time, you need to pick up these corrections. You need to update.

I wrote JANOS. I even coined the name. In fact there is no third party code in the entire OS. I did not even use the standard C Libraries supplied with the Renesas IDE. JANOS has its own C Libraries. There is a good reason for that. It puts us 100% in control. If there is a bug we absolutely can correct it. That’s a significant up side. The down side is that while I have decades of experience I can still create bugs as well as the next guy.

Fortunately as time passes the number of software issues decreases. Their complexity and obscurity increases. But eventually we exponentially approach a stable and reliable product. We are well along that curve now. Each JANOS update is critical in getting those improvements out to you.

As of this writing we have released JANOS v1.6.2 and v1.6.3 is in Beta test. Should you encounter an issue in v1.6.2 we can supply you with Beta or Release Candidate code. If the problem persists and we can replicate it then we will fix it immediately.

If you are concerned about running an update project because it may change all kinds of stuff and you don’t know what. I also understand that. But it is safe to manually update JANOS. Certainly you shouldn’t panic when you get new units with later versions of JANOS. They’ll work just as the older ones.

What Are Update Projects?

An Update Project is a procedure that can be executed using the Support Tool. The Support Tool is a Windows application that can be freely downloaded from the INTEG website Software Downloads Center (http://www.integpg.com/support/jnior/). The Support Tool lets you manage all of your JNIORs and allows you to update them singly or in groups. You would open the Update Project under the Update tab in the Support Tool.

The Update Project is actually a set of files including instructions for the update. These are contained in a ZIP library. While the update project has a ZIP file extension there is no need to extract files from the project or expand it anywhere. The Support Tool takes care of that for you.

Generally we use an Update Project when we are updating an application for you. Usually in that case we both need to update JANOS and perhaps its components like the DCP, and your application. So there are several steps involved. An Update Project is designed to handle all of that for you. You can open the Update Project and see the steps. That may help you to visualize what you are changing/updating.

It is possible to update JNIORs manually if you are not managing a large number of them and want to know what is going on. You can even disable parts of the Update Project and apply only the steps that you need.

By | On October 25, 2017 2:52 pm | No Comments |

Configuring Email

The Series 4 JNIOR can be configured to send email. The approach is slightly different than what existed in the prior controller series. The differences are driven by the heightened concern for security and an increase in restrictions on email server use.

First of all, we now we require valid user credentials (username and password) for authentication at the defined MailHost. You can only submit email to a Comcast SMTP server if you have a valid Comcast email account for example. Just having a valid Comcast email address or originating on a Comcast subnet is no longer sufficient identification. A login is typically required.

Secondly, the Series 4 can establish SSL/TLS secure connections. That means that your email content and credentials are protected by encryption. This was not possible in the prior series where such communications had to be in the clear and readable by anyone clever enough to sniff the network.

The attached document was written prior to the introduction of the DCP (Dynamic Configuration Pages) which are accessed using your browser. At that time one had to use the IPCONFIG command to enter email user credentials in order to encrypt and protect the account password. Most configuration can be also achieved through Registry key modifications. But the password entry requires the active step of encryption which is handled by IPCONFIG.

I will detail recent changes here.

Configuring JANOS for Email

Up to and including the release of JANOS v1.6.2 email can be delivered through an SMTP port (default 25) or MSA port (default 587). JANOS handles both of these ports in the same manner. The JNIOR will authenticate and then if the STARTTLS option is supported JANOS will establish an encrypted connection. The latter requires that SSL be enabled on the JNIOR which it is by default.

You will not get an indication as whether or not an SSL/TLS connection is in use. You could enable SSL Required but that may have other ramifications (such as requiring the use of HTTPS protocols for web connections).

Beginning with JANOS v1.6.3 you will be able to use the SMTPS port (default 465) for guaranteed secure email delivery. The SMTPS port requires a SSL/TLS secure connection right from the start. The email submission procedure will not proceed until the connection is secure. So in this case you can be certain that content and credentials are fully protected. A new Registry key Email/SMTPS must be set TRUE or enabled so JANOS knows to immediately secure the connection.

By the way, JANOS uses this same STARTTLS option to secure FTP. The JANOS Telnet Server which can be used to access the Command Line interface also supports STARTTLS. In this case the option had be proposed but not adopted. So, to our knowledge, the INTEG Telent tools are the only ones that provide the secure Telnet channel. All of this becomes simple when the DCP is used over a secure connection (HTTPS).

So to setup email on the Series 4:

  1. Make sure that your IP configuration (IP address, Subnet, Gateway and DNS servers) is correct. If you are using the default NTP server for synchronizing the clock and you see that NTP is doing just that by the entry in the system log, then your IP configuration is most likely correct.
  2. Set the MailHost or Mail Server. This would be something along the lines of smtp.comcast.net.
  3. Enter you own email address as the From address. Emails will look like they come from you.
  4. Enter your Username. Depending on the system that may be your email address or just the prefix. Note that IPCONFIG and also the DCP will prompt for a password. Once that is confirmed it will be encrypted and stored securely.
  5. By default the email port is 25. That should work for you. Depending on your service they may ask you to use a different port. Set the port as needed. If it is port 465 (or other SMTPS port) you will need JANOS v1.6.3 and Email/SMTPS enabled.

A good test is to enable the Email On Boot and reboot the JNIOR. That setting is on the events page in the DCP. The document attached above tells you how to use the SENDMAIL command form the Command Line which is also useful for testing.

By | On October 24, 2017 2:44 pm | No Comments |