What is mesh WiFi and How it works: A brief outline.

Mesh-WiFi or Whole Home WiFi are a craze now days. The reasons are many, Off the self-products/solutions will cost you north of $250(₹ 15000/-). unless you are sticking with never heard Chinese products. If you are new to mesh-networking I have covered it in my previous blog.

The DIY solution designed here using Raspberry Pi will help achieve the same solution with $40(₹ 3000/-).

If you find this interesting, please continue.

There a many solution which talks about mesh solutions. But none of them give a solution on Raspberry Pi without any Hardware Addons.

Multiple solutions discuss using either different wireless router or adding Some additional dongle/Hat to Raspberry pi.

This solution achieves following objectives.

  1. Mesh Networking Completely designed using only Raspberry-pi without additional Hardware.
  2. Mesh network created on 2.4Ghz and WiFi is a/b/g/n.
  3. Uses opensource components only.
  4. The solution is a complete Mesh network where Devices can roam freely and connect to the mesh network.
  5. Takes care of security and authentication.

Wherever I have read, the raspberry pi has been shown the limitation of creating a mesh due to non-opensource WiFi driver. And this is true.

HW and Software Components

The DIY Mesh solution we present here needs below components

  1. Raspberry pi zero W :2 Nodes.
  2. Raspberry pi 3: 1 Node.
  3. Openwrt 19.11 (Software Image)

Does Openwrt Support Mesh-WiFi?

Yes, Openwrt Supports Mesh Capability. Mesh WiFi works reliably with Openwrt release 19.07 onwards, including  authentication and encryption.

wpad-mesh-openssl

is the package/software which takes care of Mesh-WiFi Networking

This package is present by default in openwrt latest packages(release 19.07 onwards). In case you want to install the latest package. Below is the command to do so.

# opkg install wpad-mesh-openssl

 Apart from Openwrt support What else is required to support Mesh-WiFi?

Mesh WiFi support requires:An interoperable mesh needs to support IEEE std 802.11s and 802.11r, These two specifications are the core specifications for Mesh Networking, if these specifications are supported by  the Hardware-device(I mean wifi SoC e.g marvel,mediatek ) That’s it, Job Done!

Below image showcases the architecture of mesh functionality in openwrt.
Above MAC layer(Yellow block), there is kernel implementation of IEEE 802.11 stds,

  • To achieve mesh functionality the Router/Mesh node has to act as
    Station and AP simultaneously…
  • Wpad-meshopenssl is the module taking care of network routes and best path selection.

So far all the blocks in blue is openwrt and the block in yellow is tricky we will discuss bellow…

Openwrt with Mesh supported HW

By Design MAC implementation is scope of the wifi Soc(aka chipset) provider, It is upto the manufacture How he does the split of functionality in Kernel and Firmware.

As a rule of thumb, All Base-band and Layer-1 functionality is part of Firmware/ASIC and Layer-2 is either fully kernel driver or split between Firmware and Kernel driver.

What’s the catch here?!!No catch!!! Simple if your Hardware supports  802.11s then you are good to go!

Problem is : When your hardware & kernel driver combination doesn’t support 80211.s & r and still you want to support Mesh.

There 3 individual use cases.

Upgrade Firmware/kernel driver to supports  802.11s&r.

When I say Firmware, I mean WiFi SoC ROM . If there is a feasibility of upgrading the ROM, then and then only. Most of the times to enhance throughput and reduce Bit Error Rate, MAC functionality is ROM-coded into the Soc itself. This MAC implementation is called HARD MAC

MAC functionality if implemented in wifi driver can be upgraded to support IEEE 802.11s, this solution is also known as Soft MAC implementation.

PS: WiFi driver , kernel driver , kernel wifi driver all mean the same thing.

  • Firmware/kernel driver Doesn’t support 802.11s&r. But Soft MAC  implementation.

In short Soft-MAC implemented, but newer version of kernel driver with 802.11s & r support is not available.

Driver is closed sourced/propriety. E.g Raspberry pi wifi drivers and closed sourced, yup!!

              In this case below are your options

  1. Upgrade the kernel driver, if manufacturer upgrades the kernel driver Good.
  2. If kernel driver is open-sourced then, opensource community will upgrade it, you may find an upgraded kernel driver with IEEE 802.11s & r support.
  3. Lastly use open802.11s as part of openwrt(detailed link here “How to use open802.11”)

  • Firmware/kernel driver Doesn’t support 802.11s&r. But Hard-MAC  implementation.
    • Raspberry Pi is one of those Hardware, where Broadcom has
      • Closed sourced/propriety WiFi kernel driver
      • Firmware is closed sourced and no feasibility of upgrade
      • And of-course it doesn’t support IEEE802.11s & r stds.

Blocked!!!. But I got you covered here.

You need to use BATMAN./BATMAN-adv.

  • Doesn’t support 802.11s&r & Hard-MAC  implementation.

Blocked! You need to use BATMAN/BATMAN-adv

What is BATMAN Adv?

B.A.T.M.A.N. is derived from “Better Approach To Mobile Adhoc Networking” and works for stationary systems as well. BATMAN-adv is designed to work at layer-2 which is more efficient than BATMAN which works at Layer-3.

In addition to providing node-to-node and node-to-net connectivity, batman-adv can provide bridging of multiple VLANs over a mesh (or link), such as for “trusted” client, guest, IoT, and management networks. It provides an easy-to-configure alternative to other approaches to “backhaul”, such as WDS connections, GRE tunnels, and various “relay” and “pseudo-relay” approaches.

batman-adv can run on top of a variety of mesh implementations, including 802.11s, ad-hoc (IBSS), and multiple point-to-point links, wired or wireless.

batman-adv is reasonably robust to topology changes, typically adapting within a couple seconds.

batman-adv does not provide encryption or authentication. If required, it should be implemented either or both in the underlying transport (encrypted, authenticated mesh, for example), or protocols (IPSEC, TLS, ssh, …).

  • batman-adv is a mesh protocol for a Layer 2 networking (like Ethernet frames) running in the kernel
  • batmand is a user-space daemon for an older B.A.T.M.A.N. protocol that operates at Layer 3 (like TCP/IP packets)

Unless you’ve got a strong reason to use the older, Layer 3 protocol (such as interoperation with an existing mesh), batman-adv is suggested. This page documents configuration of batman-adv for a local mesh.

Installation Steps

Download Batman-adv with openwrt

OpenWRT Image for Pi-zero-w

OpenWRT Image for Pi-1-model-B+

Flash the SD card with image

The Raspberry Pi official documentation provides an excellent tutorial on this, using Etcher software. We recommend that you burn the OpenWRT image to the Micro SD card using Etcher.

Booting up Raspberry PI Nodes

Insert the SD-Card into the Raspberry Pi Nodes. Make sure to insert the appropriate Flashed images into the Nodes.

For Raspberry PI Zero W there is separate image

For Raspberry PI 3 Model B+ there is a separate Image

Typically, either 802.11s or IBSS (“ad hoc”) is required to set up a mesh.

IBSS configuration is not discussed in detail on this page. See further WiFi /etc/config/wireless

Note that not all driver / firmware combinations support 802.11s mesh (or IBSS). This may be checked with iw phy, looking for “mesh point” (or “IBSS”) in the various sections of the output. If the -CT drivers/firmware do not support mesh on your device, it may be the case that the “classic” (no -CT) variants do.

[email protected]:~# iw  phy | fgrep mesh

                * mesh point

                * #{ managed } <= 16, #{ AP, mesh point } <= 16, #{ IBSS } <= 1,

                * mesh point

                * #{ managed } <= 16, #{ AP, mesh point } <= 16, #{ IBSS } <= 1,

                * mesh point

                * #{ managed } <= 16, #{ AP, mesh point } <= 16, #{ IBSS } <= 1,

Activate and configure batman-adv

opkg update

opkg install kmod-batman-adv

Suggested for ease of monitoring and debugging

opkg install batctl

To enable use of 802.11s mesh

opkg remove wpad-basic

opkg install wpad-mesh-openssl  # or wpad-mesh-wolfssl

Attach the script.

# Activate batman-adv

sudo modprobe batman-adv

# Disable and configure wlan0

sudo ip link set wlan0 down

sudo ifconfig wlan0 mtu 1532

sudo iwconfig wlan0 mode ad-hoc

sudo iwconfig wlan0 essid my-mesh-network

sudo iwconfig wlan0 ap any

sudo iwconfig wlan0 channel 8

sleep 1s

sudo ip link set wlan0 up

sleep 1s

sudo batctl if add wlan0

sleep 1s

sudo ifconfig bat0 up

sleep 5s

# Use different IPv4 addresses for each device

# This is the only change necessary to the script for

# different devices. Make sure to indicate the number

# of bits used for the mask.

sudo ifconfig bat0 172.27.0.1/16

Above Script will

  1. Create a WiFi with “my-mesh-network”
  2. The ip subnet will be 172.27.01/16

Test the ad-hoc connection

Run this on both devices and note the “Cell” address. It should be the same on both devices.

$ sudo iwconfig

eth0      no wireless extensions.

wlan0     IEEE 802.11  ESSID:”my-mesh-network” 

          Mode:Ad-Hoc  Frequency:2.447 GHz  Cell: 16:A6:A5:34:53:46  

          Tx-Power=31 dBm  

          Retry short limit:7   RTS thr:off   Fragment thr:off

          Encryption key:off

          Power Management:on

lo        no wireless extensions.

bat0      no wireless extensions.

If the cell address is not the same on both devices (it will be different from what is shown above), then it can be set manually in the script by changing the address of the “ap” instruction in the script from “any” to a specific address:

sudo iwconfig wlan0 ap 01:23:45:67:89:0a

Any similarly formatted hexadecimal value that looks like a standard IPv4 MAC address can be used. After changing the line, rerun the script and test again. If the Cell addresses still aren’t the same, then the RPi3s do not have their default, fresh out-of-the-box configurations. Start over with a clean installation of Raspbian.

Step 5: Test mesh communications

Run ifconfig and note the IPv4 and HWaddr assigned to wlan0 on each device. You should see something similar to the following (For brevity, I’ve omitted the output for eth0 and lo. It is irrelevant for our purposes.):

$ sudo ifconfig
bat0      Link encap:Ethernet  HWaddr 42:2e:2b:60:34:cc  
          inet addr:172.27.0.1  Bcast:172.27.255.255  Mask:255.255.0.0
          inet6 addr: fe80::f9bd:542:ea7e:e801/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:170 errors:0 dropped:0 overruns:0 frame:0
          TX packets:43 errors:0 dropped:61 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:13811 (13.4 KiB)  TX bytes:9950 (9.7 KiB)
 
wlan0     Link encap:Ethernet  HWaddr b8:27:eb:3a:ab:5e  
          UP BROADCAST MULTICAST  MTU:1532  Metric:1
          RX packets:2513 errors:0 dropped:1 overruns:0 frame:0
          TX packets:2519 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:146297 (142.8 KiB)  TX bytes:242467 (236.7 KiB)

Now that we know where each device thinks it is on the mesh, we can test to find out if they’re actually talking to each other. First, we’ll display the list of “originators” detected by each device:

$ sudo batctl o
[B.A.T.M.A.N. adv 2016.4, MainIF/MAC: wlan0/b8:27:eb:3a:ab:5e (bat0/42:2e:2b:60:34:cc BATMAN_IV)]
   Originator        last-seen (#/255) Nexthop           [outgoingIF]
 * b8:27:eb:7e:08:f0    0.200s   (255) b8:27:eb:7e:08:f0 [     wlan0]

Note the addresses. The Originator and Nexthop addresses will be the HWAddr of the other device, not the one on which the test is being run.

Now, we’ll try a couple of pings, first on the IPv4 addresses:

$ sudo ping 172.27.0.2
PING 172.27.0.2 (172.27.0.2) 56(84) bytes of data.
64 bytes from 172.27.0.2: icmp_seq=1 ttl=64 time=152 ms
64 bytes from 172.27.0.2: icmp_seq=2 ttl=64 time=23.1 ms
64 bytes from 172.27.0.2: icmp_seq=3 ttl=64 time=11.6 ms
^C
--- 172.27.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 11.603/62.364/152.388/63.829 ms

Now, we’ll use batctl’s ping function against the wlan0 HWaddr of each device:

$ sudo batctl ping b8:27:eb:7e:08:f0
PING b8:27:eb:7e:08:f0 (b8:27:eb:7e:08:f0) 20(48) bytes of data
20 bytes from b8:27:eb:7e:08:f0 icmp_seq=1 ttl=50 time=53.66 ms
20 bytes from b8:27:eb:7e:08:f0 icmp_seq=2 ttl=50 time=18.42 ms
20 bytes from b8:27:eb:7e:08:f0 icmp_seq=3 ttl=50 time=11.56 ms
^C--- b8:27:eb:7e:08:f0 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss
rtt min/avg/max/mdev = 11.557/27.330/53.660/16.001 ms

We can obtain more diagnostic information using from batctl’s transglobal table. The “Client” address shown in the table must be the HWaddr for the bat0 interface on the other device, not the one on which the command is run:

$ sudo batctl tg
[B.A.T.M.A.N. adv 2016.4, MainIF/MAC: wlan0/b8:27:eb:3a:ab:5e (bat0/42:2e:2b:60:34:cc BATMAN_IV)]
   Client             VID Flags Last ttvn     Via        ttvn  (CRC       )
 * 82:ac:f9:16:20:13   -1 [....] (  1) b8:27:eb:7e:08:f0 (  1) (0xa67c640b)

That’s it. If the above tests were successful, the the Raspberry Pi 3s are connected to an ad-hoc mesh network, and they’re talking to each other. If the tests are not successful, see the troubleshooting section on open-mesh.org’s web site.

Future Enhancements

As of now the WiFi supported is 2.4G ieee 802.11 a/b/g/n. In future we will add support for 5GHz.

0 0 vote
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x