[Babel-users] Restarting MeshPoint – seeking advice on routing for crisis/disaster scenarios

Sun Dec 21 10:05:04 GMT 2025

Hello Stuart,

Thanks for the follow up and for sharing more context on what you are 
doing.

You can already see most of our historical hardware specs online, so 
nothing secret there. Originally MeshPoint was based on Qualcomm 
platforms, mainly because at the time they were the most stable option 
with decent driver support for what we needed. Going forward, we are 
moving away from Qualcomm and toward MediaTek chipsets. The main reasons 
are better openness, saner upstream support, and fewer surprises when 
you start pushing devices outside of their “normal home router” use 
case.

For the next iteration, the plan is to use OpenWrt One hardware as a 
base platform, then remove some things we do not need and add quite a 
few things we do. The idea is not to reinvent everything, but to start 
from something well supported and predictable, and then harden it for 
emergency and field deployment. Reliability, fast provisioning, and 
predictable behavior under abuse matter more to me than raw throughput 
numbers.

On the routing side, just to be fully transparent, we used Babel back 
then for a very simple reason. It was what we already had integrated 
into the Nodewatcher stack. It worked reasonably well, and even if it 
had not, we realistically would not have had the time or manpower to 
rework the entire Nodewatcher backend, build system, and deployment 
tooling to switch to batman adv or anything else. In the field, being 
able to deploy a lot of routers quickly and reliably is more important 
than theoretical optimality.

Our networks were actually small in terms of node count. Typically five 
to ten nodes. Where things became extreme was mobility and client scale. 
We had thousands of mobile clients moving in and out of refugee centers 
and shelters all day. In that scenario, even with a small number of mesh 
nodes, the amount of churn at the edge was brutal. That exposed 
weaknesses very quickly. To be honest, I suspect batman adv would have 
struggled as well. The problem was not just routing, but the interaction 
between routing, client mobility, and limited hardware resources.

I would like to understand your setup better as well. What kind of 
environments are you deploying in, urban or rural, indoor or outdoor. 
What problems are you trying to solve first. What have you seen work 
reliably, and what failed in ways you did not expect. Also, are you 
optimizing more for client experience, backhaul stability, or ease of 
deployment by non technical people.

Those kinds of field lessons are usually more valuable than any lab 
result.

Best regards,
Valent

------ Original Message ------
>From "Stuart Trusty" <stuart.trusty at gmail.com>
To "Valent at MeshPoint" <valent at meshpointone.com>
Cc "Juliusz Chroboczek" <jch at irif.fr>; 
babel-users at alioth-lists.debian.net
Date 21.12.2025. 2:22:22
Subject Re: [Babel-users] Restarting MeshPoint – seeking advice on 
routing for crisis/disaster scenarios

>I'm sorry, I'm always afraid to reply here.  But I request to 
>understand the deficiencies of 802.11s, in favor of going with 
>Batman-adv.  In my mind babel over 802.11s would be an ideal config.  
>But Juliusz had seemed to have the opinion if we're going with 802.11s, 
>then leave Babel out of the picture.
>
>Would you mind sharing your hardware config for this? I've been working 
>on some emergency radios myself in an ipq-4019 chipset environment.  
>I've had it where anyone who just associates with the network 
>automatically gets WhatsApp services, using coovachilli on an openWRT 
>build. I can get them meshing on about a 1 to 2 km range.
>
>It would be nice to meet the market, in the absence left by Open-Mesh 
>being sold to Datto, with a similar open source framework for a public 
>mesh network system with mapping and payment gateway like they were 
>doing, based on a bulletproof emergency response radio build.
>
>Thank you for all you do,
>s.
>
>
>
>On Sun, Dec 21, 2025, 4:08 AM Valent at MeshPoint 
><valent at meshpointone.com> wrote:
>>Forgot to share the link - https://github.com/mwarning/meshnet-lab/
>>
>>
>>------ Original Message ------
>>From "Valent at MeshPoint" <valent at meshpointone.com>
>>To "Juliusz Chroboczek" <jch at irif.fr>
>>Cc babel-users at alioth-lists.debian.net
>>Date 20.12.2025. 23:35:01
>>Subject Re[2]: [Babel-users] Restarting MeshPoint – seeking advice on
>>routing for crisis/disaster scenarios
>>
>> >Hello Juliusz,
>> >
>> >Good to hear from you again, and thanks for the detailed reply.
>> >
>> >I agree on cellular changing the landscape a lot. In practice, in 
>>deployments I have seen and worked with, cellular is often overloaded, 
>>intentionally restricted, or simply unavailable exactly when ad hoc 
>>connectivity is needed most. That is why I still look at mesh as a 
>>complementary tool rather than a replacement for cellular.
>> >
>> >On jamming and mixed link types, I am fully aligned with your point. 
>>From a practical networking perspective, this is where layer 3 really 
>>shines. If links are abstracted properly, the routing protocol should 
>>not care whether the next hop is WiFi, Ethernet, or something more 
>>exotic. In the field, mixed setups often survive precisely because not 
>>everything fails at the same time.
>> >
>> >Regarding seamless mobility, thanks for pointing me to sroamd. I 
>>actually was not aware of it before your email. Conceptually, layer 3 
>>mobility makes a lot of sense to me, especially from an operational 
>>standpoint. In community and emergency networks I have worked with, 
>>large layer 2 domains tend to look good in small tests, but become 
>>fragile once you have real users, real traffic, and imperfect links.
>> >
>> >On the large scale behaviour question, I mean this in a very 
>>pragmatic way. Many community and emergency style networks are sparse, 
>>asymmetric, and power constrained. Nodes come and go, links flap, and 
>>you often end up with long chains rather than dense meshes. The 
>>challenge is keeping control plane traffic bounded and predictable so 
>>that routing does not end up consuming most of the airtime or CPU as 
>>you scale into the hundreds or thousands of nodes.
>> >
>> >To keep this grounded in reality, I have been testing in a lab setup 
>>that tries to resemble real community networks as closely as possible. 
>>I am using meshnet lab to spin up large topologies based on real 
>>Freifunk network graphs, rather than synthetic grids or random meshes. 
>>This allows comparing behaviour on the same realistic topologies and 
>>then sanity checking the results on actual hardware in smaller setups. 
>>Have you, or anyone else on the list, worked with meshnet lab before? 
>>I would be interested to hear how well it matched real world behaviour 
>>in your experience.
>> >
>> >I also wanted to ask one more general question about Babel itself, 
>>more about process than implementation details. When you first started 
>>developing Babel, was it driven mainly by theoretical reasoning at the 
>>beginning, with real world testing coming later, or were simulators, 
>>lab setups, or live networks involved from early on? Or was it always 
>>a mix of both. I am asking from an operator perspective, since in my 
>>experience many issues only show up once you put protocols into messy, 
>>real topologies.
>> >
>> >Best regards,
>> >Valent
>> >
>> >
>> >------ Original Message ------
>> >From "Juliusz Chroboczek" <jch at irif.fr>
>> >To "Valent Turkovic" <valent at meshpointone.com>
>> >Cc babel-users at alioth-lists.debian.net
>> >Date 18.12.2025. 1:04:43
>> >Subject Re: [Babel-users] Restarting MeshPoint – seeking advice on 
>>routing for crisis/disaster scenarios
>> >
>> >>Hello, Valent, good to hear from you again.
>> >>
>> >>>  Between 2015 and 2018 I ran the MeshPoint project – a simple, 
>>rugged
>> >>>  Wi-Fi hotspot designed to work in the toughest conditions.
>> >>
>> >>I remember :-)
>> >>
>> >>>  Unfortunately, financial issues forced me to pause the project 
>>after 2018
>> >>
>> >>In addition to the issues you mention, the big change since the 
>>early
>> >>2000s is the wide availability of cheap cellular connectivity.  
>>Hence, the
>> >>demand for mesh networks has changed quite a bit.
>> >>
>> >>>  I know that in active conflict zones Wi-Fi can be jammed
>> >>
>> >>The nice thing about having a layer 3 routing protocol is that you 
>>can
>> >>combine technologies: Babel is designed to handle a network that has 
>>both
>> >>wired and wireless links, and that uses multiple wireless 
>>technologies at
>> >>the same time (WiFi at various frequencies, UWB, infrared laser, 
>>etc.).
>> >>In such a network, Babel should be able to find a path consisting of
>> >>whichever links are not jammed at a given time.
>> >>
>> >>Of course, this assumes that the opponent is not able to jam all 
>>links
>> >>simultaneously.
>> >>
>> >>>  - BATMAN-adv-style seamless mobility
>> >>
>> >>I started working on sroamd[1], which implements seamless mobility 
>>at
>> >>layer 3, but then Covid happened, and I got interested in
>> >>videoconferencing.  I guess we could revive it if there's interest.
>> >>
>> >>[1]: https://github.com/jech/sroamd
>> >>
>> >>>  - Better large-scale behaviour for hundreds-to-thousands of nodes 
>>in
>> >>>    sparse or battery-constrained setups
>> >>
>> >>Could you please clarify?
>> >>
>> >>-- Juliusz
>>
>>_______________________________________________
>>Babel-users mailing list
>>Babel-users at alioth-lists.debian.net
>>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/babel-users/attachments/20251221/a9670b1f/attachment-0001.htm>