[Jeff Hatch]

Python will be at 2.7.3 for the next release of AEP Conduit. You will have to install the mqtt module(s). There is a bitbake recipe for the paho-mqtt python library here:

https://layers.openembedded.org/layerindex/recipe/33329/

Jeff

[Jeff Hatch]

Sun,

The process should be the same as what is documented under Using “Auto-Flash During Reboot” here:

Flashing mLinux Firmware

You will put the kernel and rootfs on the SD Card in a directory called flash-upgrade, and touch /var/volatile/do_flash_upgrade, then reboot.

Jeff

[Jeff Hatch]

Ajay,

Python applications have some latency when they first start (more than C++ but far far less than node), but after that they work pretty well. The python coding I have done with on AEP Conduit, it seems to be a few seconds, or thereabouts, and the app is up and running. With Python there are far fewer interdependencies than in node. The latency also seems a lot more predictable with Python.

Jeff

[Jeff Hatch]

Johann,

Please create a support case at https://support.multitech.com

Describe what has happened as you have stated here, and they can help you re-flash with u-boot.

Jeff

[Jeff Hatch]

Work is still being done to move to the Yocto Morty version of openembedded. That will hopefully wrap up soon and then testing will begin. I can guarantee it won’t be a year. Also, Python will be upgraded to 2.7.11.

Jeff

[Jeff Hatch]

There was a change in the version(s) of openssl. In the openssl.inc file under layers/meta-mlinux/recipes-connectivity/openssl there is the following:

# Remove this to enable SSLv3. SSLv3 is defaulted to disabled due to the POODLE
# vulnerability
EXTRA_OECONF = ” -no-ssl3″

Comment out the “EXTRA_OECONF = ” -no-ssl3″” line. The old Python 2.3.x doesn’t support SSL unless SSLv3 is available.

This is going to be remedied in the near future as the Yocto version of openembedded is updated.

Jeff

[Jeff Hatch]

Ajay,

Is the lorawan server you are referring to the lora server that comes with the Conduit? If so, that application is a compiled C/C++ application. The Node environment requires interpretation of the code and then including every dependency that needs to be read up from the filesystem. The reading of the flash and the fact that a lot of other processing is going on at the same time your app is starting up will max the CPU and cause a lot of stuff to run slowly. These reasons are probably the same reasons that the Node-RED application was slow and not performing.

Jeff

[Jeff Hatch]

Joshua,

What version of mLinux are you running?

Jeff

[Jeff Hatch]

Marta,

Glad to hear you got it working. Thank you for the info and suggestions.

Jeff

[Jeff Hatch]

Marta,

The process that handles the reset must not be getting started before the TTN LoRa and mp-packet-forwarder is started and waiting in the foreground for an Internet connection. It would be really helpful to know when in the init sequence that package puts it’s init script. I have heard other people have this same problem. The only way I know how to get out of this for sure is to re-install the mLinux firmware from u-boot. Directions for how to do this can be found at (under Using U-boot & TFTP):

Flashing mLinux Firmware

If you get back to installing the TTN stuff, check and see where in the ordering the init script got installed in the rc5.d run level directory. As I said, other people have run into the same issue, and it would be nice to see if there is anything that can be done to keep it from happening more.

Thanks,

Jeff

[Jeff Hatch]

Marta,

Have you installed any packages such as a third party LoRa server or anything. This looks like an init script is hanging the boot sequence waiting for an Internet connection. Is the Conduit configured and connected to a network with Internet access?

Jeff

[Jeff Hatch]

Ajay,

Other than making sure to re-install on firmware upgrade that we already discussed, I don’t see any issues with what you are doing.

Jeff

[Jeff Hatch]

Ajay,

Do you want to change the start order in a target run level?

ie. “update-rc.d customapp stop 31 5”

If that is the case just remember that your custom app will need to be responsible for this on it’s install since this change would get blown away by a firmware update.

Jeff

[Jeff Hatch]

Ajay,

The LOCAL appID should work to start and stop your application. Since you did a local install, and not from DeviceHQ, your app was assigned the appId of LOCAL. Currently, the way app-manager works, it was intended to only manage one LOCAL app at a time, so if you install a second, you may not get the behavior you want.

In my example, the application was installed by downloading it from DeviceHQ.

Jeff

[Jeff Hatch]

Ajay,

There is an API entry point at api/customApps in the Web UI. Here is an example of stopping an app:

admin@mtcdt:/var/config# curl -X POST -H ‘Content-Type: application/json’ -d ‘{}’ 127.0.0.1/api/customApps/58a4d0d85b1b015a89000006/stop
{
“code” : 200,
“status” : “success”
}

The trick will be to get the appId -> 58a4d0d85b1b015a89000006. You can get that from the output of:

curl -s 127.0.0.1/api/customApps

which will return something like this:

{
“code” : 200,
“result” : [
{
“_id” : “58a4d0d85b1b015a89000006”,
“description” : “Basic web server running on port 3000. Firewall is opened on install. node_modules is included in the tarball. Utilizes all custom app functionality including environment variables, custom status file, config file, and install scripts.”,
“info” : “Listening on port 3000 as of Mon May 01 2017 18:09:18 GMT+0000 (UTC)”,
“name” : “express-hello-world”,
“status” : “STOPPED”,
“version” : “1.4”,
“versionNotes” : “Implement restart and reload in the Start script”
}
],
“status” : “success”
}

Jeff

[Jeff Hatch]

Ajay,

Details on the status of a custom application integrated with the Custom Application Management in Conduit can be found here:

status.json Details

The status.json file is what is being read by the Web UI for the status information.

You can start and stop your application you can use app-manager:

app-manager –command start –appId

Or you could execute the Start script directly from your application.

Jeff

[Jeff Hatch]

Eric,

Unfortunately, the process that is used to do the reset from the reset button push and would do the factory default is at the end of start-up. I recommend that you create a support portal case and get some help from Multitech Support at: https://support.multitech.com/

Jeff

[Jeff Hatch]

Ajay,

1) While trying to not sound too pedantic (though I think security requires it), giving the app-manager permission to exec on a file and to chown the same file are two separate capabilities that can be controlled with Linux capabilites (see man capabilities). The capabilities/privileges of a process can be restricted through these settings.

2) The app-manager simply runs the Install script which will install anything in the provisioning directory. If you are un-tarring a file in the Install script it will perform that operation. However, the app-manager doesn’t untar the entire application tar file over again. The /var/config/app and the /media/card/ directory (with SD Card present) will persist through the firmware upgrade.

3) You should be able to use the postinstall step to do that. I think in the case you have described you will need two init scripts. One with just a start() to start the app before the LoRa WAN server with an empty stop() that does nothing, and a second script that will be run after the LoRa WAN script that has the stop() defined to stop the app that has an empty start().

I understand that this is a lot of work to prevent loss of packets. Welcome to the world of M2M with it’s many mirco-architectures.

Jeff

[Jeff Hatch]

Ajay,

I disagree that it should be the install code’s responsibility to chmod things correctly. Future devices will have much more “locked down” permissions for the different processes on the Conduit. At this time the app-manager code does not chown or chmod anything, and keeping it that way so we can make it least privileged will not only simplify things, but also make them more secure.

“However I am wondering how we would deal with a firmware upgrade and creating a soft link and installing the custom app?”

You’re in luck on this one. As long as your app Install script creates the link. The Install script for each custom app gets re-run every time there is a firmware upgrade.

“Also is there a way I can get a custom app launch before the lora-wan server/service is up and running?”

You can create your own init script that starts your app and have the Install script install it. You can install it using the rc.update utility at whatever level you want. Make sure to have your Start script essentially be a no-op so that the only instance that is running is the one started by your init script.

Jeff

[Jeff Hatch]

Ajay,

Are you running the Conduit 1.4.1 firmware? That is the only version that supports installing and running in flash. Anything before that will always try to install it on the SD Card and ignore the SDCard key.

Jeff

[Jeff Hatch]

Ajay K,

For the angel process, I think you will be fine using angel if you create your own link to /sbin/angel for management of your app process. That way none of the built-in functionality on the Conduit will kill it if it has a unique name. What I was referring to is the possibility that using angel through the link “node-angel” could match the node-angel process name and get killed unexpectedly due to Conduit’s built-in functionality managing the Node-RED process.

So, you should be ok using angel as long as your angel instances is running through a unique link.

As for the logs, I think that should work though I would put the “>& APP_LOGDIR/$NAME.log” in the DAEMON_ARGS since it will be an argument for the daemon to redirect output to the log file.

Jeff

[Jeff Hatch]

Ajay,

In your manifest file you are missing a ‘”‘ at the end of the AppVersion key. That is why the version is UNKOWN in the error statement.

As for the use of the angel process, if you use the node-angel (which is a link to the angel binary, see code) you will need to be careful because a “/etc/init.d/node-red killstop will also kill your app. See do_killstop() in /etc/init.d/node-red.

admin@mtcdt:/etc/rc5.d# ls -l /sbin/node-angel                                                            
lrwxrwxrwx    1 admin    root            11 Apr 24 15:28 /sbin/node-angel -> /sbin/angel

On install (in the Install script) your app could install it’s own link to angel, and that could be used by your Start script to start your app under an angel process. That would restart your app if it died.

Jeff

[Jeff Hatch]

Ajay,

Could you post the contents of your manifest file?

Jeff

[Jeff Hatch]

Ajay,

1) With the new firmware, the custom app can be run from within the Conduit flash as opposed to setting up the custom app on the external mcard correct?

Yes, that is correct, you will not need an SD card on AEP-1.4.1

2) Is it possible to order when the custom app runs when the conduit boots up, for example, can it be run before the node-red application reboots or can it be parallelized to start with the lora wan server and/or mqtt broker?

The custom app will be started just before the Node-RED app. Are you looking to restart the custom application in tandem with the Node-RED application? The LoRa network server starts before the custom application, but after mosquitto. The following is the contents of rc5.d:

admin@mtcdt:/etc/rc5.d# ls
S01networking                    S78ddns
S02dbus-1                        S80dnsmasq
S15mountnfs.sh                   S80lora-network-server
S20hostapd                       S81ppp
S20hwclock.sh                    S81time
S20ntpd                          S85ser-cli
S20syslog                        S85smsd
S30api                           S85wan-manager
S31local-time                    S90crond
S50usb-gadget                    S92led-cd-ss
S60lighttpd                      S95annex-client
S61syslog-configure              S95auto-reboot
S65remove-rs9113                 S95call_home
S70mosquitto                     S95customapp
S71backoff-timers                S95gps
S71database-init                 S95led-status_heartbeat_trigger
S71wireless-conf                 S95node-red
S72lanup                         S95remove_upgrade_occurred
S72post-upgrade                  S95reset-handler
S73bluetooth                     S95stunnel
S73wifi                          S95watchdogd
S75firewall                      S99rmnologin.sh
S75routing_table_setup           S99stop-bootlogd
S76sshd

3) If by any chance the Custom application exits because of an exception, what is the best way to restart it. Basically detect that it has exited and automatically restart it?

There are several ways to accomplish restart on a failure/fault/crash. One of the simplest it to write a script that is started by the applications Start script that does something like the following:

MYAPP="app_executable -arg1 -arg2 ..."
until $MYAPP; do
    echo "myapp exited with status $? -restarting..." >&2
    sleep 1
done

This will run the app executable, and when it exits will restart it. The only problem here is shutting down the app. For that you would need a signal handler to stop the executable app.

4) This is a nodejs based custom app, can the console.log statements being executed within the custom app be re-directed to a log file under /var/logs/app//.log?

You can do the same as what is done with Node-RED on the Conduit – pipe the output of the process to a file:

myapp -arg1 -arg1 >& /var/log/app//.log

Hope that helps,

Jeff

[Jeff Hatch]

Jeff,

That number of warnings is fairly normal. At least for the “attempting MIRRORS if available” messages. If something is required for the image and it fails to fetch the build will fail with an error.

I am not sure about the populate_sysroot warnings. It appears that there is no populate_sysroot in the bitbake recipes for those pieces of software. It may be that the bitbake cache is messed up somehow. Have you tried rebuilding from scratch?

Jeff

[Jeff Hatch]

Bharat,

This issue has been encountered rarely, and we are still trying to investigate it. I have several questions: How many times have you tried to download the file to the Conduit? Have you tried deleting the file on DeviceHQ, uploading it again to DeviceHQ, and then tried to download it to the Conduit again? What method are you using to download the file to your PC?

Jeff

[Jeff Hatch]

Piyush,

The reset button handling is done in mts_io.c in the mts-io kernel module. The source can be found in: git://git.multitech.net/mts-io.git

I believe the defaults in this code are overridden by the reset-handler script that can be found in the meta-mlinux layer: git://git.multitech.net/meta-mlinux.git

Jeff

[Jeff Hatch]

James,

If you are using the LoRa Network Server on the Conduit, it can send the data through MQTT to Mosquitto on the Conduit. At least it does that on the AEP Conduit. Have you looked into the AEP Conduit? It has Node-RED available, and you can use the LoRa node there to read the LoRa data, process it with a function node if you need to, and send it to the serial card using the multi-serial node.

There are also many references for reading from Mosquitto topics on the internet including C++ and Python examples. If you use the Network Server to write to Mosquitto topics, a C++ or Python program could read the topic and write to the serial card.

The nice thing about using the LoRa Network Server is that you won’t have to reinvent the wheel writing code to read the SPI interface.

Jeff

[Jeff Hatch]

James,

You should be able to use both those cards plugged into your Conduit at the same time.

Jeff

[Jeff Hatch]

Daniel,

Do you have a static or dynamic public IP from your provider? If the IP is not public, you will not be able to connect to or through the Conduit.

If you do have a public IP the steps to create a port forwarding rule should be as simple as:

1) Specify the external WAN port
2) Specify the destination LAN IP (192.168.2.213)
3) Specify the destination port (80 or 8080)
4) Save and restart

From there you should be able to pass traffic by having the external host go to the public IP of the Cellular connection, and it should get redirected to the internal IP and port.

To debug a little more you might try the nc utility and try to connect and send simple character strings to verify that a rule is working with your environment.

Jeff

[Author]

Posts