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/
