You want a resilient wireless system that just works — and the OpenWRT mesh network setup can give you that control without cloud locks.

We’ll walk you through a practical, end-to-end journey that explains which packages to install, how to assign roles for gateway and satellites, and when to use the web interface versus SSH.

Along the way we cover device requirements, DHCP and protocol defaults, radio tips for common chipsets, and a clear path to verify links with tools like iw and batctl.

Short on flash or RAM? We show lightweight approaches and when to build a custom image so you don’t lose the web interface mid-change.

Key Takeaways

• We explain roles: primary router handles DHCP/DNS/firewall; secondaries join as clients or static nodes.
• Install mesh-capable packages and prefer WPA3-SAE with a fixed channel per band for stable roaming.
• Use the web interface when possible — switch to SSH/ImageBuilder on low-storage devices.
• Introduce batman-adv for a solid backhaul and bridge bat0 correctly to LAN.
• Validate links with iw and batctl and apply chipset-specific tweaks for best radio performance.

What you’ll build and when to use an OpenWRT wireless mesh

I’ll show a small multi-node 802.11s mesh where a single gateway router links to the connected internet and satellites act as access points over a shared wireless backhaul.

We’ll use batman-adv as the Layer 2 protocol to route frames across multiple devices. That gives smarter path choices than older routing like OLSR because batman measures real throughput and adapts.

When should you use this approach? If you have two or more routers or client-dense areas, 802.11s plus batman-adv scales well. If you only have one gateway and one repeater, WDS can be simpler and sometimes faster.

• Prefer Ethernet or fiber backhaul when possible—use dumb APs and 802.11r for best performance.
• Reserve wireless backhaul when wiring isn’t feasible; keep SSIDs and interfaces consistent so clients roam smoothly.
• We’ll stick to web visibility via LuCI for most tasks and use CLI where precision is needed.

Hardware and firmware prerequisites for 802.11s mesh

Before you flash any firmware, let’s confirm each device can handle continuous backhaul and the services you plan to run.

Minimum specs: I recommend a router with at least 8 MB flash and 64 MB RAM to host LuCI, mesh-capable packages, and logs without running out of space mid-change. Secondary devices can survive on 4 MB/32 MB, but that usually means SSH-only work and a custom image.

Radio and driver notes

Check radio chipsets early. ath10k commonly needs non-ct firmware and kmod replacement for reliable 802.11s. ath9k benefits from nohwcrypt=1 for stability. mt76 radios generally work without special flags.

Practical checks before install

• Inventory radios so you can dedicate a 5 ghz radio to backhaul and keep 2.4 ghz for clients.
• Verify ports and interface names—some devices require repurposing WAN as LAN when bridging batman-style links.
• If flash is tight, use ImageBuilder to create a custom image with wpad-mesh-wolfssl or wpad-mesh-openssl and strip nonessential packages.

Run a quick health check for failing flash, heat, or old firmware before you begin. Plan addressing and management access so you never lose login while moving radios and bridges to 802.11s.

Installing mesh-capable packages and preparing software

Let’s get the right packages and tools installed so radios can form an 802.11s mesh and batman-adv can route traffic.

In the web interface, go to System > Software. Use the Update lists tab, remove the default wpad-basic or wpad-mini, then install wpad-mesh-wolfssl (or -openssl). Add kmod-batman-adv and luci-proto-batman-adv if you want GUI controls.

Prefer the web path for quick installs. The Software tab shows available packages and options with one-click installs. Save changes and confirm versions before you move to radio configuration.

SSH commands for precision

Over ssh, I use opkg for exact control:

• opkg update
• opkg remove wpad-basic-*
• opkg install wpad-mesh-wolfssl kmod-batman-adv batctl-full

On ath10k-ct devices remove -ct firmware/kmod and install the non-ct equivalents. After kmod-batman-adv installs, reboot so the kernel module loads.

When storage is tight: build a custom image

Use ImageBuilder to craft firmware with just what you need. Example:

make image PROFILE=… PACKAGES=”wpad-mesh-wolfssl kmod-batman-adv -wpad-basic -ppp -iptables”

Finally, confirm the installed package list and reboot nodes in a controlled order. That keeps each device consistent and avoids surprises when you enable the 802.11s mesh interfaces.

OpenWRT mesh network setup in LuCI (802.11s on the radio)

Use LuCI’s Wireless page to make a dedicated 802.11s interface and preserve LAN access between nodes. I’ll keep this short—follow each step and save often.

Create the 802.11s interface

Go to Network > Wireless, add a new interface on the correct radio, and set Mode to 802.11s. Choose a Mesh ID and set the Network to lan. This keeps inter-node traffic inside your LAN zone and avoids firewall blocks.

Wireless security and radio settings

Under Wireless Security pick WPA3-SAE and use one strong key across all radios. In Device Configuration pick a fixed channel per band and set the Country Code. Do not leave the backhaul on auto—that can trigger DFS or drops.

Client AP and final checks

Add a separate Access Point interface on the same device in Access Point mode. Use a consistent SSID on every device and secure it with WPA2-PSK or WPA3 if clients support it.

• Enable the wireless network if it shows disabled.
• Confirm the interface attaches to the correct device.
• Keep AP and backhaul channels distinct unless hardware supports shared operation well.

Adding batman-adv to route the mesh backhaul

I like to get routing right before moving on — batman-adv makes the backhaul predictable and keeps client access simple.

Create the bat0 device and choose the protocol

In LuCI go to Network > Interfaces and add a Batman Device named bat0. Pick BATMAN_V in Mesh Routing so every router uses the same protocol. Enable Avoid Bridge Loops to prevent Layer‑2 storms if you have multiple paths.

Bind radio to a batman interface

Create a Batman Interface called batmesh and set its Batman Device to bat0. Then, in Wireless assign the 802.11s interface to the batmesh network. Uncheck “Forward mesh peer traffic” so batman-adv — not legacy peer forwarding — carries client frames.

Bridge bat0 into LAN and set gateway roles

Open Devices > br-lan and add bat0 as a bridge port. That lets wired LAN ports and AP traffic traverse the backhaul without extra routing. On the WAN-connected router set Gateway Mode to Server. On satellites choose Client or Off depending on desired multi-gateway behavior.

Verify all nodes use the same protocol version and that bat0 appears in br-lan. Save & Apply, then reboot in a controlled order so adjacencies form cleanly.

LAN, DHCP, and IPv6 roles for gateway and satellite nodes

I prefer to lock down DHCP and IPv6 roles early so client access stays reliable. This prevents address conflicts and keeps service discovery working across the whole LAN.

Static LAN address plan and DHCP authority

Keep the gateway as the single source of DHCP, DNS, and firewall. Example: gateway = 192.168.1.1. Set its DHCP pool to a clear range (for example 192.168.1.100–199).

On each client router assign a static IPv4 address on the same subnet. Point the client’s IPv4 gateway and DNS to the gateway address. Choose static addresses outside the gateway’s DHCP pool to avoid collisions.

Disable services on client nodes for “dumb AP” operation

On clients disable the DHCP server and stop the default firewall. This keeps lease management central and avoids double-NAT or filtering issues that break device discovery.

IPv6: relay, DHCPv6, and prefix delegation

For IPv6 set RA-Service to relay or off on client interfaces. Disable DHCPv6-Service and uncheck Delegate IPv6 prefixes on clients so the gateway handles prefix delegation.

• Confirm each client interface has the correct address, netmask, and gateway.
• Make sure you can reach clients via SSH or web UI on their static address after reboot.
• To add an extra LAN port, delete wan/wan6 aliases and add the physical WAN to br-lan.
• Document the final address plan so future changes don’t reuse critical infrastructure addresses.

Verification, diagnostics, and common pitfalls

A quick log tail and a few CLI checks can save hours of guessing when links refuse to join. I start with logs, then confirm radios and protocol adjacencies with simple commands.

Logs and status

Open a live log to watch events as radios and interfaces come up. Run:

• logread -l 20 -f — watch for mesh interface starts and peer retries.
• Check the Wireless Overview in the web UI to enable any disabled radios and inspect current associations.
• If the web pages say “missing protocol extensions,” install luci-proto-batman-adv so batman shows in the UI.

iw and batctl checks

Over ssh, use radio tools to verify link quality and adjacency.

• iw dev wlanX station dump — confirms peers, signal, MCS, and retry counts.
• batctl n — lists batman neighbors; batctl mpath — shows paths.
• batctl p — MAC-ping a neighbor to validate Layer‑2 reachability.

Frequent issues and a quick checklist

When things fail, check these common causes first. They are fast to verify and often fix the problem.

Finally, make sure every router and device uses the same protocol version (BATMAN_V or IV). When a link still won’t form, re-check radio power, distance, and client access points to avoid channel conflicts.

Radio planning, roaming, and performance tips

Treat radios like traffic lanes—dedicate them, avoid collisions, and let clients roam smoothly. A clear band plan keeps backhaul throughput high and access points responsive.

Backhaul band choice: 5 GHz throughput vs 2.4 GHz range

I recommend dedicating 5 GHz for the 802.11s backhaul so throughput stays high. Use 2.4 ghz for client coverage where range and wall penetration matter.

If a device has two 5 ghz radios, give one to the backhaul and one to access points. That prevents self-interference and preserves airtime for clients.

Client roaming, channels, and interference avoidance

Enable 802.11r fast transition on all access points and use the same Mobility Domain. Use FT over the Air to smooth handoffs for phones and laptops.

Make sure the backhaul uses a fixed, non-DFS channel when possible. For APs, pick non-overlapping channels and narrower widths in crowded areas.

• Tune transmit power so neighboring points don’t overpower each other.
• Avoid running AP and backhaul on the same channel on one radio.
• Check client device capabilities—some phones only handle legacy rates well.

Where to go next with your mesh

After the initial links are stable, focus on port reuse, per-device firmware, and clear roles so growth stays smooth.

You can repurpose the WAN port as a LAN port by removing wan/wan6 and adding the physical port to br-lan. Build custom images with the Firmware Selector including kmod-batman-adv, luci-proto-batman-adv and the proper wpad-mesh package so each device boots ready.

Keep a living map: static addresses, interface bindings, and which router acts as gateway. Keep 802.11r enabled on every access point and document defaults for roaming.

Finally, introduce VLANs, hybrid wired/wireless links, and monitoring one change at a time. That way the mesh network grows predictably and each access point stays reachable when you need it.