[Jeff Hatch]

Lawrence,

I meant for the following link to be in the last message:

Downloads

Jeff

[Jeff Hatch]

Lawrence,

Thanks for the suggestion. For now, until we create a releases forum, you’ll have to just keep an eye on:

I’ll see what I can do to get that kind of forum set up.

Jeff

[Jeff Hatch]

Thanks guys for bringing this up. We are aware that npm got dropped out of the release. The recipes on openembedded changed so that npm got moved into it’s own package separate from nodejs somewhere around nodejs 0.10.38. We are planning on making some kind of hotfix or another quick release to get it back in. I am not sure exactly when this will happen, but it should be pretty soon.

Jeff

[Jeff Hatch]

Neil,

If you have a chance, take a look at the configured range of addresses that the DHCP server on the Conduit was set to give out. Maybe the 192.168.99.1 address was given out by that.

Jeff

[Jeff Hatch]

Neil,

Is the router also the DHCP server? If not, then I think that your hypothesis likely explains how the Conduit got the address it did. The only way that the Conduit obtains an address dynamically on the Ethernet interface is through the DHCP client (in this case most likely through the call home functionality for remote provisioning that is enabled by the firstTimeSetup flag). The Conduit must have gotten the 192.168.99.1 address via DHCP.

As for the firstTimeSetup behavior, I will see if I have time today to experiment with that scenario. What you’ve reported is not what I would expect.

Jeff

[Jeff Hatch]

This is a DNS error. What server(s) is your Conduit configured to use for DNS resolution? If it is your PC, you will need to be running either a DNS forwarder or server that is configured to use your Ethernet interface.

Also, is your Conduit configured to use your PC as it’s default gateway? If that is the case, then packets will be routed to the Ethernet interface on your PC, but your PC needs to be configured as a router in order to route the packets to the internet.

Depending on what resources you have available, it would probably be easier to put your Conduit on a network with a router and DNS server(s) and just configure it to point to the router for default gateway and the correct servers for DNS.

Jeff

[Jeff Hatch]

What is the IP on your PC’s Ethernet interface? Unless it is the same subnet, your PC will not know where to route to the 192.168.2.9 address.

[Jeff Hatch]

It is possible that the DHCP server that is enabled by default on the Conduit is causing this behavior by giving your PC a lease on an address. The DHCP client on your PC may then be configuring the Conduit as it’s default gateway. You can turn off the DHCP server in the Conduit Web UI at Setup->DHCP. Select the DHCP server on the ethernet interface for edit, and disable it. Perform a “Save and Restart”, and the DHCP server will be disabled. Hopefully that will prevent your PC from losing the WiFi as it’s internet access.

Jeff

[Jeff Hatch]

Andries,

If you are trying to install a node module, you need to use the –prefix option and specify where the node module needs to go. On the Conduit Node-RED is installed in /opt/node-red. If you need to install a node module the argument will look something like this: “–prefix /opt/node-red/node_modules”.

Nodes are a little trickier to install sometimes, but most of the newer and updated nodes can use the same prefix.

Jeff

[Jeff Hatch]

Michael and Neil,

When you manually change the firstTimeSetup you need to reset the device without saving and restarting from the Web UI or alternatively restart the Web server (lighttpd) before rebooting. The firstTimeSetup flag is being cached in the instance of the API on the Conduit, and may be a part of the “transient” behavior you are seeing. If you restart from the UI doing a “Save and Restart” your manual change will get overwritten with whatever was cached in the API.

Neil, what address did the Conduit assign itself? Part of what can cause confusion here is that the DHCP server and client are enabled by default when you first power up. If the Conduit got an address other than 192.168.2.1, it was not the Conduit that assigned the address to that interface. On the other hand, if it did not successfully get an address and it was still the default, you need to connect to the Conduit directly from a PC and assign a static IP before connecting your Conduit to another network. You need to be directly connected to the Conduit when you do this.

The whole reason for Conduit defaulting to 192.168.2.1 revolves around the idea that the Conduit is going to be a gateway device either for LoRa or Ethernet and us Cellular as a back haul. At least that was the original thinking behind the design. As Conduit gets used for different applications things like this behavior may “evolve” differently.

Jeff

[Jeff Hatch]

Hello,

Which model of Conduit do you have (AEP or mLinux)? If you have an AEP model, can you connect to Web UI on the Conduit from your PC? Do you have a SIM card for the radio on the Conduit?

Jeff

[Jeff Hatch]

Right now there is nothing official. We are hoping to develop some documentation going into detail on the API to the configuration database on the Conduit, but it is currently not being worked on.

Asking questions here is probably your best bet for now. The configuration database is in /var/config/db.json on the Conduit. Pretty much all of the data in that file can be accessed by making GET requests to 127.0.0.1/api and then following the pattern of the JSON object being retrieved in that file.

Jeff

[Jeff Hatch]

Chad,

There is a cli command that returns the uuid:

mts-io-sysfs show uuid

and the serial number:

mts-io-sysfs show device-id

On the other hand you can do a REST’ful GET request using the http request node for both these values from the configuration database locally:

admin@mtcdt:/sbin# curl -m 5 -s 127.0.0.1/api/system/uuid
{
“code” : 200,
“result” : “ABCDEF0123456789ABCDEF0123456789”,
“status” : “success”
}

admin@mtcdt:/sbin# curl -m 5 -s 127.0.0.1/api/system/deviceId
{
“code” : 200,
“result” : “18114615”,
“status” : “success”
}

Jeff

[Jeff Hatch]

Chad,

I don’t think it matters where you run the command if you specify the –prefix argument when you run it. That will put node or node module wherever you specify.

Jeff

[Jeff Hatch]

Joe,

The AEP and mLinux models are the same price (in the US anyway). As Jason mentioned it is much easier to move from AEP to mLinux (and even back to AEP) than in the other direction. Buy the AEP model and convert to mLinux if you need to.

Jeff

[Jeff Hatch]

Yogesh,

Open a support portal case. This sounds like you may need a replacement, and that is the way to initiate the process. Through the portal they will help you verify that the situation is not recoverable.

Jeff

[Jeff Hatch]

On the front of the Conduit there is a plate with MULTITECH and the logo next to it. There is a screw that you need to remove to get the plate off, and behind there is a micro-b usb port. The output of that port is the Linux console. You will need to hook that up to your computer and use a terminal program to connect to it and see what is coming out on the console when you reboot your Conduit.

We need to figure out how far in the boot process it is getting in order to figure out what is wrong with the device.

Jeff

[Jeff Hatch]

Is it just the status LED that is not lighting up or flashing? Is the power led lit? Also, if there is a SIM card inserted, are the signal leds lit? By “admin screen” do you mean the debug console on the USB port or the admin Web UI?

Jeff

[Jeff Hatch]

Roland,

Is the network interface you’re connecting to on the Conduit configured as a WAN or LAN? If it is configured as a WAN, you will need to go to the Administration->Access Configuration page and enable Node-RED access via WAN. Also, verify that Node-RED is running using the ‘ps’ command and verify that a listen on localhost port 1881 is currently posted. Another thing to look at is the /var/log/app/.log file (where is some UUID value) and see what Node-RED is logging there.

Jeff

[Jeff Hatch]

For instructions to flash from mLinux to AEP, please create a support case at our Support Portal ( https://support.multitech.com ).

[Jeff Hatch]

Nathan,

I assume that you’re pinging using the ping command at the command line. Do you have a SIM inserted and cellular configured with the correct APN? For the Ethernet connection: Which version of AEP are you using, and are you configuring your Ethernet interface as a WAN with a default route?

In order to reach the Internet through the Ethernet interface you will need to configure the Ethernet interface as WAN with a default route to a router that can route to the Internet. You will also need to configure WAN access to the UI and SSH in order to be able to access the GUI through the Ethernet interface once it is configured as a WAN. To do that you would go to Administration->Access Configuration in the UI and select “Via WAN” for both HTTPS and SSH access.

In the upcoming AEP 1.1 release the Initial Setup Wizard and Network Interfaces pages in the UI have been enhanced to make this process much easier.

Jeff Hatch

[Jeff Hatch]

Tom,

Great to hear! Which tftp server were you using (in case someone else runs into the same thing flashing their device).

Jeff

[Jeff Hatch]

Brian,

From what I can tell, (I’m not an expert in this area) I don’t think that pppd tries to run the run-parts utility. You will need to invoke it from somewhere like ip-up when you want to run your start script. Either that or if you’re just simply trying to start openvpn, you can call that script explicitly.

Jeff

[Jeff Hatch]

Brian,

How comfortable are you with C++? The AEP Conduit does not have java installed by default.

Jeff Hatch

[Jeff Hatch]

Tom,

Just making sure: Is your uboot-setenv script doing a saveenv at the end. If not, the variable settings will not persist.

Jeff

[Jeff Hatch]

Brian,

The ip-up script should be getting executed by pppd once the ppp connection is up and the ppp interface can be configured. With regards to running your script, it should be working if the script is set up correctly. Have you verified that the run-parts utility will run your script when it is pointed at the right directory? What you’re trying to do is reasonable, and should work. If run-parts can run your script when you do it by hand, then it should get executed after ip-up.

Let me know if that is not the case, maybe post a copy of your script. If nothing else I can try to start something in a similar manner.

Jeff

[Jeff Hatch]

Tom,

Alright, it deleted the link twice. Here it is in plain text:

Flashing mLinux Firmware

Jeff

[Jeff Hatch]

Tom,

Somehow my link to the flash instructions disappeared:

Jeff

[Jeff Hatch]

Tom,

You are correct that all you have to do is have the oe_uImage.bin and oe_rootfs.jffs2 files in the tftpboot directory for your tftp server on your PC. Make sure to name the kernel and file system files the same as what is in the u-boot env as I think you are doing, and configure the correct IP address for the Conduit and the tftp server. Then you should be able to use the “run krb” command. It is very similar (if not the same) as the instructions for flashing through u-boot in mLinux as described about halfway down the page under “Using U-boot & TFTP”.

Hopefully everything will go well and the re-flash will get you up and running.

Jeff

[Jeff Hatch]

Michael,

The udhcpc stuff you’re seeing in the logs may be related to your problem. That functionality is part of our proportioning features that communicate with our DeviceHQ server. It is automatically enabled, but you can disable it by editing the /var/config/db.json file and changing the following from:

“firstTimeSetup” : true,

to:

“firstTimeSetup” : false,

When you make that change, reset the device.

The “call home” feature may be causing delays when you are trying to connect to the Conduit because it is taking over the ethernet interface trying to get an address from a DHCP server. I have never seen that feature completely prevent connection though.

Jeff

[Author]

Posts