[Jeff Hatch]

Jose,

First, looking at your example, ping uses icmp and not HTTP. Is the proxy set up to pass ICMP traffic? Does the ping command even accept a URL? “http://www.google.com is not a valid hostname.

Are you using curl or wget? As long as the firewall rules permit outbound traffic on HTTP or HTTPS on the Ethernet interface you should be able to use curl in the same manner as this example:

https://www.cyberciti.biz/faq/linux-unix-curl-command-with-proxy-username-password-http-options/

If you are trying to pass non-HTTP(S) traffic, is the proxy also configured as a router? The default gateway implies that is the router. Is it the same device as your proxy?

Jeff

[Jeff Hatch]

Hello Jose,

To set the eth0 IP and netmask on AEP you should use the Web UI and configure the interface in Setup->Network Interfaces. You should also configure eth0 as a WAN, static IP, and configure the default route and DNS.

Jeff

[Jeff Hatch]

The device that has a gateway has to be getting the gateway from DHCP if that is how the eth0 is configured, so that appears to be working. The non-working device has something strange: It has a br0 (bridge) interface with localhost set for it’s address.

Check on the br0 configuration on the non-working device. If it is explicitly set to localhost for it’s info try clearing that out. I am not sure that is causing any issues, but it is odd.

It may be possible that with the bridge configured it is somehow messing with the routing. Make sure that eth0 is not configured “under the bridge”. I’ve had the bridge configured with nothing assigned to it in the past and things worked find, but not with the localhost address.

Jeff

[Jeff Hatch]

Does the device that is working have a default route? On the device with issues, is ppp/Cellular enabled? If Cellular is enabled, but it is not getting a connection and not getting an IP, default route, and DNS servers, that might be part of the problem. pppd is what tells the kernel to create the ppp0 interface and configures that interface with the IP and gateway from the provider.

If ppp/Cellular is not enabled, can you provide the “route -n” on both devices along with “ifconfig -a”? There may be more configuration information needed to get to the bottom of this.

Jeff

[Jeff Hatch]

some_dev,

Your device appears to have obtained an IP, but not a gateway from DHCP. It is possible that there is a bug and the default gateway is not getting set, but if it is getting set on the other device I am not so sure about that.

Has the Ethernet eth0 interface been configured as a LAN or WAN on the device that is not getting a default route?

For the device that is working, what additional interfaces does it have and how are they configured?

Jeff

[Jeff Hatch]

Denis,

A LAN (Local Area Network) connection refers to a network with implications that there is no Internet access. A WAN (Wide Area Network) connection refers to a network that generally has Internet access.

On your Conduit you will want your devices to connect to the Ethernet LAN and use a different interface (WiFi, Cellular, …) as the backhaul connected to the Internet. A WAN interface is the interface that typically has the default gateway configured.

The Conduit has the ConnTrak and routing modules to accept traffic and send it out on the Internet. With the use of static routes and firewall rules routing from the LAN to the WAN and onto the Internet can be restricted and controlled.

Jeff

[Jeff Hatch]

Denis,

I would recommend using Ethernet as a LAN. What do you plan on using as your Internet backhaul?

Jeff

[Jeff Hatch]

aa,

If you go into the Web UI and go to the Apps page under Node-RED Apps: if the “Enabled” box is checked, Node-RED will start on boot.

Jeff

[Jeff Hatch]

Lawrence,

I don’t have any ideas other than at the URL below we have a “stock” Node-RED image for Conduit:

http://multitech.net/downloads/node-red-0.15.3.tgz

If you cannot access this download I can upload it to the Multitech Support Portal.

You can untar this image in the /opt directory. It will overwrite what you currently have there, so back up /opt/node-red if you feel the need to.

Jeff

[Jeff Hatch]

Tamas,

This is fixed in the latest firmware (AEP 1.7.2). I did not dig to see whether it is fixed in AEP-1.6.x.

Jeff

[Jeff Hatch]

Actually, according to certifications and certain industry standards, having it encrypted inside SSL is not enough. Also, this API has a dual purpose that supports a Web UI with authorizations that determine what the user can see and what they can do. The token-based approach that is being used in this API is the same as is used across industries.

Ideally, user credentials (username/password) should never be passed across when accessing a device. Authentication should be handled with protocols like kerberos with active directory or LDAP in Unix. If the password is hashed, it might be acceptable to some of the new standards.

That said, from what you have said, you will not like where security requirements for these types of devices are headed. Ease of use of APIs is going to start getting to be more painful.

[Jeff Hatch]

Bad enough that credentials are passed between client and server once. Every time is a bit much.

[Jeff Hatch]

Steve,

I see the item you are talking about and have asked the authors of the release notes about it.

As for your definition of how REST should work, I will respectfully disagree with you. I have worked with REST APIs on several Enterprise products including a firewall and a Storage Area Network controller. Due to security and other things, any changes to the device configuration must be recorded as being done by some user on the device (or in Active Dircectory or an LDAP database). There must be at least some AUTHN and accounting via some sort of session to accomplish this. The “logging out” is a limitation of this particular API (one must log out in order to log in from a different computer). Other APIs that I have worked on for devices similar to this one behave in much the same way.

The “tying” of a user to a network address is antiquated. It is an attempt to prevent man-in-the-middle if nothing else.

There is no development work being done to address these that I know of. The best place to be making enhancement requests would be at https://support.multitech.com where they can take your requests and forward them on to engineering.

Jeff

[Jeff Hatch]

SL,

The mLinux-only version of Conduit does not have a Web UI. The default administrative user on a mlinux-only Conduit is mtadm instead of admin.

I have not seen the Permission Denied when trying to access the /var/volatile partition with mtadm. What are the permissions on the flash-upgrade directory?

Jeff

[Jeff Hatch]

Steve,

Please open a portal case at https://support.multitech.com. They can help you with this. Usually these types of errors are on the provider or MVNO side. One thing to verify with the Multitech Support people is that the correct version of the firmware is on the modems.

Jeff

[Jeff Hatch]

William,

It now seems that it is having difficulty registering and appears to be still trying. The RSSI appears to be fine (+CSQ: 23,99). The dial out won’t work until there is a successful registration. I recommend that you open a support portal case with Multitech. They have a better handle on the different issues that might be happening that could cause registration problems.

Jeff

[Jeff Hatch]

John,

There are plans and new hardware in the works for a new generation of Conduits. Among other things, support for Dockers is planned. I cannot give any time frame. The current hardware is really not spec’ed to support Dockers.

Jeff

[Jeff Hatch]

Jot,

Did you change an init script or something? The factory reset only reverts the configuration to factory settings. It does not reset any changes to the init scripts or executable binaries. You may need to re-flash the device from tftp:

Flashing mLinux Firmware

Jeff

[Jeff Hatch]

William,

First thing to do is to make sure that the IMEI is valid with AT&T. This should have been taken care of in Production, but every once in a while something gets messed up on one end or the other. I found a site that can verify that the IMEI is compatible with AT&T here:

https://www.att.com/shop/wireless/imeivalidation.html

If the device is compatible, then check the registration in the Radio Terminal on the Debug Options UI page:

AT+CREG? -> the response should be “+CREG: 0,1” if the radio is registered. If it is “+CREG: 0,0” there is something wrong with the registration with that radio/SIM combination.

If the radio is registered, and you are still seeing the SIGHUP, that means that something is most likely terminating the connection from the provider side. For more help you will need to talk with Multitech support at https://support.multitech.com where they will be able to give you more support.

Jeff

[Jeff Hatch]

William,

The logging right after that last send is probably what we need to see. There should be something coming out of ppp. The following is what I have on a device that is successfully connecting with an AT&T SIM:

2019-02-06T10:59:39.507415-06:00 mtcdt pppd[6389]: Script chat -v -c -t 90 -f /var/run/config/ppp_chat f
2019-02-06T10:59:39.507718-06:00 mtcdt pppd[6389]: Serial connection established.
2019-02-06T10:59:39.541663-06:00 mtcdt pppd[6389]: using channel 1
2019-02-06T10:59:39.549870-06:00 mtcdt pppd[6389]: Using interface ppp0
2019-02-06T10:59:39.552644-06:00 mtcdt pppd[6389]: Connect: ppp0 <--> /dev/modem_at0
2019-02-06T10:59:40.529326-06:00 mtcdt pppd[6389]: rcvd [LCP ConfReq id=0x1 ]
2019-02-06T10:59:40.557541-06:00 mtcdt pppd[6389]: rcvd [LCP ConfAck id=0x1 ]
2019-02-06T10:59:40.582318-06:00 mtcdt pppd[6389]: rcvd [IPCP ConfRej id=0x1 ]
2019-02-06T10:59:40.582668-06:00 mtcdt pppd[6389]: sent [IPCP ConfReq id=0x2

[Jeff Hatch]

William,

Have you looked in /var/log/messages to see what the output is from the “chat” script? In the log you should see the execution of the chat script and if it is failing it may give us enough info to see why the connection is not working. If ppp is connecting, but no IP and no DNS are getting acquired, then there are some other things to check.

Jeff

[Jeff Hatch]

William,

With Cellular enabled, does your device have an IP address and a DNS server? The way to tell is to go the the “Home” page in the Web UI, and in the WAN pane on that page you should see the State and it should say “PPP Link is up”. Below that you should see an IP address and for DNS there should also be another IP.

If the WAN has a ppp connection and has both an IP and a DNS IP, and the DNS nslookup is still failing, check the WAN configuration under Setup and make sure that the Cellular WAN is at the top (Priority 1).

Also, are there any other WANs configured besides Cellular?

Jeff

[Jeff Hatch]

Bob,

The watchdog process is not documented. If you add the -node-red argument I don’t think it will provide what you need. If the node-red process is just hung and hasn’t actually disappeared this watchdog will not restart it.

BTW, there is a simple process called angel (a link to it called node-angel is used for node-red) is used to restart the node-red process when it terminates. As you have noted, I think something else is going on and the node-red process is getting into some kind of “hung” state.

A couple of things to look at when node-red gets in this state:

1) How much memory is it using: “ps auxww | grep node-angel” output should be able to tell you this.
2) Run top and see if it is consuming lots of CPU.

Are you using SSL in node-red, and therefore in node. I have seen node use a lot of memory when doing SSL for some reason, ie. ~150MB

Jeff

[Jeff Hatch]

Lawrence,

Turn of Remote Management under the Administration page. Try rebooting again, and see if the 3MB of data happens. I think that there might be app data being sent up to Device HQ when the configuration is sent.

Jeff

[Jeff Hatch]

Jostein,

Python 3 can be installed from the feeds. Python and a large number of modules are available for mLinux 4.0.1 at:

http://www.multitech.net/mlinux/feeds/4.0.1/arm926ejste/

Jeff

[Jeff Hatch]

Christos,

Please file a support portal case at https://support.multitech.com. They will be able to help you.

Thank You,

Jeff

[Jeff Hatch]

William,

Could you file a support portal case at https://support.multitech.com on this? There’s been some issues with the connectors to the board for the gps antennas among other things. Also, they may be able to give some additional advice on what environmental factors to rule out.

Thanks,

Jeff

[Jeff Hatch]

Hello Christos,

For help with this you could open a support portal case at https://support.multitech.com. They can provide better support than the forums.

Jeff

[Jeff Hatch]

Hello William,

Is there anything related to the GPS fix/lock in the /var/log/messages on the device that has the failure?

Jeff

[Jeff Hatch]

Damon,

The Conduit will only “check in” to Device HQ at regularly configured intervals. In the mean time it does not maintain an open connection to Device HQ (thus the “idle” status).

If you’re watching the status when it checks in on the configured interval, you should see it connect, check in, and then go back to idle.

Jeff

[Author]

Posts