[Jeff Hatch]

Daniel,

If I remember correctly there was a significant memory leak fixed in the AEP API that helps solve these problems. Unfortunately, I think that fix isn’t available until AEP-1.2.2. It is possible to upgrade through u-boot, though that will wipe everything in the persistent partition also. If you want to pursue that option please file a Support Portal Case at https://support.multitech.com.

Jeff

[Jeff Hatch]

Evan,

Is the IP address of the Conduit on the same subnet as the router?

Jeff

[Jeff Hatch]

Evan,

Is your PC set up to accept and handle DNS requests? If not the Conduit needs to be configured to access a DNS server, whether it is over Cellular or Ethernet.

Jeff

[Jeff Hatch]

Evan,

The npm utility cannot resolve a DNS hostname of some sort. You will need to fix the DNS on the Conduit in order to get the resolution to work.

Jeff

[Jeff Hatch]

Daniel,

Do you have any custom applications running on the Conduit?

Jeff

[Jeff Hatch]

Chris,

It is possible to increase the size by changing the syslog config file in /etc/syslog-startup.conf. However, I would recommend installing rsyslog and logging to another device that can handle bigger files. If you do not want to do that then you can change the path in the syslog-startup.conf to lag to a directory on the SD card. One warning, though: We have had some problems logging lots of data to the SD Card. Not sure if it has something to do with FAT format or something else. You will have to test it thoroughly.

Jeff

[Jeff Hatch]

Damian,

From the chat output it looks like the radio is responding. The problem may still be radio related, but I am not sure. You can turn up the ppp debugging by:

Diagnostics

Messages are sent to the syslog daemon using facility LOG_DAEMON. (This can be overridden by recompiling pppd with the macro LOG_PPP defined as the desired facility.) See the syslog(8) documentation for details of where the syslog daemon will write the messages. On most systems, the syslog daemon uses the /etc/syslog.conf file to specify the destination(s) for syslog messages. You may need to edit that file to suit.

The debug option causes the contents of all control packets sent or received to be logged, that is, all LCP, PAP, CHAP, EAP, or IPCP packets. This can be useful if the PPP negotiation does not succeed or if authentication fails. If debugging is enabled at compile time, the debug option also causes other debugging messages to be logged.

Debugging can also be enabled or disabled by sending a SIGUSR1 signal to the pppd process. This signal acts as a toggle.

You can either send a SIGUSR1 to the pppd process or add the debug option to the ppp start script. It would probably be easier to try the SIGUSR1 first.

Jeff

[Jeff Hatch]

As far as the SMS node, I don’t think that will cause memory/CPU issues, but it does use http to our API that in turn is using utility programs to get SMS data from the radio. Again, I don’t think that will cause problems, but what might is using any node code, Node-RED included, that does HTTPS. for some reason that seems to be a real resource hog. The original person who wrote the SMS node was using HTTPS to localhost for the API calls and that was causing resource issues when there was a lot of SMS going on.

For the PPP monitoring, are you making the API calls remotely or are you doing them locally on the Conduit?

Jeff

[Jeff Hatch]

Mikel,

Just need to make sure. We have customers that port other software onto the Conduit.

As for using udhcpc, what arguments are being specified when it is getting executed? Are you using a script file? In the past I have used the -qn arguments: udhcpc -i eth0 -qn

With this it will try a few times and quit with an exit status of either 0 (success) or 1 (failure) to get a lease. I then check the exit status and if it didn’t succeed I re-run it after sleeping for a designated amount of time. Doing that in a loop, you can control how often and how long you retry.

The contents of the udhcpc.conf are:

start                   192.168.2.100
end                             192.168.2.254
interface               eth0
option subnet   255.255.255.0
option router   192.168.2.1
option dns              8.8.8.8                 # google's DNS server

In this simple case I don’t have udhcpc executing a script (–script argument).

Hopefully that will help,

Jeff

[Jeff Hatch]

Ajay,

A couple of things that might be going on is if you are using HTTPS in the Node-RED traffic, and a lot of LoRa is going on, there is a possibility the CPU is getting maxed out. One way to see if this is the case would be to be connected in via SSH before the “busy” period starts and run the “top” command. Watching the output of top during the period while you can’t log in should tell you the state of the CPU consumption and the memory. It is quite possible things are thrashing.

I don’t think that the PPP REST requests to the API are the cause. The only thing that might be disruptive that I can think of is that is running radio commands that could cause a blip in the processing of anything else. Are you by chance using the SMS node in Node-RED?

Jeff

[Jeff Hatch]

Damian,

Can you post the entire output of the chat script? That might give a better clue. As it is it appears that the radio is responding to the chat script, but failing on connection establishment. It is difficult to get any debugging from the radio itself. It might be possible to turn up the debugging coming out of ppp though.

Jeff

[Jeff Hatch]

Damian,

The only thing that I can think of without more information is that the radio on that device is “coming up” slower than on the other device for some reason. I’m assuming that both the device that works and the device with the problem are using the same provider and are effectively in the same location and behave the same with the exact same SIM card?

Jeff

[Jeff Hatch]

Mikel,

Are you using udhcpc or a different DHCP client program?

Jeff

[Jeff Hatch]

Ajay,

If the login brute force protection is enabled, the default failed attempts that trigger lockout is three. If the user fails three times they will be locked out for the lockout time which defaults to five minutes.

The Node-RED authentication uses the REST API to authenticate the admin user, so this can also trigger the Brute Force Protection if it is enabled.

Have you been able to log in successfully since the “Lock out” behavior started?

Jeff

[Jeff Hatch]

Ajay,

You can use the command at the SSH prompt or you can go into the Web UI, got to the Apps page, disable Node-RED and then re-enable it.

Jeff

[Jeff Hatch]

1) I am assuming the settings.js file under the \var\config\app\install\development\settings.js file is the one I am supposed to update?

If you have not installed an app from DeviceHQ, that is correct.

2) If the location of the setting.js file mentioned above is the right one, I am assuming this is protected from firmware upgrades?

This file is not overwritten by upgrades. The only field that gets overwritten is the listen port for Node-RED.

3) When I make changes to the settings.js file, do I need to restart the node-red application or is there a file watcher setup by node-red application that would cause the node-red to restart on its own? If not what is the best way to restart node-red?

You should restart Node-RED. There is an init script “/etc/init.d/node-red” you can use to restart it: /etc/init.d/node-red restart

Jeff

[Jeff Hatch]

Michael,

Do you mean a MTAC serial card port or something else?

Jeff

[Jeff Hatch]

Ajay,

By default the Conduit is configured for UTC. The timezone files should support daylight savings time in the timezones that support it.

Jeff

[Jeff Hatch]

Ajay,

There are a couple of places where files will persist through a firmware upgrade:

/dev/mtdblock6 -> /var/config -> ~7MB available
SD Card -> mounts at /media/card

A path to a file in the mtdblock6 would look something like /var/config/

A path to a file on the SD Card would look like /media/card/

Jeff

[Jeff Hatch]

Florian,

We are actively working on upgrading the Yocto version. The current target is Krogoth (2.1). Hopefully this will be available in Q2.

Jeff

[Jeff Hatch]

Patrick,

You are correct that /dev/modem_at1 is a second tty with access to the modem for AT commands. The intent is for that tty to be used for other entities than pppd to do exactly the type of things you are trying to do with it, monitoring being the main thing.

Jeff

[Jeff Hatch]

Patrick,

I checked the krogoth level of Yocto and that dependency is not there. If you want it fixed in the broader openembedded community you will have to push it upstream with them. To get it fixed in mLinux please file a Multitech Support portal case at:

https://support.multitech.com

Jeff

[Jeff Hatch]

Patrick,

One thing you could try is setting the DEPENDS for pam in the Inetutils bitbake recipe. That should fix the dependency problem.

Jeff

[Jeff Hatch]

Yogesh,

1) Is it possible to query the status of the two LORA i/p and o/p node?

Where are you wanting to query from assuming this is different from question #3?

2) I am guessing the connected state indicates all is good with MTAC LORA card?

That is correct.

3) If not how would I be able to query and determine from node-red flows all is good with the Attached MTAC LORA Card and the conduit can successfully receive and send LORA packets?

The only way to tell if sending and receiving will work with LoRa is to actually send and receive packets between the gateway and the mote.

Hope that helps,

Jeff

[Jeff Hatch]

Akshay,

You can configure the Ethernet interface (eth0) as a WAN with a gateway and dns settings in the Web UI in Setup->Network Interfaces. In order make your page accessible you will have to create a firewall rule in Firewall->Settings to allow a connection to the Ethernet interface address on the desired port. That should allow a customer to log into your Node-RED page.

Jeff

[Jeff Hatch]

Julien,

Usually the forward rules are meant for traffic going through the device, and not to the device. I am not sure what the effect of those rules will be. Could you do an “iptables -L” and an “iptables -t nat -L” and post that output. It may be a rule ordering problem with the new rules you added.

When you enabled “Via WAN” and saved and restarted that created rules for the services you enabled “Via WAN” automatically, so you should be able to access the Web UI if that was enabled.

Can you ping your PPP public IP when the device is up and running?

Jeff

[Jeff Hatch]

Julien,

Just want to make sure: Is the dynamic IP you get a public IP?

Jeff

[Jeff Hatch]

Julien,

Did you save and restart after making your changes? Also, is PPP your only WAN, and is it the highest priority in Setup->WAN? Does your SIM have a static public IP?

Jeff

[Jeff Hatch]

Juha,

Please open a Multitech Suppor Portal ticket at:

https://support.multitech.com

They should be able to help you.

Jeff

[Jeff Hatch]

You will need to SSH into the Conduit.

Jeff

[Author]

Posts