DEV Community: joshbullock90

ATAK over a mesh network

joshbullock90 — Wed, 01 Mar 2023 15:43:38 +0000

What is ATAK?

ATAK (Android Team Awareness Kit) is the civilian release of military software known as TAK (Tactical Assault Kit). It runs mainly as a server, and as an app on mobile devices. At its core, it displays a map, the operator's GPS location and name, the locations and names of any team members/friends on the same network, and allows sending, receiving, and displaying of CoT's (Cursor-on-Target), which can be thought of as POI's (Points of Interest). This functionality is critical for nation-state military units (it allows units to perform two of the three pillars of small unit warfare: Shoot, Move, Communicate), unconventional fighters (volunteers and private military contractors can use it in the same way), and civilians (land navigation for backpacking, search and rescue, etc).

Limitations of ATAK

ATAK requires a server, which must be always accessible over a network connection. As one might imagine, militaries have various methods of connectivity, and more networks with more acronyms than anybody would need to remember. The servers they use are hosted and run by their respective governments (from this point onward I will refer only to the US government), and are tightly controlled. How then can a civilian use ATAK? A team of developers have created FreeTAK, a Python-based ATAK server with near-feature-parity. Civilians can use a public instance, or install their own. The FreeTAK server allows creating users, assigning roles, authentication with ATAK clients, and has other useful features including a webmap.

Can you hear me now?

But what about some of the use cases where a civilian might want to use ATAK, such as wilderness backpacking? Sure, maps can be cached and GPS doesn't require cell service to function, so it can still be about as useful as Google Maps without internet, but how can members of a hiking group see ecah other, send messages, and point out landmarks if they get separated without cell service?

Enter mesh networking

Mesh networking! As I touched on in my previous article about drones in combat, mesh networking is an emerging technology that we could leverage to solve this problem. Assume each member in a hiking group had a mesh node on their backpack, and periodically dropped a mesh node along their trail (discreetly of course, Leave No Trace). Or, if this hiking area is popular, hikers could donate and leave nodes (with permission) all around the area, creating a mesh network that spans the entirety. This would remove the problem of having no network connectivity, provided hikers bring their own personal nodes to interface with the mesh network. But how does this help us with ATAK?

The open-source community

Chances are, if we've had an idea, somebody else has too. And chances are, if our idea concerns an application of open-source technology, somebody else has already created a project for it on Github. In our case, this is exactly the situation. Mesh networking can be used with ATAK thanks to the efforts of Paul, with his project atak-forwarder. This project is an Android app that installs as a plugin for ATAK, which allows it to use mesh networking for core functionality (specifically, it interfaces with the Meshtastic project). The process is fairly simple: Install the Meshtastic app, pair it with a mesh device flashed with Meshtastic firmware, install the ATAK Forwarder app, and then configure a few settings within ATAK to get it all working. It can send member location (name, GPS coordinates) displayed as a marker on the map, send messages, and even share CoT's/POI's. No internet access required!

Mesh networking in combat?

Using Meshtastic over ATAK can be useful not just for civilians, but for military also. As we've seen in the Russo-Ukrainian war, units have been located by their signals (WiFi, cellular, Bluetooth). EMCON (EMissions CONtrol) is becoming increasingly crucial. Can mesh networking help us here? Yes! In our scenario above, the only signals are periodic transmissions from the mesh nodes, which generally use the same bands as the Internet of Things (hiding in plain sight). These nodes are also mostly not in the same position as soldiers (aside from the ones they carry on them). And as the nodes are set-and-forget, with proper handling (fingerprints, etc) they are non-attributable. What if a small military unit, in a combat zone with SIGINT (SIGnals INTelligence) threats and/or without cell service, wanted to still communicate with their team members using ATAK? They could deploy enough mesh nodes to cover their AO (Area of Operations), and be able to effectively Shoot, Move, and Communicate. By the way, depending on placement and antenna tuning, these nodes have been documented as successfully communicating over the range of a few miles! Not many nodes would be needed, their chances of being found are very low, and if they are found, they are non-attributable, so there is no risk to the team. And while the common method of connecting a smart device to a Meshtastic node is via Bluetooth, a USB cable can also be used, so there would be no signals for an adversary to locate.

Emerging tech, future possibilities

Once again referring back to my previous article on drones in a combat environment, we can now see how a drone could leverage mesh networking to the advantage of the team. If a drone is created that only communicates over LoRa (Longrange Radio) and can send and receive information over the mesh network, the advantages will be substantial. And it could be displayed, and controlled, within ATAK as well. To my knowledge nobody has created one yet, but it's only a matter of time. Necessity is the mother of invention, after all.

Drones in combat applications

joshbullock90 — Mon, 27 Feb 2023 17:49:59 +0000

Drones growing in popularity on the battlefield

If there's one new thing the war in Ukraine has showed us, it's the widespread tactical application of consumer drones. Employed by both sides, they have been used for everything from recon to kinetics. They gather intel with their gimbaled eyes, drop grenades with servos, and occasionally get shot down. The war in Ukraine marks a new era of warfare: any soldier or civilian can pay a few hundred dollars on Amazon and join the fight in a way that, as of today, is very difficult to prevent or combat.

Current weakness of drones on the battlefield

There is one huge drawback to using drones in combat, however. EMCON. A military shorthand for EMission CONtrol, this concept concerns the defensive side of SIGINT (SIGnals INTelligence); finding, decoding, reading, and locating electromagnetic signals. With drones, the operator is nearly always standing somewhere closeby to the drone, with a controller and/or smartphone, controlling it using electromagnetic signals, generally on the WiFi bands. This means that the operator's location can be triangulated, and then hit with artillery.

Other drawbacks of WiFi

The other issue with controlling drones with WiFi is that, at least on the models we have seen in use the most, flight plans can't be stored on the drone itself. This is the case for the most common consumer drones, such as the DJI Mini line. Which means that in order to use the drone (or to use any drone with realtime video feed), the operator has to maintain that WiFi connection. This means that a simple jammer can neutralize the drone altogether (and when most drones Return-To-Home upon signal loss, it also means that the operator's location will be revealed by the returning drone!).

An evolving technology

Drone technology is still relatively young. DJI itself hasn't even been a contender for a decade. There is still plenty of room for innovation, and the war in Ukraine has revealed areas that need it. This is why drones are still considered an "emerging technology." Could we find a viable solution to the issue we've laid out, in another emerging technology?

Mesh networking: Another emerging technology

The answer, I believe, is yes! Another emerging technology is mesh networking. Just like drones, any consumer can purchase equipment to stand up their own mesh network with just a few hundred dollars, from websites such as Amazon, Etsy, and Adafruit. In another article I will go over some combat applications of mesh networking, but for now we will just look at how it could be employed to solve our problem with WiFi.

Feasible ideas not yet materialized

Almost a year after the start of the war, we have seen custom drone companies pop up and grow in Ukraine, and also in Russia and beyond. Everybody has seen the serious advantage to be had on the battlefield by drones, and have been working to leverage them. But there is one thing that I have not yet seen. I have not seen anybody design and bring to life a drone that communicates on the LoRa bands. These are the RF (Radio Frequency) ranges designated for LoRa (LOngrange RAdio) frequencies. This is the driving technology behind mesh networking (mesh network can also refer to networks using other bands but LoRa is becoming the backbone), and is the driving technology used for the Internet of Things. What would be some benefits of designing a drone that can talk on these bands?

The Internet of Drones

I will break down two scopes of these benefits: local and global. For local we will look at a scenario without Internet access, and for global we will look at a scenario with Internet access.

Redundant, Non-Attributable, Discreet

For our local scenario, let's assume we have a brand-new drone with LoRa capabilities. Let's also assume we have a backpack full of LoRa mesh nodes. These nodes would be powered by batteries, and maybe small solar panels, so we don't have to worry about them too much. Set and Forget. Now if we start hiding these nodes like little Easter eggs around the battlefield before it becomes an active battlefield, we can deploy our own mesh network. What could we do then with a drone that can communicate with this network?

Dialing into the World Wide Web

For our global scenario, let's build off of the local one. There is a type of mesh node, defined by its function, called a gateway. This is a node that is close enough to other mesh nodes to be able to communicate with them (and therefore be part of the mesh network), but is also in a location with some sort of Internet access, so it can be plugged in via Ethernet, or connected via WiFi, etc. Information, commands, etc can be piped to and from the mesh network via this mesh gateway node using protocols such as MQTT (Message Queue Telemetry Transport). What sort of functionality could we gain by being able to communicate with our drone over the Internet?

Hanging From a Cliff

In future articles I will delve into the practical applications of future drone warfare in our local and global scenarios. You've likely had a few ideas yourself at this point. But for now, we can see that: the war in Ukraine is revealing new needs and new opportunities, and emerging technologies may be able to fulfill those. And when combat-applicable technologies don't require nation-state funding, but can be purchased by anybody with a little extra cash, the face of war will change forever.

Towards mesh networking with the Pinephone

joshbullock90 — Sat, 25 Feb 2023 22:43:48 +0000

Where we began

I bought my first Pinephone in 2020. The thought of having a full GNU/Linux computer in my pocket was everything I never knew I wanted. I bought another Pinephone a few months later (the 3G variant with a fixed circuit). Then I got a Pinephone Pro last year. I actively hunted down applications that worked on them, at least decently, and for a while I almost ran the Mobian wiki with how much content I was adding to it. Despite the hiccups along the way it's been a fun ride.

But one accessory that really caught my eye was the LoRa backplate.

LoRa on the Pinephone

The concept of being able to communicate without Internet depply interested me, for a few reasons. One, when you're out backpacking in the middle of nowhere and have no cell service, the ability to still communicate with your friends if you get separated is pretty important. Two, the ability to attend events of interest such as protests, or public venues in the middle of a "lockdown", without being incriminated while not breaking any laws, is equally as important.

Experiments collecting dust

Without giving all the backstory, development in the Pine ecosystem hit a sharp decline. Notably, the backplate. By the time I got a couple of them, all that had been done with them by the community was that an alpha-state driver had been written by JF002, and the initial reverse engineering had been performed and documented by Lup Yuen Lee (to be clear these were no small feats!). But those projects sat untouched and unimproved. Nobody had ironed out the bugs, or added what would be considered full-featured functionality, or written a GTK4 communication app. It seemed like the dream of pocket-Linux mesh communication might be dead.

What I did

So I started reading through the code of the driver and test program written by JF002. I reached out and asked a few questions. And the first thing I found was that the backplate wasn't even seen by the Pinephone Pro! I knew nothing about SPI or anything embedded, really, but was determined that this idea shouldn't die. So I started researching the different busses and how it all worked together. And given that the code written by JF002 was all in C++, I decided to start learning that (and C). My main programming abilities up til now have been almost exclusively Bash and its tools. But I dove in and started learning, and as I learned new concepts, re-read the various .cpp files in the project, until I could figure out what was happening.

Then I started writing a bullet-point list of what needed to be done to make the app work as more than just a proof-of-concept test. Things like handling messages longer than 27 characters (a limitation of the SPI bus), encryption, reliable transport, among other things. A lot of serious functionality for a guy who barely just started learning C++! But I picked the first one in line, which was handling longer messages. If I tried to send a message longer than 27 characters, nothing would happen.

Eventually I stumbled my way through adding code (mostly loops) to iterate through the msgStr vector, split it into <27 byte chunks, and store it in its own vector. In order to know how many chunks would need to be received and concatenated however, I would need to add some sort of EOT for the receiving device to see. So I added 'EOT' as the last characters before '\0' (original, no?). Then as I was testing, I noticed the program would periodically dump other messages from devices around me transmitting on the same frequency, and as interesting as it is to see whose smart meter isn't happy, it wasn't what I wanted to deal with when talking to another Pinephone. So I prepended the message chunks with 'EPP' (Encrypted Pinephone Packet). So now I had my messages split into chunks with a "preamble" and an EOT. For the receiver, then, it would need to filter out any transmissions that didn't start with 'EPP', and then store them until it received one with an 'EOT' at the end. Can I just say that if you don't use arrays or vectors or indices all the time, it's really easy to be off by one?

So now the program can split messages into chunks small enough for the SPI to handle, and can concatenate received messages. I removed the hex debug statements so that all one would see is the message sent on the sender device, and the message received on the receiver device. It works! Four days of learning C++ and I was able to tackle Baby's First Project. Not too bad, but there is much work ahead of me.

What remains to be done

Currently there is the issue of some sent transmissions simply not being seen by the receiver device at all. I will have to troubleshoot this to see whether it's the sender garbling the data somehow (Baby's First Project, remember?), or the SX1262 being overloaded (timeouts?), or even frequency drift (does the radio, if set to 915000000, always transmit at 915 MHz? Or does it drift to 914.75 MHz?). Then there is the issue of encryption. That's going to be fun. But, in my experience you only truly learn by doing, so doing is what I'll do.

Check out the code at https://codeberg.org/joshbullock/pinedio-lora-driver