[Jeff Hatch]

Chris,

If you access the USB Debug Console port on the front of the device (behind the Multitech plate), you could try to interrupt the boot and put the device in the boot-loader (u-boot). Once it is in that mode, if the Ethernet port seems to be behaving normally, then there is something going on at the Linux level. If the port is dead in u-boot, then it is most likely broken.

Jeff

[Jeff Hatch]

Chris,

Just one thing to start: Have you tried unplugging the power to the device and plugging it back in? If that doesn’t clear it up, have you installed any init scripts that may be messing up the boot. If the answer is ‘no’ to both of these, you may have a bad Ethernet port.

Jeff

[Jeff Hatch]

Damon,

Is DNS working on the Conduit? If you SSH into the device and do a “nslookup http://www.devicehq.com” does it resolve to an IP address.

Jeff

[Jeff Hatch]

Christos,

The “Dial-on-Demand” feature in the Cellular configuration may help you in this regard. If the traffic is not outgoing, the Cellular connection should remain down. Do you have “ICMP/TCP Check” enabled on the Cellular interface. That would cause traffic on your Cellular interface.

Jeff

[Jeff Hatch]

Hello Denis,

Currently, on the AEP Conduit you can use the following example:

This curl example can be used externally to do a login:

curl -ik -c cookies -X POST -H ‘Content-Type: application/json’ -d ‘{“username”:”admin”,”password”:”admin”}’ https://192.168.2.2/api/login

Get the token from the response:

HTTP/1.1 200 OK
Set-Cookie: token=F2A41FB275BF23F5AB382373DB7B20A4; Max-Age=300; Path=/; Secure
Cache-Control: no-cache
Content-type: application/json
Transfer-Encoding: chunked
Date: Wed, 22 Feb 2017 09:36:42 GMT
Server: rcell

{
“code” : 200,
“result” : {
“address” : “192.168.2.200”,
“permission” : “admin”,
“port” : “45170”,
“timestamp” : “9:36:42:216”,
“token” : “F2A41FB275BF23F5AB382373DB7B20A4”,
“user” : “admin”
},
“status” : “success”
}

Then use the token in the curl POST request to send an SMS:

curl -k -X POST -H “Content-Type:application/json” -d ‘{“recipients” : [“1234567890”], “message” : “This is a test of sms_send” }’ https://192.168.2.2/api/sms/outbox?token=F2A41FB275BF23F5AB382373DB7B20A4
{
“code” : 200,
“status” : “success”
}

In the future this is going to change due to multiple user support and API changes that are being made.

Jeff

[Jeff Hatch]

Lawrence,

As far as I know, the mode on Conduit is always FAILOVER. I don’t think that CONSTANT is an option anywhere that is configurable.

If Ethernet is not enabled as WAN, ie. on the Network Interfaces Configuration, eth0 is configured as LAN for the Direction setting, it should not be able to fail over to Ethernet. If this is the configuration you have, then I am not sure what is “hanging” your Ethernet connection other than possibly the routing tables are being rewritten. Is the Cellular interface a higher priority than WAN Ethernet? If that is the case, then it will definitely try to find a Cellular interface, however, I am not sure that the wan manager code actually tries to fail over if ppp0 doesn’t exist.

Jeff

[Jeff Hatch]

Caroline,

To get this global setting to persist through reboot you should add the export command to the /etc/environment file. Running this command at the command line will only make it available for the currently running shell session.

Hope that helps,

Jeff

[Jeff Hatch]

Hello Stelios,

Please open a Multitech Support Portal ticket for help with this at https://support.multitech.com.

Thank You,

Jeff

[Jeff Hatch]

Stelios,

Try the following to change the password:

curl -ik -c cookies -X POST -H ‘Content-Type: application/json’ -d ‘{“username”:”admin”,”password”:”“}’ https:///api/login

Get the Token.

curl -ik -c cookies -X PUT -H ‘Content-Type: application/json’ -d ‘{“name” : “admin”, “password” : ““, “newPassword” : ““}’ https:///api/users&token=

curl -ik -c cookies -X POST -H ‘Content-Type: application/json’ -d ‘{}’ https:///api/command/save_restart&

When you make changes, make sure to do a save and restart.

Jeff

[Jeff Hatch]

Hello William,

The explanation for why the changes to those file get undone is: On AEP Conduit, the API code starts up on boot and rewrites the passwd and shadow files so that the users in the database are present. This is legacy from our MTR product (which no longer behaves that way anymore), and is currently being addressed in development. There will be multiple user support (same as MTR) and no rewrites of those files in the future. In addition, I think that sudo will work the way it does on other Linux variants. These updates will be released late Q1 next year or early Q2 (at least that’s what the schedule says).

Jeff

[Jeff Hatch]

William,

I figured out what is probably going on with the sudo command. I was able to successfully switch to the root user (prompt says “root@mtcdt:/run#” and whoami says root) after I did the following:

1) I moved the root user to the top of the /etc/passwd and /etc/shadow files.
2) executed “sudo -u root su” at the command line.

I think that even sudo is only going through the passwd and/or shadow files and looking for the first user with id=0. Other than the sudo command being updated I don’t know what else is influencing this change in behavior with the root user vs. any other user with id=0.

Jeff

[Jeff Hatch]

William,

That software must be doing a “whoami” and looking for root instead of doing an “id -u $USER” or something like that. The uid of admin is the same as root on the AEP device: 0 (zero). The behavior of the “sudo su root” on the Conduit appears to be different than it is on systems like Ubuntu. I do not get an error when doing a “sudo su root” on AEP-1.6.2 with the changes made to the sudoers file, but “whoami” still says that I am “admin” and not “root”. If I have time today I will see if I can figure out why. It may have to do with the sudoers config file again.

Jeff

[Jeff Hatch]

Mauro,

There is a possibility that you have locked the SIM and need a PUK number to unlock it. Do you have access to the device to do AT commands to the modem?

Jeff

[Jeff Hatch]

Mark,

The same version of Node-RED and node-js runs on AEP-1.6.2. The Conduit is locked at Node-RED 0.15.03 and node-js at 0.10.x due to hardware limitations (the ARM processor is armV5 architecture and does not support the newer versions of node-js and Node-RED). If you have developed applications on AEP-1.4.x in Node-RED, they should work on AEP-1.6.2.

Jeff

[Jeff Hatch]

Mark,

There is a new version of AEP called AEP-1.6.2 that is based on mLinux 4. What version of mLinux are you targeting?

Jeff

[Jeff Hatch]

William,

Yes, this is a change you can make with visudo. You should be able to work around this limitation using visudo and adding the line from my previous comment.

Jeff

[Jeff Hatch]

William,

I added the following under the “User privilege specification” in /etc/sudoers:

admin ALL=(ALL) ALL

And then as admin user I was able to do a “sudo -s”.

Jeff

[Jeff Hatch]

William,

The sudo program did get updated in the Yocto update. Another interesting piece is that the “admin” user is not in the sudoers file, and I’m assuming not in the sudo group:

admin@mtcdt:~# sudo -s
admin is not in the sudoers file. This incident will be reported.

The sudo program didn’t go away, but something appears to have changed to prevent the admin user from successfully using sudo.

Jeff

[Jeff Hatch]

William,

Is your software checking for user ID 0 (zero) or is it actually checking the username? On AEP the admin user doesn’t have sudo privilege, however, it’s user ID is 0, the same as root.

Jeff

[Jeff Hatch]

Hello Bob,

On the Conduit, can you ping the host that you are trying to connect to with the http request node? Usually the ESRCH tends to indicate a problem with DNS or a proxy being used to forward DNS.

For the LoRa-IN node/MQTT messages this is most likely due to the upgrade of several packages (Mosquitto and libmqtt). I have seen this same kind of reconnect behavior in other (C++) code doing MQTT. Something in libmqtt seems to time out the MQTT connections or something. It appears to me that the “re-connects” don’t seem to be harming anything.

Jeff

[Jeff Hatch]

Chad,

It is possible. The SMS commands feature has been added in AEP 1.6.2.

Jeff

[Jeff Hatch]

Hello Christian,

If you create a Multitech Support Portal case at https://support.multitech.com they can help you with some of these customizations. In short:

wan-manager: is a process that is tightly integrated with WAN failover on the device and also with management of DNS and other WAN related things. I don’t know that you should touch that one.

led_cd_ss is a script that is managing the LEDs on the device (at least some of them including the signal strength and carrier detect. If you are not using cellular, you might get away with disabling this one.

If you are not using Device HQ, and don’t plan to, then you can disable monitor-annexcd by disabling remote management.

mgsgps: this daemon is used to get GPS data from the u-blox chip on the device. If you do not care whether GPS data is sent to Device HQ or displayed in the Web UI, then you can turn that one off.

Jeff

[Jeff Hatch]

Mark,

You are on the right path. If you are adding nodes or node-js modules that need “cross-compilation” in order to install and work on Conduit, then you should be able to build the nodes or modules with the mLinux distribution or the SDK.

Jeff

[Jeff Hatch]

Noman,

Are you using hostnames to ping out to the Internet or IPs?

Jeff

[Jeff Hatch]

Noman,

Can you ping the gateway (192.168.200.1) from the Conduit? What does the output of the “ifconfig -a” command show?

Jeff

[Jeff Hatch]

Christiian,

When you look for the traffic, is it on the external (Internet) side of the firewall? If so, Multitech can take a look on Device HQ and see if there is any reason that the device(s) cannot establish a check-in session. If nothing is coming back from Device HQ on the Internet side, please file a Multitech Support Portal case at https://support.multitech.com and someone can help you.

Thanks,

Jeff

[Jeff Hatch]

Herb,

To get help with this file a support portal case at https://support.multitech.com.

Jeff

[Jeff Hatch]

Stelios,

Try doing “/etc/init.d/mts-gps stop” before starting gpsd. If that fixes the problem, then the mts-gps daemon needs to be disabled before gpsd will start.

Jeff

[Jeff Hatch]

William,

In the GPS configuration have you made sure to check both the GGA and GLL settings? These are required.

Jeff

[Jeff Hatch]

Nick,

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

Jeff

[Author]

Posts