Skip to content

HOWTO 0.4.2

Jump to bottom Edit New page
Javier Cardona edited this page Mar 6, 2012 · 2 revisions

This page explains how to set up a mesh network using open80211s and a "supported driver":http://o11s.org/trac/wiki#DriverStatus.

Note: at this time, this HOWTO assumes that you are not running a [[WiFi]] manager such as [[NetworkManager]]. Please kill or otherwise stop [[NetworkManager]] or similar software before setting up your mesh interfaces or tell it to ignore the device that you plan to use for mesh.

Index

  • "Software Requirements":/cozybit/open80211s/wiki/#pieces
    • "For Open Mesh":/cozybit/open80211s/wiki/#openpieces
    • "For Secured Mesh":/cozybit/open80211s/wiki/#secpieces
  • "Open Mesh":/cozybit/open80211s/wiki/#openmesh
  • "Secured Mesh":/cozybit/open80211s/wiki/#secmesh
  • "Advanced Tinkering":/cozybit/open80211s/wiki/#advancedmesh
  • "Mesh Portal (MPP)":/cozybit/open80211s/wiki/#meshportal

Software Requirements #pieces

In order to set up a mesh you'll need a kernel and a few packages. Internally we use a master project ("distro11s":https://git.github.com/cozybit/distro11s) that can build a full mesh node from the different repositories listed below. You are welcome to try that.

o11s works on OpenWrt - see "Building for OpenWrt":/cozybit/open80211s/wiki/wiki:OpenWrtBuilding

Or you can fetch the different components individually:

For Open Mesh #openpieces

An open mesh is one where all peers with compatible configuration are allowed to join the mesh. Essentially this means that just the Mesh ID and the channel must match.

The kernel #kernel

Get the wireless-testing kernel:


git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git

If you are trying this release within a few days of release date all our patches may not be in wireless-testing yet. In that case, just clone the kernel from here:


git://o11s.org/open80211s

Configure the kernel including the mac80211 stack with mesh capabilities (CONFIG_MAC80211, CONFIG_MAC80211_MESH) and enable the driver(s) that you need, for example the zd1211-rw driver (CONFIG_ZD1211RW). Compile and install on your target. Here are "instructions for Ubuntu":/cozybit/open80211s/wiki/wiki:Ubuntu.

You also have the option of using "compat-wireless":http://linuxwireless.org/en/users/Download instead of building the kernel or you may also use the "2.6.26":http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=summary or later mainline kernel. Using wireless-testing is strongly recommended as it represents the latest development and driver support.

iw

Follow the instructions at "iw documentation page":http://linuxwireless.org/en/users/Documentation/iw/ to build the latest version of iw from source or use a recent released version of iw.

For Secured Mesh #secpieces

In a secured mesh, all peers must share a secret password. Authentication is established via the Simultaneous Authentication of Equals protocol. Key derivation and cipher suite negotiation is done via the Authenticated Mesh Peering Exchange. Both protocols are specified in the 802.11s amendment.

In addition to the basement requirements above you will need the following:

Kernel

See "this section":/cozybit/open80211s/wiki/#kernel

authsae

Get our fork of authsae from here


git://github.com/cozybit/authsae.git

authsae depends on openssl. You'll have to edit linux/Makefile to tell it where to find it.

Then build:


$cc -g -DLINUX -Wall -Werror -I..   -c -o meshd.o meshd.c
cc -g -DLINUX -Wall -Werror -I..   -c -o ../common.o ../common.c
cc -g -DLINUX -Wall -Werror -I..   -c -o ../sae.o ../sae.c
cc -g -DLINUX -Wall -Werror -I..   -c -o ../service.o ../service.c
cc -g -DLINUX -Wall -Werror -I..   -c -o ../ampe.o ../ampe.c
cc -o meshd meshd.o ../common.o ../sae.o ../service.o ../ampe.o ../crypto/aes_siv.o -L. -lcrypto -lconfig
cc -g -DLINUX -Wall -Werror -I..   -c -o meshd-nl80211.o meshd-nl80211.c
cc -g -DLINUX -Wall -Werror -I..   -c -o nlutils.o nlutils.c
ar rcs libsae.a ../common.o ../sae.o ../service.o ../ampe.o ../crypto/aes_siv.o
cc -o meshd-nl80211 meshd-nl80211.o nlutils.o libsae.a -L. -lsae -lnl -lnl-genl -lcrypto  -lconfig
cc -g -DLINUX -Wall -Werror -I..   -c -o mon.o mon.c
cc mon.o ../service.o ../common.o -o mon

Open Mesh Setup #openmesh

Each mesh node needs to be configured as follows:

  • Boot several nodes with the compiled kernel and with iw properly installed.

  • Choose a mesh ID. The mesh ID is a string that will be used in the mesh node beacons. Only mesh points with the same mesh id will be able to communicate with each other. The mesh id is a maximum of 32 bytes long. In this document, we refer to the mesh id as $MESH_ID.

  • Add a new mesh interface for the wlanN device on each node. You can choose the name of the mesh interface. "mesh" is a popular choice. In this document, we refer to the mesh interface as $MESH_IFACE.


# iw dev wlan0 interface add $MESH_IFACE type mp

A new interface will be created:


# ifconfig -a | grep mesh
mesh      Link encap:Ethernet  HWaddr 00:18:39:14:48:B5

Note: depending on your Linux distribution, you may see "a slightly different name":http://linuxwireless.org/en/users/Download#Knownissues for the mesh interface.

All mesh interfaces start by default in channel 1. The channel can be changed with


# iw dev $MESH_IFACE set channel

Bring up your $MESH_IFACE interface and assign an IP


# ifconfig $MESH_IFACE

For this tutorial, let's assume that our mesh nodes are assigned addresses in the 192.168.3.80/28 subnet.


# ifconfig $MESH_IFACE 192.168.3.80

Join a mesh network:


# iw dev $MESH_IFACE mesh join $MESH_ID
  • In the default configuration, mesh points will automatically attempt to create peer links will all other mesh nodes with the same mesh ID. You can examine which peer links have been established with the iw dev $MESH_IFACE station dump command:

# iw dev $MESH_IFACE station dump
Station 00:15:6d:84:14:10 (on mesh)
	inactive time:	1320 ms
	rx bytes:	352
	rx packets:	4
	tx bytes:	174
	tx packets:	2
	signal:  	-61 dBm
	tx bitrate:	1.0 MBit/s
	mesh llid:	32577
	mesh plid:	15969
	mesh plink:	ESTAB
Station 00:15:6d:84:14:09 (on mesh)
	inactive time:	3370 ms
	rx bytes:	1064
	rx packets:	12
	tx bytes:	545
	tx packets:	7
	signal:  	-53 dBm
	tx bitrate:	1.0 MBit/s
	mesh llid:	41036
	mesh plid:	24435
	mesh plink:	ESTAB

Each Station'' stanza in the station dump output represents a mesh node with whom we have a peer link. The first line shows the MAC address of the mesh node. The ''mesh plink field reports the state of the peer link with this mesh node. When this value is ESTAB, direct communication with this mesh node is possible.

  • You should now be able to ping any node in the mesh. After doing that you can use arp'' and ''iw to inspect the arp table and path table. This will reveal where the packet was actually sent in order to get to its destination.

192-168-3-80:~# ping -c 2 192.168.3.83
PING 192.168.3.83 (192.168.3.83) 56(84) bytes of data.
64 bytes from 192.168.3.83: icmp_seq=1 ttl=64 time=8.85 ms
64 bytes from 192.168.3.83: icmp_seq=2 ttl=64 time=3.42 ms

192-168-3-80:~# arp
? (192.168.3.83) at 00:15:6d:84:14:0e [ether]  on mesh

192-168-3-80:~# iw dev $MESH_IFACE mpath dump
00:15:6d:84:14:10 00:15:6d:84:14:10 mesh	0	228 	0	2196731904	0	0	0x10
00:15:6d:84:14:0e 00:15:6d:84:14:10 mesh	2	456 	0	2196731904	360	0	0x4
00:15:6d:84:14:09 00:15:6d:84:14:09 mesh	1	8193	0	2196731904	0	0	0x10

The arp table shows the hardware address of the destination node. This is useful for interpreting the output of the mpath dump'' command. The ''mpath dump shows the table that the mesh stack uses to route packets. This table is constructed as the mesh stack successfully establishes paths to destinations in the mesh. Each output line shows the destination address in the first column and the next hop address in the second column. Look up the destination address of our ping packet (00:15:6d:84:14:0e) in this table. You can see that the next hop is 00:15:6d:84:14:10, revealing that the packet will not be sent directly to the destination. Instead, it will be sent to 00:15:6d:84:14:10 who will presumably forward it on appropriately. In contrast, if the destination of the packet were 00:15:6d:84:14:09, the packet would be sent directly to that node. This is because the path table reports the same address for the destination and next hop.

Each entry in the mpath dump has several trailing fields after the destination and next hop addresses. For more information on the meaning of these fields, see the "mpath page":/cozybit/open80211s/wiki/wiki:mpath. Also, be sure to check the "the driver status page ":http://o11s.org/trac/wiki#DriverStatus for any known issues related to your driver.

Et voilà!

Secured Mesh Setup #secmesh

Everything you need to create an authenticated mesh is listed in "Requirements":/cozybit/open80211s/wiki/#secpieces. authsae will handle all authentication and peering for us.

Edit authsae.conf to enter your mesh password:


/* this is a comment */
authsae:
{
 sae:
  {
    debug = 480;
    password = "thisisreallysecret";
    group = "26, 21, 25, 20":/cozybit/open80211s/wiki/19,;
    blacklist = 5;
    thresh = 5;
    lifetime = 3600;
  };
 meshd:
  {
       meshid = "byteme";
       interface = "mesh0";
       passive = 0;
       debug = 1;
       mediaopt = 1;
       band = "11g";
       channel = 1;
       htmode="HT20";
  };
};

Then on each node:


AUTHSAE_DIR=/path/to/authsae
AUTHSAE_CONF=/path/to/authsae.conf
$AUTHSAE_DIR/linux/meshd-nl80211 -c $AUTHSAE_CONF -s $MESHID -i $MESH_IFACE

After authentication and peering completes you should see authenticated mesh peers:


$ iw $MESH_IFACE station dump 


Station 00:02:03:04:00:00 (on mesh0)
	inactive time:	608 ms
	rx bytes:	26967
	rx packets:	535
	tx bytes:	1182
	tx packets:	10
	tx retries:	0
	tx failed:	0
	signal:  	-30 dBm
	signal avg:	-30 dBm
	tx bitrate:	1.0 MBit/s
	mesh llid:	0
	mesh plid:	0
	mesh plink:	ESTAB

Advanced Tinkering #advancedmesh

  • You can modify the mesh path table with these commands:

    • iw dev $MESH_IFACE mpath del $DST_ADDR: to delete a mesh path entry.
    • iw dev $MESH_IFACE mpath new $DST_ADDR next_hop $NEXTHOP_ADDR to force a specific network topology.

  • You can modify the mesh peer links table with these commands:

    • iw dev $MESH_IFACE station dump: list all the plinks.
    • iw dev $MESH_IFACE station set $HW_ADDR plink_action [open|block]: trigers a specific peer link stablishment process or blocks a specific peer link.
    • iw dev $MESH_IFACE station del $HW_ADDR: deletes a peer link from the peer table.

  • You can get and set mesh parameters using the "mesh_param" command in iw. For example, to change the mesh TTL value (which defaults to 5), one would:


# iw dev $MESH_IFACE get mesh_param mesh_ttl
5
# iw dev $MESH_IFACE set mesh_param mesh_ttl 3

The following mesh parameters can be inspected and set:

  • mesh_retry_timeout (time in ms to wait for a peering confirm frame before resending a peering open frame)
  • mesh_confirm_timeout _ (time in ms to wait for a peering confirm frame before aborting the attempt)_
  • mesh_holding_timeout (time in ms to hold a peer entry before removing it from the peer list, following a peering close request, or other peering timeouts)
  • mesh_max_peer_links (the maximum number of established peer links this node can have)
  • mesh_max_retries (the number of times to attempt peering requests before aborting)
  • mesh_ttl (the number of hops before a data transmission in the mesh is dropped)
  • mesh_auto_open_plinks _ (whether or not to automatically open peer links with a discovered peer)_
  • mesh_hwmp_max_preq_retries (the number of attempts that this node can make to discover a path to a single destination. the minimum wait time between retries is twice the mesh_hwmp_net_diameter_traversal_time)
  • mesh_path_refresh_time (how many ms prior to a path expiration should a path refresh be attempted)
  • mesh_min_discovery_timeout (? does this override the 2x diameter_traversal_time for preq_retries?)
  • mesh_element_ttl (the number of hops an hwmp element may be propagated)
  • mesh_hwmp_active_path_timeout (the length of time "TU":/cozybit/open80211s/wiki/in that derived forwarding path information will remain valid)
  • mesh_hwmp_preq_min_interval (interval "TU":/cozybit/open80211s/wiki/in between proactive tree building path requests from this root node)
  • mesh_hwmp_max_preq_retries (the number of attempts for path discovery to a single desitnation in the mesh before aborting)
  • mesh_hwmp_net_diameter_traversal_time (the interval "TU":/cozybit/open80211s/wiki/in that an originator hwmp sequence number may be re-used when attempting to discover paths, to improve established return path stability and reduce overhead.)
  • mesh_hwmp_rootmode (if this node should operate as a root node, i.e. a gateway node)
  • mesh_hwmp_rann_interval (time in ms between root announcements)
  • mesh_gate_announcements (whether this node should announce itself as a root node gateway)

Note: 1 TU = 1024 microseconds.

Wireshark

Our wireshark mesh patches have been accepted upstream (since r38281), so you just need to get a recent wireshark version to dissect mesh (see here how to get it http://www.wireshark.org/develop.html).

Open Mesh

For an open mesh network, Wireshark recognizes and dissects the data within the mesh frames

||Image(HOWTO-0.4.2:wireshark-data.png,100%)||Image(HOWTO-0.4.2:wireshark-data-icmp.png,100%)||

Secure Mesh

For this scenario, Wireshark can only parse the mesh frames (because the data is encrypted)

||Image(HOWTO-0.4.2:wireshark-data-secure-1.png,100%)||Image(HOWTO-0.4.2:wireshark-data-secure-2.png,100%)||

Mesh Gate #meshportal

A mesh gate is just a mesh node that connects to an external network. To bring up a mesh gate we need to setup up a bridge between a mesh interface and, for example, an Ethernet interface.

  1. Bring up a mesh interface as described in the "Testing" section above.

mpp$ iw dev wlan0 interface add $MESH_IFACE type mp mesh_id ${MESH_ID}
mpp$ ifconfig $MESH_IFACE up
  1. Add this new interface and your ethN interface to a new bridge:

mpp$ brctl addbr br0
mpp$ brctl stp br0 off
mpp$ brctl addif br0 eth1
mpp$ brctl addif br0 mesh
mpp$ ifconfig $MESH_IFACE down
mpp$ ifconfig eth1 down
mpp$ ifconfig $MESH_IFACE 0.0.0.0 up
mpp$ ifconfig eth1 0.0.0.0 up
mpp$ ifconfig br0 ${MESH_IP}

If you are having problem setting up the bridge, here is a great howto: "Ethernet Bridge + netfilter HOWTO":http://www.faqs.org/docs/Linux-HOWTO/Ethernet-Bridge-netfilter-HOWTO.html

  1. Enable gate announcements

You can configure gates to advertise their presence on the mesh. We do this by including those advertisements in root announcements. To enable this functionality you must make your gate a root node and enable gate announcements:


iw mesh set mesh_param mesh_hwmp_rootmode=1
iw mesh set mesh_param mesh_gate_announcements=1

Once you do this, all the nodes in your mesh will proactively create paths to your gate. Mesh nodes will send to gate(s) all traffic to those destinations that could not be resolved in the mesh.

Gates introduce some management and data traffic overhead. You should keep the number of gates down on your network.

"Comments? Questions? Praise? Flames?":http://o11s.org/mailman/listinfo/devel

Add a custom footer
Clone this wiki locally