Uncategorized

The following post talks about entering the processor bootloader.  Entering the bootloader could have unintended consequences should the wrong commands be entered.  Proceed at your own risk.

Note, this is for a series 3 JNIOR that went out of production in 2015. You can upgrade to Series 4 JNIORs easily in most cases.

Most JNIOR3 batteries should be dead and therefore removing power to reboot should restore the default accounts. If the battery is still doing its job you can force your way in using the following:

  1. Connect USB-to-Serial cable to COM/RS-232 port.
  2. Open Terminal program of your choice (Support Tool). Serial settings are 115200 baud, 8 data bits, 1 stop bit, and No Parity. No hardware buffer control. We are hoping that the DTR line (pin 4) is wired through the cable and is asserted by default.
  3. Access the JNIOR and prove to yourself that you cannot log in. Try jnior:jnior and admin:admin.
  4. With jumper (or screwdriver) short jumper next to COM port briefly (1/2 second).
  5. Immediately hit repeated (at least 3 or so) ENTER keystrokes. The bootloader banner should appear.
  6. Enter: B 02 <ENTER>
  7. Enter: F 00 0000 0100 <ENTER>
  8. Enter: E <ENTER>
  9. The JNIOR should reboot. Note the above switches to the Block for the Heap Memory (Bank 2); Clears the first 256 bytes of the Heap damaging its structure; And, then Exits restarting the system.
  10. Note in the dialog the indication “Blast HEAP”. This restores the original /etc/passwd file with the default credentials.
  11. Eventually log in using jnior:jnior

If shorting the jumper pins or inserting the jumper briefly does not reboot the JNIOR and accept your ENTER keystrokes, then DTR is not wired or asserted.

This test was done using Putty on an Ubuntu system with an old USB-to_Serial adapter.

Extend the life of your logs. Use the Log Archiver to compress backups to an archive.

The archive that is used is determined based on the log name that is about to be archived. There are several known system logs that will be archived in a system.zip archive. Other log files use the beginning part of the file name to determine the archive name. tasker.log and tasker-tasks.log will go to the tasker.zip archive.

Each archive will grow to a maximum size. The archiver will try to remove an entry once the maximum size is reached. The entry to be removed is determined by trying to find the oldest entry for a file that has more than one copy. If the oldest entry is the only entry of its kind then it will not be removed.

Applications must use a .log.bak file naming convention for this application to archive the backup log files. JANOS uses this concept but the Java applications have been using a rolling file concept for quite some time. The logging concept in the applications will change as the applications are updated. This application will initially start archiving the system log files.

The maximum size is configurable. It is 128 KB by default. It can be change to a value between 32 KB and 512 KB. To configure this setting you will edit the AppData/LogArchiver/MaxArchiveSizeInKB registry key.

The Max Archive Size in KB registry key

The application must be set to run on boot. You will use the Applications section in the Configuration tab in the DCP to ensure that the Log Archiver application is set to run on boot.

Se the Log Archiver application to run on boot

Here is a good example of how the oldest entry is not always removed.

Screenshot showing the system.zip contents and the system.zip filesize

This is the honeypot unit. Its our publicly accessible unit that we use to map source locations for failed login attempts to the telnet port. Here you can see that the jniorboot-202004080118.log file is by far the oldest entry. It should have been removed many times but because it is the only jniorboot*.log, it is saved. The jniorsys-202005110533.log file also should have been removed but since it is the only jniorsys*.log, it hasn’t. The failed login attempts are quite numerous, thus filling up the access.log and causing it to be archived many times. The other thing we notice here is that we have 14 files in this archive and the archive size is only 120 KB!

Screenshot of honeypot.integpg.com

To get SNMP to run on boot we need to set the Run key in the JNIOR registry. You can do this manually or by checking the checkbox next the SNMP.

A reboot WILL be required after changing the selection here.

INTEG is saddened by the cancellation of CinemaCon this year. We will miss seeing all of our friends. We hope for the well being of everyone and the speedy recovery of all those affected. We will see you all next year.

Bruce, Kevin, and Tony will be in Vegas at CinemaCon.  If you want to set-up an appointment to meet with us at the show email support@integpg.com or visit INTEG at booth number 2306A and meet the people actually responsible for the product hardware, firmware and application development.  We also want to meet you, answer your questions and to thank you for your ongoing business.

Follow INTEG on Twitter for updates: @integpg

See you in Vegas!