[Jeff Hatch]

Miha,

You will need to configure a WAN interface on one of the interfaces (Ethernet, WiFi, Cellular). Then enable access via WAN for HTTPS. Make sure you are not using the default password or you will get hacked faster than you can type.

Jeff

[Jeff Hatch]

Eric,

A couple of things that I noticed is that node-bacnet wants node 0.12.0 or newer, whereas the node on Conduit is stuck at 0.10.48 due to the fact that node stopped supporting the armV5 architecture after that release.

This is a node module, so are you trying to require it in a function node? I don’t believe that anything will show up in the Node-RED pallet.

Jeff

[Jeff Hatch]

Eric,

The node red log is in /var/log/app. See if there is anything pertaining to the bacnet node when node-red starts. What kind of dependencies does the bacnet node have?

Jeff

[Jeff Hatch]

Pascal,

There are some packages that had issues because they expected Internet connectivity in their boot scripts and would block until it was available. This would cause the boot to “hang” before the process was started that handles the reset button press. I believe that TTN and Loriot were a couple that may have had this issue. Some of those packages have been fixed since.

Jeff

[Jeff Hatch]

Patrick,

We’ve found that we’ve had to still test our Internet connectivity even though pppd is up and has carrier and connectivity with the tower. We basically ping 8.8.8.8 and if over a given amount of time the ping still isn’t working we restart pppd.

Jeff

[Jeff Hatch]

Patrick,

I’m pretty sure that pppd doesn’t automatically redial/reconnect. You will need to check the connection by pinging 8.8.8.8 or something like that, and if the ping fails restart pppd.

Jeff

[Jeff Hatch]

Pascal,

I looked at the code that handles the reset button press. It is handled in the mts-io kernel module and by the reset-monitor process. The kernel module keeps track of a short press (~5s), a long press (> ~5s && < = ~30s), and an extra long press (> ~30s).

On AEP, for a short press a SIGHUP is sent to the reset-monitor. For a long press a SIGUSR1 is sent to the rest-monitor. For an extra long press a SIGUSR2 is sent to the reset monitor. These are not the hard-coded defaults, but are set on boot by the AEP watchdog process. On the AEP Conduit the reset monitor process is the watchdog process. The following is what happens for each button press length:

short press (< ~5s): the system just reboots long press (> ~5s && < ~30s): the device is reset to user defined defaults and rebooted. The factory settings are used if user defined defaults have not been set. extra long press (> ~30s): the device is reset to factory defaults.

I believe that the status LED should go solid at the start of reboot until the kernel is back up and the mts-io module is reloaded, then the status LED should start blinking normally again, but don’t quote me on that as I have not dug into that functionality to verify that.

I have not observed any behavior outside these parameters on my device, however it is only one device, and the hardware is almost a year old.

I am interested what the load is on these devices that are exhibiting this bad behavior on reset. If you have time to gather some information and let me know here or file a support portal ticket at https://support.multitech.com, please let me know. If you can provide the following information:

1) Output of a top command to see what the CPU and memory state of the system is.
2) A ‘cat’ of /sys/devices/platform/mts-io/reset-monitor.
3) A ‘cat’ of /sys/devices/platform/mts-io/reset-monitor-intervals

That would be a start to figure some of these issues out. If #’s 1, 2, and 3 look OK, maybe it is an actual bad hardware problem.

Jeff

[Jeff Hatch]

John,

I would need the error output to determine anything.

Jeff

[Jeff Hatch]

John,

There is a “force” option (-f, –force) that might work. See https://docs.npmjs.com/cli/install

Jeff

[Jeff Hatch]

Brandon,
There is a script called get-eeprom-device-info in /sbin that gets the device information. In that information is the product-id field highlighted below. If the device was shipped as an AEP model, the product-id field ends with an ‘A’. If it shipped as an mLinux model, it ends with an ‘L’.

admin@mtcdt:/sbin# get-eeprom-device-info
[INFO] eeprom_main.c:main:577: loaded id eeprom from /sys/bus/i2c/devices/i2c-0/0-0056/eeprom successfully
[INFO] eeprom_main.c:mts_id_eeprom_inspect:291: sizeof: 512
[INFO] eeprom_main.c:mts_id_eeprom_inspect:292: vendor-id: Multi-Tech Systems
[INFO] eeprom_main.c:mts_id_eeprom_inspect:293: product-id: MTCDT-LAT1-247A
[INFO] eeprom_main.c:mts_id_eeprom_inspect:294: device-id: 19214963
[INFO] eeprom_main.c:mts_id_eeprom_inspect:295: hw-version: MTCDT-0.1
[INFO] eeprom_main.c:mts_id_eeprom_inspect:302: mac-addr: 00:08:00:4A:20:AB
[INFO] eeprom_main.c:mts_id_eeprom_inspect:303: imei: 358942053427614
[INFO] eeprom_main.c:mts_id_eeprom_inspect:304: capa-gps: yes
[INFO] eeprom_main.c:mts_id_eeprom_inspect:305: capa-din: no
[INFO] eeprom_main.c:mts_id_eeprom_inspect:306: capa-dout: no
[INFO] eeprom_main.c:mts_id_eeprom_inspect:307: capa-adc: no
[INFO] eeprom_main.c:mts_id_eeprom_inspect:308: capa-wifi: yes
[INFO] eeprom_main.c:mts_id_eeprom_inspect:309: capa-bluetooth: yes
[INFO] eeprom_main.c:mts_id_eeprom_inspect:310: capa-lora: no
[INFO] eeprom_main.c:mts_id_eeprom_inspect:318: mac-bluetooth: 00:23:A7:49:5D:FA
[INFO] eeprom_main.c:mts_id_eeprom_inspect:325: mac-wifi: 00:23:A7:43:A3:6C
[INFO] eeprom_main.c:mts_id_eeprom_inspect:331: uuid: 9E71DC6A7E185B1B5C704CEC123062FD
[INFO] eeprom_main.c:mts_id_eeprom_inspect:341: lora-eui: “00:00:00:00:00:00:00:00”
[INFO] eeprom_main.c:mts_id_eeprom_inspect:343: lora-product-id:
[INFO] eeprom_main.c:mts_id_eeprom_inspect:344: lora-hw-version:
Finding cellular module…
Try #0
Reading accessory cards data
Adding accessory cards data

That is one way to tell what model the Conduit is.

Jeff

[Jeff Hatch]

Joshua,

This release will be entering testing in the next few weeks. There will probably be at least six weeks of testing time. That probably puts it at the end of July at the very earliest.

Jeff

[Jeff Hatch]

Mike,

When you specify a subnet mask (netmask) of 255.255.255.254, you are specifying a subnet of two addresses. If this is what you want you would only be able to route to your own address and one other (in this case the gateway’s). Any traffic to the internet should be routed to the gateway, but you will not be able to directly route to anything else on the 192.96.161.0 subnet. You may be able to reach them through another interface and different gateway. I think that may be why the gateway is invalid. While this may be a valid configuration, it won’t accomplish much locally. That said, I think that this is a bug.

As for after you reset the conduit, I don’t think that 192.96.0.0/16 is a network-local address. If you try to connect to it without a gateway configured, and your PC is on a different subnet or network, you will not be able to connect.

I would recommend trying a subnet mask of 255.255.255.0 first and see if you can then define the gateway you want and see if that works. Then try a more restrictive subnet mask. I agree that you should be able to define the subnet mask that you first tried.

Jeff

[Jeff Hatch]

Ajay,

Glad to hear you have probably figured it out. It appears the app was not checking for existence of the /var/log/app directory before trying to open the log file. It is puzzling as to why the power cycle affected things in this way. I am still stumped on that one.

Jeff

[Jeff Hatch]

Christopher,

The libmpsse should already exist on your Conduit. You can try using the –force-depends option to opkg to ignore dependency errors on the ipk install.

Jeff

[Jeff Hatch]

Patrick,

On the AEP Conduit there is support for running ‘post-upgrade’ scripts. The ‘post-upgrade’ script checks for a file that was created in /var/config called upgrade_occurred. If the file exists, the post-upgrade script runs whatever scripts are in /opt/upgrade. After running the scripts it deletes the upgrade_occurred file in /var/config, and won’t run again unless upgrade_occurred gets created again.

You can do the same type of thing with an init script and ipk files.

Jeff

[Jeff Hatch]

Patrick,

The /var/oem is not used for anything on the mLinux model. It is used for custom customer configurations on the AEP model.

Your proposal for the how to get the script into your image sounds reasonable. Most of the init scripts reside in different directories pertaining to their feature bitbake recipe. For example, the reset-handler init script resides in layers/meta-mlinux/recipes-core/multitech/reset-handler. You’ll need a recipe similar to the reset-handler_1.0.bb that declares an INITSCRIPT_NAME and the corresponding INITSCRIPT_PARAMS that specify the update-rc.d options so that the script gets installed in the correct run level(s), etc.

Jeff

[Jeff Hatch]

Jean,

Are you using the mLinux or AEP version of the Conduit?

Jeff

[Jeff Hatch]

Ajay,

That is definitely a possibility. I didn’t think of that. Added that argument over two years ago. That argument helps make the node garbage collection a lot more aggressive if I remember correctly, and tries to keep the size down. Try it as an option to node when starting your app.

Jeff

[Jeff Hatch]

Ajay,

I’m pretty sure it’s where you have specified with the –pidfile argument. That is why I don’t think that is your problem because your –pidfile points to /var/run which is not persistent through reboot.

To figure out what run level you are currently running in:

admin@mtcdt:/var/run/config# runlevel
N 5

This example the current run level is 5. For some reason who -aH doesn’t display the run level, and the busybox who doesn’t have the ‘-r’ option.

Jeff

[Jeff Hatch]

Enkyan,

Please create a support portal case at https://support.multitech.com/ if you need more help with flashing the device.

Jeff

[Jeff Hatch]

Ajay,

As for the -initd parameter, it is just a way to detect whether the Start script is being run by the init script or not. There are customers that are doing their own startup init scripts and they don’t want our init script to start the app with the Start script, so they modified their Start script so it does nothing if it receives that parameter.

Jeff

[Jeff Hatch]

Ajay,

Before figuring out the run level stuff, is the pid file of the app still laying around with a pid value in it? If that is the case, maybe start-stop-daemon is checking the pid file and seeing that there is already a process running with that pid and won’t try to start the app. It’s worth checking. If that is the case, I would have to think a little bit to figure out what might be a solution.

However, I just realized by checking your script that the pid file is in /var/run, so that probably isn’t the problem.

Jeff

• This reply was modified 7 years, 11 months ago by Jeff Hatch.

[Jeff Hatch]

Ajay,

I’m not sure what exactly is going on in this case. Is it possible that a different run level is getting executed when you power back up in less than 30 seconds? That might explain why none of the startup for the application is getting executed.

Jeff

[Jeff Hatch]

Patrick,

There are not a lot of ways to get this to happen on the mlinux without more customization to your base image. You would need to include the init script in the image. To persist the .ipk files you can use an SD Card or you could put them in /var/config (/dev/mtdblock6) if there is enough room in that partition. I think that /var/config persists through the flashing process.

Jeff

[Jeff Hatch]

Ajay,

If your application doesn’t generate any status information as described at http://www.multitech.net/developer/software/aep/creating-a-custom-application/application-status/ app-manager will not know that anything is amiss due to the fact that the angel process is still running. If your app provides a pid and any status information through the status.json file you will receive more information from app-manager.

Jeff

[Jeff Hatch]

Patrick,

There isn’t anything that would automatically install .ipk files after an install of a new rootfs. You would probably have to create an init script that looks for files in a specific place and installs them if they are there and then deletes them so that they don’t get installed over and over again every time you reboot.

Jeff

[Jeff Hatch]

Ajay,

One thing you could do is turn up debugging through the Web UI so that processes like app-manager will log more information. The app-manager logging is all identified by the string “APPMANAGER” and should at least tell you if it is getting any errors. The app-manager program is what the custmapp init.d script uses to start the application.

Jeff

[Jeff Hatch]

Ajay,

If there is no debug logging that is helpful either on the console or in /var/log/messages and any other logs, I would insert debug logging in strategic places in an effort to determine where the app is failing.

Jeff

[Jeff Hatch]

Ajay,

Does your app require internet access right away when it starts? The reason I ask is that the Verizon radios, for whatever reason, take significantly longer to start up and get a connection. We have had to put in special code on the AEP and some of our other products to work around this for starting ppp or anything else that interoperates with the radio.

Jeff

[Jeff Hatch]

Jac,

There are multiple third party packet forwarders and network servers that people are installing on their Conduits. This is one of the first times that anyone has actually come out and said what package they were installing that was causing their boot issue. When designing init scripts, they should not block or retry anything indefinitely.

The process that handles reboots isn’t started until after your software was being started. Thus, the issue with the hang and inability to process the reset button presses. While not a desirable architecture, it has been that way for some time. This will be addressed in the future.

Thank you for updating your package to resolve the boot issue.

Jeff

[Author]

Posts