[Jeff Hatch]

Lawrence,

AEP 1.2.x is now in test, and on it’s way to being released. It has npm back in, and also allows you to modify the settings.js in a Node-RED application without being overwritten by the app.py script among other things.

Jeff

[Jeff Hatch]

Heath,

One recommendation would be to lock down your forwarding rules from the WAN to only the ports that you want to allow. Also, you could restrict the forward rules by specifying source and dest IPs to lock down what traffic is allowed through. You could also lock down what protocols are allowed. Those restrictions would close the hole a lot. Especially from the WAN side I would make the rules as specific as possible.

Jeff

[Jeff Hatch]

Chris,

Do you have an “iptables -L” from when the issue was still occurring. If I have time I could take a look into what you did and find a way to do what you really want to do.

Jeff

[Jeff Hatch]

Chris,

What about a configuration file outside of Node-RED that is downloaded onto the Conduit with these values in a location that is persistent through firmware upgrade?

Jeff

[Jeff Hatch]

Chris,

Thank you for the feedback. While I’m not sure we’ll be adding the FTP module for node, using mqtt as an alternative was a good approach. Are you still sending a file via mqtt, or did you just send the information in a custom protocol?

Jeff

[Jeff Hatch]

Heath,

I think that you need to add the -m state and –state arguments to specify that NEW, ESTABLISHED, and RELATED packets will be accepted. Something like:

iptables -A FORWARD -i eth0 -p udp -d 10.0.3.14 –dport 502 -m state –state NEW,ESTABLISHED,RELATED -j ACCEPT

This causes the current packet to essentially get associated with an “existing” connection. In this case for UDP packets it will associate the response packets with the original packets sent by your master. I think that this is what is missing in your FORWARD rule.

Hope that helps,

Jeff

[Jeff Hatch]

Heath,

You are going to have to use iptables on the mLinux model to do port forwarding. I suggest that you read some of the online information such as http://www.systutorials.com/816/port-forwarding-using-iptables/ and the iptables man page.

You can set up an init script to create the rules that you need on boot to make them “persistent”. Are you NAT’ing the source or dest ports or addresses? Are you looking for the traffic to just pass straight through without redirection?

Jeff

[Jeff Hatch]

Chris,

We do not have the FTP node module installed the AEP Conduit. We do have both the FTP and SCP client programs installed. You could write a simple script that reads a directory and uploads any new files that get created. There are plenty of examples of bash scripts that use ftp or scp to upload files to a remote server.

I don’t think that an npm install of one of the available ftp node modules will work on the Conduit at this time due to the dependencies required.

Jeff

[Jeff Hatch]

Arnaud,

I’m pretty sure we only support FAT32 and the Linux filesystems, and not NTFS as you suspect.

Cheers,

Jeff

[Jeff Hatch]

Arnaud,

You should be able to plug a USB key into the USB Host port on the Conduit, and it will automatically mount in the /media directory on the Conduit. It should be able to read FAT32.

Jeff

[Jeff Hatch]

Arnaud,

The serialport package is installed with Node-RED on the AEP Conduit. You should be able to use it to communicate with USB devices in a function node. The home page for the serialport node module is https://github.com/voodootikigod/node-serialport. There are numerous examples on this page’s documentation and also out on the Internet on stack overflow and other information thread sites.

Jeff

[Jeff Hatch]

Arnaud,

It will be possible soon. We are releasing a test candidate for AEP 1.2.x this week that will hopefully go smoothly and be release. The latest release of DeviceHQ has the ability to request uploading of the log files to DeviceHQ from the AEP Conduit, and the first release that supports that feature in AEP is 1.2.x.

Jeff

[Jeff Hatch]

Kiran,

You’re in luck, I am currently running Ubuntu 14.04 as my workstation. You should be able to just connect your Conduit’s debug console to a USB port on the Ubuntu machine, and the tty should get instantiated in /dev as a /dev/ttyACM*. I use minicom to connect to the debug console tty from a terminal. The terminal program I use is called Terminator.

The minicom program has a man page and a lot of different questions pertaining to its use are on the Internet. To connect with minicom you might have to ‘sudo’ in order to connect to the tty.

Jeff

[Jeff Hatch]

Lawrence,

Do you need a 1.0.33 version of AEP for some reason? The latest download is 1.1.2 and that is greater than 1.0.33, so it will work. We can probably put 1.0.33 back out there if there is a good reason.

Jeff

[Jeff Hatch]

Kiran,

The information that you want to modify is in the API configuration file in /var/config/db.json. However, if you modify this file outside of making API requests it is possible that you will see your settings get reverted back by the API. The most effective way to modify these settings outside of the Web UI is to make curl requests to the API. To do this you can use a command like:

curl -s -m 5 -X PUT -H “Content-Type: json/application” -d ‘{ “network” : { “eui”:”UUIDabcdefg”, “key”:”SOME_VALUE” }}’ 127.0.0.1/api/loraNetwork

And then save this change:

curl -i -X POST -H ‘Content-Type: application/json’ -d ‘{}’ http://127.0.0.1/api/command/save

Hope that helps,

Jeff Hatch

[Jeff Hatch]

Albert,

You can make an API request to get or set the rx2Datarate. You can use something very similar to the example at

Connect Node-RED to Any Cloud Service’s REST API

Instead of going to some Xivley or M2X server you will go to localhost (127.0.0.1) and do PUT/GET to api/loraNetwork/lora/rx2Datarate.

Jeff

[Jeff Hatch]

Quentin,

The “firewall –init” is a utility that creates a default set of rules that allow incoming connections for SSH and HTTP(s), along with DHCP and DNS. Also, it creates default forward rules to allow RELATED and ESTABLISHED forward connections. All output on the LAN and WAN is pretty much wide open.

There is a default rule that you can enable in the UI that should allow any incoming connection on the LAN on ports 1024 – 65535. You shouldn’t have to create a new rule. If this doesn’t help let me know. I think the best place to add your custom rule would be in the /etc/init.d/firewall script right after the firewall –init line. This modification will get overwritten any time you reflash the firmware.

Jeff

[Jeff Hatch]

Quentin,

You are correct that you will need to add an INPUT rule for port 8080. I am not sure how the SSH is getting blocked. Are you trying to access the Conduit through the WAN interface?

I think that the same problem with the firewall rules not permitting port 1337 using a NodeJS server may also be blocking you on the Conduit.

As for NPM, yes we have custom AEP 1.1.2 firmware with only npm added back in. The bitbake recipes changed for the NodeJS package and the npm utility got separated out into it’s own recipe. We did not realize that until too late. If you file a portal case with support.multitech.com and request the AEP 1.1.2 firmware with npm added, we will get you a download of the firmware.

Jeff

[Jeff Hatch]

Quentin,

You should leave the localhost port that Node-RED is listening on as 1881 and just modify the stunnel.conf accept port from 1880 to 8080. Leave stunnel redirecting to 127.0.0.1:1881. This will free up 1880 on the external interface while still using the same port on localhost for Node-RED. That way you won’t have to touch settings.js.

On the npm front, we have a version of AEP 1.1.2 that has npm added back in that you can request. You will need to make a portal request, and we can make that firmware available to you. The only change it has in it from the 1.1.2 firmware is the re-addition of npm.

Jeff

[Jeff Hatch]

Quentin,

You can try editing the /etc/stunnel.conf and changing the accept = 1880 to accept = and see if that works (I think it should but haven’t tested it).

Remember, Node-RED, by default, listens to port 1880, but as you may know, that is modifiable by changing the uiPort in either settings.js or in the Node-RED module itself. However, right now on Conduit the settings.js is not modifiable (changes won’t persist because an administrative app.py script overwrites it every time Node-RED starts). In the upcoming release 1.2.x the settings.js will be left alone and the user will be able to modify it and not worry about it being overwritten.

In the future we may also make the listen port for the Node-RED connection configurable.

Jeff

[Jeff Hatch]

Quentin,

The stunnel listen on port 1880 is redirecting to port 1881 localhost for the Node-RED admin login. We have found that the HTTPS login to Node-RED uses up significant memory, so we redirect port 1880 connections to Node-RED to localhost 1881. That way there is support for HTTPS to the Conduit for logging into Node-RED. At this time there is no easy way to change this. You will probably have to use a different port, possibly 8080 or something like that.

Jeff

[Jeff Hatch]

Gavin,

You could try the what Nick O’Leary recommended in the following thread:

https://developer.ibm.com/answers/questions/176998/error-on-sending-e-mail-by-using-e-mail-node-on-no.html

Jeff

[Jeff Hatch]

Gavin,

The change to the SMS node was for localhost-only traffic between the node and the SMS API interface on the Conduit. HTTPS consumes a lot of memory in nodejs.

As for the SMTP node, I’m not sure that it does TLS. That may be the issue. Either that or the auth is broken. Either way, it is the stock Node-RED SMTP node, and we haven’t touched it. I haven’t gotten it to work effectively with any “real” email server.

Jeff

[Jeff Hatch]

David,

The setup.py is trying to import the python email module, but it is not installed. You will need to install the email module.

The link you posted is an alternative way to install the disutils module. It is probably the better way in that building it that way should pull in all the dependencies for the module also. Otherwise, you are going to have to install things one at a time and find out what the next missing dependency is.

Jeff

[Jeff Hatch]

Jonathan,

I did a cursory check with opkg on the AEP Conduit and did not see snmpd available. This would mean that getting snmpd built and installed on the AEP will mean building it for mLinux, keeping track of the dependencies, installing the dependencies on the AEP and the snmpd binary that you have built.

It’s a bit of an undertaking, but doable.

Jeff

[Jeff Hatch]

Jonathan,

The pppd daemon gets the DNS server settings from it’s peer (the provider) when it connects, and writes the /etc/ppp/resolv.conf. Not sure where things go entirely from there since on my unit /etc/ppp/resolv.conf doesn’t exist.

The /var/run/resolv_ppp0.conf gets written by the lanup script in /etc/init.d from the API (rcell_api). The settings in this file are linked to the wan_resolv.conf by the wan manager daemon.

I can spend more time getting to the bottom of this if you open a portal case with support.multitech.com.

Jeff

[Jeff Hatch]

Lawrence,

I have a build of AEP 1.1.2 that includes the npm utility in it. If you would like a copy open a portal case and make a request for it. It is an unofficial release of software. The next release of AEP will also contain the npm utility added back in.

Thanks,

Jeff Hatch

[Jeff Hatch]

Alehandro,

I’m afraid you will have to re-flash the device from Uboot. I am not aware of any way to avoid the network interface configuration once you’re in that state.

The following link provides detailed instructions on how to re-flash from Uboot:

Flashing mLinux Firmware

[Jeff Hatch]

Terrence,

>>When using the conduit without cell, it will always be in dhcp client mode so it can receive an ip address as well as gateway and dns addresses (or statically assigned).

When you configure the Ethernet interface in the WEB UI, you can enable the DHCP client to get and address, gateway and DNS. If you choose static, you will need to configure the interface IP, the gateway, and the DNS yourself. If DHCP client is enabled, the Conduit must be connected to a network with a DHCP server available.

>>When would the 2.1 address ever be used, as the conduit will always be connected to a network to gain a gateway and 192.168.2.1 will most likely not be on the current network.

If DHCP client is enabled, the 192.168.2.1 address will not be used. The interface should not get configured with an address by the system until a DHCP response is received that provides the DHCP lease with the address and other information. You would use the 192.168.2.1 static address if you were connecting directly to the Conduit from your PC (a cable going directly from an Ethernet card in your PC and plugged into the Conduit).

>>I configured the conduit for dhcp client, and hooked it up to my router and saw where it got an ip address. I was unable to connect to the conduit with the assigned address

Can you ping the Conduit address from your PC or whatever you’re trying to connect to it with? Have you accessed the Conduit via the debug console to verify that the address is in fact assigned (use ifconfig -a)?

Jeff

[Jeff Hatch]

Terrence,

By “configure my [MTCDT-210A Firmware1.1.2] to receive messages” do you mean that you are using LoRa to receive the messages and want to use Node-RED to send these messages to your Azure API webservice? In that case, on the Node-RED end of things you can start with the following link:

Connect Node-RED to Any Cloud Service’s REST API

There is a link that talks about configuring LoRa here:

Getting Started with LoRa Conduit mLinux (LoRa Configuration)

Hope that helps,

Jeff

[Author]

Posts