Inside the JANOS Operating System

Welcome to my world…

JANOS Core:

Pictured is the core processing section of the first 412DMX hand-assembled prototype. This is typical of a core for the Series 4 JNIOR.

So there is hardware but it ain’t worth the FR4 it sits upon without Firmware.

No one today would argue that statement unless, of course, they just like to argue. But 50 years ago (yes its about 50 years!) few would understand.

That Renesas RX63NE micro-controller’s internal high speed Flash initially is blank. This board would do nothing until we put something in there. I will tell what we put in there and how it came to be in this forum section.

So we see here that the micro-controller has a basic RS-232 serial port (COM Diagnostic Port); It has access to the Ethernet LAN through an external PHY chip; And, there is a variety of external memory components.

One of the key aspects or the hardware that the Operating System must determine is the configuration. The 412DMX pictured above supports 128MB of NAND Flash. The JNIORs in production at this point use 32MB Serial Flash. So this NAND is being introduced here. It provides for lower cost, larger storage capacity, faster access, and more flexibility. It may find its way back into the entire series 4 line when revisions come up.

Every JNIOR has that battery backed-up low power SRAM. In production today we supply the 2MB chip. Some early JNIORs were built with 4MB chips. This is non-volatile memory. It contains the root of the file system (everything outside of the /flash and /temp folders). It maintains the Registry as the Series 4 does not reload from the /flash/jnior.ini file on boot. And, it holds other immutable memory blocks as might be needed for the system and its applications. All of that being the choice of the Operating System and we will discuss it a bit later.

The 64MB DRAM is high-speed volatile memory that serves as the memory heap for the system. memory here is allocated, managed, freed, cleaned-up and formatted at the pleasure of the Operating System. JANOS has mastered the art of garbage collection making Java applications almost real-time. We will get in to all of that as well.

Early JNIOR Series 4 and the Series 3 versions did not utilize DRAM. These depended entirely on the SRAM for non-volatile storage and memory heap. Life back then was limited. The DRAM offered much greater capacity and lower cost. It also provided for faster access.

So that is the lay of the land where JANOS lives. Shortly we will get to know JANOS at an unprecedented level.

By the way, and as an aside, JANOS is only available in the Series 4 JNIOR at the moment. It will appear in other INTEG products as time goes on. It will also make itself at home in other other processors (ARM for instance). In fact, it may even be available to anchor the operation of products developed by other companies. It was conceived of and born just a short 5 years ago. Only time will tell. Now, at least, it has us spoiled.

With hardware just waiting to be programmed we encountered the first hurdle.

Project Name?

The first thing the IDE wanted was a name for the project. This gave me pause since it would be the code base for the new operating system. So what do we call this OS?

Knowing that we could change the name at any point we decided to get creative. I came up with JANOS which is an acronym standing for (J)nior (A)utomation (N)etwork (O)perating (S)ystem. The ‘J’ being a bit questionable as it could stand for (J)ava like that in JNIOR. Or it could just be because we like starting names with ‘J’.

But JANOS started to make sense when we learned that Janus was an ancient Roman figure, spirit or god that guarded doorways and archways. Depicted with his face pointing in both directions he was the god that dealt with all things coming and going, past and future, beginning and ending. This could loosely be considered to be the controller or god of I/O, right? Bingo!

So unless something better were to come up everyone seemed cool with the name and we quickly made it over our first real hurdle. A quick scan of the Internet led us to believe that “JANOS” would be relatively unencumbered for this use. The first C files were cast with a Copyright header referring to the code as JANOS. The earliest inception date seems to be the 15th of December 2011. That would be for main.c.

Processor Selection

I suppose that I could get into the reasoning behind the selection of the Renesas RX600 processor. Initially we developed using the RX62N and then moved to the RX63N when that became available.

To start I would have to say that there certainly wasn’t an exhaustive search and very few processors were considered for JNIOR. Basically it was between some flavor of ARM and one or two micro-controllers that we had briefly looked into some years earlier. Luckily the local sales support for Renesas stepped in to tell us about the RX600 series. We had been inquiring about an earlier product. I had just wanted to pick something with the proper I/O mix that can handle the job and to pick it quickly.

Processors these days are quite complex. Most of the techniques employed in their design are now common place but 50 years ago things were somewhat simpler. Pipelining is an example. We want code to execute efficiently and quickly. Speed being somewhat of concern as we were growing tired of the performance (or lack of) in the Series 3 JNIORs. Most all processors these days employ a form of pipelining wherein multiple instructions at various stages are being processed simultaneously. This manages memory access and calculations making optimum use of each and every clock cycle.

I had been figuring on around a 100MHz system clock. That by itself isn’t fast given that PCs and smart phones all run an order of magnitude faster. But the JNIOR is just a controller and cost is a consideration. I also had wanted to avoid some of the concerns that come with high frequency circuit design.

At the same time I was concerned about code size. The operating system would surely be quite large and the ARM appeared to have a fixed 32-bit instruction size. That means that to simply increment a register that instruction would consume 4 bytes of program memory. I will have to admit that I have no experience with ARM at this point. I figure that migrating JANOS to it is inevitable. But I was attracted to the RX line as it boasted both fast execution and compact code size. Having variable length instructions and instructions that combine operations makes the pipeline design difficult if not nearly impossible. But the RX has apparently gotten it done.

Beyond the I/O pin count of the micro-controller and the included set of peripherals, I had also wanted a good amount of high-speed internal Flash for program storage. The processor also needed a good amount of high speed internal RAM for stacks. There also needed to be some form of internal EEPROM or erasable Data Flash for critical configuration settings. I had hoped to be less dependent upon the external memory devices which necessitate longer access timing. The RX62N seemed to cover my needs.

So a quick decision was made and I proceeded to pick up an RX62N evaluation kit. That was the sum and total of our (not so) elaborate processor selection process.

Considerations for Coding

Of concern is the IDE supplied for the RX line. Looking back I can’t give Renesas good grades on this front. Their home grown IDE was full of rookie GUI bugs among other things. They quickly moved to an Eclipse based IDE which caused a bit of a headache at one point. The IDE gets the job done but there are soooo many configuration settings that even creating a branch in code for development is a challenge. It works though.

But for operating system development you absolutely need good access to assembly code. Unlike 50 years ago the IDE now has you developing directly in C and hides any assembly aspect by supplying hidden initialization files and built-in libraries. That is all good if you are writing a simple single-threaded program but I was not. So to start I took the usual “Hello World” sample and had to dig into it to find all of the hidden code. We were not going to develop JANOS dependent on any one IDE or processor. So I needed access to each and every byte generated and incorporated in the resulting object files.

Once the startup code was located and I proved that I could pull that out of hiding, I had to deal with libraries. The IDE supplies its own “Standard C Libraries”. Again that is great for simple program development. But here again taking JANOS to another platform would mean different library code and therefore uncertainty in result. I would also be developing a preemptive multi-tasking environment and C libraries that are not guaranteed to be reentrant or that use even a single static variable spell disaster.

So JANOS required its own C Library code. Trying to prevent the IDE from supplying its own library code proved to be an issue. I managed to find the right balance that kept the built-in libraries out of the way. Even today it remains a concern. I’ve had to utilize uniquely named headers supplying standard named functions (i.e. pintf, etc.). It has been a challenge where the IDE should just have let me tell it that I did not want any libraries.

Even at the instruction level there are macros that need to be considered. If you add two 64-bit variables on a 32-bit processor there is no single instruction available. The IDE inserts a block of code that performs the operation. So that sum becomes several instructions the code for which is IDE or manufacturer specific. This you cannot prevent and it is a necessity but I needed the source code for those macros. Again this is to insure proper operation of the preemptive tasking system and to increase confidence in moving to other platforms. None of these seemingly personal requirements of mine seemed to be received by Renesas with any evidence of understanding. Simply put, reverse engineering is also a necessity.

I also needed to understand the approach the Renesas compiler uses for function calls. What processor registers are used and how stack space allocated and released. In addition I needed to understand the precise response to interrupts. This is key in creating a pure multi-tasking environment. Fortunately those topics are covered (briefly) in the Renesas compiler documentation. This does present a hurdle say if I want to use the IAR RX compiler at any point.

Obviously JANOS exists and I managed to find some level of comfort and control over the development environment.

If you are setting out to write an Operating System on par with Linux or JANOS you don’t want to do this. This is akin to standing at the edge of a cliff and looking straight down. If you realize how much work you have ahead of you, you will likely lose confidence in yourself. Then again, if you are staffing up to get the job done then understanding what needs to be done is critical.

Here I am going to list the sections of code that had to be developed to get JANOS to where it is. I would bet that this list will be missing some of it but here goes. This will also be in rough chronological order. At least as to when coding for the section was started.

Startup – Basically the main.c for the OS program. It is responsible for configuring hardware and each subsystem. Eventually this terminates and becomes the “Idle Process” executing an infinite wait look and collecting unused process time.

Diagnostic Serial Port – The RS-232 (COM) port code so boot messages can be output and the command line interface developed.

Process Management – The ability to execute more than one process through preemptive multitasking. Requires a 1 millisecond tick interrupt and the ability to swap process context with minimum overhead. This also allows processes to terminate or be terminated. This subsytem maintains the uptime and realtime clocks.

Ethernet Interface – Configures the Ethernet peripherals and external PHY. This handles the delivery of outgoing packets and the reception of packets. This establishes the high-priority Network process needed to insure that network traffic can be received and processed quickly and efficiently. The Network Process was the first process created for JANOS and the first to run outside of the Startup/Idle Process.

Command Process – The Command Line executes as its own process. This process is awakened by a keystroke on the RS-232 (COM) port and will handle all Command Line access. You will also be able to access this through a Telnet connection and via the Websockets Interface as well.

Command Line – Prompts for command entry and allows for convenient entry of textual commands. Includes a set of built-in commands and facilitates the execution of application programs. Maintains command history allowing commands to be easily repeated.

Memory Manager – Maintains Heap memory. This gives processes the ability to allocate memory for different purposes and then to return it for reuse. Efficiently manages the free memory block pool. Strives to minimize fragmentation and improve the availability.

Date & Time – Provides the ability to set and read the hardware RTC. Maintains the time of day in milliseconds since some epoch. Provides the ability to convert the millisecond count into year-month-day formats. Handles time zones and Daylight Saving Time.

System Process – The operating system itself has a number of background tasks it must attend to while other processes are busy with their own tasks. These are performed by the System Process.

Network Protocol Stack – To exist on the network the JNIOR must handle standard protocols at a low level such as ARP, ICMP, DHCP and DNS. Then once IP addressing is established the higher level protocols like IP, UDP/IP and TCP/IP are required.

Digital I/O – Subsytem handles the Digital Inputs and Relay Outputs. Handles counters and usage metering.

File System – Provides that ability to store and retrieve data as files. This handles file storage as it distributed across memory technologies. The JNIOR stores files in the non-volatile SRAM, in Flash (/flash), and in volatile Heap (/temp). This includes static content from the Program ROM (/etc). Provides for file access controls using permissions modeled after Unix.

C Libraries – JANOS is written in C and requires the standard C library. In order to insure the re-entrant and thread-safe aspect of the C Library you have to have the source code and therefore have written a custom library.

AUX Serial Port – While very similar to the Diagnostics port, the AUX port includes handshaking capabilities and can support RS-485 communications.

FTP Server – Required to get files on to and off of the JNIOR.

WebServer – Used to serve files and create web sites.

Websockets – WebServer HTTP/HTTPS connections can be upgraded to handle the Websockets Protocol. This provides for the ability to remotely monitor and control the JNIOR.

JNIOR Protocol Sever – Provides for legacy support of the JNIOR protocol which allows for remote monitoring and control of the JNIOR.

Registry System – Subsystem to manage name-value pairs for system configuration.

JVM – Java Virtual Machine permitting programs written in Java to be executed. This includes a complete stand-alone Java Runtime Environment for the JNIOR. Uses a Native interface with the operating system.

Library File Handling – The ability to access and decompress files stored in ZIP and JAR files. Necessary for the execution of externally compiled Java programs. Also expands the File System allowing the WebServer to serve files directly out of a ZIP library.

External Module Support – Configures and utilizes the Sensor Port to manage external expansion modules.

Network Time Protocol – NTP synchronizes the JNIOR clock with the rest of the world.

Beacon Protocol – Required to facilitate initial network configuration. Used by the Support Tool in managing collections of JNIORs.

Field Update – The ability to update JANOS in the field. Allows a UPD file to be loaded and the operating system updated on reboot. This must be a fault tolerant procedure.

Sockets – The means by which Java application programs integrate with the network stack.

Users – The ability to create users, maintain credentials and require login. Users can be created, disabled and removed. There are different user permissions/capabilities.

Email – JANOS has the ability to send email notifications.

Inter-process Messaging – JANOS supports a Message Pump which is a system by which messages can be circulated between processes. JANOS can notify applications of certain events.

I/O Logging – The ability to log and display DIgitial I/O events and serial communications.

Network Capture – The ability to capture network traffic for use in debugging. JANOS creates files compatible with WireShark.

Security – Implements SSL/TLSv1.2 secure communications. This includes multi-precision math libraries, message digest calculations, encryption and decryption. Supports RSA, RC4, DES and others. Automatically generates self-signed certificates.

Server-side Scripting – Handle PHP-like server side scripting to support the development of sophisticated dynamic websites.

Regex Engine – Support the ability to perform search and replacement operations using Regular Expressions.

Watchdogs – The ability to detect when program operation has failed and then to take action to restore operation.

User Groups – Create user groups and assign users for use in handling file permissions.

If I am missing anything feel free to ask about it. Some of these items are extremely complex in and by themselves while others were not all that complicated. It has taken some 5 years in development. The OS consists of over 400 individual source files and countless lines of code. Does anyone really know how to count code lines? Anyway, slowly I will proceed to describe the implementation details.

 

By | On October 28, 2017 11:41 am | No Comments |

JANOS History

In 2011 it became apparent that we needed to redesign the JNIOR. This was not because its features and functions were lacking in any serious way. It was more due to the fact that product performance was limited and starting to fall behind that expected by the market. We also could tell that certain devices we used were approaching some kind of End of Life. Specifically the Dallas/Maxim-IC DS400 processor.

We needed to develop hardware around a new processor. While that was certainly doable from a hardware perspective, it meant that none of the existing JNIOR operating system code and its applications would be usable. Regardless of processor selection we would be faced with a new real-time operating system (RTOS) and have to develop a new approach to applications. This would mean as well that the user would see a totally different user interface and would have to learn new procedures for the JNIOR.

Would the result actually be a JNIOR? Certainly we would not be creating a drop-in product revision. This was not going to be an acceptable approach. The main point in the specification of the next series of JNIOR demanded that it remain consistent and familiar to the customer base. If this was not the case then we would never be able to stop producing the Series 3 and move to the Series 4 in any seamless fashion.

So in order to develop a revised series of the JNIOR without disrupting product use we had to both redesign the hardware and the firmware. We needed an RTOS were we would have complete control over the user interface and product capabilities. Given that existing operating system offerings were bloated with generic code, burdened with licensing issues, and expensive the decision was made to write our own.

Series 4 Product Specification

So the first step in any engineering project is to write the Specification document, right? It shouldn’t be any different here. But we never did create a specification document for this. Actually in this case there was no need. The Series 3 JNIOR in and by itself was our design specification.

The intent of the effort was to create a 100% drop-in revision to the Series 3 that utilized a new processor. That meant that it couldn’t look different form a Series 3. All of the external hardware connections had to remain consistent. The external expansion modules needed to continue to be usable. And, it still needed to execute the existing application programs. Basically, once the Series 3 were no longer in production we needed to be able to ship a customer a replacement JNIOR that didn’t involve re-engineering the application and modifying the installation.

That said, the intent also was for the new version of JNIOR to demonstrate “improved performance”. This mostly referred to processing speed. The Series 3 JNIORs were taking upwards of a minute just to boot and load applications. We had to improve on that. But by just how much? It was left unstated.

There were also (naturally) software issues with the existing Series 3 line. Many were rooted in 3rd party code for which we had no access and no ability to rectify. Some of those bugs we indeed started to consider as features. It would make no sense to replicate any of those. The revised JNIOR would be able to address those issues even if it meant some slight change in user interface or procedure. This was to be minimized however.

We had to consider licensing and copyrights. We could not directly convert the Dallas/Maxim-IC TINI operating system for our own use. We absolutely needed to develop our own new and improved code to avoid any legalities or added licensing expense.

Further we wanted to insure that we would not encounter any deficiency or issue caused by 3rd party code. These tended to be costly in our experience as a solution generally was not forthcoming and we would spend a large effort in creating our own work-around. So the new operating system would not utilize 3rd party code if possible. We were to have 100% control of, and knowledge of, the source code. This allowing us to guarantee bug fixes in an unprecedented short turnaround.

Finally, the door had to remain open for the introduction of new functionality that would improve the value of the product.

So, I believe that this conveys the (previously unwritten) set of specifications behind the creation of the Series 4 JNIOR and the JANOS operating system. Now that the product revision is reaching its own maturity I’ll let you create the report card.

Processor Selection
(Fall 2011)

With our goals set we obviously first and foremost had to select a new processor to sit at the core of the new JNIOR series. This would be a good topic for the Hardware section as there were a number of considerations involved. We decided to try the Renesas RX600 line and specifically the 144-pin version of the RX62N.

We obtained an RX evaluation kit, installed the Renesas IDE and wrote some simple “Hello World” type programs. I then jumped into the assembly code and looked carefully at the register handling in C subroutine calls, the complexity of startup code, and the handling of interrupts. It also mattered how the program stack was handled. And there needed to be some atomic instructions (for mutex implementation). I could experiment with these things with the evaluation kit. It also mattered how code was optimized. Was code compact and yet still execute efficiently?

The micro-controller’s complement of I/O pins and their flexibility were of interest. There had to be a good set of peripherals available. Enough to handle at least 3 serial streams. There needed to be flexibility in an external memory bus. Much had to be considered.

Once the decision was made new schematics were created and a board laid out for the first Model 410. The first prototype was hand assembled and made to execute a simple “Hello World” program through the RS-232 (COM ) port. That was (to the best of my recollection) December of 2011.

By | On October 28, 2017 11:34 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 ain't broke... Don't fix it!

I fully understand this mentality. Believe me. I am still using the Summer 9 version of Altium to lay out 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 roll back 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 (https://integpg.com/jnior-support-tool). 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 JNIOR Web Page which is 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 JNIOR Web Page is used over a secure connection (HTTPS).

Series 4 Email Setup

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 JNIOR Web Page 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 JNIOR Web Page. 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 |

Public Web Pages

Since today you really need to keep the Login requirement enabled on your JNIORs, what if you want to serve some Web data publicly? You know, without having everyone use a password?

Well, you probably aren’t aware that in addition to the default WebServer root of /flash/www there is another called /flash/public. Yep. You can probably guess now that anything you put in /flash/public will be served by the WebServer without requiring that the client login/authenticate. Everything else remains secure and requires your login for access.

In fact that is how our HoneyPot unit that is sitting out directly on the Internet lets you access the following page:

http://honeypot.integpg.com/map.php

There you didn’t need to login and yet that JNIOR is secure and nothing else can be accessed or modified without securely logging in.

Pretty sweet, eh?

Oh and you could rename /flash/www.zip as /flash/public.zip and serve the DCP publicly. Wait! wouldn’t that be dangerous?

Well, not really. The DCP makes a secure Websockets connection back to the JNIOR. That Websockets interface requires a login (assuming you haven’t also disabled that). So when you open the public DCP you are again asked to login. You have to properly authenticate before you can really do anything.

By | On October 24, 2017 12:00 am | No Comments |

Trusted Secure Access

The Series 4 JNIOR supports TLS v1.2 and provides for secure communications through HTTPS port 443. Your unit’s certificate however is not signed by a Trusted Root Authority and you will need to approve access. While that procedure results in secure communications the browser tends to make you think otherwise. But, there is a way to get the coveted Green Secure Logo.

Now when you try to make such a connection you are more than likely going to be confronted by something like this:

I am using Chrome and every browser has its own way to scare you. In this case I would need to use the ‘ADVANCED’ link in the lower left. In clicking ‘ADVANCED’ there is a bit of an explanation. Here I have to option to proceed.

Note that it says “unsafe” but you are accessing the JNIOR and what does the browser know about that? Why is the JNIOR unsafe? But if you were heading to your bank and plan to enter all of your secrets I guess then this might be unsafe. When you proceed (and the JNIOR is safe!) you get the page.

Even though it says that you are “Not Secure” the communications are indeed encrypted and quite secure. The browser just can be certain that you are communicating with someone or something that you can trust. By the way, I snapped the image before the map markers appeared.
Generally you can click on the red “Not Secure” logo and obtain some further details. There generally is some way to view the certificate and potentially trust it. I will show you how that is done at least with my version of Windows 7.

I am going to take you through the manual procedure as a browser-independent approach. First you will need a copy of the JNIOR’s certificate. Now it may be possible to get that using the browser. You would need to do that if you were not the administrator of the JNIOR. That would be the case for you and our HoneyPot unit.
Assuming that you are the administrator of your JNIOR, log into the the command line Console. We are going to use the CERTMGR command to get a copy of the current certificate. Note that when you change the unit’s IP address or hostname a new certificate will be automatically generated That new certificate will be different than one that you may have trusted. So you may need to repeat this for units running DHCP if they are assigned a new IP address and simply don’t continue to renew the same one.

HoneyPot /> help certmgr 
CERTMGR 
-V Verify installed keys and certificate 
-C [file] Regenerate Certificate [Install file] 
-S file Verify signature on certificate 
-K file Install RSA Key Pair 
-D [file] Decode and dump certificate [file] 
-E file Export certificate to file 
-B Export in binary 
-G [len] Generate key pair [bit length] 
-R Restore default credentials 
SSL Certificate Management. 
HoneyPot />

So here we see that the -E option will export the certificate. Simply use the following command to export the certificate to a file. The CER extension is appropriate.

Download the honeypot.cer certificate

Finally download this file to your PC. You can do that through the Folders tab in the DCP by double-clicking the file or through FTP however you like.

Now we are going to use the Microsoft Management Console (MMC) to import this certificate into the trusted area. Note that by doing so you are not creating any risk. The JNIOR’s certificate cannot be used to sign other certificates and having it present in the Certificate Store will not trust anything other than your JNIOR (and then only for as long as that certificate stays active).
In the following procedure you will open the MMC as an administrator, add the snap-in that handles Certificates, and import the JNIOR’s certificate into the proper trusted store.

  1. Open the Start Menu and enter “MMC” to search.
  2. Right-click on mmc.exe and select ‘Run as Administrator’. Allow the console to run.
  3. Click ‘File’ and “Add/Remove snap-in..’ from the menu bar.
  4. From the Available snap-ins select ‘Certificates’ and click ‘Add’. You will be managing certificates for the ‘Computer Account’ on the ‘Local Computer’. Click ‘Finish’ and ‘Ok’ to return to the main MMC screen.
  5. Expand ‘Certificates (Local Computer)’.
  6. Expand ‘Trusted Root Certificate Authorities’.
  7. Click ‘Certificates’. A lengthy list should appear on the right.
  8. Right-click on ‘Trusted Root Certificate Authorities’ back on the left and select ‘All Tasks’ and ‘Import…’. You can also right-click on ‘Certificates’ over there and get to the same ‘Import..’ action.
  9. Click ‘Next’ and follow the WIzard. You will browser for your CER file. Then use ‘Next’, ‘Finish’ and ‘Ok’ to perform the import. You should see a message indicating success.

Your certificate will now appear in the lengthy list of root certificates. Note that at some point you may have older certificates here for JNIORs. You can right-click them to ‘Delete; the older ones. Make sure to only delete JNIOR certificates. You don’t want to disturb the computers normal chains of trust.
Now exit the MMC and you don’t need to save the console.
Access your JNIOR using the HTTPS form of URL in your browser and you should now see the Green Secure logo!

Attached is the CER file for HoneyPot as of this writing. This has been pretty stable as this unit has a fixed IP address. If you add this to your Trusted Root Certificate Authorities store you will get the Green Secure logo too.
By the way the JNIOR can show you the content of these CER files. It is pretty cryptic and some of us know what it all means.

HoneyPot /> certmgr -d honeypot.cer
0000  30 82 02 ED    SEQUENCE {  (749 bytes)
0004  30 82 02 56    |  SEQUENCE {  (598 bytes)
0008  A0 03          |  |  [0] EXPLICIT {  (3 bytes)
000A  02 01          |  |  |  INTEGER 02
                     |  |  }
000D  02 04          |  |  INTEGER 2499A900
0013  30 0D          |  |  SEQUENCE {  (13 bytes)
0015  06 09          |  |  |  OBJECT IDENTIFIER 1.2.840.113549.1.1.11
0020  05 00          |  |  |  NULL
                     |  |  }
0022  30 81 81       |  |  SEQUENCE {  (129 bytes)
0025  31 20          |  |  |  SET {  (32 bytes)
0027  30 1E          |  |  |  |  SEQUENCE {  (30 bytes)
0029  06 03          |  |  |  |  |  OBJECT IDENTIFIER 2.5.4.10
002E  0C 17          |  |  |  |  |  UTF8STRING 'INTEG Process Group Inc'
                     |  |  |  |  }
                     |  |  |  }
0047  31 17          |  |  |  SET {  (23 bytes)
0049  30 15          |  |  |  |  SEQUENCE {  (21 bytes)
004B  06 03          |  |  |  |  |  OBJECT IDENTIFIER 2.5.4.11
0050  0C 0E          |  |  |  |  |  UTF8STRING 'JNIOR Controls'
                     |  |  |  |  }
                     |  |  |  }
0060  31 1D          |  |  |  SET {  (29 bytes)
0062  30 1B          |  |  |  |  SEQUENCE {  (27 bytes)
0064  06 03          |  |  |  |  |  OBJECT IDENTIFIER 2.5.4.3
0069  0C 14          |  |  |  |  |  UTF8STRING 'honeypot.integpg.com'
                     |  |  |  |  }
                     |  |  |  }
007F  31 25          |  |  |  SET {  (37 bytes)
0081  30 23          |  |  |  |  SEQUENCE {  (35 bytes)
0083  06 09          |  |  |  |  |  OBJECT IDENTIFIER 1.2.840.113549.1.9.1
008E  16 16          |  |  |  |  |  IA5STRING 'bcloutier2@comcast.net'
                     |  |  |  |  }
                     |  |  |  }
                     |  |  }
00A6  30 1E          |  |  SEQUENCE {  (30 bytes)
00A8  17 0D          |  |  |  UTCTIME[13] 170322173023Z
00B7  17 0D          |  |  |  UTCTIME[13] 190322173023Z
                     |  |  }
00C6  30 81 81       |  |  SEQUENCE {  (129 bytes)
00C9  31 20          |  |  |  SET {  (32 bytes)
00CB  30 1E          |  |  |  |  SEQUENCE {  (30 bytes)
00CD  06 03          |  |  |  |  |  OBJECT IDENTIFIER 2.5.4.10
00D2  0C 17          |  |  |  |  |  UTF8STRING 'INTEG Process Group Inc'
                     |  |  |  |  }
                     |  |  |  }
00EB  31 17          |  |  |  SET {  (23 bytes)
00ED  30 15          |  |  |  |  SEQUENCE {  (21 bytes)
00EF  06 03          |  |  |  |  |  OBJECT IDENTIFIER 2.5.4.11
00F4  0C 0E          |  |  |  |  |  UTF8STRING 'JNIOR Controls'
                     |  |  |  |  }
                     |  |  |  }
0104  31 1D          |  |  |  SET {  (29 bytes)
0106  30 1B          |  |  |  |  SEQUENCE {  (27 bytes)
0108  06 03          |  |  |  |  |  OBJECT IDENTIFIER 2.5.4.3
010D  0C 14          |  |  |  |  |  UTF8STRING 'honeypot.integpg.com'
                     |  |  |  |  }
                     |  |  |  }
0123  31 25          |  |  |  SET {  (37 bytes)
0125  30 23          |  |  |  |  SEQUENCE {  (35 bytes)
0127  06 09          |  |  |  |  |  OBJECT IDENTIFIER 1.2.840.113549.1.9.1
0132  16 16          |  |  |  |  |  IA5STRING 'bcloutier2@comcast.net'
                     |  |  |  |  }
                     |  |  |  }
                     |  |  }
014A  30 81 9F       |  |  SEQUENCE {  (159 bytes)
014D  30 0D          |  |  |  SEQUENCE {  (13 bytes)
014F  06 09          |  |  |  |  OBJECT IDENTIFIER 1.2.840.113549.1.1.1
015A  05 00          |  |  |  |  NULL
                     |  |  |  }
015C  03 81 8D       |  |  |  BITSTRING[140] Encapsulates {
0000  30 81 89       |  |  |  |  SEQUENCE {  (137 bytes)
0003  02 81 81       |  |  |  |  |  INTEGER
                     |  |  |  |  |     A99483174B2EBC8578ECEA5BE9F75840703B06EA49D9333D
                     |  |  |  |  |     493D035A8D84DB5AB7E5491D334BAF1B59A3A271E25C4276
                     |  |  |  |  |     D410F3B3C90E801E89A162C6A282EC51AB05CF9731561A95
                     |  |  |  |  |     22A0B3039DF72FA25BA1061E6BBB7A1AA6B287A314FDDBB9
                     |  |  |  |  |     E1034B45D5E1FFC15A59C40D772D3CDAD6142A707650F11E
                     |  |  |  |  |     BCD30CFF75E65E91
0087  02 03          |  |  |  |  |  INTEGER 010001
                     |  |  |  |  }
                     |  |  |  }
                     |  |  }
01EC  A3 70          |  |  [3] EXPLICIT {  (112 bytes)
01EE  30 6E          |  |  |  SEQUENCE {  (110 bytes)
01F0  30 1D          |  |  |  |  SEQUENCE {  (29 bytes)
01F2  06 03          |  |  |  |  |  OBJECT IDENTIFIER 2.5.29.14
01F7  04 16          |  |  |  |  |  OCTETSTRING[22] Encapsulates {
0000  04 14          |  |  |  |  |  |  OCTETSTRING[20]
                     |  |  |  |  |  |     29CB0357BCDD26E78AD5E564C1D087B0  )..W..&....d....
                     |  |  |  |  |  |     3B583082                          ;X0.
                     |  |  |  |  |  }
                     |  |  |  |  }
020F  30 0C          |  |  |  |  SEQUENCE {  (12 bytes)
0211  06 03          |  |  |  |  |  OBJECT IDENTIFIER 2.5.29.19
0216  04 05          |  |  |  |  |  OCTETSTRING[5] Encapsulates {
0000  30 03          |  |  |  |  |  |  SEQUENCE {  (3 bytes)
0002  01 01          |  |  |  |  |  |  |  BOOLEAN TRUE(255)
                     |  |  |  |  |  |  }
                     |  |  |  |  |  }
                     |  |  |  |  }
021D  30 3F          |  |  |  |  SEQUENCE {  (63 bytes)
021F  06 03          |  |  |  |  |  OBJECT IDENTIFIER 2.5.29.17
0224  04 38          |  |  |  |  |  OCTETSTRING[56] Encapsulates {
0000  30 36          |  |  |  |  |  |  SEQUENCE {  (54 bytes)
0002  87 04          |  |  |  |  |  |  |  [7] 32C5224B  2."K
0008  82 14          |  |  |  |  |  |  |  [2]
                     |  |  |  |  |  |  |     686F6E6579706F742E696E7465677067  honeypot.integpg
                     |  |  |  |  |  |  |     2E636F6D                          .com
001E  82 08          |  |  |  |  |  |  |  [2] 686F6E6579706F74  honeypot
0028  82 0E          |  |  |  |  |  |  |  [2] 686F6E6579706F745F6A6E696F72  honeypot_jnior
                     |  |  |  |  |  |  }
                     |  |  |  |  |  }
                     |  |  |  |  }
                     |  |  |  }
                     |  |  }
                     |  }
025E  30 0D          |  SEQUENCE {  (13 bytes)
0260  06 09          |  |  OBJECT IDENTIFIER 1.2.840.113549.1.1.11
026B  05 00          |  |  NULL
                     |  }
026D  03 81 81       |  BITSTRING[128]  0 unused bits
                     |     2B42E05E331AEEB265F4DAC118DF73E7  +B.^3...e.....s.
                     |     F555D72605F6ECAB67D860324A7C5056  .U.&....g.`2J|PV
                     |     14C5203337A98C2157D85C57A736B82D  .. 37..!W.\W.6.-
                     |     DA88475E93A6C9FC2C5983678C8D461A  ..G^....,Y.g..F.
                     |     9CE7F53A2766DBBD26C0B99CE1F4514F  ...:'f..&.....QO
                     |     6BAC3D09C33000BC7E5F6151C0BA175F  k.=..0..~_aQ..._
                     |     29B6E73B8E7FEBAE1099269A9AFD7067  )..;......&...pg
                     |     17C67CF9C7F17EBB3F8DB2ED4353C2D1  ..|...~.?...CS..
                     }
HoneyPot />

Download the honeypot.cer certificate.

By | On October 20, 2017 10:02 am | No Comments |

JNIOR Built-in UPS

A controller depends on the availability of good clean and stable power. Unfortunately with the JNIOR any small interruption or glitch in the power source results in a reboot. Applications need to be written to handle unscheduled restarts.

The recommended solution is to place all critical systems on an Uninterruptible Power Source (UPS) like those available from APC.

Things like air conditioner compressors can cause momentary dips in local power. The amperage of the power circuit and distance from the subpanel come into play here. The voltage available at the end of wiring that operates near its rated current or that may be lengthy tends to be easily affected by current surges. The voltage drops very briefly. That minor drop can be significant enough to reboot a JNIOR located on that circuit. And, the addition of a separate UPS means extra cost.

The 412DMX model of JNIOR is being developed and here we are testing the new internal power circuit. This JNIOR will incorporate “ride-thru” power supply technology. Regardless of the selection of buzz words that we use to describe it, the basic function is to store enough energy to keep the JNIOR powered through a momentary loss of external power. The implementation will flash the blue power LED to indicate the loss of external power. If power is restored before the stored energy runs out then the JNIOR continues unaffected. The loss of external power and its restoration are logged in the system log. Here we let it run out to see how long we really have.

Can you do that? Does it work? Well observe the first prototype:

By | On October 19, 2017 9:33 am | No Comments |

Command Line Access – Diagnostic Port

The birth of any operating system, and this is true for JANOS (Series 4) as well, begins with serial access to a command line interface. There are often boot and diagnostic messages transmitted over that first communications channel. The Series 3 is based up the TINI Operating System and the RS-232 (COM) port located at the bottom of the unit next to the ETHERNET (LAN) port is that very diagnostic channel for TINI.

The DB-9F connector there was designed to be directly connected to the COM serial port on the PC. Only a straight-thru M-F serial cable was required. Communications are at 115.2 Kbaud, 8 data bits, 1 stop bit and no parity. There is no handshake and this port is 3-wire (Rx, Tx and GND). Today no PC is manufactured with such a COM port. Fortunately USB-to-Serial adapters are readily available and provide the necessary compatible connection point.

If you are working with the JNIOR for the first time you may want to first try this serial connection. A new unit or one that has been configured to work elsewhere will not be immediately compatible with your network. While there are alternative solutions to the network setup the serial connection is the most basic. It is the only place where you can “watch” the unit go through it’s boot procedures.

This connection point and its use remain consistent through the Series 4 products. The command line interface found there is the same. There is a huge difference in response (where the Series 4 shines) and the diagnostic messages are different.

Now with the JNIOR powered and the serial port connected to the PC you can use a Terminal program. We used to use hypertext but now MS no longer distributes that. Nice of them, eh? You can use PuTTY (http://www.putty.org/) and configure for the proper baud rate (115,200) and data format (8/1/none).

If you open the port and strike any key (i.e. Enter) you should obtain something like the following on a Series 3).

Here, for example, is a terminal program that I designed for JNIOR use in-house but PuTTY works perfectly. This one has the capability to force a jnior:jnior login (administrator account ‘jnior’, default password ‘jnior’) because, as you can imagine, we here at INTEG log into JNIORs a lot!

If you have obtained your JNIOR from a prior installation the passwords may have been changed. There is a significant chance though that they have not and the above jnior:jnior login could work. Most Series 3 JNIORs have gone into physically secure networks where customers have not had the need to vary from default passwords.

If you can successfully login to the ‘jnior’ account you will reach the command line. Note that if you access the command line through a network Telnet connection the ‘TINI’ prompt is replaced by the unit’s defined hostname. Byte default the hostname is the unit’s serial number prefixed with ‘jr’.

There are a number of commands available at this point. The command line here emulates some DOS commands and some Linux commands. the goal being that it should appear familiar to those that work in either environment. But there are differences and the HELP command can be used to retrieve some limited assistance.

If the ‘jnior’ account password has been changed there is another administrator’s account that you can try. Try to login to the ‘admin’ account using the default password ‘admin’.

The Series 3 does not have a USERS command that would list the set of defined users. This has been added in the Series 4. Most customers are unaware of the ‘jnior’ account out of necessity but are not aware that there are also ‘guest’, ‘user’ and ‘admin’ accounts the latter also being an administrator.

On the Series 3 you can check the available accounts by displaying the content of the etc/passwd file. There is an entry in this file for each user. The username is apparent although the password is encrypted. The trailing user ID represents the user level. A ‘128’ signifies an administrator. A ’64’ a user who does not have administrator privileges but can control the unit’s outputs. And the ‘0’ representing a guest who can monitor the JNIOR’s IO status but cannot alter anything.

It is highly likely that the prior administrator of your JNIOR was unaware of these accounts and you can gain access using the ‘admin’ account. You can then utilize the PASSWD command to reset the password for the ‘jnior’ account. Um, perhaps setting it back to the default until you place your Series 3 JNIOR in service on-line someplace.

Note that you can use the ‘rm etc/passwd’ command and delete the passwd file and reboot (use the ‘reboot’ command or pull power). The boot process will restore the default etc/passwd file and therefore all of the default accounts.

If you cannot gain access with either the ‘jnior’ or ‘admin’ accounts then a more elaborate procedure will be required. That is beyond the scope of this thread. I’ll address it in another.

So now you are connected to the serial COM port (labelled “RS-232”) and it is supposedly the “diagnostic port”. That would tend to mean that the system might just blurt diagnostic messages out of this port regardless of what you might otherwise be using it for. Well that is true. Generally these messages are only issued during boot up. And, you can disable them if you are planning on using the port to communicate with another device.

So let’s watch the boot. The Series 3 is painful in that the boot takes a minute. That is very much unlike the Series 4 which completes the boot process so fast that you have barely removed your hand from the power connector. Here’s the Series 3 boot:

By the way the POR (Power On Reset) count reported in the above video is 00000001 because the battery in that unit is DEAD. This is likely going to be the case in many Series 3 units now that the line is over a decade old. If you are handy with the soldering iron that can be fixed. See the post 310/312/314 Battery Replacement.

By | On October 11, 2017 10:57 am | No Comments |

DHCP not working

Under certain conditions the Series 3 JNIORs are not able to obtain IP addressing via DHCP. This is due to a flaw in the early implementation of IPv6, The bug is part of the built-in TINI operating system supplied by the component manufacturer and INTEG is not able to directly correct it.

You can disable the use of IPv6 by making the call to com.dalsemi.tininet.TININet.enableIPv6 with a ‘false’ boolean parameter. As this would require a change to the OS release and the product being no longer in production and deprecated, the recommendation is to disable IPv6 on the local subnet or use a fixed IP address. Since a fixed IP address is usually required and few JNIORs actually use DHCP the OS update is not scheduled.

Alternatively an application can be set to run on boot that makes the call.

By | On October 11, 2017 10:56 am | No Comments |

Series 3 Power Supply

If you have a 310/312/314 Series 3 JNIOR you may also have its wall power supply. As we ship JNIORs in bulk we often supply them without the corresponding power supplies. Customers often use their own power sources. So you might just have the JNIOR or perhaps its original supply is still in service with a replacement Series 4.

By itself the JNIOR is not self explanatory. It’s a 6″ by 4″ by a little over 1″ black box with connectors filling the 4 sides. On the cover there are places for 18 LED indicators. You may recognize two DB-9F connectors for serial communications. You likely notice the CAT5 LAN connector. But the rest is somewhat mysterious. So what is next?

Typically we supply the JNIOR with a 12VDC Regulated 1A wall mounted power supply. Some series 3 are labelled with ‘9-24V DC/AC’ and some with ’12-24V DC/AC’. While the JNIOR will operate with a 9VDC supply that turns out to be too close to the low side and does not afford enough margin to insure reliable operation under all conditions. So at some point we made 12V the recommended low end.

The 4-position connector at the top of the unit is for the supply. The positive lead is connected to either of the left two positions (1 or 2) and the negative to either of the right two (3 or 4). We supply connectors wired to the center two positions, positive to pin 2 and negative to pin 3. The other two pins are there to allow you to tap this voltage for use in simple circuits involving the digital inputs or relay outputs as needed. Of course if an AC power source is used it is connected to pins 2 and 3 without regards to polarity.

One advantage to this particular design is that if you make an error and connect the DC supply backwards it will still work. Note though that the negative lead IS NOT circuit GND. More on that later.

Using any appropriate power source (and we all have a box of them laying around these days) the JNIOR should power up. A GREEN LED to the left next to the power specification will illuminate to indicate that power has been applied. We improved on this in the Series 4. The leftmost LED on the Series 4 is BLUE. That greatly enhances the product. :-)

Actually, it is hard to resist a BLUE LED. They were a rarity for many years. When we built the first Series 4 units the prototype boards were installed in Series 3 enclosures. I elected to use a BLUE LED for the power indicator so we could easily tell a prototype Series 4 from a standard Series 3. We have so many mounted around the office. It was supposed to be temporary but democracy prevailed and we were destined to leave it that way.

So power up your Series 3. If the LED illuminates then your internal power rails have reached their proper voltages. You should also see the rightmost LED (ORANGE) come on for a brief period. That is illuminated during the OS boot. It also flashes indicating connection status. More on that at some other time. The rest of the indicators are RED and will display the state of the corresponding input or output.

By the way if you have a Series 4 you will notice one other difference (besides the BLUE LED). When the Series 4 boots the ORANGE Status LED flashes on for no more than a second or two. That is because JANOS boots in just a couple of seconds and applications start in seconds.

The operating system on the Series 3 however can take minutes to boot. The ORANGE status LED only illuminating as the base TINI operating system loads and subsequently the JniorOS loads. Once that is done applications then load. The boot process is lengthy but the unit will get it job done.

So the Series 3 internal power supply is a bit unconventional. While we typically power the unit with 12VDC it is designed to be powered by an AC source. Here is the front end. I had to go back and reinstall OrCAD to get to these schematics. We use Altium for the Series 4.

It is important here to note that the negative (-) power supply connection IS NOT the same as GND.

Now that generally isn’t an issue as all of the JNIOR’s inputs are isolated and all of the outputs are dry relay contacts and therefore also isolated. The GND signal does appear on the serial connectors and on the Sensor Port. The external modules that are designed to run on our Sensor Port are also isolated. The bottom line is that you can possibly cause an issue if you ground (GND) the negative (-) supply lead and then also connect the GND pin of either serial port. This is also true with the Series 4 with the exception of the 412DMX that is currently under development.

Another issue that has been corrected in the Series 4 JNIOR is that the negative path is not fused. In this case if a grounding problem occurs and you use the GND pin of one of the serial ports you can cause high current to flow through the product. As mentioned this has been corrected with the addition of the second fuse on Series 4 units.

The VUNREG here supplies the rest of the power supply regulation. With a 12VDC regulated source VUNREG will be somewhat less than 12V but sufficient to power the regulator that generates the internal 5V rail. That was not true with a 9VDC source under some load. Thus, the change to a minimum 12VDC.

Another concern here is that if you use a 24VRMS AC source VUNREG becomes 34V challenging the 5V regulator to follow. This is easily worsened in an HVAC environment where the 24VAC supply can be an unloaded transformer with more like 30V+ RMS. VUNREG can exceed 40V and component ratings including the rating of the subsequent 5V regulator become a concern.

So run the JNIOR with a 12VDC 1A regulated supply and avoid issues. Use increased voltages with caution.

One does not need to use a Regulated external supply. That does insure though that you have precisely the voltage that you want. Unregulated supplies tend to vary more significantly in voltage than you would think from the nominal.

The internal 5V (VCC5) is used to power our relay coils. It if stepped down further to provide the 3.3V (VCC) and 1.8V (VCC1) rails that the processor and digital circuits require.

You can see here that the GREEN (BLUE in Series 4) Power LED illuminates when the 3.3V rail is powered.

The internal Series 3 power supply produces 5V at 0.75A (stepped up to 1A with Series 4) driving the rest of the product. In addition to relay coils the 5V is presented to the Sensor Port circuit as a source of power for external modules. The Series 3 also supplies the VUNREG to the Sensor Port which was not used and removed for Series 4.

To verify the supplies on the bench, power the JNIOR with 12VDC. You can check each rail across the associated capacitors as show below.

Here we note that VUNREG is approximately 10.6V showing the diode drops from the supplied 12V inherent in the full-wave bridge. The 5V (VCC5) and 3.3V (VCC) rails are nearby and easily checked. The 1.8V (VCC1) rail is developed at the far other end of the board as shown below.

That pretty much covers the power supply requirements, powering your JNIOR and testing voltages.

If you have a Series 3 that no longer functions, check carefully for evidence of damage from over-voltage or high-current in the area of the 5V regulator. The use of excessive input voltages can melt traces around the power connector. A grounding issue can cause damage to the 5V regulator U12 which can show physical damage. In these cases the JNIOR more than likely cannot be repaired.

In some cases the Power LED did not illuminate as a result of a bad LED or poor soldering. Voltages are otherwise as expected. Most of those failures are caught in production. A marginal solder joint can operate for some time but as pass production tests. But after aging it can present as an open circuit.

This power supply has proven to be very reliable. INTEG has seen an extremely small percentage in failure rate. In general, most causes have been tracked to improper external wiring and severe grounding issues.

By | On October 10, 2017 10:40 am | No Comments |

310/312/314 Battery Replacement

The Series 3 JNIOR is no longer in production. The 310, 312 and 314 have some time ago been replaced by the much more capable Series 4 models 410, 412 and 414. All versions of JNIOR utilize a 3V Lithium cell as battery backup for the time clock and the RAM based portion of the file system. While the Series 4 employ standard coin cells (CR2016 or CR2032) that can be easily replaced with batteries available from your local convenience store, the Series 3 batteries are soldered in place.

JNIOR Series 3 Coin Battery

The one shown here is dead. So DEAD in fact that you can barely detect the 0.008 volts that remain.

These batteries were expected to last 10 years in the typical JNIOR application where the unit remains powered 24/7 or nearly so. In applications where the JNIOR is powered less than 8 hours per day these batteries need to be replaced after about 6 years of service.

Note that the battery IS NOT required for product operation. In situations where the time clock needs to be accurate (scheduling) then units should be updating their clocks from a separate time server (NTP) through the network. The clock will be set after booting. The RAM based portion of the file system retains log files which are normally only necessary for debugging. Those files need not be retained through power loss.

INTEG no longer has inventory for these batteries. It is not cost effective for us to replace them.

If you feel confident using a soldering iron, these batteries can be replaced.

The original battery was Panasonic BR1632A/HAN and is currently not in stock at DigiKey. However, you can use the Panasonic BR-1632/HFN battery and at this writing there appears to be sufficient stock. These are less than $2 in quantities of a few.
https://www.digikey.com/products/en?keywords=P299-ND

You can however use any 3V battery source. You might add wires to accept wired batteries. You might even find a coin cell holder to fit. The pin spacing is 15.2mm. But since you will likely not need to replace the battery or another half dozen years you might not get too fancy.

Desoldering is tricky. First of all the solder has a high melting temperature due to its RoHS nature. Secondly the (-) GND terminal connects to the ground plane which represents a fair heat sink. It will take time and a lot of heat to loosen the negative battery terminal. Replacement is simpler if you first carefully cut the existing battery off of the board. The positive lead can be removed easily with the simplest desoldering equipment. The negative lead will take some effort. I end up using a hot air soldering iron in combination with a desoldering station. Be patient. It can be done.

Even though an old battery may be dead it should be disposed of properly. Most instructions for Lithium cell displosal are referring to serious batteries like that for your laptop computer. Those may require a more complicated procedure. If necessary in this case you can simply wrap the battery with tape sufficient to prevent the accidental shorting of the contacts and toss it out with your trash.

There is one additional note of caution. You will note that there are surface mount components under the battery itself and near the terminals. Care must be taken to not disturb those components. Don’t damage them if you go to cut the battery off of the board. Watch that you don’t apply so much heat to the terminals that you loosen the surface mount components. Apply heat only to the rear of the board.

If you damage those circuits you will impact product operation.

By | On October 10, 2017 10:39 am | No Comments |

File Compression Support in JANOS

As you know we have been supporting ZIP and JAR files (they are the same as far as JANOS is concerned) for a while. JAR files being predominantly for application programs and Java support. More recent OS versions allow the WebServer to serve files directly out of a ZIP library. The DCP is an example where you need only add the www.zip file to the /flash folder to install the set of files that are the DCP. There is no need to expand the library.

To do this JANOS is able to understand the ZIP/JAR file structure and extract data stored within it with either the STORE or DEFLATE methods. Presently JANOS cannot handle the LZW compression or many other ZIP options such as encryption.

I had once developed a program called “Curator” which was a backup utility that worked much like SVN and stored all of its data using LZW compression. We were always amazed at the compression ratios. I had even worried at times that there might have been a problem in figuring that ratio because sometimes it seemed way off. But the program worked and accurately recovered data.

So I do have code that I have written (although in C++ in that case) that can be used in JANOS to handle LZW. We just haven’t encountered it. Apparently DEFLATE is the compression method of choice.

So I expect that we will encounter externally zipped libraries that JANOS will not be able to process. In those cases depending on the reasons for the incompatibility I am prepared to implement the fix.

But the question now is whether or not there would be any use in the JAR command being able to compress files and create libraries? I realize it has been suggested and even entered in our Redmine system. Would this be something worth doing?

By | On September 30, 2017 8:47 am | No Comments |

Externally Accessible Controller

Would you trust your controller directly connected to the Internet?

We’ve been testing a JNIOR 410 on the network with only the following safeguards:

  1. Disable all accounts except the administrator ‘jnior’ account.
  2. Changed the ‘jnior’ account password.

There has been enough malicious activity attempting to login into the Telnet port that we have an application processing the access/log failed login reports and mapping the host locations. Try http://honeypot.integpg.com or https://honeypot.integpg.com if you prefer a secure connection.

Note that this unit is running the current Release Candidate for JANOS v1.6.2 as we have continued to enhance the unit’s ability to withstand life on the open network.

By the way there are a couple of publicly accessible web pages on this unit:

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

By | On September 17, 2017 3:01 pm | No Comments |

Series 3 Not Recommended for New Applications

The Series 3 JNIOR continues to be a reliable workhorse in a number of industries. The Series 3 models (310, 312, and 314) however no longer represent the performance, reliability and stability of the current JNIOR controller line. We no longer produce them. While you would likely benefit from an upgrade to a Series 4 model (410, 412, or 414), doing so is still your decision. The change is almost seamless. Just know that INTEG will dedicate itself to the success of your conversion with the same attention and personal support that you have always experienced.

Just a few added benefits of the Series 4:

  • Secure network connection using HTTPS, STARTTLS, etc.
  • Faster execution making applications more responsive.
  • Boots in only a few seconds.
  • Dynamic Configuration Pages (DCP) replaces the Java Applet panel.
  • Emphasis on Security.
  • Simpler approach to application programming makes user programming even more feasible.
  • Enhanced WebServer provides for the development of state of the art Web interfaces.
  • Supports server-side scripting (PHP).
  • Provides Websockets alternative to the binary JNIOR Protocol.
  • And much more…
By | On September 17, 2017 11:01 am | No Comments |

Network Capture

The JNIOR can create a network capture! This network capture can be loaded in a sniffer application such as Wireshark for protocol analysis. To do this simply follow a few steps.

  1. Create a telnet connection to the unit. DO NOT USE THE DCP AS THIS CREATES A LOT OF EXTRA TRAFFIC THAT WILL FILL UP THE BUFFER.
  2. Execute the netstat -r command. This step is optional. If you are going to conduct a test procedure then you might want to execute this command so that only the traffic that occurs during your test will be captured.
  3. Conduct your test
  4. Use the telnet connection to execute the netstat -c command. This will create the capture file with the network buffer content.
  5. Use the DCP and the folders tab to pull the resulting network.ngpcap file. It is in the temp directory. It will be removed when the unit reboots!
By | On September 15, 2017 2:19 pm | No Comments |

412DMX Status

You may not know that we are creating a JNIOR Model 412 that supports the DMX512 protocol for lighting control. Basically a DMX Output port replaces the AUX serial port that we find normally on the JNIOR. This will be dubbed the JNIOR 412DMX.

An initial prototype was completed and tested. It is functional. However, an issue in the mechanical mounting of the required 5-pin XLR connector necessitated a revision. By the slightest amount the connector interfered with the enclosure cover when mounted on the main PCB. While some creative machining could accommodate the connector it is not the proper way to do it. So the revision lowers the connector in an arrange as shown here. This should do just fine. We will see in a week or so.

This also avoids an issue that Kevin pointed out where the release tab was sitting higher than the unit. It could easily be damaged or damage something else. Here we see that it will be safely below the top of the cover.

In case you couldn’t picture the issue I show it here with the interference highlighted in yellow. You can also see how the release tab is inconveniently placed.

The solution adds a little cost but is the proper implementation.

I’ve located the entire DMX512 ISOLATED circuit on that little piece of PCB so this could be used by other product models.

The PCBs will be in this week and I’ll have to build a set. I milled one housing this morning and mounted the XLR connector to see how it likes its new home.

Now let’s hope that the PCB arrangement lines the connector up for this.

Yeah so the R01 boards are in. The revision was needed to move that XLR connector down. Perhaps you are mechanically inclined and can imagine what is involved in placing the DMX connector on the side of the enclosure. You need to reference the dimensions through the plastic housing and up through the PCB mounts and then onto the daughter board. So even though it can be done you are never 100% certain that you have it right until.. the hardware shows up.

So there is joy! Time to celebrate with some whiskey, right?

This is an ISOLATED DMX512 Output port. The isolation transformer is a tall component and that’s what that square recess is for. It will sit there. All of the RS-485 hardware and isolation is on that small PCB. The connector just carries Rx, Tx, Gnd, 3.3V and CHASIS connections. And that board will let me put these XLR connectors side-by-side for a product that has multiple outputs.

Well I’ve populated the DMX module. Everything looks good except I need to used a slightly taller pin header. Not a problem.

The 412DMX is ready to go. I just need to pull the package together for production.

This prototype has 20 seconds of ride-thru power backup and 128MB of Flash storage. The 5-pin standard DMX XLR connector sits perfectly now in place of the usual AUX port.

By | On September 14, 2017 12:54 pm | No Comments |

First DMX Prototype

Did you know that I have been tweeting my progress with the 412DMX (hastag #412DMX) on Twitter? Follow us @integpg.

I’ve been machining the first enclosure for this. There’s a video of some of it on YouTube.

By | On September 14, 2017 12:48 pm | No Comments |