fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

10K
active users

Fuck meshtastic, long live lora.

This is a subtoot and should probably be a blog post. But basically some techbros are re-inventing mesh radios (badly).

Low cost, developer friendly mesh radios have kinda been going in circles for decades. I've personally been watching this space for 20yrs & it's not progressing.

So in many ways I guess I shouldn't be surprised to review yet another cheap mesh radio project and realize, "dude this just plain sucks and isn't improving at all, oh and the community is kinda awful".

First the good.

The core tech of LoRa remains amazing.

The hardware has gotten DIRT CHEAP.

The idea that anyone can go buy a $10 circuit board, 3d print a case and have a radio that can talk privately to satellites or across town IS ground breaking!

The biggest break through lately is that the hardware IS good AND cheap at long last!

Some LoRa history.

First off a company called Semtech developed & patented the silicon to make LoRa radios back in 2014.

In the EU a corporate outfit, "The Things Network"(TTN), was the earliest adopter and created an open specification for a centralized LoRa network(LoRaWAN).

TTN feels a lot like a cellular network and isn't a mesh network. Suffers from the typical coporate conflicts but has a nice enough free tier and a fair bit of open source code behind it.

patents.google.com/patent/US20

patents.google.comUS20160094269A1 - Wireless communication method - Google Patents A wireless communication method between a plurality of end-points by a plurality of base stations, based on frames that have a CSS-modulated preamble followed by a data body modulated at a narrower bandwidth, either by CSS or by a UNB modulation. The system permit to avoid or mitigate collision between packets and to increase the network capacity, maintaining the simplicity of detection inherent of CSS modulation.

So the problems with the TTN is basically is a SaaS capitalist play. You buy a gateway, connect it to TTN then TTN sells access back to you and your community for your own hardware 🥴

They do give a free tier and act open but your hardware and data is THEIR profit center. Lame.

It's got a lot of network coverage in the EU, but never really took off in the US.

In practice the network in the EU is viable, the one in the US isn't.

thethingsnetwork.org/map

The Things NetworkThe Things NetworkWe are building a global open free crowdsourced long range low battery IoT data network.

In the end TTN/LoRaWAN make a ton of sense for corporate customers or people selling IoT gear to corporate buyers.

It works well where you have coverage. It's well designed and there's tons of quality hardware, though much of it not fully open.

LoRaWAN's claim to fame is that device data connections can be as cheap as $1/year and some of the gear like soil sensors can last for 10yrs on a single coincell battery.

But TTN's LoRaWAN was always plagued with limited adoption in the US especially.

Enter the crypto bros....

A crypto startup used the basic business plan from TTN, multiplied the cost to deploy a device by like 5-10x and put an allbeit secure, but confusing AF layer of cryptocurrency around the whole thing and promised to share profits with routers err I mean "miners"

Naturally they hit the adoption jackpot but cost structure is f'd so its a non-starter🙄

explorer.helium.com/

Helium ExplorerHelium ExplorerHelium Explorer is an open source network explorer for the Helium network

Me, watching this chaos from like 2017 to 2020 things seemed hopeful. Like... I've been playing with mesh radios since 2006. So this felt like a lot of progress and a TON of potential.

I've just been dying to see someone take the same gear and use it in a mesh instead.

Enter meshtastic . . .

I first found #Meshtastic in 2020. It was early, had aloha broadcast (aka floodfill routing) as the core routing protocol.

I thought it was a cute LoRa mesh demo but it was super buggy and the hardware wasn't good then.

Back to that flood fill tho... friends, THIS IS NOT HOW TO MESH. I've been playing with wifi, bluetooth, zigbee meshes since 2006. Friends, you can't scale flood fill.

So I made a note to check in on meshtastic when they did real routing.

2024 rolls around, the cryptobro hype has died off, the corporate hold is doing its thing on TTN and well... all other types of public comms are getting spied on like no ones business.

Time to go catch up on the LoRa mesh going ons.

I noticed meshtastic was close to FINALLY merging their public/private key system in the fall last year and decided it finally hit my first min. bar for re-review.

Mind you they were kinda making misleading encryption claims up to this point.

I found it pretty quick and easy to throw together nodes and repeaters.

Even got some permanent installs in some high places. Built piles of nodes for frens.

Which my friends went wild and threw up more nodes, built chat bots and mesh bots.

And it's chattering away.

Meshtastic postives:

- code works
- there's DM level pub/priv crypto
- community is slinging a lot of code
- there's docs now
- it's popular so you will see some nodes in many places including the US.

So from my previous LoRa experiments with TTN in the same area, Seattle, I was familair with the propagation properies of LoRa.

LoRa is great at line of sight, If you can see it, they can probably hear you.

I could -easily- with TTN make connections to my home router along the Burke Gillman trail in U District and all the way up to any visible part of Capital Hill from the TTN gateway in U District.

Meshtastic performs similarly rangewise, but datarate is almost non-existant vs TTN.

Part of why LoRaWAN (like TTN & Helium) have better RF performance than meshtastic (and other lowcost LoRa meshes) is that LoRaWAN makes use of actual gateway chips which enable them to listen to 8 channels at once while meshtastic only uses one static channel at a time.

LoRaWAN gateways can then use intelligent scheduling modes (they call it device classes) to make super efficient use of the 8 channels and possible hop around noise channels too.

semtech.com/products/wireless-

I personally -really- want to be able to use LoRaWAN gateways as part of a mesh so it can serve 8x the users and frequency hop around noise.

I've also been pretty up to date with mesh and lora stuff so I just feel its a lil lame none of the meshes use gateways.

It's not the worse problem and in the case of meshtastic having more channels will only make their problems worse.

Floodfill can't scale.

That's the core issue with meshtastic.

All the nodes repeat what they hear, kinda like "the people's mic" at a protest. This strategy is great if we all want to hear ONE person's speech across a whole crowd.

But try the people's mic with 10's hundreds or thousands of different bi-directional conversations and things get messy.

We're all shouting to hear and expecting the person next to us to repeat. But all they hear is noise and very rarely a few words here & there

So doing what LoRaWAN does(optionally using better router hardware), could help maybe 8x the ability of this chaotic shouting fest but it'd never improve things.

The ONLY routing approach meshtastic has seriously considered is this broadcast system. They keep futzzing around with how long people pause before shouting but they don't introduce anything more than this.

This is why the datarate sucks. Messages collisions. "router_late" etc won't fix this.

meshtastic.org/docs/overview/m

meshtastic.orgMesh Broadcast Algorithm | MeshtasticDiscover the Meshtastic Mesh Broadcast Algorithm: a simple, yet effective routing protocol designed for off-grid communication using LoRa technology.

Aside from playing with timers, the meshtastic core team encourages people to use very low hop counts.

Now IMO "hop limit" shouldn't even be a thing a user needs to know about or set 🚨

The system, must use a routing algo that can adapt.

If I'm in Tacoma and the mesh has a route to nodes in Seattle and I want to chat with my friend in Seattle idgaf how many hops it takes.

We -actually- have a mesh that far already.

Meshtastic refuses to hop far enough.

Worse, its a 3bit hop limit!

In practice I've been able to make meshtastic connections all over Seattle, gotten line of sight links from North Gate to West Seattle and everything in between.

With meshtastic's mesh I can even make a ton of those long shots without line of sight by hoping over and around the hills and buildings.

But its clear, I -frequently- run out of hops NOT network!

The broadcast algo eats up all the hops in the core downtown and rarely makes it out the otherside with low hop limit or even with the max

Now to the kicker with meshtastic.

The project is run in the usual tech-bro seeming ways and are rude ass fuck to new comers with less experience / platform than I who've made the -same- observations about floodfill's limits.

The core team is dying on the hill of the shitiest routing algo possible because they I guess don't want to read anything about routing research.

Bruh... I worked in a networking research lab in the early 2000's, almost every excuse this team has made is bullshit.

So when I have spent time and money learning an open source project, encouraged friends to also go learn and spend money.... and then the core team is rude as fuck to them when they have polite and honest feedback.... yea fuck that noise.

Meshtastic is gonna fail on the same dumb hill as many tech-bro led projects, fighting their community over dumbshit.

It's a perfectly fine toy of a project to learn LoRa but please know better is possible and we don't have to deal with these assholes.

Normally I'd recommend forking once a project is getting well known for bad leadership.... but IMO meshtastic isn't worth forking.

It needs so much work to be good, like it -might- be an ok starting code base but so much needs changing so it may be easier to start the fuck over.

I really need to refute their core teams constant insistance that routing algos other than floodfill are too complex to implement and are too heavy weight.

I point to the project RadioHead... which now a decade ago implemented a better LoRa mesh routing algo a DECADE before meshtastic.

Someone please inform the meshtastic crew that for literally 10-20yrs makers have been making more complex mesh algos run on low end processors ffs.

airspayce.com/mikem/arduino/Ra

airspayce.comRadioHead: RHMesh Class Reference

Now back to the positive.

All is not lost, meshtastic is the biggest LoRa mesh and it sucks BUT its not the only one and the same mobile nodes and repeaters you'd use for meshtastic can be used on any other LoRa mesh.

I think the most exciting meshtastic alternative is Reticulum. It exists already, has a routing and security approach for the real world but might be too opinionated in some ways for some users. It's a bit of a grander vision

reticulum.network/manual/whati

reticulum.networkWhat is Reticulum? - Reticulum Network Stack 0.9.1 beta documentation

Lately a youtuber whose been doing a lot of videos about meshtastic just announced he's launching his own meshtastic replacement targeting the same hardware.

I watched a lot of Andy Kirby's videos and he seems to have an eye for the same sorts of problems I've mentioned with meshtastic so I'm very curious to see how his project goes.

They haven't released their code yet so we'll have to wait and see.

youtube.com/watch?v=fNWf0Mh2fJ

I wish I had less complaints for meshtastic, comments reminded me of others.

0. Has routing table, doesn't use it
1. Static MAC is used and expected over lora
2. The static MAC is the same or similar to the device ble/wifi mac
3. Location data leaks in unexpected ways
4. MQTT arch is messy af
5. Their simulator is buggy & bad. But is how they make technical decisions
6. Security is an after thought (and finally ok-ish)
7. History of non-sane defaults + many users are slow or never upgrade = bad

8. User identity is directly tied to radio MAC, not public key so users identity can easily be spoofed.
9. Bc of #8 users are used to accepting changed user public allowing full identity theft.
10. No device level security, a captured/stolen device can be trivially used to receive or send messages and may leak message history, location history or implied location history

11. Limited protocol privacy behavior by default responds to certain protocol events unless in specific mode (client_hidden). But they still leak data sometimes, possibly bugs???
12. Lack of strategy on #11 means once you know a node's ID you can track it trivially both via MQTT or physically or even via BLE or Wifi.

And if you've seen my defcon talk.... you probably can figure out what I can do with #1, #2 #11 and #12 🤔

#13 No conversation privacy in default scalable configuration. Anyone can see your to/from fields and bc #1 it's great metadata.

Need to verify how bad #13 is, I think you can mitigate but most people use a public channel. The header I think its technically encrypted BUT with a known public key so everyone can see whose talking to whom. I think you can get encrypted headers on the public channel but docs aren't clear and probably limits your hops.

Finally I suspect that IF meshtastic ever does fix their routing algo they will suffer from MITM exploits due to issues around #1, #6, #8, and #9.

Bc when you have MAC as the root of trust I can respond to your MAC and poison the routing table.

There might even by a solid security downgrade attack here too bc they have backwards compatibility for insecure DMs. So once I clone your MAC I can also downgrade security and ppl are trained to accept downgrades.

MeshCore has released their code today.

I've read most of the code and this is fairly early, limited docs, no mobile app and limited hardware testing.

That being said the over the air protocol+routing looks excellent. The code is well designed and fairly slim. The security posture is good and designed in from the start.

They get so much right in so little code. I even think I could make this messtastic compatible faster than they can improve.

github.com/ripplebiz/MeshCore

A new lightweight, hybrid routing mesh protocol for packet radios - ripplebiz/MeshCore
GitHubGitHub - ripplebiz/MeshCore: A new lightweight, hybrid routing mesh protocol for packet radiosA new lightweight, hybrid routing mesh protocol for packet radios - ripplebiz/MeshCore