[Heath Raftery]

Great. Hopefully this thread saves someone else 8 hours of futile debugging!

[Heath Raftery]

Sure enough, I tried again on another Conduit that also has a 1.0 card and had the same (non) result. I then tried on yet another Conduit (a MTCDT-247A this time) with a 1.5 card, using the same procedure, and this time it worked.

[Heath Raftery]

The Conduit API does indeed have a ping call. You can see it here:

Commands

Based on the javascript used in the web interface, it looks like you need to pass it an ip field and an interface field. But that’s about all I know.

Otherwise, calling ping from Node.js may be as simple as using exec. Some great guidance is here:

https://stackoverflow.com/questions/4737130/how-to-ping-from-a-node-js-app

The payload is quite arbitrary. The BSD ping uses a 56 byte payload by default. The first 8 bytes is used for a timestamp so it can calculate round trip times. AFAIK, the rest is just garbage.

[Heath Raftery]

The Release Notes for 5.3.0 say that OpenSSL was upgraded to 1.1.1b (from OpenSSL 1.0.2k in 5.2.1), and notes that this will break support for some software. This may be the issue you’re facing.

[Heath Raftery]

FWIW, in firmware 1.6.4 I had to also restart the LoRa Network Server (I used the “Restart LoRa Services” button in the LoRaWAN->Network Settings tab of the AEP web site).

[Heath Raftery]

Thank you, the linked reference answers my questions perfectly (except whether this is new behaviour, but that’s no big deal).

From the references:

Why the CHECK-PKT|FCNT is +10000 after the reset?
The server is checking if the 16-bit counter has rolled-over since the last packet.

Which when combined with this:

The FCNT is expected to be only increasing per LoRaWAN. An FCNT should only be used once per set of session keys. The FCNT is only reset when OTA join is received.

Explains the primary issue. Then this explains how to disable the check (with obligatory security warning):

Disable "enableStrictCounterValidation"

• This reply was modified 6 years, 4 months ago by Heath Raftery. Reason: typo

[Heath Raftery]

Worked around it by editing the source of the page to remove the “style: hidden” tag from the GPS time interface field. I was then able to enter a valid number into the new field and successfully “Submit”.

Looks like a clear website bug?

• This reply was modified 6 years, 7 months ago by Heath Raftery.

[Heath Raftery]

For the record, it seems the mDot spits out [ERROR] SPIFFS_remove failed -10002 when you change the join mode, but that doesn’t seem to be an issue. Had me running a goose chase for a while.

[Heath Raftery]

The power supplied to the mdot is connected to the input of a 3v regulator. VBAT and VDDA are both connected to the output of the regulator.

This doesn’t add up.

AnalogIn   adcVref(ADC_VREF);
float vdda = 1.21f / adcVref.read(); //Internal voltage reference is 1.21V 

gives vdda = 3.00V. Makes sense.

But

AnalogIn   adcBatt(ADC_VBAT);
float vbatt = 4.0f * adcBatt.read() * vdda; //VBAT pin is div by 4

gives vbatt = 3.85V. That doesn’t make sense if, as you say, Vbat and Vdda are connected to the same rail.

[Heath Raftery]

If its just one nuisance ip address or range you could manually use iptables to DROP all traffic from the ip/range.

Very handy. I tried to install ipset to streamline this but it’s not part of the opkg list.

In the end I hacked fail2ban into working. It’s not an ideal hack, but nonetheless 24 hours later it has banned 63 IP addresses!

Interestingly, very few are in the same subnet. There’s three 61.177.172.0/24, two 103.207.37.0/24, two 123.31.0.0/16 and two 193.201.224.0/24. I think the rest are unique, so there’s probably not much value in risking a false positive with entire classes. Not sure if there’s a performance hit having so many to check.

Also of interest, instead of -j DROP, fail2ban uses -j REJECT --reject-with icmp-port-unreachable by default. I guess that’s more likely to discourage future attempts?

Would love to see some improvements to or configuration of the built-in brute-force prevention, or even a supported fail2ban package. It was pretty maddening even trying to figure out which distribution mLinux was closest to to get fail2ban to play ball. Each fail2ban package relies on so many packages that turned out to be unavailable, that I ended up just disabling large sections of functionality just to get it to run.

[Heath Raftery]

Still an issue. Adds up to quite a bit of traffic.

I tried to install fail2ban to take care of it, but could not figure out a configuration to suit the mLinux distribution.

[Heath Raftery]

Great tool, thanks!

Have been running for a couple of hours. Nothing too surprising yet. Average (excluding the ssh connection used to run iftop) is 0.9kb/s (405kB/hour, 9.5MB/day). Maybe 25% of that is Node-RED uploading processed LoRa events. The rest seems to be an idle ssh connection I have open, regular brute-force attempts on http and ssh, and regular dyndns lookups.

Doesn’t take much to add up to many MB per day.

Will continue to monitor.

[Heath Raftery]

What happens why you try?

Step 1 would probably be:

cd /opt/node-red/nodes
npm install node-red-node-sqlite

More info:

Adding nodes to node-red

[Heath Raftery]

Thanks for sharing. Care to let us in on the secret?

I believe it’s Standard right? And the Multitech page is wrong?

Hot tip for others: don’t try to put a nano in, even just to test! Too easy to lose it inside the device with no way to retrieve it.

[Heath Raftery]

I don’t know if you performed a search for “US to Australia AC adapters” but maybe just such an adapter will fit your needs.

From my original post:

I’m sick of buying adaptors.

I have a stack of them. All of them are bulky, ugly, loose and once in use, can’t be repurposed. Besides, it’s maddeningly backwards to have an adaptor for an adaptor because it’s the wrong adaptor!

[Heath Raftery]

Thank you, that’s great! I’ve sent an email to sales. I suspect it still might be challenging to get them in hand, but it’s a promising lead.

Unfortunately (based on the photo) the blade attachment would only suit the first Conduit I bought – the second one uses a slightly different attachment style. In that case I can just buy the whole power supply, though that’s a bit of a waste.

Maybe one day I’ll be able to buy the Conduit complete with the Australian plug!

[Heath Raftery]

Despite what the web interface says, you don’t have 0.0.0. Try head /var/log/app/node-red.log. Chances are you already have 0.11.1.

[Heath Raftery]

When I execute /opt/node-red/bin/node-red-pi -v I get an error regarding already using the ports

Ah… you can’t run two instances. You have to stop node-red first. Just uncheck the “enabled” button in Node-RED apps in the web admin interface.

In my npm-debug file, I have the following:

That’s just the old network error message. I’m sure since you’ve fixed that that the npm-debug file is old.

[Heath Raftery]

18 Jan 19:27:32 – [warn] Failed to register 1 node type
18 Jan 19:27:32 – [warn] Run with -v for details

Great! Did you try? You could kill node-red and then run /opt/node-red/bin/node-red-pi, perhaps with -v, for details. Or, now that I look at package.json and see this:

“dependencies” : {
“mysql” : “^2.12.0”
},

I’m going to have a red hot guess and say you haven’t installed mysql. That’s something npm does for you – takes care of dependencies.

Which leads me to believe that I’m not connected to the internet…which doesn’t seem right.

What makes you think you’re connected to the Internet? Your results certainly suggest otherwise. Interesting that Martijn Jonker had the same issue. Is it possible you’ve both been tricked into thinking you’ve connected your Conduits to the Internet?

Check the output of ifconfig, ping google.com and ping 172.217.25.174. If you can’t figure it out, I suggest starting a new thread on connecting the Conduit to the internet.

[Heath Raftery]

I’m pretty sure you need the package.json file as well as the other two. Otherwise the entry in .config.json looks good. Anything in /var/log/app/node-red.log ?

[Heath Raftery]

Unfortunately that config file is mysterious. It has been deprecated in node-red but the conduit is stuck on an old version, so it’s hard to understand how it’s supposed to work.

A couple of things to check:

1. What are your .config.json permissions? It’s a long shot, but I guess it needs to be writable by admin. Mine are: -rw-r--r-- admin root
2. Have you waited a long time after rebooting? node-red takes many minutes to start. I guess you have if you can see the palette.
3. Try watching /var/log/app/node-red.log as node-red starts. Normally there’s not much to see (only “Loading palette nodes” seems to be relevant) but maybe yours is showing an error.
4. Try killing Node-RED, and then running it from the command line with /opt/node-red/bin/node-red-pi. You’ll see a bunch of stuff appear on the command line which may include something useful.
5. As a last resort, could you try modifying .config.json yourself? It’s not pretty, but it doesn’t seem too hard to guess what should appear in there.

Hopefully something in the logs/command line will help. Might it’s just be a dependancy or a file write issue. It’s tricky to work with though.

[Heath Raftery]

Probably worth it’s own thread, Martijn, but a few things to try:

Are you behind a proxy? Do other connections to the Internet work? For example, does curl http://www.google.com work? What about ping github.com ? What does Google say about the error? Anything in npm-debug.log that would identify the offending address?

I noticed there’s been some very recent changes to the package. Have you tried again recently? For what it’s worth, it fails for me, but for a very different reason. That is, it tries to satisfy the dependency node-serialport, fails to find binaries, so attempts to build from source and fails because I don’t have make installed.

[Heath Raftery]

Okay, finally solved it.

For me the problem was a damaged inode in the /opt/node-red/nodes/ folder. I had installed a new node there but the directory was no longer functional. node-red was choking on it during start up. I discovered that by running /opt/node-red/bin/node-red-pi from the command line, which reported the relevant error. Running node-red-pi was a wild guess – I tried for ages to find what the actual invocation command is when you click the “Enabled” button for Node-RED in the AEP web interface. After tracing through a heap of javascript and lighttpd.conf stuff I found a reference to /usr/bin/rcell_api but go no further.

Anyway, the inode was stuffed so I moved the enclosing folder out of the way, copied everything into a new folder of the same name and I’m back in business.

Took forever partly because all the node stuff (including npm and node-red) takes so bloody long to start.

[Heath Raftery]

Couldn’t figure out how to delete a post. This is no longer relevant – actual problem is detailed in the other thread.

I think this method is flawed. On the next reboot, the newly installed node is gone, yet it is still registered, which causes a mysterious failure on boot. See the harrowing tale at http://www.multitech.net/developer/forums/topic/continuous-reload-of-node-red-page/#post-16011.

So I don’t know the correct way. Maybe it’s npm install -g node-red-contrib-the-new-node for a global install in /usr/lib/node_modules. But I can’t get node-red to run at all now despite hours battling with it, so at this stage, proceed with caution!

• This reply was modified 8 years, 4 months ago by Heath Raftery. Reason: Needs deleting

[Heath Raftery]

Same problem here. Did you ever get it sorted?

I can confirm that the node-red process is crashing – as soon as I check the “Enabled” box in the Node-RED config page in AEP under Apps, the node-red process appears. Some 10s of seconds later it disappears and is replaced with node-angel and node.

In the intervening period, the /var/log/app/node-red.log file shows:

Welcome to Node-RED
===================

12 Dec 17:17:40 - [info] Node-RED version: v0.11.1
12 Dec 17:17:40 - [info] Node.js  version: v0.10.40
12 Dec 17:17:40 - [info] Loading palette nodes

but once the process disappears that file is wiped clean.

Hitting the Node-RED URL (port 1880) at this time results in the continuous refresh the OP reported.

I’ve tried increasing the log level to ‘debug’. Various restarts and reboots. Various browsers and cookie deletion. I tried removing the /var/config/app/install/development/ directory to start fresh. All with no change in behaviour.

This is killing us. We need a resolution.

[Heath Raftery]

Nothing is easy is it? Thanks to this thread I was finally able to add a node to Node-RED on the Conduit. Here’s a summary:

• cd /opt/node-red/nodes
  • The default $HOME/.node-red/nodes seems to be disabled, so you need install in the installation directory, which also means your additions will be gone if you upgrade the firmware.
• npm install node-red-contrib-the-new-node
  • npm exists since AEP 1.2.2
• Restart the Conduit using the web interface under the Commands menu.
  • Oddly, restarting node-red is not enough. There is a mysterious hidden file at /var/config/app/install/development/.config.json which needs to contain the new node. Somehow a restart causes this to happen.
  • node-red takes minutes to start. Monitor /var/log/app/node-red.log to see progress.

• This reply was modified 8 years, 4 months ago by Heath Raftery.

[Heath Raftery]

Any further plans on this? The Conduit is still on Node-RED 0.11.1 which is getting pretty long in the tooth. Makes it hard to search for support when most of the stuff out there is incompatible.

We will not be upgrading the node version beyond 0.10.x until it has been confirmed that the newer version (4.x) can compile and run on ARM5 architecture or when the Conduit hardware has been upgraded to use a CPU that supports the newer instruction set.

It looks like the former is very unlikely:
https://groups.google.com/forum/#!topic/v8-users/aSOFbaAQvMk
https://archlinuxarm.org/forum/viewtopic.php?f=58&t=8468

So is the latter coming any time soon?

[Author]

Posts