[Jeff Hatch]

Hello Joe,

Updating the EEPROM will require opening the chassis/case to put a jumper on the MTCDT board. Unfortunately, I think that would void the warranty. I suggest that you contact Multitech support at https://support.multitech.com. I can’t promise anything, but they may be able to do an exchange or something.

Someone definitely reprogrammed those fields in the EEPROM. The numbers in the device-id and IMEI would not end up that way due to corruption.

Jeff

[Jeff Hatch]

Hello Joe,

The device-id, imei, mac-addr, and uuid do not look correct. The mac-bluetooth and mac-wifi are not set for some reason even though the capa values for those are set to “yes”. Do you know where this device came from? This looks like someone set dummy values for some reason. Without the device-id it is going to be hard to figure out where this device came from.

Jeff

[Jeff Hatch]

Hello Joe,

First, can you confirm that the EEPROM has the incorrect value? Is the 00:80:00:10:00:00 the address reported in the /var/log/messages when the device is booted? There are log messages from the mts-io kernel module that report the EEPROM contents.

Thank You,

Jeff

[Jeff Hatch]

Hello WK,

In the /var/log/messages the logging events by a daemon called annexcd. If there are errors related to check-in the annexcd logging will be helpful. It is the daemon that does the actual connection to DeviceHQ.

Jeff

[Jeff Hatch]

Hello Ajay,

In order to get the dedicated attention this will need you should open a case with https://support.multitech.com/ since this involves different radios and versions of the firmware on the Conduits. This is going to involve digging through some logs and debugging the connection attempt(s) with AT commands to discover what state the radios are in.

Jeff

[Jeff Hatch]

Hello Ajay,

This is odd from my perspective. When you use the API restart the only difference is that the modem is reset during the boot. I think that might be helping synchronize all the steps that get followed to start up the Cellular connection. If you are using the mPower or AEP firmware can you tell me what version you are seeing this on? Which Cellular radio? I’m assuming it is a “blue box” MTCDT. Is that correct?

Which version of firmware is definitely a big deal. There have been a very large number of changes and improvements in the connectivity management over the last year.

Thank You,

Jeff

[Jeff Hatch]

Hello Fred,

Configuring full SMTP AUTH and/or SMTPS (TLS) are not currently supported with the mPower SMTP feature. Google’s mail servers have required AUTH and the authentication requires an “administrator account” and not a user account, ie. your @gmail.com cannot be used.

There is also another possible way to use gmail by using a Static IP on the router. I have not worked through the steps to get a Multitech device to work with gmail as a SMTP relay. Someone at http://support.multitech.com/ might know.

Jeff

[Jeff Hatch]

Hello,

There isn’t a way to get into Linux single-user mode (not without messing with the run levels). The explanation is mainly to do with security. Customers that have analyzed our products do not want it available during the boot process.

Depending on what you are needing to do, it is possible to drop into the boot loader (u-boot). From there you can do a lot of things and have complete control of the device. Accessing the rootfs and other file system partitions is possible, but it is tedious.

Jeff

[Jeff Hatch]

Hello Melanie,

Here is a script to do what you are trying to do with curl that was tested against Ubuntu:

#! /bin/bash
#check commissioning mode
##script tested using ubuntu
set -e
 
curl -k "https://192.168.2.1/api/commissioning"
 
##set username
aas_ID=$(curl -k -X POST -H "Content-Type: json/apaas_IDplication" -d '{"username":"admin", "aasID": "", "aasAnswer":""}' https://192.168.2.1:443/api/commissioning | jq -r '.result.aasID' )
##set password
curl -k -X POST -H "Content-Type: json/application" -d '{"username":"admin", "aasID":"'"$aas_ID"'", "aasAnswer":"Admin123"}' https://192.168.2.1:443/api/commissioning
##confirm password
curl -k -X POST -H "Content-Type: json/application" -d '{"username":"admin", "aasID":"'"$aas_ID"'", "aasAnswer":"Admin123"}' https://192.168.2.1:443/api/commissioning
 
##log in and save token
token=$(curl -k "https://192.168.2.1/api/login?username=admin&password=Admin123"| jq -r '.result.token' )
 
curl -k -X POST -H "Content-Type: json/application" -d '{"info":{"fileName":"conduit_5.3.0_upgrade-signed.bin","fileSize":81674240}}' https://192.168.2.1/api/command/firmware_pre_upgrade?token=$token
curl -i -k -b /tmp/headers --http1.0 -F file=@conduit_5.3.0_upgrade-signed.bin "https://192.168.2.1/api/command/firmware_check?token=$token"
curl -k -X POST -H "Content-Type: json/application" -d '' https://192.168.2.1/api/command/firmware_upgrade?token=$token
 
sleep 12m
 
token1=$(curl -k "https://192.168.2.1/api/login?username=admin&password=Admin123"| jq -r '.result.token' )
 
#factory reset back to comissioning mode
curl -k -X POST -d "" https://192.168.2.1/api/command/restore_defaults?token=$token1

I think that the -d option with the JSON data is what may make the difference. Among other things there is a “filesize” field for the size of the upgrade file.

Thank You,

Jeff

[Jeff Hatch]

Hello Ajay,

I’m pretty sure that “{ “ip” : “192.168.2.200”, “interface” : “ANY” }” is that JSON object referred to that is in the script code. I would start with that. The interface options should be the same as those in the Debug Options in the Web UI.

Jeff

[Jeff Hatch]

Hello Ajay,

I’m pretty sure that there is an API command that will ping out through the Linux system and not the radio, and is what you could use. There is a brief description here: http://www.multitech.net/developer/software/mtr-software/mtr-api-reference/command-table/

As a matter of fact I have an old script that used to work that would at least give you a head start on how to use the command in the API. I don’t have time at the moment to test it, but maybe it even still works:

#!/bin/bash
# load-config v1

ARG_NUM=$#

show_usage()
{
  echo "Usage: pingAPI:"
  echo ""
  echo "  To ping from the device"
  echo "      pingAPI DEVICE_ADDRESS LOGIN PASSWORD IPADDRESS"
  echo ""
  echo "  All arguments are required"
}

# Checking input arguments number
if [ ${ARG_NUM} -ne 4 ] && [ ${ARG_NUM} -ne 4 ]
then
  echo "Error: incorrect number of input arguments"
  show_usage
  exit 1;
fi

# Arguments input process
ADDRESS=https://$1
LOGIN=$2
PASSWORD=$3
echo "PASSWORD=${PASSWORD}"
if [ ${ARG_NUM} -eq 4 ]
then
  SAVE_PATH=$4
  # If the path is a directory
  if [ -d ${SAVE_PATH} ]; then
    echo "Error: specified path is a directory"
    show_usage
    exit 1;
  fi
else
  # Will be obtained later
  SAVE_PATH=""
fi

# Logging in
TOKEN=$(curl -s -k -X POST "${ADDRESS}/api/login" -d "username=${LOGIN}" -d "password=${PASSWORD}" | grep "token")

echo "response TOKEN: ${TOKEN}"

if [ ${?} -ne 0 ]
then
  echo "Error: cURL could not connect to the specified address"
  show_usage
  exit 1;
fi

# Token extracting
TOKEN=${TOKEN##*'token" : "'}
TOKEN=${TOKEN%%'"'*}

echo "extracted TOKEN: ${TOKEN}"

# Obtaining the file URL
#FILE_URL=$(curl -s -k "${ADDRESS}/api/command/download_config?method=POST&token=${TOKEN}")
PING_RES=$(curl -s -k -X POST -H "Content-Type: application/json" -d '{ "ip" : "192.168.2.200", "interface" : "ANY" }' "${ADDRESS}/api/command/ping?token=${TOKEN}")

if [ ${?} -ne 0 ]
then
  echo "Error: cURL could not obtain file rquest address"
  show_usage
  exit 1;
fi

echo "RESULT: ${PING_RES}"

Jeff

[Jeff Hatch]

Hello Ajay,

There are ways to do a ping. I would recommend pinging from your app if the remote host will respond. The Cellular connection can get “broken” without the device knowing. The only way to verify that the connection is still working is to ping. That is what the ICMP check does in the Cellular management on the mPower devices. There are ways to check that a tcp connection will be successful also. What the timeout values would need to be is probably empirical based on the application.

It boils down to this: If the Linux system can route to and ping a remote device then barring firewalls and other things getting in the way, a tcp connection should work. A Cellular connection can still be up, but traffic is either prohibited for some reason or cannot be routed.

Jeff

[Jeff Hatch]

Hello Marco,

The key is the requirement to have no Internet connectivity. That definitely changes how the feature could/would work. An enhancement request for this idea has been submitted. There is no guarantee on when it could get done, but both something like we discussed from Device HQ and in the Web UI on the device are good ideas.

Jeff

[Jeff Hatch]

Hello Marco,

At this time there is nothing that I can think of available to do something like that through the Web UI. That could be a feature enhancement. Would something like being able to specify a Python function and it’s arguments in the UI be useful? Possibly a python function along with a dictionary that would contain the argument data for the function?

Of course this would have security ramifications.

Perhaps something that can be run on the device for Device HQ similar to a LAMBDA function in AWS Greengrass, for example?

At this point it is brainstorming.

Jeff

[Jeff Hatch]

I’ve not had much luck with any kind of permissions on an SD card via Linux when the card is formatted in FAT32. In fact, I don’t think that FAT32 has any way of storing file permissions, so I don’t know if it could do anything with directory permissions.

If you want, you could file a case at https://support.multitech.com/support/login.html to see if you can get some help getting EXT4 working. If nothing else, they will know the exact specs the SD Card needs to be compatible with a Conduit.

Jeff

[Jeff Hatch]

Hello,

If the formatting utilities along with a lot of other “app building” tools, ie. cross compiler etc., were included on the Conduit there would be no space for anything else.

Using app-manager is not a requirement as long as you are not planning to use the Device HQ platform to manage your application(s).

One additional thing: The throughput on the SD card will be limited by the CPU and hardware on the Conduit. What that means is that you will not want to log lots of data to the SD Card or do busy database operations like high usage of a SQLite database. If you are just using it to store your apps and run them from there you should be good.

Jeff

Jeff

[Jeff Hatch]

Hello,

I think this has to do with assumptions that were made in managing SSH from the Web UI. I have added an enhancement request to support disabling password authentication and supporting public key authentication.

Jeff

[Jeff Hatch]

Hello,

The FAT32 or EXT3/4 formats should work on the MTCDT. Formatting can be done on any Windows or Linux PC (as long as you have an SD card slot). Have you “sudo’ed” to root privilege before trying to access the SD card?

# sudo -s

For instructions to get started on creating a custom application see http://www.multitech.net/developer/software/aep/creating-a-custom-application/

Custom applications are managed on the Conduit by the app-manager program. This program can be used to install applications locally or download them remotely from Device HQ. It is also used to manage the applications starting and stopping.

Jeff

[Jeff Hatch]

Did you have a custom LoRa configuration of any kind that you created? This sounds like either something in the configuration broke the formatting for the database, or something else related to the configuration caused the API to have errors.

I don’t suppose you have an /var/log/messages logs from the time of when the Save/Apply issue was occurring?

Jeff

[Jeff Hatch]

Hello Anthony,

Please file a Support Portal Case at https://support.multitech.com/support/login.html. This is either some kind of timing problem in kernel module initialization of mts-io or a hardware issue. Either way, more investigation is needed.

Thank You,

Jeff

[Jeff Hatch]

Hello Ajay,

I would recommend that you file a Support Portal case at https://support.multitech.com/support/login.html.

Thank You,

Jeff

[Jeff Hatch]

Hello Rafael,

I did find one interesting difference between starting the app by hand at the command line and through the init script on boot. On boot the /etc/init.d/customapp script sets the –initd flag when executing the app-manager program. This would have the effect of causing the Start script to get executed as “/var/config/app/app-name/Start start –initd”. If that messes up the argument processing on the Start script maybe that is causing a problem.

Jeff

[Jeff Hatch]

Hello Rafael,

I think that by executing the “run-app” script in the foreground it may be what is causing the app to not go into the background when executed at the command line. Try running “run-app” in the background, ie “run-app &”. Let’s see if that “fixes” the execute at the CLI behavior.

It is odd, but I have seen some interesting behavior between processes and deadlocks with non-backgrounded processes and also with running backgrounded process where the app’s pipes (stdout and stderr) were not redirected to /dev/null. By trying to run with the something like the following: “node app.js > /dev/null 2>&1 &” it might help cause all the pipes to be “disconnected” between the parent and child processes.

Jeff

[Jeff Hatch]

Hello Rafael,

In the Start script, what does the command that starts the application look like?

Jeff

[Jeff Hatch]

Hello Rafael,

It doesn’t appear that the SDCard value is defined in the application manifest file, so it should be installed on an SD Card. Is that correct? We need to verify where it got installed to.

Do you have any logging from when you ran the “sudo app-manager –command start –appid ” command? The only output I see that you captured from app-manager looks like it is running the status command and having difficulty finding the status.json file. Possibly because the app isn’t where it expects it to be.

Jeff

[Jeff Hatch]

Hello Rafael,

Could you do a “cat /var/config/AppManager.json” and let me know what is in that file?

Thank You,

Jeff

[Jeff Hatch]

Ajay,

As far as I know that is correct. Connecting with a SIM via WWAN should work with PPP also.

Jeff

[Jeff Hatch]

Hello Ajay,

My best guess would be that something happened initially with registration and the radio could not connect. When the switch to WWAN was done, the device firmware and/or radio initiated a “deregister” and then re-registered successfully.

Did the SIM get moved from another device to the one in question? There have been times when a SIM was being used with another radio and that radio didn’t get deregistered before the SIM was switch, and the SIM with being in a different radio caused registration issues.

Both are just hypothesis, but those are a couple of things that we’ve seen that cause that type of behavior.

Jeff

[Jeff Hatch]

Ajay,

I might be able to hypothesize, but first: Which radio was it?

Jeff

[Jeff Hatch]

Hello Ajay,

If bandwidth is a priority I highly recommend WWAN. Testing has shown WWAN to have three times or more bandwidth than PPP.

In future products we are not planning to support PPP due to the fact that it is slower and it is actually harder to maintain when supporting the newer radios.

Jeff

• This reply was modified 4 years, 5 months ago by Jeff Hatch.

[Author]

Posts