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/
