Building a drone swarm is hard enough when you are focusing on flight dynamics, coordination algorithms, and payload hardware. But as soon as multiple vehicles take to the air, water, or ground, communications quickly become another problem that needs to be solved.

Traditional setups often rely on a ground station acting as a central communications point, fixed network infrastructure, or centralized service discovery. That works well while every vehicle has a reliable path back to the infrastructure. Once terrain, distance, interference, or mobility breaks that path, however, otherwise healthy vehicles can become isolated from the rest of the system.

UglyMesh was created to address this problem by turning small, standard OpenWrt routers carried by each vehicle into a self-configuring mobile ad-hoc network (MANET).

Instead of depending on an Internet connection or central controller, UglyMesh builds a decentralized peer-to-peer data network between participating nodes. As vehicles move, disappear behind terrain, or spread over a large area, traffic can be forwarded through other nodes that remain within radio range.

Each node also creates its own deterministic network configuration, so there is no central DHCP server or address-management service that the entire network depends on.

One particularly useful UglyMesh feature is distributed DNS-based service discovery.

When a new node joins the MANET, its network and DNS namespace become discoverable by the rest of the mesh. Applications can therefore reach resources using names such as:

camera1.drone-03.manet

instead of hardcoding addresses or teaching application software how MANET routing works.

The goal is simple: applications should see an ordinary IP network. The messy details of radio links, moving nodes, route changes, addressing, and service discovery should remain underneath it.

You can install the UglyMesh package and let it configure a compatible OpenWrt router automatically, or continue reading if you are interested in how the network actually works.

What Do We Mean by “Mesh”?

The word mesh is overloaded. Different vendors and engineers use it to describe very different technologies, so it is useful to define what we mean first.

At the bottom of the UglyMesh stack is IEEE 802.11 mesh networking, originally standardized as 802.11s.

802.11s allows Wi-Fi stations to form a self-configuring, multi-hop Layer 2 network without requiring a traditional access point to sit at the center of the topology.

For ordinary consumer Wi-Fi, that may already be enough. Many mesh Wi-Fi products essentially use mesh links to extend an Ethernet-like network across several access points.

For mobile robots and drones, however, we want considerably more control over what happens above that radio layer.

Take a rest and play with mesh simulator

IPv6 First, but Not IPv6 Only

A quick word about addressing.

IPv6 sometimes gets avoided simply because IPv4 is more familiar, but IPv6 has several properties that make it particularly attractive for ad-hoc and zero-touch networking.

UglyMesh therefore uses IPv6 as the foundation of its MANET control plane. Mesh-facing interfaces can communicate using IPv6 link-local addressing, while every node deterministically derives its own IPv6 ULA prefix for the local assets connected to it.

For equipment that still requires IPv4, UglyMesh also derives a unique IPv4 LAN prefix from the node’s deterministic identity.

The result is that a new node can generate its own addressing without asking a central authority:

node identity → ULA prefix → IPv6 LAN \+ deterministic IPv4 LAN

There is no spreadsheet of addresses to maintain and no central DHCP server responsible for assigning networks to routers.

Combining Multiple Links with B.A.T.M.A.N. Advanced

Above the individual mesh links, UglyMesh uses B.A.T.M.A.N. Advanced (batman-adv).

Unlike a conventional IP routing daemon, batman-adv operates at Layer 2. From the perspective of software above it, the participating nodes behave roughly like ports on one distributed virtual Ethernet switch.

This is particularly useful because a vehicle does not necessarily have only one communications interface.

For example, an UglyMesh node might have:

• 5 GHz Wi-Fi for high-bandwidth, relatively short-range links;
• 2.4 GHz Wi-Fi for longer-range connectivity;
• Wi-Fi HaLow for lower-bandwidth, long-range connectivity;
• Ethernet between physically connected systems;
• or a tunnel transported over some other datalink.

batman-adv can combine compatible underlying interfaces into a common Layer 2 mesh and select paths according to the available links and their metrics. That means two nearby vehicles may have their best path over 5 GHz, while a more distant node may ultimately be reachable through 2.4 GHz, HaLow, an intermediate vehicle, or some combination of links.

The important abstraction is that software above batman-adv does not need to understand which physical radio currently carries a frame. Once batman-adv has assembled the participating links, it exposes a bat0 interface that behaves much like a large distributed Layer 2 switch.

We could stop there.

But UglyMesh deliberately does not.

Layer 3: Babel

A giant Layer 2 domain is convenient, but we want every UglyMesh node to own its own IP networks and explicitly route between them.

So on top of the batman-adv transport, UglyMesh runs the Babel routing protocol.

At first glance this may look redundant: batman-adv already determines how traffic crosses the mesh, so why introduce another routing protocol?

Because they solve two different problems.

batman-adv answers: “How do I get an Ethernet frame to another mesh node?”

Babel answers: “Which node owns the IP network I am trying to reach?”

Every UglyMesh router advertises the IPv6 and IPv4 prefixes belonging to its local assets. Babel distributes those prefixes through the MANET and installs the appropriate routes on participating nodes.

Babel is particularly well suited to this environment. It is a loop-avoiding distance-vector routing protocol based on distributed Bellman-Ford, with mechanisms for detecting neighbor reachability and link quality. Its feasibility mechanism draws on ideas pioneered by EIGRP, while its use of sequenced routes draws on DSDV.

The practical result is much more interesting than the protocol history: Babel is designed to behave well when topology changes.

If a vehicle disappears, a link fails, or another path becomes preferable, Babel updates the routing state and the affected nodes converge toward the new topology.

It can carry both IPv6 and IPv4 routes in the same routing domain, which fits UglyMesh particularly well.

Most importantly, Babel makes network partitioning survivable: if the Layer 2 mesh splits, each resulting island remains an independently functioning routed network rather than losing access to centralized DHCP, DNS, or gateway services. Assets within each partition can continue communicating directly and executing the swarm mission autonomously until connectivity between partitions is restored.

Internet Access Is Just Another Route

The same mechanism works for external connectivity.

Suppose one vehicle has Starlink, cellular, Ethernet, or another WAN connection.

That node can advertise a default route into Babel.

Other UglyMesh nodes can then use it as their path to the outside world without being explicitly configured to know where the Internet gateway is located.

If several nodes provide WAN connectivity, multiple default routes can be advertised and routing policy can determine which one is preferred.

From the perspective of an application running on a remote vehicle, Internet access simply appears or disappears as routing changes.

Distributed DNS: Finding Services Instead of Addresses

Finally, we add one more ingredient.

Humans — and applications — are much happier dealing with names than addresses.

Every UglyMesh node therefore maintains its own DNS namespace:

<node-id>.<configured-domain>

Clients connected to that node receive names underneath that namespace:

<client>.<node-id>.<configured-domain>

For example:

camera1.drone-03.manet

or:

autopilot.rover-07.manet

The interesting part is discovering where those DNS zones live without maintaining a central DNS server.

UglyMesh already learns about remote node prefixes through Babel, so it uses routing changes as its discovery mechanism.

A small service watches the kernel routing table using:

ip monitor route

When Babel installs a newly discovered peer route, UglyMesh queries the peer using reverse DNS. The PTR response identifies the peer’s UglyMesh DNS namespace.

UglyMesh can then install a conditional DNS forward for that namespace pointing toward the peer’s DNS server.

Conceptually:

Babel discovers peer → route appears → reverse DNS identifies peer → DNS forward is installed

If drone-01 later needs:

camera1.drone-03.manet

its local DNS resolver already knows that queries for the drone-03.manet zone should be forwarded to drone-03.

No central DNS database is required. And because discovery follows routing, when nodes appear or disappear, the DNS view can follow the network topology.

And as DNS updater is a simple script, you can extend it to support something application-level, like Zenoh Gossip links and run telemetry inside a swarm or a partition. The modern OpenWRT router is actually a good companion computer, but that is a topic for another article.

The Whole Stack

The resulting stack looks roughly like this:

Physical radios / Ethernet / tunnels

↓

802.11s and other Layer 2 transports

↓

batman-adv — distributed Layer 2 connectivity

↓

Babel — IPv4/IPv6 prefix routing

↓

UglyMesh DNS discovery — distributed naming

↓

Applications

Each layer has a deliberately narrow job. 802.11s establishes peer-to-peer Wi-Fi connectivity, batman-adv hides the complexity of multiple physical paths behind a common Layer 2 interface, Babel distributes the Layer 3 networks owned by each node, and UglyMesh adds deterministic addressing and decentralized DNS discovery. Applications simply get IP connectivity and human-readable service names.

That is ultimately the design goal of UglyMesh: joining a MANET should feel much closer to plugging a device into Ethernet than configuring a routing protocol. Focus on your swarm intelligence, and let datalink just be a pipe.

What to read if you are interested in MANET-like networking?

https://datatracker.ietf.org/doc/draft-ietf-manet-inet-gap-analysis/

https://www.nrl.navy.mil/Our-Work/Areas-of-Research/Information-Technology/NCS/OSPF-MANET/