Roofnet is an experimental multihop 802.11b-based mesh network consisting of about 50 nodes located in Cambridge, Massachusetts, installed and operated by the Massachusetts Institute of Technology (MIT). The network participants are volunteers who accept hosting in their apartments the equipment required to implement a mesh node. Each node is equipped with a single 802.11b wireless card with RTS/CTS disabled. All cards share the same 802.11b channel. Multi-hop routing is implemented using the Click modular router.
Roofnet routes packets using SrcRR a protocol inspired by DSR. The original protocol has been modified extensively, mainly for supporting link-quality metrics. SrcRR uses the ETX for choosing good routes. The metric assigned to each link tries to estimate the number of times a packet have to be transmitted before both the packet and the corresponding ACK are received successfully. SrcRR is independent from IP, and operates at a lower layer using it own frame format.
Roofnet is built exploiting Atheros-based 802.11b/g wireless adapters. Madwifi is used as device driver. The testbed heavily exploits the monitor mode provided by the device driver in order to send and receive raw 802.11 frames allowing the the control of most of the node's functionality trough Click. For instance, it is possible to set the transmission rate on a per-packet level basis and get per-packet signal and noise readings.
Being not defined in the IEEE 802.11 standard, monitor mode has been variously implemented or sometimes not implemented at all. As a result IEEE 802.11 compliant devices are not guaranteed to interoperate properly in monitor mode. In order to make the WING platform device driver agnostic we had to drop the support to the monitor mode and exploits in its place the Independent Basic Service Set (IBSS) mode which is which is part of the IEEE 802.11 standard. The Click router configuration has then been modified by removing all the monitor mode-related elements. More specifically the following elements have been removed:
The Roofnet's routing protocol operates below the IP protocol using its own frame format. A virtual interface named \textbf{srcr1} using multi-hopping is created at each node. Since this interface advertises a classical MTU size of 1500 bytes, the physical wireless device's MTU size has been set to 1900 bytes, leaving 400 bytes for the routing protocol's header. However some wireless adapters' device drivers do not support MTU's sizes higher than 1500 bytes. We decided then to lower the \texttt{srcr1}'s advertised MTU size to 1100 bytes leaving the physical wireless device's MTU size to 1500 bytes.
When operating in Ad Hoc mode, all nodes composing an IEEE 802.11 network must share the same BSSID. However if different regions of the network start without being able to talk to each other, they will select different random BSSID identifiers. So, even if all devices use the same SSID and the same channel, the devices will not be able to see each other because since the node’s firmware filters out packets with the wrong BSSID. Eventually, all devices will agree on the same BSSID, however this convergence might turn out to be slow.
Such an issue is not relevant when the wireless interfaces are running in monitor mode since each node is capable of sending raw 802.11 frames where the BSSID field is artificially set to to 00:00:00:00:00:00. However such a feature is not available in Ad Hoc mode making our platform vulnerable to BSSID partitioning.
Roofnet's routing protocol, SrRR, tries to find the highest throughput route between any pair of nodes. Omnidirectional antennas give SrRR many choices of links it could use, but since most links are low-quality, SrRR must evaluate each link's usable throughput. SrRR chooses routes with an Estimated Transmission Time (ETT) metric, derived from estimated transmission count (ETX). ETX measures the expected number of transmissions, including retransmissions, needed to send a unicast packet across a link.
When operating in monitor mode each node can send broadcast probes at arbitrary rates. However while most 802.11 devices can automatically select the best rate for any Unicast packet, they will send all broadcast packets at the lowest rate (1 Mbps).