[Jeff Hatch]

Alvin,

>> Are the above observations correct?
What you have said is correct. It must be noted that Node-RED is not the only supported application platform. It is also possible to create custom applications following the instructions at http://www.multitech.net/developer/software/aep/creating-a-custom-application/. Custom applications can be installed through Device HQ or locally.

>> Further questions would be, what sort of customizations are possible with AEP (C, C++, Python, bash, Nodejs…?
Support on AEP for C/C++, Python, bash, node-js is correct. C/C++ applications have to be cross-compiled for the Conduit architecture. There is also the option to install Java or Mono on the device.

>> If I get the mLinux version, is it possible to “install” AEP features to it or even convert to?
If you buy the mLinux version, you can install the AEP firmware. Currently a full firmware install is necessary to “convert”.

Jeff

[Jeff Hatch]

Stelios,

One significant difference is the remote management feature on AEP. The mLinux Conduits cannot be managed from Device HQ. This is important for remote management of applications and configurations of devices. One other significant difference is is the Cellular connection monitoring. AEP has a number of feature for monitoring and maintaining a PPP connection already built-in whereas on mLinux the customer has to do it.

AEP also has significant support for configuring LoRa functionality through the Web UI. This is a major convenience over doing it one’s self.

Jeff

[Jeff Hatch]

Christian,

As Steve said, there is not a guaranteed IP or IP range that will allow Device HQ traffic from the MTR or Conduit. However, the hostname is devicehq.com. Depending on the sophistication of the firewall product, rules may be possible that specify the hostname or domain.

Jeff

[Jeff Hatch]

If you create a Multitech Support Portal Case at https://support.multitech.com they have a procedure for converting to AEP.

• This reply was modified 6 years, 9 months ago by Jeff Hatch.
• This reply was modified 6 years, 9 months ago by Jeff Hatch.

[Jeff Hatch]

William,

It is possible to change the interval by hand in the /var/config/db.json. However, when the device checks in to Device HQ, the Device HQ server will revert it back to a minimum of 4hrs unless things are changed there. We will look into enhancing this feature in the near future.

Jeff

[Jeff Hatch]

Hello,

At this time I am doubtful that Dockers would work on the Conduit. I have not seen much support for it on the armv5 architecture. Newer generations of Conduit, however, will probably support Dockers.

Jeff

[Jeff Hatch]

William,

Do you have access to the device? It would be good to determine what is causing this “hang”. If you can, it would be good to do a top, free, and ps auxww on the device and get the output of those three commands. We could at least tell how much memory there is, what is eating the CPU (if anything), and what the status of the annexcd process is.

Jeff

[Jeff Hatch]

Stelios,

The AEP 1.6 based on the Morty version of Yocto is being tested and is scheduled to be released next month. That version of AEP has Python 2.7.12 and should solve your problems with TLS.

Jeff

[Jeff Hatch]

Stelios,

You can probably use the recipes you mention, but you will most likely have to update/upgrade the version of bitbake that you use to build it with the version of mLinux you are using.

Jeff

[Jeff Hatch]

Bob,

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

I am not sure what is going on, but a person that can dedicate more time to reproducing and tracking down this issue will be assigned to the case.

Sorry we couldn’t get this resolved in the forum.

Jeff

[Jeff Hatch]

Bob,

It may be that the GPS interval is not in sync with the regular check-in interval. That can happen with the way the intervals are designed and would explain the separate check-ins.

It looks like the GPS is having trouble keeping a lock/fix. The only thing I can think of right now is that the interval that there isn’t a fix is large enough that annex client is not getting coordinates from mtsgps.

The annex client connects to mtsgps over a socket and does not read the gps_dump. The gps_dump file is used by other things including the Web API. What that means is that I think that annex client has a “more real-time” access to the current GNSS data from the ublox chip. Unfortunately it seems to be querying the chip when the lock/fix has been lost.

I’m not ruling out another issue, but with the devices I have, once I see a lock, the GPS coordinates get sent to Device HQ.

All that said, have you tried putting the conduit somewhere where the GPS reception would be better?

Jeff

[Jeff Hatch]

Bob,

I am going to file an enhancement request. I don’t think that this functionality is working the way it is supposed to. Let me know if what’s been done so far fixes your issue.

Jeff

[Jeff Hatch]

Bob,

Is the GPS server or client enabled in your GPS configuration? If not, try enabling one of those. If that works, then I think I know what may be happening. If that does not work try sending a SIGHUP to the mtsgps process.

The mtsgps process creates the /var/run/gps_dump file, however it has to get a SIGHUP to do that. Without the server or client enabled in GPS, I don’t think that mtsgps ever gets HUP’ed. This would be an enhancement that needs to be made so that it is not required to enable the GPS server/client programs for streaming data just to get the GPS data sent up to Device HQ.

Jeff

[Jeff Hatch]

Jon,

The most straight forward way I can think of is to write a script to add to the init scripts that creates and saves the rules. However, this script would not persist through a firmware upgrade.

Another possibility that would persist through a firmware upgrade would be to create a simple custom application. The application would just be a simple shell script that created and saved the ipfilter rules. See our instructions on creating a custom application here:

Creating a Custom Application

Once your custom application is working you can upload it to Device HQ and download it remotely from there to your device(s).

Jeff

[Jeff Hatch]

Bob,

In /var/log/messages on the device there will be messages from annexcd. That is the daemon that is responsible for sending up GPS data. Also, verify that the file /var/run/gps_dump. That is a file that is shared by different processes and contains the gps NMEA strings. If the strings are in the gps_dump file, then something may be going wrong with the annexcd process.

Jeff

[Jeff Hatch]

Colas,

Have you looked into the “Advanced Settings” where you can create DNAT (Pre-routing) and SNAT (Post-routing) rules. These are using simple NAT and not masquerade. I am not positive that it will work like MASQUERADE when the IP changes, but you could try that.

Jeff

[Jeff Hatch]

Bob,

Have you given the Conduit at least 12 hours to check in once it has a lock? Due to the way Device HQ behaves, it will not allow Conduit to send up GPS coordinates in any shorter than 4-8 hour intervals. The Conduit doesn’t get a GPS lock in time after reboot for it to send the coordinates up on check-in after boot. What that means is that you have to wait for it to send up coordinates on the next check-in after the one that happens at reboot.

When you tell it to check in through the Web UI, it will check in, however, it will not send up the GPS coordinates. I have verified that even though you can configure the GPS interval to an interval as small as 5 minutes, Device HQ responds on check-in and tells the Conduit that it has to increase the interval to something like four or eight hours.

Jeff

[Jeff Hatch]

Rob,

Could you open a case at https://support.multitech.com/ where you could upload the logs. I’d like to get a case going so that this can be investigated. Multitech can help you better that way, and it will get tracked internally.

Thanks,

Jeff

[Jeff Hatch]

Robert,

There is a race condition that gets exposed the longer it takes the radio and ppp to come up when Cell is the primary WAN. Verizon is one of the longest. I am not sure why you’re hitting it with Ethernet other than you also have a Cellular WAN. We do have a fix for this issue (restart dnsmasq when starting a new WAN). That fix should be in the next release of the 1.4.x AEP Conduit. I am not positive when exactly that will be, it should be within the next couple of months.

You should be able to set up Ethernet as your highest priority WAN in the Web UI under Setup->WAN. Make the Cellular the second highest priority. If the Ethernet connection fails, it will fail over to Cellular. It should fail back to Ethernet if that interface again regains Internet access.

Sometimes Verizon can be tricky to get working. All you should need to do is insert the SIM, enable Cellular under Cellular->Cellular Configuration, and restart the device. If that does not work, post the chat script logging from /var/log/messages. That along with whatever pppd is outputting should give us a clue.

Jeff

[Jeff Hatch]

Robert,

The server you found it pointing to is correct. The dnsmasq daemon is listening on 127.0.0.1. It is what is handling and forwarding all DNS requests. That is part of the WAN failover design.

As for your DNS not working: Could you perform a “/etc/init.d/dnsmasq restart” and see if DNS works after restarting the daemon. If that works, could you do me a favor and describe your network setup -> what interfaces are WAN, LAN, and what their configurations are? I am interested if you have more than one WAN configured and are using failover.

Thank You,

Jeff

[Jeff Hatch]

George,

I have gotten the following to work at some point:

curl -s -m 5 -X PUT -H ‘Content-Type: application/json’ -d ‘{“name” : “admin”, “password” : “admin”, “newPassword” : “admin123”}’ 127.0.0.1/api/users

Where your actually doing a put on the user collection instead with the existing user “admin” and the old password “admin” and the newPassoword specified.

Let me know if that helps.

Jeff

[Jeff Hatch]

Martin,

You’re welcome! Let us know if you have any more questions.

Cheers,

Jeff

[Jeff Hatch]

Martin,

To find out what version of mLinux your AEP is based off of, at the command line execute “cat /etc/issue” and you should see the mLinux version. From there you can check out the appropriate version of mLinux and build against that. I believe that AEP 1.4.16 is built against mLinux 3.3.22.

Jeff

[Jeff Hatch]

Luis,

The AEP firmware is proprietary, so you will not be able to build a custom image of that firmware. However, you can use the mLinux distro based off of Yocto found here: http://git.multitech.net/cgi-bin/cgit.cgi/mlinux.git/

Using mLinux you can add the flask and sqlalchemy pip packages to that, build the packages, and use the .ipk files (packages) that generates to install on your AEP.

You should use the version of mLinux that the AEP firmware you have installed is based off of. To figure that out via an ssh connection to the Conduit: “cat /etc/issue” will tell you what the mLinux version is.

[Jeff Hatch]

Yoshihiro,

Please file an Support Portal Case at https://support.multitech.com.

Thank You,

Jeff

[Jeff Hatch]

Antonio,

The AEP-1.4.16 has a number of fixes for the GPS/GNSS data. That version should fix your issue with GPS coordinates not showing up on Device HQ after a check-in. That is if the GNSS is able to get a lock. It may take a couple of check-ins since the initial check-in to Device HQ happens early enough that the GNSS chip generally does not have a lock yet.

Thank You,

[Jeff Hatch]

Aleksandr,

Please open a support portal case at https://support.multitech.com and they can help you.

Jeff

[Jeff Hatch]

Benjamin,

Please open a portal case at https://support.multitech.com where they can help you.

Jeff

[Jeff Hatch]

Please file a Multitech Support Portal case at https://support.multitech.com. They will be able to help you at a more in-depth level. Have you tried using wireshark or tcpdump to verify that connectivity with duckdns is working?

Jeff

[Jeff Hatch]

I took a couple minutes and looked up RC_DYNDNS_INVALID_RSP_FROM_IP_SERVER with Google. A large number of people that have run into this issue seem to have had connectivity issues to the DDNS server. Have you tried connecting with a browser to see if you get any kind of response?

Jeff

[Author]

Posts