[Jeff Hatch]

Hello Dean,

If the device is from 2018 and is an AEP device there is a chance that a feature called “Call Home” may be taking down the Ethernet interface and trying to do DHCP as a client to get settings for the Ethernet interface. In that case the interface will go down for this activity every thirty seconds. The udhcpc process is supposed to only try once to get a lease and then exit, the interface is brought back up for another thirty seconds.

Also, what do the Ethernet LEDs appear to be doing?

Jeff

[Jeff Hatch]

Hello,

Which version of mPower are you working with? On versions older than 5.2.1, it is necessary to reboot the device. Even on 5.2.1 you will have to hit the submit button and the Save & Apply button to have changes take effect.

I believe that there is a Mosquitto broker on the device that the LoRa data can be read from.

Jeff

[Jeff Hatch]

Hello Guillermo,

The SNAT rule will NAT the source address of the device that the connection is coming from. Is that what you want it to do?

Jeff

[Jeff Hatch]

Hello Guillermo,

Hooking the two Conduits together like that with their Gateway settings pointing at each other will probably cause a routing loop. Maybe since they are configured as LAN the gateway settings for those interfaces won’t get set in the routing configuration. Can you ping from one Conduit to the other?

Jeff

[Jeff Hatch]

William,

The Node-RED stuff uses libmqtt “under the hood” to do it’s connections. A bunch of it is not external connections, but brokers on the device locally. Thus my question since I’m trying to figure out where they may be getting generated. Maybe a library or two need upgrading in mPower.

Thanks for helping out!

Jeff

[Jeff Hatch]

Hello Zwang,

Was your device doing this “straight out of the box” after you purchased it? If so, there it would be very good to know. There may be a step with SAM-BA that manufacturing at Multitech needs to employ to prevent this from happening during SAM-BA flashing.

Thank You,

Jeff

[Jeff Hatch]

Hello William,

That is interesting. Does it come back after a while when the LoRa node is being used? The last time I looked into this, the libmqtt seemed to be causing the “reconnects”. I have seen the same behavior in C++ code doing MQTT with libmqtt in the past.

Jeff

[Jeff Hatch]

Ernesto,

Are you using a custom configuration or are you using the configuration generated by configuring the VPN through the UI? If you are using the UI, and have mPower 5.2.1 on the device, there is a feature to specify the tunnel the rule is intended for in the Firewall Web UI.

Jeff

[Jeff Hatch]

Ernesto,

I recommend that you create a Multitech Support Portal case at https://support.multitech.com where they can help you figure this out.

Jeff

[Jeff Hatch]

Ajay,

I’ll see what’s going on. I may spend some time on it myself, but I am swamped at the moment.

Jeff

[Jeff Hatch]

William,

Wait! The above is for SD card. Sorry about my misunderstanding your question. There are AT commands that are available to detect the SIM. One way to do it on an mPower is to use the radio-query utility:

root@mtcap:/home/admin# radio-query –sim-status
{
“isSimInserted” : false
}

It returns whether the SIM is inserted/detected. This is an abstracted higher level implementation that works for all the radios supported by mPower software. To do this for a Quectel or Telit radio specifically implemented on your own it is different.

For Quectel you would use the “AT+QSIMSTAT?” command and parse its output.

For Telit you would use the “AT#SIMDET?” command and parse its output.

Jeff

• This reply was modified 3 years, 10 months ago by Jeff Hatch.

[Jeff Hatch]

Hello Wiliam,

Here’s some C++ example code that detects the card on the current mPower devices:

const char * const MEDIACARDDIRMLINUX3 = "/media/card";
const char * const MEDIACARDDIRMLINUX4 = "/run/media/mmcblk0p1";
const char * const PROCMOUNTS = "/proc/mounts";

bool isSDCardInserted()
{
    std::ifstream procMounts(PROCMOUNTS);
    std::string line;

    if (!procMounts.good())
    {
        return false;
    }

    while(!procMounts.eof())
    {
        line.clear();
        std::getline(procMounts, line);
        //std::cout << line << std::endl;

        std::size_t found = line.find(MEDIACARDDIRMLINUX3);
        std::size_t found4 = line.find(MEDIACARDDIRMLINUX4);
        if ((found != std::string::npos) || (found4 != std::string::npos))
        {
            return true;
        }
    }

    return false;
}

It’s really just using /proc/mounts and looking for the right string for the media card mount. Probably could be done in a shell script in the same amount of code or less.

Jeff

[Jeff Hatch]

Ajay,

Does your Install script install any dependencies such as IPK’s in the provisioning directory of the tar archive? I wonder if the application gets untar’ed in the correct place and everything, but execution of something by the Install script in the tmpfs is causing app-manager to hang. Either that or something in the untar process is causing a hang.

Have you created a Support Portal request? While it will be beneficial to identify the root cause here, it will be better to do the debugging via a portal case. There you could share more about what the application install process is doing.

Jeff

[Jeff Hatch]

Ajay,

One pertinent question: Are you trying to execute anything from the tmpfs (ie. /tmp /var/volatile/tmp). A security change was made in 5.2.1 to prohibit execution from tmpfs due to a number of our large customers identifying it as a risk on their security analysis tools.

Jeff

[Jeff Hatch]

Ajay,

What does the APPMANAGER logging in /var/log/messages say at the point where it hangs? Is it possible that there are two instances of app-manager running that are not doing a status? The APPMANAGER does log quite a bit of information.

Jeff

[Jeff Hatch]

Claudia,

It looks like it is getting to u-boot and then failing to load the kernel. Not sure exactly what happened.

You should be able to drop into u-boot. The most straight forward way to do that is to “power the device” by pulling power, and after reconnecting power, in the terminal hit any key fast enough so that it drops directly into u-boot and doesn’t try to load the kernel. At that point run a print command and let me know what the u-boot environment is.

From there it would be a matter of setting up a TFTP server and I can get you some scripts to run in u-boot to set up the u-boot env to do TFTP. From there you will be able to flash the kernel.

Jeff

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

[Jeff Hatch]

Hello Claudia,

Can you hook up a debug cable to the port behind the “Multitech” cover on the front of the device? The output of that port will tell how far the boot is getting, ie. ROMBOOT, u-boot, Linux. I believe the cable required is a USB Micro-B.

Jeff

[Jeff Hatch]

Claudia,

Try holding in the reset button for more than 30s. That should factor default the device unless the boot has not fully completed. There is a possibility that a boot script is failing before the process that monitors for the factory reset.

Jeff

[Jeff Hatch]

William,

For some documentation out of development on this and the general changes to the API for the latest release open a Support Portal ticket, and request this info. Ask for the case to be assigned to Jeff Hatch, and I can get you the information.

In general, I don’t get assigned support cases because I am in engineering, but until the docs get the additional information on Save & Apply added, I can supply the documentation from development to assist.

Jeff

[Jeff Hatch]

Hello William,

Here is a response from one of the API developers:

1. But I did not see a corresponding save_apply in the updated API (mPower Release 5.2 – API Delta).
I checked it just now and looks like it was not documented in the API Delta file for some reason. Please two document attached for all Save and Apply related stuff.

2. Is the save API command the same as *SAVE and APPLY*?
No, it is no the same. The behavior of the Save command is left unchanged comparing to the previous versions. It allows to save the settings without applying them.

3. Please verify my assumption: when I click on submit, it changes the configuration, but that change would not survive a restart. Only *SAVE and APPLY* or *SAVE and RESTART* preserves the config change across restarts?
Yes, it is correct.

4. When *SAVE and APPLY* or *SAVE and RESTART* is highlighted, is there a way to find out which configuration items have been changed?
Unfortunately, this information can’t be fetched on a user request in mPower 5.2.

For #4 I can put in a feature enhancement request.

Also, here is some additional information from another thread I had with the developer:

[JEFF] 1. Is there still a Save & Restart in the API?
[SERHII] Yes, it’s still available and is actually recommended for some cases. Please see the document attached (same as in the other email thread).

[JEFF] 2. As the customer asks, does the Save do a Save & Apply, or just save the database changes?
[SERHII] It just saves the database changes.

[JEFF] 3. For Save & Apply, if the operation would require a reboot, what kind of response does the client get?
[SERHII] In general – this is the response.

HTTP/1.1 409 Conflict
{
“code”: 409,
“error”: “Reboot is needed to apply the changes”,
“status”: “fail”
}

Thank You,

Jeff

[Jeff Hatch]

William,

The link button didn’t work:

https://support.multitech.com/support/dashboard.html

Jeff

[Jeff Hatch]

William,

Is this an intermittent issue, or do you see it for a specific device, or multiple devices? If it is reproducible with a specific device, for example, it might be good to create a case in the Multitech Support Portal -> . There are some guys who work with Device HQ that might be able to figure out what is causing this.

Jeff

[Jeff Hatch]

Amaud,

The following info should help in doing commissioning through the API.

// Execute this command to check that the device is in the commissioning mode

andrey@andrey-HP-ProBook-640-G1:~/Downloads$ curl -k "https://192.168.2.1/api/commissioning"
{
   "code" : 200,
   "status" : "success"
}

// Execute this command to set the username. In the example the username is "admin"

andrey@andrey-HP-ProBook-640-G1:~/Downloads$ curl -k -X POST -H "Content-Type: json/application" -d '{"username":"admin", "aasID": "", "aasAnswer":""}' https://192.168.2.1:443/api/commissioning
{
   "code" : 200,
   "result" : {
      "aasDone" : false,
      "aasID" : "5EC7E7C8FE2A6E3584D2A124A10E9",
      "aasMsg" : "New password: ",
      "aasType" : "question; input hide"
   },
   "status" : "success"
}

// Execute this command to set the password. Use the aasID value that is received in the previous response.

andrey@andrey-HP-ProBook-640-G1:~/Downloads$ curl -k -X POST -H "Content-Type: json/application" -d '{"username":"admin", "aasID": "5EC7E7C8FE2A6E3584D2A124A10E9", "aasAnswer":"Admin123"}' https://192.168.2.1:443/api/commissioning
{
   "code" : 200,
   "result" : {
      "aasDone" : false,
      "aasID" : "5EC7E7C8FE2A6E3584D2A124A10E9",
      "aasMsg" : "Retype new password: ",
      "aasType" : "question; input hide"
   },
   "status" : "success"
}

// Execute this command to confirm the password. If you get a response to the command "Change password success!", it means that the commissioning mode has been completed successfully.

andrey@andrey-HP-ProBook-640-G1:~/Downloads$ curl -k -X POST -H "Content-Type: json/application" -d '{"username":"admin", "aasID": "5EC7E7C8FE2A6E3584D2A124A10E9", "aasAnswer":"Admin123"}' https://192.168.2.1:443/api/commissioning
{
   "code" : 200,
   "result" : {
      "aasDone" : true,
      "aasID" : "5EC7E7C8FE2A6E3584D2A124A10E9",
      "aasMsg" : "Change password success!",
      "aasType" : "info"
   },
   "status" : "success"
}

*****************************************************************************************************************************************************************

Jeff

[Jeff Hatch]

Amaud,

In api/system there is a firmware field that contains the firmware version and a productId field that contains the type of device.

Jeff

[Jeff Hatch]

Hello Ajay,

Does it give the same error if you change it to a POST instead of a GET?

Jeff

[Jeff Hatch]

Hello Satoshi,

By default curl does a GET. I believe that the commands are required to be a POST (ie. -X POST). Try a POST and see if that works.

Jeff

[Jeff Hatch]

Hello Ajay,

Here is another curl version I have used in a bash script in the past.

curl -s -k -X POST “${ADDRESS}/api/login” -d “username=${LOGIN}” -d “password=${PASSWORD}”

The curl utility usually defaults to a GET unless so this one explicitly does a POST. Also, the -d options are the same as Jason’s, just there are two data parts. I’m not sure that specifying the creds on the URL is supported anymore.

Jeff

[Jeff Hatch]

Hello Ajay,

The API ppp_start and ppp_stop commands restart ppp only (or WWAN if that is being used). It does not reset the radio.

As you observed with the radio reboot feature there is the warning. That warning is because that feature attempts to use the back-off timers, and the fact that the algorithm is rather complex, ie. complex enough that it is very, very difficult to be sure that all possible combinations are tested. With that feature we cannot guarantee that it will NOT introduce behavior such as attempting to reconnect or re-register (due to resetting the radio) too frequently and get the radio blacklisted.

The back-off timers are used for the ppp connection in the ICMP-TCP keep-alive feature because some providers have required that behavior, and there is still a potential that the radio could be blacklisted with those providers if we do not follow the timers (for simply trying to reconnect too frequently). However, with the networks the way they are now with LTE, I am not sure that the back-off timers are required anymore.

What all this means is that you might want to talk with your provider to make sure that you will not have problems if you try to reconnect too often. Clear as mud? Welcome to my world:)

Thank You,

Jeff

[Jeff Hatch]

Hello Ajay,

Have you used the Expect header previously with the API. I don’t think that the server on Conduit is set up to handle Expect.

Jeff

[Jeff Hatch]

Hello Ajay,

The ppp_stop command will stop pppd and leave it that way. Same for ppp_start, starts pppd. These two commands run “/etc/init.d/ppp stop|start”.

The ppp toggle is kind of weird in that I do not know exactly what it’s use is, but all it does is check if pppd is running, and if it is it will stop it. If pppd is not running, it will start it. From an external viewpoint if I were using the API I don’t know when I would use it because as with any normal programming I would always want things to be as deterministic as possible (am I starting it or stopping it?). Just my two cents.

Jeff

[Author]

Posts