[Jeff Hatch]

Hello Ajay,

Sorry about the delay. I’m pretty bogged down with a bunch of things and am having a hard time getting back to this. I agree that the best route right now is to file a support portal case. It will at least get another set of eyes on it.

Jeff

[Jeff Hatch]

Hello Ajay,

After you have installed the custom application, have you logged into the Web UI and looked to see if the application can be found on the Apps page? The customApps data doesn’t persist if I recall correctly. It is an in-memory thing in the API at run-time. What is the output of the “app-manager –command status”?

Are you able to execute the application by hand directly in /var/config/app/Orcellap? Also, are you running this application on an MTR or Conduit? I see the “rcell” in the app name and am just wondering.

Thank You,

Jeff

[Jeff Hatch]

Hello Ajay,

I think that with the kernel upgrade from 1.7.x that the nf_conntrack_helper module and possible other required modules for doing things like passive FTP and other multi-port back-and-forth protocols like H323 and SIP are disabled.

To turn on nf_conntrack_helper you can execute the following command:

sysctl -w net.netfilter.nf_conntrack_acct=1

This will not persist through reboot. To do that you will have to add an entry to the /etc/sysctl.conf

This sysctl is now disabled by default due to the protocols it is supporting and the behaviors of those protocols is inherently insecure. Being that you are trying to use SFTP, hopefully the conntrack module being enabled will solve your problem and at least secure FTP tries to be much more secure by encrypting inside SSL via SSH.

Thank You,

Jeff

[Jeff Hatch]

Hello Ajay,

I mean …,:) Sorry about the name deal. Lot’s going on and I have problems remembering who I’m talking with somtimes:(

Anyway, It is possible to run the app-manager “by hand” at the command line and execute the custom application. Running “app-manager -h” prints out the options. You would execute something like this:

app-manager –command start –appid –appname

You can get the app_id and app_name from the app-manager database. A lot of the time “app-manager –command status” will print out the application information, but I’m not sure that the app_id would be available. Doing a “cat /var/config/AppManager.json” will print all the info that app-manager has on any apps installed.

If running app-manager by hand at the command line doesn’t yield any more information or errors, then you might have to run the start script by hand and even the app itself.

Jeff

[Jeff Hatch]

Hello William,

The app-manager executes the start script with root privilege and is effectively root. What are the permissions on the files that are not accessible and where are they on the system?

Thank You,

Jeff

[Jeff Hatch]

The upgrade “.bin” file gets up loaded to the tmpfs in /tmp which is a link to /var/volatile. The /var/volatile directory appears to be full:

tmpfs 123.3M 121.6M 1.7M 99% /var/volatile

A reboot may clean up most of the stuff in /var/volatile. Then try the upgrade.

Jeff

[Jeff Hatch]

Christopher,

I have been able to reproduce the same thing. The interesting thing is that when I added the openwrt line to the mlinux-feed.conf and do an opkg list, I can see a lot of openwrt stuff that got pulled in from the Packages.gz, but the avahi stuff isn’t there. If I have time I will dig a little more.

Jeff

[Jeff Hatch]

Samuel,

If you are referring to the RSSI it is available in the stats/radio collection, ie. api/stats/radio

An example of this collection would be:

{
   "code" : 200,
   "result" : {
      "abnd" : "EUTRAN BAND4",
      "carrier" : "Verizon Wireless",
      "channel" : "2050",
      "cid" : "2ED1B0C",
      "code" : "LNA7",
      "debug" : {
         "rsrp" : "-112",
         "rsrq" : "-15",
         "rssidBm" : "-76",
         "sd" : "CS+PS"
      },
      "expired" : true,
      "firmware" : "EG95NAFBR05A04M4G",
      "firmwarebuild" : "Not Supported",
      "hardware" : "Not Supported",
      "iccid" : "89148000001470859108",
      "imei" : "869394030020900",
      "imsi" : "311480148821104",
      "lac" : "BF35",
      "manufacturer" : "Quectel",
      "mcc" : "311",
      "mdn" : "+17632495361",
      "mnc" : "480",
      "model" : "EG95",
      "msid" : "0148821104",
      "netreg" : "REGISTERED",
      "network" : "Verizon",
      "quectelDebug" : {
         "dlBandwidth" : "5",
         "freqBandInd" : "4",
         "isTdd" : "\"FDD\"",
         "pcid" : "271",
         "rat" : "LTE",
         "sinr" : "-4",
         "srxlev" : "-",
         "state" : "\"NOCONN\"",
         "ulBandwidth" : "5"
      },
      "roaming" : false,
      "rssi" : 19,
      "rssidBm" : "-75",
      "service" : "LTE",
      "tac" : "BF35",
      "timestamp" : "02/19/2020 17:32:38",
      "type" : "LTE"
   },
   "status" : "success"
}

Jeff

[Jeff Hatch]

Hello Martin,

The instructions that you followed are for an mLinux model. This thread is on the Conduit AEP forum so I assumed you were running the mPower version of the Conduit and not just mLinux. If you are running the mPower version of Conduit you will need to go into the Web UI and on the Global DNS page you can change the hostname there.

The mPower software will overwrite the hostname in the /etc/hostname file, so editing the file by hand won’t do much good.

Jeff

[Jeff Hatch]

Martin,

I have tried to reproduce this unsuccessfully. Did you make sure to hit the “Submit” button on the Global DNS page before saving and restarting?

Jeff

[Jeff Hatch]

Python 3.5.2 is available with the latest mLinux release 5.1.8 in the feeds at http://www.multitech.net/mlinux/feeds/5.1.8/arm926ejste/

Python 3.5.3 was made available in Yocto in the rocko (2.4) release. I am not sure how compatible that bitbake recipe is with the one in Yocto Morty (currently used by Multitech Conduit). It is possible that it will just work with the current mLinux build, or it may not due to changes in bitbake.

Work is being done to support Yocto Thud on the current Conduit, however, I am not aware of what timeframe that may be available in.

Jeff

[Jeff Hatch]

Ali,

There was an issue with loading an essential driver to support the SD Card on 5.5.0. There is a workaround that Multitech Support can provide you or you can upgrade to a newer version.

There is a driver blacklist file somewhere that I cannot remember exactly that is causing the necessary driver to NOT load. Removing that file will cause the necessary kernel driver to get loaded.

Jeff

[Jeff Hatch]

Hello William,

I am not aware of any documentation outside of the API documentation that identifies defaults of the endpoints.

That said, I think the best way to find the defaults for most configuration values on the device is in the file /etc/db_default.json. That file is the factory defaults for the API database. The collections are pretty straight forward.

Which set of defaults are you looking for?

Thank You,

Jeff

[Jeff Hatch]

Hello Justine,

I would recommend that you have your pyModbusTCP slave post a listen on the appropriate interface (probably 192.168.2.1 since it sounds from your description that you access the device that way.) You should pick a port to listen on. My recommendation is port 1502 or 502 since that is what some applications use for modbus. You would also need to create a firewall Input Filter rule to allow modbus traffic to the port you pick.

You can package your python modbus application up as a custom application (http://www.multitech.net/developer/software/aep/creating-a-custom-application/) if you want to be able to install the application from Device HQ.

The libmodbus library is also available on the Conduit to build C/C++ applications, but unless you have a good reason to go that route Python is a good way to go for implementation.
Hope that helps.

Jeff

[Jeff Hatch]

William,

Please open a support portal case on this. They will need to know your configuration among some other things. Have you hit submit after disabling signed firmware validation? As long as you’ve done that and saved and rebooted to disable signed firmware validation, there is something else going on.

Thank You,

Jeff

[Jeff Hatch]

Hello William,

That script may not exist on 1.7.4. I know it exists in 5.0.0.

#!/bin/sh

DEBUG=1

if ((DEBUG)) ; then
LOGDBG=”/usr/bin/logger -s -t WIFI”
else
LOGDBG=”echo”
fi

function scan() {
# Ensure WLAN is up

if [ ! -d /sys/class/net/wlan0 ]; then
${LOGDBG} “Wifi client is not run”
fi
WLAN0_STATE=$(ifconfig wlan0 |grep UP|awk ‘{print $1}’)
if [ $WLAN0_STATE != “UP” ];then
ifconfig wlan0 up
${LOGDBG} “wlan0 is not up. bringing up”
fi
WLAN0_STATE=$(ifconfig wlan0 |grep UP|awk ‘{print $1}’)
if [ $WLAN0_STATE != “UP” ] ;then
${LOGDBG} “wlan0 has not been up. Scan is not possible”
exit 0
fi
ALLOW_SCAN=”true”
#
# Scanning hangs on connected rs9113 chip
#
RS9113_DETECTED=$(/usr/bin/lsusb | grep -o 1618:9113)
if [[ -n “$RS9113_DETECTED” ]]; then
CURRENT_SSID=$(iw dev wlan0 link | grep ‘SSID:’ | awk ‘{print $2}’)
if [[ -n “$CURRENT_SSID” ]]; then
${LOGDBG} “WiFi is connected to an access point. Scan is not possible.”
ALLOW_SCAN=”false”
fi
fi

if [[ “$ALLOW_SCAN” == “false” ]]; then
exit 0
fi

${LOGDBG} “Start scanning”
# Scan
#workaround rs9113 driver issue.
#if wifi client has connection to AP scanning doesnt stop never.
mts-timeout -t 15 -s 2 iw wlan0 scan
}

scan

[Jeff Hatch]

Hello William,

There is not a WiFi scan request through the API. The values you see in the GET requests you are doing are generated dynamically by a separate thread in the API. Theoretically, the data should be updated when a valid scan can be done (see next paragraph).

The WiFi on Conduit has a limitation that it cannot do a scan while the WiFi client is connected.

There is a script called wifiscan that exists on the Conduit that can be used as a reference for doing a wifi scan. As you will see in that script, it checks to see if the client is connected first before it tries to do a scan.

Hope that helps.

Jeff

[Jeff Hatch]

Hello William,

You are correct, Wi-Fi Access Point and Wi-Fi Client are both disabled when the device is set to Factory Settings.

Jeff

[Jeff Hatch]

Hmm. You can talk with the supplier, however, it would be a good idea to open a support case with support.multitech.com. Either the supplier did this, or there is an OEM problem of some kind. Whoever/whatever put that ‘$’ in the product-id is what I believe is causing this problem. The support engineers at Multitech can help you fix this, but someone needs to not be messing up the EEPROM values. I don’t think this EEPROM information was what was set in production out of the factory at Multitech.

It may be possible there is/was some kind of problem with the EEPROM. The Multitech support team can help you fix this and should be able to straighten out what is going on with the reseller.

Jeff

[Jeff Hatch]

Is this some kind of sample device? Other than the vendor ID none of the values in the eeprom on that device look valid.

Updating to 5.0.1 without valid values in the EEPROM will not solve this problem.

Setting values in the EEPROM can be done, however, you will need to talk with customer support at support.multitech.com. To write the EEPROM you need to put a jumper on the board and then write the values using a command like the following example:

mts-id-eeprom –in-file /sys/class/i2c-dev/i2c-0/device/0-0056/eeprom –update –out-format bin –uuid

Jeff

[Jeff Hatch]

Does the value for the product-id really contain a ‘$’? That is very odd and possibly the problem for parsing the command line arguments by the daemon. I am not sure where that character would be coming from.

At the command line could you perform the following command:

AEP 1.7.x:
mts-id-eeprom –in-file /sys/devices/i2c.3/i2c-0/device/0-0056/eeprom

AEP 5.x:
mts-id-eeprom –in-file /sys/class/i2c-dev/i2c-0/device/0-0056/eeprom

This will show the contents of the eeprom where the product-id and other pertinent information is stored.

Jeff

[Jeff Hatch]

Below is the ps output for the annexcd command line arguments on a Conduit that is successfully checking into devicehq.

root@mtcdt:/var/config/home/admin# ps auxww | grep annexcd
root 4745 0.0 0.6 2704 1540 ? S 13:17 0:00 /bin/bash /sbin/monitor-annexcd
root 4796 0.5 2.6 33068 6784 ? Sl 13:17 0:01 annexcd –account-key XXXXXXXX-xxxx-XXXX-xxxx-XXXXXXXXXXXX –host ds.devicehq.com –port 5798 –product-id MTCDT-LAT3-240L –device-id 12345678 –rpd-interval 43200000 –gps-interval 43200000 –net-interval 43200000 –cell-interval 43200000 –active-apps-interval 43200000 –lora-interval 43200000 –when-ppp-up on –firmware-upgrade true –config-upgrade true –config-upload false –radio-firmware-upgrade true –ssl-method tls –ssl-ca-certificate /etc/ssl/certs/rootCA.pem –ssl-ca-strict –log-upto 7 –dial-on-demand false
root 6163 0.0 0.4 3092 1096 pts/0 S+ 13:21 0:00 grep annexcd

The vendor-id argument is not required in this case. What are the messages from annexcd in /var/log/messages saying?

Jeff

[Jeff Hatch]

Bastien,

If you are looking for the SDK for 5.0.0 mLinux it is located at http://www.multitech.net/mlinux/sdk/5.0.0/

Code compiled with this SDK will run on an 5.0.0 AEP Conduit assuming all the dependencies are also there.

Thank You,

Jeff

[Jeff Hatch]

Benjamin,

Try “reset-defaults –hard”. I think that you are missing a “-” character before the long argument.

Jeff

[Jeff Hatch]

@akopan

Try connecting via HTTPS on port 443. The connection to port 80 is most likely getting redirected to port 443 HTTPS. If your application code is not handling redirection it will not work.

Jeff

[Jeff Hatch]

Kilian,

Do you still get these errors when you try to build without the layer you added? It is possible that some tools are being packaged that are built for the build host and not the ARM target.

Jeff

[Jeff Hatch]

William,

Do you have access through the Web UI to this device. This looks like the device’s Remote Management configuration has been changed. It is possible to turn off firmware upgrade, configuration upgrade, configuration upload, and change the check-in interval(s) through the UI.

Something/someone has changed the default settings which are 12hrs check-in interval, enable firmware upgrade, enable configuration upgrade, and enable configuration upload. By default Remote Management is disabled, so, since that is working it must be enabled.

Jeff

[Jeff Hatch]

Robert,

The “route -n” command should tell you which interface that the default route is set to. This will tell you what WAN the device is using. Then check the cellular interface status. Between the dashboard “home” page and the radio status you can see the status of the cellular connection.

Jeff

[Jeff Hatch]

Eric,

The download is working for me this morning. What error were you getting on the download?

Jeff

[Jeff Hatch]

I would recommend seeing if logrotate works. It is available on Conduit and is what is used with the syslog output.

[Author]

Posts