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/
