[Jeff Hatch]

Chris,

I have been away on vacation for a little while and things got really hectic after I got back. Have you made any progress on this?

Jeff

[Jeff Hatch]

Görkem,

I have been away on vacation for a little while and things were very hectic when I got back last week. Have you been able to make any progress with firewall rules used to block your PC from using the AEP Conduit for Internet access? If not you should be able to make a Forwarding Drop rule with your PC’s address as the source address of the rule.

Jeff

[Jeff Hatch]

Lawrence,

Thank you for your efforts. I know there isn’t much documentation for the Node-RED app stuff on AEP right now. Hopefully that will be rectified in the near future.

Jeff

[Jeff Hatch]

Lawrence,

I am confused as to what you’re trying to get at with this post. To clarify:

The settings.js file that support for modification and persisting through firmware upgrade is the settings.js in the applications that are installed on the Conduit. You can modify the development (default) application’s settings.js, and you can modify the settings.js in any Node-RED application that you have installed through DeviceHQ in the /var/config/app/ directory.

The /opt/node-red/settings.js file currently is overwritten on firmware upgrades and will continue to be until we have new hardware and support package upgrades on the AEP Conduit.

Jeff

[Jeff Hatch]

Chris,

I have a couple of things that you can look into. First, on the PC, is there a way for you to configure it to DHCP with addresses only? If you can this should prevent the PC from getting a gateway setting that overrides the gateway pointing to the WiFi interface.

Also, so far I have played around with using the same rule that you describe, but also blocking by specifying a port value. This seems to be working as expected. I will see if I can get any time tomorrow to play with this.

Jeff

[Jeff Hatch]

Görkem,

Before you try to solve this with firewall rules, check to see if you can configure the PC interface to do DHCP with “addresses only”. I know Linux has this ability, Windows can probably do it too. That way the PC will only get the address for the interface, and will not accept gateway and DNS information from the Conduit.

Jeff

[Jeff Hatch]

Görkem,

Is the ethernet interface on the PC that is connected to the AEP Conduit getting its address through DHCP or is it static? If it is getting a DHCP address from the Conduit, you can prevent the PC from passing traffic through the Conduit with firewall rules on the Conduit. If it is static, then you need to make sure that the default route points to a gateway other than AEP.

When the Conduit DHCP server gives out IP’s and gateway information due to the way the kernel on the PC is handling routing, I think that the gateway provided by the Conduit is overriding the gateway for the wireless network.

Jeff

[Jeff Hatch]

Chris,

You can use the curl utility and issue API requests on the Conduit to enable UI access via WAN and then issue a second API request to save and restart to make the change effective. It would be something like the following:

Enable HTTPS over WAN
curl -s -m 5 -X PUT -H “Content-Type: json/application” -d ‘{ “wan” : true }’ 127.0.0.1/api/remoteAccess/https

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

To disable just set the “wan” to false in the first request and save and restart with the second request.

Jeff

[Jeff Hatch]

Chris,

Probably the first thing to consider before making firewall rules is to determine what you want to block, and then the best way to block it. In the AEP Conduit Web UI, you will probably want to use the “advanced settings” and create what are called “Forward Filter Rules”. Those are the base rules that allow or block traffic going through the Conduit, ie. in Ethernet interface and out the Cellular interface.

You can block specific source IPs or a source subnet or IP range. You can also block anything matching certain ports, or different combinations. Give me an example of what you want to do, and I should be able to help you fashion a rule or two that can allow and block what you need to.

Jeff

[Jeff Hatch]

No problem. We have limited documentation on that feature,and the interactions between the different parts (Call Home and interface configuration) is complicated.

Jeff

[Jeff Hatch]

Johnathan,

I have a hypothesis as to what you have seen. When you performed the firmware upgrade, did you use the Web UI? Did you go through all the steps in the Initial Setup Wizard, or did you just hit the “X” to exit out of the wizard?

The reason I am asking these questions is that I think you were seeing interactions between the “Call Home” feature that is intended to be part of the “Zero Touch” functionality where customers can manage their Conduit entirely from the DeviceHQ remote management server.

When a Conduit is first powered up with the default configuration, the Call Home feature is active and is what is attempting to get a dynamic “DHCP” address. As long as it can successfully negotiate an address it will then try to check in to DeviceHQ and get an account key. If it cannot successfully check in it will continue to manage the Ethernet interface address dynamically.

If someone logs into the Conduit Web UI they will initially encounter the Initial Setup Wizard, and typically walk through it to configure the administrator password, time management, cellular, and the Ethernet interface. Whether they follow these steps, or they hit the “X” and exit the wizard, this activity will deactivate the Call Home feature. When this happens the Call Home feature will no longer obtain an address for the Ethernet interface dynamically. The Ethernet interface will then be configured either statically or dynamically depending on what it was configured to be in the Initial Setup Wizard. If the user clicks the “X” to exit the wizard, the default behavior is for the Ethernet interface to be “static” with the 192.168.2.1 address.

This may be the behavior that you have seen.

Jeff

[Jeff Hatch]

Jonathan,

Thank you for the additional information. We will try to reproduce and fix the problem.

Jeff

[Jeff Hatch]

John,

If you have a terminal program running on the PC, you could also use a terminal program on the Conduit to send files to the PC from the Conduit. However, it sounds like you are trying to use the command line on the Conduit. Is that correct?

Jeff

[Jeff Hatch]

Jonathan,

I have not seen this in my own testing of upgrades from 1.1.2 to 1.2.2. Might you have possibly reset the device to defaults or to user defined configuration? There is a remote possibility that the /var/config/db.json got corrupted, and the unit defaulted back to the default_db.json.

Did you back up the configuration before you applied the upgrade?

Jeff

[Jeff Hatch]

Chris,

In the Web UI, if you go to Setup->DHCP, there should be a list of server entries (maybe only one). In the server entry you can modify what Gateway you want it to give out. If you set it to something that you want the PCs to use instead of the Conduit, this may solve your problem. Let me know. Otherwise, there are ways to do it with Firewall rules, but that is more complicated as you have already figured out.

Jeff

[Jeff Hatch]

Chris,

A question or two:

When your configuration team manually changes the mode for ETH0 are they using the Initial Setup Wizard or are they using another means to configure the interface?

I may not have the complete picture of what is going on, but have you tried configuring the Eth0 interface to DHCP Client instead of static? This is how it is working “out of the box”. If the DHCP server is disabled on the Conduit, and the interface is configured to use the DHCP Client, it will attempt to get an address, but not give out any addresses as a DHCP server.

I guess I am still trying to get an accurate picture of what you want to accomplish. Do you want the Conduit to just be a DHCP client and get an address, or do you want it to do something else?

Jeff

[Jeff Hatch]

John,

There is tons of stuff online about using minicom. Searching on Google for “minicom commands” gives links to the man page and numerous other helpful links depending on what you are trying to do.

Jeff

[Jeff Hatch]

Neil,

>> 1) Can you confirm I can switch between AEP and mLinux ‘flavours’ simply by loading the appropriate image?

Yes you can switch to mLinux by just loading the appropriate image. If you had an mLinux model it is a different story due to what is stored in the EEPROM on an AEP model that has to do with Remote Management. You will lose the ability to do remote management if you switch to the mLinux model.

>> 2) Is there any documentation on meta-mono. I’m comfortable with writing C# under windows but a simple ‘how to get “hello world” running’ app note would save some time.

For this I think you will have to look at the Yocto and OpenEmbedded projects to see if they have anything. I am not aware of anything that Multi-Tech has created.

Jeff

[Jeff Hatch]

Fabien,

There is a –json (-j) option for the lora-query command that will output the node list in json format. That should be pretty easy to handle in Node-RED.

Jeff

[Jeff Hatch]

John,

The Conduit does have minicom and a busybox version of microcom. You could probably use one of those to write to the USB serial device and receive the data on the other end on the PC.

Jeff

[Jeff Hatch]

Adrian,

The /etc/network/interfaces file settings will get overridden by the API process on boot. The information in the interfaces file will get applied early in the boot process, but when the API starts it will override those settings with what is in the /var/config/db.json.

You can use the “if” commands or ifconfig to bring the interface down and then back up to apply the interfaces settings. If you want the device to apply the settings in the /etc/network/interfaces file you should log into the Web UI once you have access and update the eth0 settings to what you want them to be.

Jeff

[Jeff Hatch]

Haykel,

The AEP Conduit API overwrites the /etc/passwd and /etc/shadow files on boot. The only account that is currently supported for login through either SSH or the Web UI is the admin user account. The mLinux version does not have the API that manages the users like this, thus the password files do not get overwritten. The admin and root users have the same uid on the AEP Conduit.

Jeff

[Jeff Hatch]

Corentin,

There is a way to do this manually by copying the file to the Conduit with SCP, and then logging in via SSH and running the firmware_upgrade script by hand:

Copy the firmware upgrade file to the Conduit:
PC# scp conduit_AEP-1.2.2_upgrade.bin admin@:/var/tmp

Log in to the Conduit via SSH and run the firmware upgrade script by hand:
Conduit# firmware_upgrade /var/tmp/conduit_AEP-1.2.2_upgrade.bin

This will run the upgrade by hand. The output of the firmware_upgrade script in the logs and at the CLI should hopefully give you more information about what is going wrong if it is still failing. If the file is good and the upgrade is triggered successfully, the Conduit will automatically reboot at the end of this script to trigger the flash upgrade.

Jeff

[Jeff Hatch]

Adrian,

I’m assuming that you don’t have a WAN interface enabled that you can access either via HTTP/HTTPS or SSH. If that is the case the only other way to access it is if you have physical access to the debug console. You can log in there and issue API commands to localhost port 80, or you can change the IP by editing the /var/config/db.json and either rebooting or restarting lighttpd.

Jeff

[Jeff Hatch]

Johnathan,

>> How can we query the voltage received by the Multitech Conduit? What about its internal temperature?

There is no means to query the voltage powering the Conduit. The best idea I can come up with would be to use the AtoD on the GPIO card to measure the voltage by having some kind of device hooked up to the power cable and measuring the voltage, then outputting some conversion (from a reference voltage?) into the AtoD to represent the power voltage.

There is a way to get the internal temperature on a Conduit. Information for that is on the multitech.net site at http://www.multitech.net/developer/software/mlinux/using-mlinux/mlinux-configure-and-use-hardware-io/ under Temperature Sensor at the bottom of the page.

As for a watchdog, the aep model does have watchdog code that checks the radio and resets it if it is not responding. Also, the pppd daemon should detect if the connection is dropped and try to re-connect.

Jeff

[Jeff Hatch]

Jonathan,

Please file a support case at https://support.multitech.com/.

Jeff

[Jeff Hatch]

Are you trying to talk to a terminal program on the other end like minicom or are you trying to write to a mass storage device that is connected to the USB host port? What are you using to communicate on the other end on your PC?

Jeff

[Jeff Hatch]

Which serial port were you trying to use? The Multi-Serial nodes in Node-RED on the Conduit are for interfacing with the MTAC Serial cards that you can plug into the Conduit. Are you trying to use the USB host port on the back of the Conduit?

Jeff

[Jeff Hatch]

The npm utility is once again included with the 1.2.2 firmware release.

Jeff

[Jeff Hatch]

Currently, we do not have a supported way for a customer to build modules and install them on MTR. That may be changing in the future as the MTR will be migrated to mLinux. However, I do not know if that will be applicable to the older models.

You could create a support portal case at https://support.multitech.com since this is not currently supported.

Jeff

[Author]

Posts