Coffee Space – Coffee Space

LoRa Mesh

Introduction

LoRa is a promising and relatively new communications protocol for low-power devices, that seems to be getting a lot of backing within the hacker community. In theory it allows for low-bandwidth communications for more than 10km in good enough conditions. As Wikipedia says:

LoRa (Long Range) is a proprietary low-power wide-area network modulation technique. It is based on spread spectrum modulation techniques derived from chirp spread spectrum (CSS) technology. It was developed by Cycleo of Grenoble, France and acquired by Semtech, the founding member of the LoRa Alliance and it is patented.

Out here in New Zealand, they appear to be using 915MHz (same as Australia). The data rate you can expect is between 0.3kb/s and 27kb/s, so this really relegates you to small bursts of data - no video or voice calls (if you are being respectful with your time on the network).

LoRa WAN

LoRa itself only accounts for the physical layer, it doesn’t define the way in which communications are done. Sending random bytes around doesn’t allow for devices to easily communicate on this network.

The intention of LoRa WAN is to provide a routing system through the use of Gateways (GWs), connecting devices to The Things Network (TTN) - an initiative setup by IBM, Everynet, Actility, MicroChip, Orange, Cisco, KPN, Swisscom and friends. As you may imagine, these companies only have their own interests at heart and not hackers or extensibility.

TTN is specifically designed for IoT, data collection from edge nodes that have a variety of sensors. What’s worse is that LoRa WAN devices can only connect to TTN, there is no way to connect to other services. What’s more is that by default, any devices you connect to TTN use proprietary servers, namely AWS and Google Cloud for example. This again is not particularly hacker friendly.

Ideally, we need something setup by hackers, for hackers.

“Pine WAN”

There is not an official name yet at the time of writing, but the plan is to create a Pine64 network that is more hacker friendly. The intention is that the LoRa WAN GWs are replaced with an open source version that is highly hackable. Some initial ideas about what this could be used for:

Local messaging - Speak to people in your near vicinity.
Messaging via GW - Speak to people across the internet.
Time - Get the current date and time.
RSS - Get updates from feeds to serve as notifications.
IRC - Chat in small, slow rooms.
Weather - Local weather updates.
Small web pages - This is one of my ideas, where you could request small content from a server specifically designed for LoRa communication. I think you would impose some limits in the page size, like for example to be only 256 bytes maximum (likely imposed by the GW).

All of these things currently would be quite difficult to implement on the current LoRa WAN network - hence the need for something new. We want to push this further than just being an IoT device!

Protocol Considerations

I think there are quite a few considerations in this space:

Extensibility - We want to expand the number of protocols as people create them. We will need some kind of control to ensure people aren’t just adding stuff maliciously, but we can accept new protocols within reason.
Security - Ensure a malicious GW can’t inspect or inject data.
Integrity - Ensure the data arrived as expected.
Repeat attack - Make sure people don’t just repeat the last sent packet repeatedly to mess with our devices.

My thinking on this is that the most important protocol to setup is the one that connects devices to servers - if we have this, technically we have the possibility to do it all. Being able to retrieve data from any given remote server is already a useful function and would allow tonnes of hacking to be performed.

My initial ideas in this space are to send a request like follows:

0001                  <-------------------------------------> Encrypted to GW
0002                                                 <------> Encrypted to server
0003 [SRC][DEST][SIZE][PROTOCOL]][RAND][IPV4 + PORT + PAYLOAD][CHECK]
0004 [4B ][4B  ][2B  ][1B       ][2B  ][4B   + 2B   + 1B+    ][2B   ]

The idea is that SRC would be some ID for your device (that uniquely identifies you in your current area) and the destination DST being the device you want to speak to. The SIZE is the length of the rest of the packet (including the checksum - so that it knows how many more bytes to expect).

From here on in, the data (other than the checksum) is encrypted using the public key of the GW - to ensure only the GW can read the response. The PROTOCOL indicates the protocol being used in this packet (which in this case would be a IPv4 protocol). You the specify a random number RAND - this partially prevents repeat attacks somewhat and also allows you to know which request is being responded to.

Then we have the payload, which in this case is a 4 byte IPv4 address, followed by the 2 byte port and data to be sent to that server. The data payload to be sent to the server is encrypted with the public key for that server to ensure the GW does not tamper with it. The GW would then connect to a server via HTTPS and respond with the reply (within limits).

Finally we have a 2 byte checksum CHECK to ensure the data was not corrupted despite the forward error checking. Two bytes should be enough to be able to figure out if there is any hope of successfully decoding the packet.

As I said previously, this is just some initial ideas in this space and would need to be fleshed out further within the community itself.

Servers

Some initial ideas around different servers that would be interesting:

Key server - You would only really need to store a handful of public keys on the device itself that you trust, and fetch the others from a trusted key server. You could reference the server by IP or domain and get a return of the IP and public key.
Time server - Fetch the current time.
LoRa proxy server - Convert some remote content into a format that can be transmitted over LoRa communications.
IRC bridge server - Bridge your LoRa device to IRC. This would be slightly complicated as you would need to figure out exactly what messages the LoRa device did and didn’t get - meaning the server needs to carry state, etc.

Next Steps

It’s still going to be a while till the Pine64 LoRa devices become officially available, and until then I’m going to want to experiment. Even when I get the device, I want it to talk to another device! I purchased some small LoRa devices - the plan is to use one as a GW and one as a test device. As they are based on the ESP32, it will also be possible to connect them to the internet to act as a bridge.

I have some LiPo’s and JST connectors, so I should be able to solder these together when they arrive. There are also some 3D models out there for putting them in a nice enclosure and connecting the buttons, so in theory it should be pretty plug and play to start experimenting with them.