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.
https://www.semtech.com/products/wireless-rf/lora-core/sx1303
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.
https://meshtastic.org/docs/overview/mesh-algo/#layer-3-managed-flooding-for-multi-hop-messaging
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.
https://airspayce.com/mikem/arduino/RadioHead/classRHMesh.html
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
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.
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
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.
Rapidly moving my meshtastic nodes over to meshcore 🤘🏿
Going very smoothly so far. Meshcore is notably very fast at message delivery and delivery confirmations back to the sender.
Thinking I'll leave my primary meshtastic infrastructure nodes up and build meshcore nodes to deploy next to them so as the network matures I can do head to head comparisons.
#lora #meshtastic #meshcore #lilygo #tdeck #wisblock #seeedstudio #esp32
Writing my first meshcore PR 🤘🏿
It's still a work-in progress, but having a lot of fun learning this code base!
https://github.com/ripplebiz/MeshCore/pull/96
#lora #meshcore #meshtastic #privacy #networking #esp32 #offgrid
Idea for this PR is to add a network bridge mode for repeaters.
This will let you take multiple LoRa radios, setup meshcore repeater firmware and listen on any number of channels or with different antenna setups and bridge the routing across those different channels with a shared Wifi link(the two dotted white boxes).
I've tested it for a few days and it's pretty amazing to see meshcore automatically finding bridged routes.
Wrote a little parser for meshcore packets tonight. It's still messy and a lot more to implement. But, it reads the container format so I'm happy for now.
I have meshcore packets flowing from multiple repeaters(on different frequencies) talking on wifi using udp broadcasts.
The repeaters automatically discover each other on the network and now I'm able to watch their chatter with a quick nodejs server.
#lora #meshcore #networking #radio #nodejs #container #incus
Working on a meshcore testbed.
I want to have several radios on the roof so I can develop in production
Cleaning up the wiring and checking antenna SWR with a NanoVNA.
Was curious if these cheap antennas were similar to their name brand look alikes. And no, no they are not comparable lol. Stick to the name brand I guess for this style of antennas, the cheaper ones are not worth it this time.
Trying out a safer route to the roof and sorting out how we'll deliver PoE to our radio mast projects.
Really hope the hacker space can get some proper folding stairs for attic access at some point.
Some results from a week of there being a meshcore repeater on Cougar mountain.
A lot of us can now hear around 80 radios throughout the Seattle / Tacoma region.
The public chat channel is extremely busy at various times throughout the day.
I've been able to DM people in Tacoma and connect to their chat servers all the way from Seattle.
Some routes are extremely stable, meanwhile others are more flaky. It's super exciting!
Testing routes from central Seattle down to Tacoma is shockingly stable.
Meshcore is working well enough in Seattle that now adoption is the largest issue to having a more robust LoRa mesh network.
So if you're in the PNW area and want to build a solid handheld LoRa radio to try out meshcore I've made a bill of materials for my go to portable build LoRa plans.
https://git.devhack.net/nullagent/lora-builds/src/branch/main/rak
#meshcore #seattle #pnw #tacoma #openhardware #arduino #lora #radio
I think the best thing about the home made nodes I've been using is that it's durable enough to carry almost daily. But flexible enough that I can do tons of experiments with external antennas and temporary installations in client mode or repeater.
The big one especially has crazy battery life and can run all week.
The other thing that rocks about this build is that it can be assembled with no soldering so its about as noob friendly as DIY hardware gets.
#MutualAidRequest I'd like to build a dozen of these LoRa radios to teach people and write a complete review of meshcore in Seattle.
It'd be nice to be able give away a few to people who can't afford to buy the parts themselves.
$45 / $600
So feel free to throw a few bucks at me so I can scale up my LoRa expirements.
Venmo / cashapp $nullagent
Good news, there's an unreal amount of interest in meshcore lately.
My community came together and group purchased 20 nodes and have rapidly been onboaring tons of new LoRa curious hackers.
It looks like I might have single handedly increased the user base of the Seattle meshcore user base by 10 - 20%.
#meshcore #pnw #seattle #lora #meshtastic #mesh #radio #maker
@nullagent So as someone just getting into the whole LoRa thing, do you have any reasons for #MeshCore vs #Meshtastic ?
I just picked up some devices last week so haven't had the opportunity to discover the differences in the options.
I wrote a hot take on all the issues with meshtastic. This is before meshcore came out. Since this time a ton of vulns have been found in meshtastic in many of the spots I expected. Several more serious vulns I call out still exist in #meshtastic and are completely unmittigated.
Should be a fun #defcon with #meshtastic this year 😉
Meshcore on the other hand gets a lot more right and I have not found similar numbers or types of issues with meshcore so far.
been playing with meshtastic for several months now. I acknowledge the issues with the routing but haven't hit scaling issues despite dozens of nodes in my area and some one-way bleed over from the city.
I peaked at meshcore and but am put off by the premium paid tier for features native to meshtastic.
I also find it interesting that most meshcore enthusiasm I come across is paired with overly aggressive antagonism for meshtastic.
Feels like it's fine to play with meshtastic. If it hits limits that meshcore can solve, people will switch over. But many urban meshtastic nets have been working just fine (Austin and the Bay, for example).
The reality is both projects have flawed approaches to the market.
Meshcore 100% has too many paid and premium features. Meanwhile meshtastic is basically doing a Microsoft style end run on OEM partnership fees.
Both are getting $$$ out of users in a not super open source way imo.
Meshtastic however has a completely fucked security model. Meanwhile meshcore has premium but so far, competent security model on their free tier.
Both's UX suck.
So choose your poison basically
Meshcore made some of the repeater firmware features also paid. They sell unlock codes for this feature on their store, see below.
I developed and PRd a similar feature but was unaware they were working on a similar paid feature. They seemed to ignore my PR so they could complete the paid version instead.
Which is totally their prerogative but imo not the greatest FOSS approach.
https://store.meshcore.co.uk/products/meshcore-hyperbridge-license
nullagent
Charlie
Ben
Ryan King