The firmware will not let me install software

LPWAN Developer Gateways / Concentrators
1

What I need: I need a LoRa concentrator, without going through TTN. I need to process received raw data in the RPi

What I have: I have a RAK7244 with the LTE module, running Chirpstack and HTTP Integration.

Regulatory Domain: USA.

What it is and is not doing: It boots up, the GPS displays my location on a surprisingly accurate map, ifconfig shows the browser interface, the wireless client, and the loopback interface. the presence of the map indicates I have internet connectivity

It appears to me that I need tcpdump to access the packets on the loopback. I can’t get tcpdump. when I try it jumps through the usual hoops, then fails when it can’t find the package. I tried apt install tcpdump on the RPi I use to interface with the 7244, and it installed immediately.

I have internet connectivity on both devices, another similar device on the same network loads the apparently necessary program, so it appears that the OS is lacking some necessary bit of software to retrieve packages.

How do I obtain tcpdump without apt? how do I install apt without apt? Am I missing something simple?

2

What do you mean when you say “raw data”?

If you have Chirpstack & HTTP Integration running, you are sending uplinks somewhere.

How does a loopback interface or TCP dump factor in to all of this?

FWIW, Chirpstack is an alternative to TTN that you run on your own computer, so “without going through TTN” doesn’t really seem applicable.

Removing the technicalities, what are you trying to achieve in simple terms?

3

Blockquote What do you mean when you say “raw data”?

data straight from the radio. not sent through the IoT network, processed through a remote app server, and sent back. it’s a latency thing, and a reliability thing

Blockquote How does a loopback interface or TCP dump factor in to all of this?

the default IP of Chirpstack is 127.0.0

that seems to be the point of ChirpStack.

I started out to build a doorbell on an Arduino Mega, and ended up with a vast intrusion detection system for perimeter monitoring on a large property.

To get full property coverage, I need a dozen or more intrusion detection sensors. because it is a large property, a quarter mile long, I can’t run wires to the sensors. I need RF to send motion detector signals to the house. I will also send weather data to the house, one sensor per location, as a way of knowing the field sensor system is alive.

If I send data over individual radios I need one receiver per sensor package, and an RF distribution system. The expense and complexity would be frightful. I can’t do anything with the information, except set off an alarm.

If I use LoRa and a concentrator, I can use one radio per location, recover data from packets, send that to I2C, and use an I2C to 16IO module at the RPi to pull pins low on my Arduino project. I can send instructions to the field sensor package: fire up the wifi camera at the sensor point, spark up the IR illuminators, send video back to the house. Power up power sucking video gear only when you need it.

At some point in the future, I can move the alarm system to the RPi in the concentrator, which has the Ethernet, SD, sound, and GPS functions I worked so hard to fit in the Arduino, and make it a one component system.

but not until I can recover the data from the loopback port, which needs tcpdump or some other software which will be equally impossible to acquire.

4

Data sent straight from the radio is encrypted, twice.

I’d strongly recommend learning about LoRaWAN in a normal environment before trying to subvert its core design. You’ll find out that the default IP of Chirpstack isn’t what you think it is and in fact it is a network & app server just like TTN that you can run locally, um, just like TTN if you want.

I find MQTT latency from the sensor in front of me to the gateways in the office (end of garden) to wherever the TTN servers are, processed and back out to this laptop feels pretty instant.

Or you could just read the packet forwarder log and decrypt, twice, the raw payload.

Or run LoRa point to point with one node setup to receive the incoming messages.

Or use NRF radios - they can have one receiver & 5 transmitters and are about €2 each. They are transceivers so you can communicate in both directions. Perhaps trigger an ESP32-CAM and stream video over WiFi.

I’d really not recommend messing about with tcpdump etc to see the uplinks being transferred through to the on-gateway Chirpstack, it’s doing it the very hard way. You could leave Chirpstack to process & output via the HTTP integration in a loop back to an internal web server running on a different port from ChirpStack. Perhaps better to run a Go daemon using gRPC.

If may find Wireshark is easier to see the traffic. Strangely enough, Chirpstack has a feature it calls “Live frame-logging” which it summarises as “It will display all the RX / TX meta-data, together with the raw LoRaWAN PHYPayload in a readable format. It is like Wireshark for LoRaWAN!”

But as someone who has manufactured & sold devices for security professionals for over 15 years, I can assure you that I’d not use any of this stuff for your application. It’s a reliability thing.

5

Only encrypted once, then given a cryptographic checksum.

But only even that if the node is using LoRaWan, which it’s unclear that it is.

If one wants the raw data, then pointing the packet forwarder at the loopback interface would make sense. But “tcpdump” is not how to obtain it, that’s at most a tool for a brief test.

Rather, the OP would need to create something which speaks the Semtech UDP protocol.

Or they could run an old version of the Chirpstack gateway bridge and convert the UDP protocol to MQTT, which is likely going to be easier to detail.

Anyway, you’re right that the OP is mistaken to be blaming LoRaWan for latencency.

Most the issue is that they don’t have a very clear idea what they’re trying to do.

apt issues are a tangent - if they don’t like the RAK image they’re free to use some other, all that’s really needed is dropping the SPI clock speed from standard to maybe 1 MHz.