Re: Restarting MeshPoint – seeking advice on routing for crisis/disaster scenarios

Hello,

I wanted to follow up on my previous message. I did not see any replies, 
so I hope it is ok to share one concrete finding from recent testing in 
case it helps the discussion.

To move beyond purely theoretical arguments, I have been running large 
scale tests using meshnet lab
https://github.com/mwarning/meshnet-lab

The main reason for choosing it is that it allows replaying real world 
community network topologies, including Freifunk graphs, instead of 
relying on synthetic grids or ideal meshes. This makes it easier to 
observe behaviour under sparse, asymmetric, and imperfect conditions 
that are closer to what actually gets deployed.

One interesting observation so far is that results can vary 
significantly depending on how nodes are brought up and how control 
plane load interacts with the topology. In other words, the same 
protocol on the same topology can behave very differently depending on 
timing, churn, and scale effects, even when the underlying links are 
identical. This was not obvious to me before testing at this scale.

I am curious whether others here have used meshnet lab or similar 
namespace based emulation tools for BATMAN adv testing, and if so, 
whether your observations matched real deployments closely, or if there 
are known caveats when interpreting the results.

Any feedback or pointers would be appreciated.

Best regards,
Valent


------ Original Message ------
>From "Valent Turkovic" <[email protected]>
To [email protected]
Date 16.12.2025. 16:37:01
Subject Restarting MeshPoint – seeking advice on routing for 
crisis/disaster scenarios

>Hi everyone,
>
>My name is Valent Turkovic.
>
>Between 2015 and 2018 I ran the MeshPoint project – a simple, rugged Wi-Fi hotspot designed to work in very tough conditions.
>
>During the refugee crisis in Croatia we deployed these devices in camps and transit centers, providing internet connectivity for humanitarian organizations such as the Red Cross, UNICEF, IOM, Greenpeace, and many smaller NGOs. Through these deployments, more than 500,000 people were able to stay connected. The same system was also used in flood response and other emergency situations. The project received the “Best Humanitarian Tech of the Year” award at The Europas in 2016.
>
>Unfortunately, financial constraints forced me to pause the project after 2018. It was entirely self-funded, and the prolonged stress eventually led to long-term health issues.
>
>Over the years I stayed in contact with first responders and field teams from organizations such as WFP, UNICEF, the Red Cross, and various NGOs. The feedback has remained consistent: when disasters strike, whether earthquakes, floods, or large-scale displacement, teams still struggle to bring up reliable communications quickly. What they need most is a mesh network that works within minutes, not hours or days, and that continues operating on battery power when infrastructure is down.
>
>I am fully aware that in active conflict zones Wi-Fi can be jammed or restricted, for example due to drone countermeasures. However, there are many other scenarios where Wi-Fi mesh remains extremely valuable: evacuation centers, field hospitals, temporary shelters, flood-affected villages, and coordination points for responders. In these environments, fast, robust, and easy-to-deploy networking makes a very real difference for coordination, family contact, and medical or logistical data sharing.
>
>Because of this, I am now restarting the project as MeshPoint V2. The focus is updated hardware, improved battery life, and even simpler deployment, while keeping the original goal: crisis response and off-grid or underserved communities.
>
>In the original MeshPoint we used Babel. This was largely driven by practical constraints at the time: our deployment tooling was based on Nodewatcher, which was Babel-only. Technically, Babel served us very well. It converged fast, was reliable, and worked nicely for small to medium-sized networks.
>
>At the same time, I am well aware that many community networks and real-world mesh deployments successfully used batman-adv, often through Gluon or custom firmware builds. In larger, more dynamic, or highly mobile topologies typical for crisis scenarios, the layer-2 approach and seamless mobility properties of batman-adv are very attractive, especially when nodes are frequently moved, powered on and off, or replaced in the field.
>
>For MeshPoint V2 I am evaluating batman-adv and would appreciate insights on the following aspects, specifically in the context of crisis and emergency deployments:
>
>Behaviour at larger scale in real deployments
>In crisis scenarios networks often start small but can grow quickly as more nodes are deployed by different teams or organizations. We are interested in how batman-adv behaves when scaling to hundreds or more nodes in non-ideal, real-world conditions, without centralized planning and with limited ability for on-site tuning.
>
>Performance in sparse or highly mobile topologies
>Nodes in the field are frequently moved, turned off, replaced, or temporarily isolated. Vehicles, backpacks, and mobile command posts constantly change network topology. We are looking for practical experience with how well batman-adv handles frequent topology changes, intermittent links, and sparse node placement without requiring constant manual intervention.
>
>Suitability for battery-powered and intermittently connected nodes
>Many nodes run on battery for long periods and may sleep, reboot, or disappear entirely when power is lost. Low overhead, predictable behaviour, and fast recovery after reconnect are essential. We are particularly interested in any known trade-offs between routing performance, control traffic, and power consumption in such environments.
>
>If there is existing work, documented limitations, field experience, or design guidance relevant to these constraints, pointers would be greatly appreciated. The goal is to build a system that field teams can deploy and rely on under stress, without requiring deep networking expertise on site.
>
>Thank you for your time, and thank you to everyone who has contributed to making mesh networking viable outside of labs and into real-world, high-stakes situations.
>
>Best regards,
>Valent Turkovic
>https://www.meshpointone.com/
>
>Technical specifications of the original MeshPoint (for reference):
>https://www.meshpointone.com/technical-specifications/