MAC36NL - Platform - Unable to log in to the controller's platform
Issue
The user is unable to log in to the MAC36NL controller.
Possible causes and solutions
Connecting to the controller is not possible after a long time of operation
Unable to connect just after commissioning - the controller responds to ping
Unable to connect just after commissioning - the controller does not respond to ping
Controller is after launching a first step of restoring factory settings
State of DIP and rotary switches forces the controller into a bootloader mode
Too fast attempt to connect to the controller
A possible cause here is that the Niagara deamon has not started on the controller yet. The Niagara platform takes about 2 minutes to start after powering on the controller. At the same time, the TCP/IP communication of the Ethernet interface starts considerably quicker, which is why it may be possible to ping the IP address of the controller from a command line (cmd
) just after a few seconds. The platform takes longer to fully launch.
javax.baja.naming.UnresolvedException: platformssl:
at com.tridium.platcrypto.daemon.wb.BDaemonSecureScheme.resolve(BDaemonSecureScheme.java:127)
at javax.baja.naming.BOrd.resolve(BOrd.java:278)
at com.tridium.workbench.shell.BNiagaraWbShell.resolve(BNiagaraWbShell.java:669)
at com.tridium.workbench.shell.NHyperlinkInfo.resolve(NHyperlinkInfo.java:279)
at com.tridium.workbench.shell.NHyperlinkInfo.hyperlink(NHyperlinkInfo.java:131)
at com.tridium.workbench.shell.BNiagaraWbShell.doHyperlink(BNiagaraWbShell.java:528)
at com.tridium.workbench.shell.BNiagaraWbShell.hyperlink(BNiagaraWbShell.java:486)
at javax.baja.workbench.nav.tree.NavTreeController.nodeDoubleClicked(NavTreeController.java:119)
at javax.baja.ui.tree.TreeController.mousePressed(TreeController.java:234)
at javax.baja.workbench.nav.tree.NavTreeController.mousePressed(NavTreeController.java:65)
at javax.baja.ui.tree.BTree.mousePressed(BTree.java:611)
at javax.baja.ui.BWidget.fireMouseEvent(BWidget.java:1365)
at com.tridium.ui.awt.MouseManager.fire(MouseManager.java:373)
at com.tridium.ui.awt.MouseManager.fire(MouseManager.java:304)
at com.tridium.ui.awt.MouseManager.pressed(MouseManager.java:126)
at com.tridium.ui.awt.MouseManager.process(MouseManager.java:107)
at com.tridium.ui.awt.AwtShellManager.processMouseEvent(AwtShellManager.java:509)
at com.tridium.ui.swing.BSwingWidget$GlassMouseListener.redispatchMouseEvent(BSwingWidget.java:642)
at com.tridium.ui.swing.BSwingWidget$GlassMouseListener.mousePressed(BSwingWidget.java:510)
java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:81)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:476)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:218)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:200)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:162)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:394)
at java.net.Socket.connect(Socket.java:606)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.connect(Unknown Source)
at com.tridium.crypto.core.io.CryptoCoreSecureSocket.connect(CryptoCoreSecureSocket.java:64)
at com.tridium.crypto.core.io.CryptoCoreClientSocketFactory.createSocket(CryptoCoreClientSocketFactory.java:101)
at javax.baja.net.HttpsConnection.createSocket(HttpsConnection.java:210)
at javax.baja.net.HttpsConnection.connect(HttpsConnection.java:149)
at javax.baja.net.HttpsConnection.newRequest(HttpsConnection.java:293)
at javax.baja.net.HttpConnection.newRequest(HttpConnection.java:373)
at com.tridium.platform.daemon.BDaemonSession.sendNewRequest(BDaemonSession.java:3587)
at com.tridium.platform.daemon.BDaemonSession.getConnection(BDaemonSession.java:2529)
at com.tridium.platform.daemon.BDaemonSession.initHostProperties(BDaemonSession.java:969)
at com.tridium.platform.daemon.BDaemonSession.connect(BDaemonSession.java:307)
Solution
To avoid the problem, wait until the RUN diode on the controller starts blinking quickly (which means the platform has started) or slowly (which means the station has started). The RUN diode lit continuously means that the controller is only starting FW or the Linux system.
If the RUN diode is hidden from sight or the controller is placed in a remote location, it is recommended to wait at least 2 minutes before attempting to connect to the platform.
Connecting to the controller is not possible after a long time of operation
Occasionally, when the controller is working for some time with no interruptions, it is no longer possible to log in to the platform and the Workbench logs indicate the following error:
javax.baja.naming.UnresolvedException: platformssl:
at com.tridium.platcrypto.daemon.wb.BDaemonSecureScheme.resolve(BDaemonSecureScheme.java:103)
at javax.baja.naming.BOrd.resolve(BOrd.java:274)
at com.tridium.workbench.shell.BNiagaraWbShell.resolve(BNiagaraWbShell.java:656)
at com.tridium.workbench.shell.NHyperlinkInfo.resolve(NHyperlinkInfo.java:279)
at com.tridium.workbench.shell.NHyperlinkInfo.hyperlink(NHyperlinkInfo.java:131)
at com.tridium.workbench.shell.BNiagaraWbShell.doHyperlink(BNiagaraWbShell.java:515)
at com.tridium.workbench.shell.BNiagaraWbShell.hyperlink(BNiagaraWbShell.java:473)
at javax.baja.workbench.nav.tree.NavTreeController.nodeDoubleClicked(NavTreeController.java:119)
at javax.baja.ui.tree.TreeController.mousePressed(TreeController.java:234)
at javax.baja.workbench.nav.tree.NavTreeController.mousePressed(NavTreeController.java:65)
at javax.baja.ui.tree.BTree.mousePressed(BTree.java:591)
at javax.baja.ui.BWidget.fireMouseEvent(BWidget.java:1227)
at com.tridium.ui.awt.MouseManager.fire(MouseManager.java:325)
at com.tridium.ui.awt.MouseManager.fire(MouseManager.java:299)
at com.tridium.ui.awt.MouseManager.pressed(MouseManager.java:122)
at com.tridium.ui.awt.MouseManager.process(MouseManager.java:103)
at com.tridium.ui.awt.AwtShellManager.processMouseEvent(AwtShellManager.java:509)
at com.tridium.ui.swing.BSwingWidget$GlassMouseListener.redispatchMouseEvent(BSwingWidget.java:641)
at com.tridium.ui.swing.BSwingWidget$GlassMouseListener.mousePressed(BSwingWidget.java:509)
DaemonConnectException: javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
at com.tridium.platform.daemon.BDaemonSession.processException(BDaemonSession.java:831)
at com.tridium.platform.daemon.BDaemonSession.processException(BDaemonSession.java:782)
at com.tridium.platform.daemon.BDaemonSession.processException(BDaemonSession.java:794)
at com.tridium.platform.daemon.BDaemonSession.processException(BDaemonSession.java:782)
at com.tridium.platform.daemon.BDaemonSession.connect(BDaemonSession.java:3608)
at com.tridium.platcrypto.daemon.wb.BDaemonSecureSession.connect(BDaemonSecureSession.java:231)
at com.tridium.platform.daemon.BDaemonSession.getConnection(BDaemonSession.java:2432)
at com.tridium.platform.daemon.BDaemonSession.initHostProperties(BDaemonSession.java:948)
at com.tridium.platform.daemon.BDaemonSession.connect(BDaemonSession.java:287)
at com.tridium.platform.daemon.BDaemonSession.connect(BDaemonSession.java:275)
at com.tridium.platcrypto.daemon.wb.BDaemonSecureScheme.resolve(BDaemonSecureScheme.java:91)
at javax.baja.naming.BOrd.resolve(BOrd.java:274)
at com.tridium.workbench.shell.BNiagaraWbShell.resolve(BNiagaraWbShell.java:656)
at com.tridium.workbench.shell.NHyperlinkInfo.resolve(NHyperlinkInfo.java:279)
at com.tridium.workbench.shell.NHyperlinkInfo.hyperlink(NHyperlinkInfo.java:131)
at com.tridium.workbench.shell.BNiagaraWbShell.doHyperlink(BNiagaraWbShell.java:515)
at com.tridium.workbench.shell.BNiagaraWbShell.hyperlink(BNiagaraWbShell.java:473)
at javax.baja.workbench.nav.tree.NavTreeController.nodeDoubleClicked(NavTreeController.java:119)
at javax.baja.ui.tree.TreeController.mousePressed(TreeController.java:234)
There are known cases of MAC36NL controllers so overloaded with logic, files, and historic data that there was no more memory available to start a TCP/IP socket.
Solution
To solve this problem, reboot the controller. It should bring back access to the platform. To make sure the problem does not recur, go to the File Transfer Client in platform and remove the sw
folder contents (if the folder is not present in the controller, the described case is not the reason of being unable to connect to the platform).
The sw
folder stores data from past commissionings and is not always visible. If the folder is unavailable or empty, it means that the station needs to be reduced.
Unable to connect just after commissioning - the controller responds to ping
In the process of establishing new users on first commissioning of the platform, an error occurred while removing a default user (niagara
-> tridium
). Despite the error, the commissioning process was finished and it was possible to begin operations. However, after restarting the controller, it was no longer possible to log in and the following logs appeared:
javax.baja.naming.UnresolvedException: platform:
at com.tridium.platcrypto.daemon.BDaemonScheme.resolve(BDaemonScheme.java:111)
at javax.baja.naming.BOrd.resolve(BOrd.java:274)
at com.tridium.workbench.shell.BNiagaraWbShell.resolve(BNiagaraWbShell.java:656)
at com.tridium.workbench.shell.NHyperlinkInfo.resolve(NHyperlinkInfo.java:279)
at com.tridium.workbench.shell.NHyperlinkInfo.hyperlink(NHyperlinkInfo.java:131)
at com.tridium.workbench.shell.BNiagaraWbShell.doHyperlink(BNiagaraWbShell.java:515)
at com.tridium.workbench.shell.BNiagaraWbShell.hyperlink(BNiagaraWbShell.java:473)
at javax.baja.workbench.nav.tree.NavTreeController.nodeDoubleClicked(NavTreeController.java:119)
at javax.baja.ui.tree.TreeController.mousePressed(TreeController.java:234)
at javax.baja.workbench.nav.tree.NavTreeController.mousePressed(NavTreeController.java:65)
at javax.baja.ui.tree.BTree.mousePressed(BTree.java:591)
at javax.baja.ui.BWidget.fireMouseEvent(BWidget.java:1227)
at com.tridium.ui.awt.MouseManager.fire(MouseManager.java:325)
at com.tridium.ui.awt.MouseManager.fire(MouseManager.java:299)
at com.tridium.ui.awt.MouseManager.pressed(MouseManager.java:122)
at com.tridium.ui.awt.MouseManager.process(MouseManager.java:103)
at com.tridium.ui.awt.AwtShellManager.processMouseEvent(AwtShellManager.java:509)
at com.tridium.ui.swing.BSwingWidget$GlassMouseListener.redispatchMouseEvent(BSwingWidget.java:641)
at com.tridium.ui.swing.BSwingWidget$GlassMouseListener.mousePressed(BSwingWidget.java:509)
java.net.ConnectException: Connection timed out: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:75)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:476)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:218)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:200)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:162)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:394)
at java.net.Socket.connect(Socket.java:606)
at javax.baja.naming.BIpHost.openSocket(BIpHost.java:170)
at javax.baja.net.HttpConnection.createSocket(HttpConnection.java:303)
at javax.baja.net.HttpConnection.connect(HttpConnection.java:337)
at javax.baja.net.HttpConnection.newRequest(HttpConnection.java:416)
at javax.baja.net.HttpConnection.newRequest(HttpConnection.java:373)
at com.tridium.platform.daemon.BDaemonSession.sendNewRequest(BDaemonSession.java:3547)
at com.tridium.platform.daemon.BDaemonSession.getConnection(BDaemonSession.java:2489)
at com.tridium.platform.daemon.BDaemonSession.initHostProperties(BDaemonSession.java:952)
at com.tridium.platform.daemon.BDaemonSession.connect(BDaemonSession.java:290)
at com.tridium.platform.daemon.BDaemonSession.connect(BDaemonSession.java:278)
at com.tridium.platform.daemon.BDaemonScheme.resolve(BDaemonScheme.java:90)
The reason is that the default user was not successfully removed, which is possible when the Putty console with the default user (niagara
-> tridium
) logged in was simultaneously started (for example, to check the IP address). During the first commissioning of the platform, the error of removing the default user occurred because there was an active session open for that user. Ultimately, logging in with a new user could not be possible. To avoid the issue, make sure to perform all works with the Defaults Settings Wizard
with the Putty console shut down.
Solution
To solve the problem, reload the SD card image according to the following instructions: https://support.ismacontrolli.com/02%20Small%20%26%20Medium%20BMS/iSMA-B-MAC36/iSMA-B-SD-NL/.
Unable to connect just after commissioning - the controller does not respond to ping
After performing a commissioning process (with changing the IP address) of the MAC36NL-family controller, it is not possible to log in. The controller does not respond to a ping
command.
Most probably, due to a mistake while configuring the IP address, the controller saved a DHCP option active or saved an IP address different than intended.
In such a situation, check the actual IP address of the controller and try to connect. Unfortunately, if the controller is part of a larger network, it is possible that it shares the IP address with another device and may be unreachable.
Solutions
Connect the controller directly to the PC (in the PC network configuration, set the IP address in the same subnet as the expected address of the controller) and scan the network with a software like
Advanced IP Scanner
to check whether a different address was mistakenly assigned in the last octet.In any case different than a mistake in the last octet of the IP address, it is required, first, to connect to the controller using the serial console https://icdocs.ismacontrolli.com/kb/article/mac36-console-serial-connection. Then, use the following command:
cat /etc/network/interfaces
The command returns a full configuration of both Ethernet interfaces saved in the controller. If a specific IP address has been set, it is sufficient to set on the computer the IP address in the same subnet and connect to the controller’s platform to reset the IP address to the intended one.
If the configuration is set to DHCP, it is required to use the below command to check the IP address in use (the Ethernet cable must be plugged into the specified interface of the controller and connected on the other side to the computer):
/sbin/ifconfig
The returned IP address may seem unusual but it is still required to set on the computer the IP address in the same subnet and log into the controller’s platform to reset the IP address to the intended one.
If no mini USB cable, necessary for a serial console connection, is available, it is required to connect the controller to a router with DHCP active. Using a diagnostic tool, verify whether the device has been found and what IP address it is. Alternatively, use a 6th DIP switch restore function or reload the SD card to restore a default IP address.
WARNING: Depending on the method, other settings will be restored to default too.
Controller is after launching a first step of restoring factory settings
In case an S3 6th DIP switch is set to the ON position and the controller is then powered up, it will go into a phase of waiting for a factory reset process to complete, and the platform of the controller cannot be started.
The ALARM diode on the controller blinks quickly and the logs show stopping the startup process:
U-Boot SPL 2017.03-mx6+g3b5f889 (Jul 23 2018 - 18:04:11)
Part number: VSM-DUAL-239A
Assembly: AS1811142076
Date of production: 2018 Dec 10
Trying to boot from MMC1
MMC Boot Device: mmc0 (SD)
Authenticate image from DDR location 0x177fffc0...
Check CSF for Write Data command before authenticating image
(...) 260 lines more
imx_thermal 2000000.aips-bus:tempmon: Commercial CPU temperature grade - max:95C critical:90C passive:85C
rtc-pcf8563 0-0051: setting system clock to 2024-07-01 09:44:12 UTC (1719827052)
Freeing unused kernel memory: 27648K
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 5 ports detected
rorootfs-overlay: Could not mount , bind mounting...
usb 2-1.1: new high-speed USB device number 3 using ci_hdrc
EXT4-fs (mmcblk1p2): warning: maximal mount count reached, running e2fsck is recommended
EXT4-fs (mmcblk1p2): recovery complete
EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
EXT4-fs (mmcblk1p3): warning: maximal mount count reached, running e2fsck is recommended
EXT4-fs (mmcblk1p3): recovery complete
EXT4-fs (mmcblk1p3): mounted filesystem with ordered data mode. Opts: (null)
random: crng init done
Solution
To solve the problem, follow the below steps:
disconnect the controller’s power supply,
set the S3 6th DIP switch to OFF,
power the controller back on.
WARNING: This sequence cannot be changed - setting the S3 6th DIP switch to the OFF position when the controller is powered causes it to go into a second phase of restoring factory setting, which is a final overwriting of the current settings with the factory settings.
State of DIP and rotary switches forces the controller into a bootloader mode
When all S3 6 DIP switches are set to ON and both rotary switches (S1 and S2) are set to 0, the controller after the next reboot or voltage power restart will automatically go to the bootloader and wait for uploading new firmware. Unfortunately, it cannot be done as the MAC36NL-family controllers transfer files during commissioning.
In such a case, the controller will light a red ALARM diode and stop the platform from starting, which will prevent the possibility to log in.
Solution
To solve the problem, set the DIP and rotary switches to a different state.
WARNING: Leaving the S3 6th DIP switch set to ON will commence the procedure of restoring factory settings!
No SD card inserted
Out-of-the-box MAC36NL controller does not have an SD card inserted. In some cases, it is provided in the box, but sometimes it is required to purchase the SD card separately.
In any case, first, check if the SD card is places in an SD card slot on the side of the controller. If the SD card is missing from the slot, no diodes other than ON will be lit.
The following log will also be generated in the Putty console (serial connection):
U-Boot SPL 2017.03-mx6+g3b5f889 (Oct 08 2018 - 14:35:15)
Part number: VSM-DUAL-239B
Assembly: AS2112173828
Date of production: 2022 Jul 17
Trying to boot from MMC1
MMC Boot Device: mmc0 (SD)
MMC: no card present
mmc_init: -123, time 2
spl: mmc init failed with error: -123
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
Solution
Place the iSMA-B-SD-NL card in the SD card slot on the side of the controller while the controller is powered off and then switch on the power supply.
Incorrectly inserted SD card
It may happen that the SD card is placed incorrectly in the MAC36NL controller’s SD card slot. It will be signaled with a red ALARM diode. It may not necessarily mean that the SD card is placed upside down; occasionally, it happens that the copper pads do not fully contact and the SD card is read incorrectly.
Solution
Remove the SD card when the controller is powered off. Check if the SD card is being inserted a correct side up, place it in the SD card slot and power on the controller.
Damaged image or files on the SD card
Sporadically, the SD card of the MAC36NL-family controller (especially, a brand new one) has an incorrectly uploaded file image or a single file has been corrupted while writing. It prevents logging in to the platform and may cause one of the following:
no diode other than ON is lit,
the red ALARM diode is lit,
the green RUN diode is lit continuously.
Solution
Remove the SD card when the controller is powered off and reload the card’s image according to the following instructions: https://support.ismacontrolli.com/02%20Small%20%26%20Medium%20BMS/iSMA-B-MAC36/iSMA-B-SD-NL/.
Then, insert the SD card to the controller and power it on.
Damaged partitions on the SD card
Seldom, a partition system on the SD card gets damaged, which causes that the SD card is incorrectly read by the MAC36NL controller, at the same time being recognized by the PC but it is impossible to copy its image.
The reason to this may be a damaged partition system. Such a damage can occur when the SD card is inserted to the PC. In this moment, the Windows system automatically discovers all partitions on the card and cannot recognize the files format. Pop-up windows appear with a suggestion to format the partitions. The correct approach is to obligatorily reject formatting. However, if, by mistake or out of inexperience, the SD card does get formatted, it will be no longer possible to load a new image to the card.
Solution
The solution is to remove all volumes from the SD card using a Windows' built-in tool, Disk Management.
Open the Disk Management tool and select the Delete volume option from the context menu.
WARNING: Make absolutely sure that the removed volume is from the SD card and NOT the HDD disk or a phone connected to the PC.
Having removed all volumes from the SD card, it is ready to load a new image according to the following instructions: https://support.ismacontrolli.com/02%20Small%20%26%20Medium%20BMS/iSMA-B-MAC36/iSMA-B-SD-NL/.
Finally, insert the SD card to the controller and power it on.
Mechanical micro-crack or visible damage to the SD card
The iSMA-B-SD-NL card, dedicated to the MAC36NL-family controllers, needs to be cautiously inserted to the SD card slot; especially, it is not allowed to use any tools to insert it, such as a screwdriver. Using hardware tools instead of fingers increases an amount of pressure on the card when it is pressed against the end of the slot. Due to the resulting stress, the SD card may be slightly bent in the slot, which in effect may lead to micro-cracks on the surface of the card. Such a micro-crack can cause damage to the microcontroller or copper tracks embedded in the plastic. The SD card damaged this way may (but does not have to, depending on the location of the damage) overheat. A micro-crack resembles a damage pictured below:
On the other hand, when the damage is clearly visible, as below, a very strong mechanical force had to be applied to bring the card to such a state:
Solution
In this case, the only solution is to exchange the SD card. If the damaged card is overheating and left in the powered on controller for a too long time, it can also cause a damage to the card slot.
Windows system in Turkish
This is a known issue that it is not possible to log in to the MAC36NL controller from the Workbench installed on the Windows system in Turkish language version. The problem is rooted in a specific coding of letters using in this language.
javax.baja.naming.UnresolvedException: platform:
at com.tridium.platform.daemon.BDaemonScheme.resolve(BDaemonScheme.java:111)
at javax.baja.naming.BOrd.resolve(BOrd.java:274)
at com.tridium.workbench.shell.BNiagaraWbShell.resolve(BNiagaraWbShell.java:656)
at com.tridium.workbench.shell.NHyperlinkInfo.resolve(NHyperlinkInfo.java:279)
at com.tridium.workbench.shell.NHyperlinkInfo.hyperlink(NHyperlinkInfo.java:131)
at com.tridium.workbench.shell.BNiagaraWbShell.doHyperlink(BNiagaraWbShell.java:515)
at com.tridium.workbench.shell.BNiagaraWbShell.hyperlink(BNiagaraWbShell.java:473)
at javax.baja.workbench.nav.tree.NavTreeController.nodeDoubleClicked(NavTreeController.java:119)
at javax.baja.ui.tree.TreeController.mousePressed(TreeController.java:234)
at javax.baja.workbench.nav.tree.NavTreeController.mousePressed(NavTreeController.java:65)
at javax.baja.ui.tree.BTree.mousePressed(BTree.java:591)
at javax.baja.ui.BWidget.fireMouseEvent(BWidget.java:1227)
at com.tridium.ui.awt.MouseManager.fire(MouseManager.java:325)
at com.tridium.ui.awt.MouseManager.fire(MouseManager.java:299)
at com.tridium.ui.awt.MouseManager.pressed(MouseManager.java:122)
at com.tridium.ui.awt.MouseManager.process(MouseManager.java:103)
at com.tridium.ui.awt.AwtShellManager.processMouseEvent(AwtShellManager.java:509)
at com.tridium.ui.swing.BSwingWidget$GlassMouseListener.redispatchMouseEvent(BSwingWidget.java:641)
at com.tridium.ui.swing.BSwingWidget$GlassMouseListener.mousePressed(BSwingWidget.java:509)
javax.baja.sys.LocalizableRuntimeException: Error connecting to platform daemon at 192.168.1.123:
GET /platformInfo
at com.tridium.platform.daemon.BDaemonSession.handleConnectionException(BDaemonSession.java:3288)
at com.tridium.platform.daemon.BDaemonSession.getConnection(BDaemonSession.java:2513)
at com.tridium.platform.daemon.BDaemonSession.initHostProperties(BDaemonSession.java:948)
at com.tridium.platform.daemon.BDaemonSession.connect(BDaemonSession.java:287)
at com.tridium.platform.daemon.BDaemonSession.connect(BDaemonSession.java:275)
at com.tridium.platform.daemon.BDaemonScheme.resolve(BDaemonScheme.java:90)
at javax.baja.naming.BOrd.resolve(BOrd.java:274)
at com.tridium.workbench.shell.BNiagaraWbShell.resolve(BNiagaraWbShell.java:656)
at com.tridium.workbench.shell.NHyperlinkInfo.resolve(NHyperlinkInfo.java:279)
at com.tridium.workbench.shell.NHyperlinkInfo.hyperlink(NHyperlinkInfo.java:131)
at com.tridium.workbench.shell.BNiagaraWbShell.doHyperlink(BNiagaraWbShell.java:515)
at com.tridium.workbench.shell.BNiagaraWbShell.hyperlink(BNiagaraWbShell.java:473)
at javax.baja.workbench.nav.tree.NavTreeController.nodeDoubleClicked(NavTreeController.java:119)
at javax.baja.ui.tree.TreeController.mousePressed(TreeController.java:234)
at javax.baja.workbench.nav.tree.NavTreeController.mousePressed(NavTreeController.java:65)
at javax.baja.ui.tree.BTree.mousePressed(BTree.java:591)
at javax.baja.ui.BWidget.fireMouseEvent(BWidget.java:1227)
at com.tridium.ui.awt.MouseManager.fire(MouseManager.java:325)
java.lang.UnsupportedOperationException: Unknown SCRAM type "SCRAM-GLİBC-SHA512"
at com.tridium.platform.daemon.ScramAuthenticator.setAuthorization(ScramAuthenticator.java:101)
at com.tridium.platform.daemon.ScramAuthenticator.setAuthorization(ScramAuthenticator.java:63)
at com.tridium.platform.daemon.BDaemonSession.setAuthOnConnection(BDaemonSession.java:3590)
at com.tridium.platform.daemon.BDaemonSession.getConnection(BDaemonSession.java:2445)
at com.tridium.platform.daemon.BDaemonSession.initHostProperties(BDaemonSession.java:948)
at com.tridium.platform.daemon.BDaemonSession.connect(BDaemonSession.java:287)
at com.tridium.platform.daemon.BDaemonSession.connect(BDaemonSession.java:275)
at com.tridium.platform.daemon.BDaemonScheme.resolve(BDaemonScheme.java:90)
at javax.baja.naming.BOrd.resolve(BOrd.java:274)
at com.tridium.workbench.shell.BNiagaraWbShell.resolve(BNiagaraWbShell.java:656)
at com.tridium.workbench.shell.NHyperlinkInfo.resolve(NHyperlinkInfo.java:279)
at com.tridium.workbench.shell.NHyperlinkInfo.hyperlink(NHyperlinkInfo.java:131)
at com.tridium.workbench.shell.BNiagaraWbShell.doHyperlink(BNiagaraWbShell.java:515)
at com.tridium.workbench.shell.BNiagaraWbShell.hyperlink(BNiagaraWbShell.java:473)
at javax.baja.workbench.nav.tree.NavTreeController.nodeDoubleClicked(NavTreeController.java:119)
at javax.baja.ui.tree.TreeController.mousePressed(TreeController.java:234)
at javax.baja.workbench.nav.tree.NavTreeController.mousePressed(NavTreeController.java:65)
at javax.baja.ui.tree.BTree.mousePressed(BTree.java:591)
at javax.baja.ui.BWidget.fireMouseEvent(BWidget.java:1227)
Solution
To avoid this issue, install the Windows system in English and install the Workbench instance there.
Damage to the KeyMaterial file
In older Niagara distributions (4.4, 4.6, or 4.7), supported by the MAC36NL-family controllers, right after cleanDist is executed, there may be a problem with the keyMaterial file that stores login data for the controller station or its services.
WARNING: Failed to encrypt local session credentials, stationPolfarmexBMS may not start properly
INFO [nre] Launching Niagara Runtime Environment
SEVERE [11:52:29 17-Nov-20 CET][security.keyMaterial] Permission failure when getting key material
java.security.PrivilegedActionException: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.platform.NativePlatformProvider.getKeyMaterial(NativePlatformProvider.java:1511)
at com.tridium.nre.security.km.PlatformKeyMaterial.doGetKeyMaterial(PlatformKeyMaterial.java:56)
at com.tridium.nre.security.km.KeyMaterial.getKeyMaterial(KeyMaterial.java:33)
at com.tridium.nre.security.km.KeyMaterial.keyExists(KeyMaterial.java:61)
at com.tridium.nre.security.km.KeyMaterialFactory.getKeyMaterial(KeyMaterialFactory.java:82)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:93)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:77)
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.security.KeyRingFactory.getKeyRing(KeyRingFactory.java:68)
at com.tridium.nre.security.SecurityInitializer.initSecurityInfo(SecurityInitializer.java:350)
at com.tridium.nre.security.SecurityInitializer.configure(SecurityInitializer.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.tridium.nre.di.BaseSupplier.evaluateConfiguration(BaseSupplier.java:99)
at com.tridium.nre.di.SingletonSupplier.get(SingletonSupplier.java:62)
at com.tridium.nre.di.NreInstantiator.instance(NreInstantiator.java:123)
at com.tridium.nre.bootstrap.Bootstrap.Main(Bootstrap.java:87)
Caused by: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at com.tridium.nre.util.SimpleKeyValueUtil.getInstance(SimpleKeyValueUtil.java:68)
at com.tridium.nre.platform.NativePlatformProvider.lambda$getKeyMaterial$20(NativePlatformProvider.java:1512)
... 20 more
SEVERE [11:52:29 17-Nov-20 CET][security.keyMaterial] Error checking for existence of key material
java.lang.RuntimeException: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at com.tridium.nre.platform.NativePlatformProvider.getKeyMaterial(NativePlatformProvider.java:1528)
at com.tridium.nre.security.km.PlatformKeyMaterial.doGetKeyMaterial(PlatformKeyMaterial.java:56)
at com.tridium.nre.security.km.KeyMaterial.getKeyMaterial(KeyMaterial.java:33)
at com.tridium.nre.security.km.KeyMaterial.keyExists(KeyMaterial.java:61)
at com.tridium.nre.security.km.KeyMaterialFactory.getKeyMaterial(KeyMaterialFactory.java:82)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:93)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:77)
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.security.KeyRingFactory.getKeyRing(KeyRingFactory.java:68)
at com.tridium.nre.security.SecurityInitializer.initSecurityInfo(SecurityInitializer.java:350)
at com.tridium.nre.security.SecurityInitializer.configure(SecurityInitializer.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.tridium.nre.di.BaseSupplier.evaluateConfiguration(BaseSupplier.java:99)
at com.tridium.nre.di.SingletonSupplier.get(SingletonSupplier.java:62)
at com.tridium.nre.di.NreInstantiator.instance(NreInstantiator.java:123)
at com.tridium.nre.bootstrap.Bootstrap.Main(Bootstrap.java:87)
Caused by: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at com.tridium.nre.util.SimpleKeyValueUtil.getInstance(SimpleKeyValueUtil.java:68)
at com.tridium.nre.platform.NativePlatformProvider.lambda$getKeyMaterial$20(NativePlatformProvider.java:1512)
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.platform.NativePlatformProvider.getKeyMaterial(NativePlatformProvider.java:1511)
... 18 more
SEVERE [11:52:29 17-Nov-20 CET][security.keyMaterial] Permission failure when getting key material
java.security.PrivilegedActionException: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.platform.NativePlatformProvider.getKeyMaterial(NativePlatformProvider.java:1511)
at com.tridium.nre.security.km.PlatformKeyMaterial.doGetKeyMaterial(PlatformKeyMaterial.java:56)
at com.tridium.nre.security.km.KeyMaterial.getKeyMaterial(KeyMaterial.java:33)
at com.tridium.nre.security.km.KeyMaterial.keyExists(KeyMaterial.java:61)
at com.tridium.nre.security.km.KeyMaterialFactory.getKeyMaterial(KeyMaterialFactory.java:97)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:93)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:77)
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.security.KeyRingFactory.getKeyRing(KeyRingFactory.java:68)
at com.tridium.nre.security.SecurityInitializer.initSecurityInfo(SecurityInitializer.java:350)
at com.tridium.nre.security.SecurityInitializer.configure(SecurityInitializer.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.tridium.nre.di.BaseSupplier.evaluateConfiguration(BaseSupplier.java:99)
at com.tridium.nre.di.SingletonSupplier.get(SingletonSupplier.java:62)
at com.tridium.nre.di.NreInstantiator.instance(NreInstantiator.java:123)
at com.tridium.nre.bootstrap.Bootstrap.Main(Bootstrap.java:87)
Caused by: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at com.tridium.nre.util.SimpleKeyValueUtil.getInstance(SimpleKeyValueUtil.java:68)
at com.tridium.nre.platform.NativePlatformProvider.lambda$getKeyMaterial$20(NativePlatformProvider.java:1512)
... 20 more
SEVERE [11:52:29 17-Nov-20 CET][security.keyMaterial] Error attempting to upgrade key material
java.lang.RuntimeException: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at com.tridium.nre.platform.NativePlatformProvider.getKeyMaterial(NativePlatformProvider.java:1528)
at com.tridium.nre.security.km.PlatformKeyMaterial.doGetKeyMaterial(PlatformKeyMaterial.java:56)
at com.tridium.nre.security.km.KeyMaterial.getKeyMaterial(KeyMaterial.java:33)
at com.tridium.nre.security.km.KeyMaterial.keyExists(KeyMaterial.java:61)
at com.tridium.nre.security.km.KeyMaterialFactory.getKeyMaterial(KeyMaterialFactory.java:97)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:93)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:77)
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.security.KeyRingFactory.getKeyRing(KeyRingFactory.java:68)
at com.tridium.nre.security.SecurityInitializer.initSecurityInfo(SecurityInitializer.java:350)
at com.tridium.nre.security.SecurityInitializer.configure(SecurityInitializer.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.tridium.nre.di.BaseSupplier.evaluateConfiguration(BaseSupplier.java:99)
at com.tridium.nre.di.SingletonSupplier.get(SingletonSupplier.java:62)
at com.tridium.nre.di.NreInstantiator.instance(NreInstantiator.java:123)
at com.tridium.nre.bootstrap.Bootstrap.Main(Bootstrap.java:87)
Caused by: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at com.tridium.nre.util.SimpleKeyValueUtil.getInstance(SimpleKeyValueUtil.java:68)
at com.tridium.nre.platform.NativePlatformProvider.lambda$getKeyMaterial$20(NativePlatformProvider.java:1512)
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.platform.NativePlatformProvider.getKeyMaterial(NativePlatformProvider.java:1511)
... 18 more
SEVERE [11:52:29 17-Nov-20 CET][security.keyMaterial] Permission failure when setting key material
java.security.PrivilegedActionException: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.platform.NativePlatformProvider.setKeyMaterial(NativePlatformProvider.java:1569)
at com.tridium.nre.security.km.PlatformKeyMaterial.doSetKeyMaterial(PlatformKeyMaterial.java:67)
at com.tridium.nre.security.km.KeyMaterial.setKeyMaterial(KeyMaterial.java:42)
at com.tridium.nre.security.km.KeyMaterialFactory.getKeyMaterial(KeyMaterialFactory.java:110)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:93)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:77)
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.security.KeyRingFactory.getKeyRing(KeyRingFactory.java:68)
at com.tridium.nre.security.SecurityInitializer.initSecurityInfo(SecurityInitializer.java:350)
at com.tridium.nre.security.SecurityInitializer.configure(SecurityInitializer.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.tridium.nre.di.BaseSupplier.evaluateConfiguration(BaseSupplier.java:99)
at com.tridium.nre.di.SingletonSupplier.get(SingletonSupplier.java:62)
at com.tridium.nre.di.NreInstantiator.instance(NreInstantiator.java:123)
at com.tridium.nre.bootstrap.Bootstrap.Main(Bootstrap.java:87)
Caused by: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at com.tridium.nre.util.SimpleKeyValueUtil.getInstance(SimpleKeyValueUtil.java:68)
at com.tridium.nre.platform.NativePlatformProvider.lambda$setKeyMaterial$23(NativePlatformProvider.java:1570)
... 19 more
SEVERE [11:52:29 17-Nov-20 CET][security.keyMaterial] Error generating key material
java.lang.RuntimeException: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at com.tridium.nre.platform.NativePlatformProvider.setKeyMaterial(NativePlatformProvider.java:1583)
at com.tridium.nre.security.km.PlatformKeyMaterial.doSetKeyMaterial(PlatformKeyMaterial.java:67)
at com.tridium.nre.security.km.KeyMaterial.setKeyMaterial(KeyMaterial.java:42)
at com.tridium.nre.security.km.KeyMaterialFactory.getKeyMaterial(KeyMaterialFactory.java:110)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:93)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:77)
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.security.KeyRingFactory.getKeyRing(KeyRingFactory.java:68)
at com.tridium.nre.security.SecurityInitializer.initSecurityInfo(SecurityInitializer.java:350)
at com.tridium.nre.security.SecurityInitializer.configure(SecurityInitializer.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.tridium.nre.di.BaseSupplier.evaluateConfiguration(BaseSupplier.java:99)
at com.tridium.nre.di.SingletonSupplier.get(SingletonSupplier.java:62)
at com.tridium.nre.di.NreInstantiator.instance(NreInstantiator.java:123)
at com.tridium.nre.bootstrap.Bootstrap.Main(Bootstrap.java:87)
Caused by: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at com.tridium.nre.util.SimpleKeyValueUtil.getInstance(SimpleKeyValueUtil.java:68)
at com.tridium.nre.platform.NativePlatformProvider.lambda$setKeyMaterial$23(NativePlatformProvider.java:1570)
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.platform.NativePlatformProvider.setKeyMaterial(NativePlatformProvider.java:1569)
... 17 more
Exception in thread "main" com.tridium.nre.di.NreInstantiationException: unable to create instance
at com.tridium.nre.di.SingletonSupplier.get(SingletonSupplier.java:71)
at com.tridium.nre.di.NreInstantiator.instance(NreInstantiator.java:123)
at com.tridium.nre.bootstrap.Bootstrap.Main(Bootstrap.java:87)
Caused by: java.lang.RuntimeException: Unable to initializeSecurityProviders key ring
at com.tridium.nre.security.SecurityInitializer.initSecurityInfo(SecurityInitializer.java:357)
at com.tridium.nre.security.SecurityInitializer.configure(SecurityInitializer.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.tridium.nre.di.BaseSupplier.evaluateConfiguration(BaseSupplier.java:99)
at com.tridium.nre.di.SingletonSupplier.get(SingletonSupplier.java:62)
... 2 more
Caused by: java.lang.SecurityException: Could not generate key material
at com.tridium.nre.security.km.KeyMaterialFactory.getKeyMaterial(KeyMaterialFactory.java:116)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:93)
at com.tridium.nre.security.KeyRingFactory$GetKeyRingPrivilegedAction.run(KeyRingFactory.java:77)
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.security.KeyRingFactory.getKeyRing(KeyRingFactory.java:68)
at com.tridium.nre.security.SecurityInitializer.initSecurityInfo(SecurityInitializer.java:350)
... 9 more
Caused by: java.lang.RuntimeException: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at com.tridium.nre.platform.NativePlatformProvider.setKeyMaterial(NativePlatformProvider.java:1583)
at com.tridium.nre.security.km.PlatformKeyMaterial.doSetKeyMaterial(PlatformKeyMaterial.java:67)
at com.tridium.nre.security.km.KeyMaterial.setKeyMaterial(KeyMaterial.java:42)
at com.tridium.nre.security.km.KeyMaterialFactory.getKeyMaterial(KeyMaterialFactory.java:110)
... 14 more
Caused by: java.io.IOException: Process can not write to provided directory '/etc/niagara'
at com.tridium.nre.util.SimpleKeyValueUtil.getInstance(SimpleKeyValueUtil.java:68)
at com.tridium.nre.platform.NativePlatformProvider.lambda$setKeyMaterial$23(NativePlatformProvider.java:1570)
at java.security.AccessController.doPrivileged(Native Method)
at com.tridium.nre.platform.NativePlatformProvider.setKeyMaterial(NativePlatformProvider.java:1569)
... 17 more
App Failed
It occurred most often when after performing cleanDist, the controller was rebooted too quickly, due to, for example, a loss of power supply, which prevented finishing of the keyMaterial file generation. After the controller restarted, the platform was not able to generate the file again.
Solution
To solve the problem of the damaged keyMaterial file, perform cleanDist again making sure that the controller will be steadily powered during the process.