|Stable release||Batman-adv 2013.3.0 / July 29, 2013|
The Better Approach To Mobile Adhoc Networking (B.A.T.M.A.N.) is a routing protocol for multi-hop ad hoc networks which is under development by the "Freifunk" community and intended to replace OLSR. It can be used for mesh networks but this is not the only potential use.
B.A.T.M.A.N.'s crucial point is the decentralization of the knowledge about the best route through the network — no single node has all the data. This technique eliminates the need to spread information concerning network changes to every node in the network. The individual node only saves information about the "direction" it received data from and sends its data accordingly. The data gets passed on from node to node and packets get individual, dynamically created routes. A network of collective intelligence is created.
In early 2007, the B.A.T.M.A.N. developers started experimenting with the idea of routing on layer 2 (Ethernet layer) instead of layer 3. To differentiate from the layer 3 routing daemon, the suffix "adv" (for: advanced) was chosen. Instead of sending UDP packets and manipulating routing tables, it provides a virtual network interface and transparently transports packets on its own. The batman-adv kernel module has been part of the official Linux kernel since 2.6.38. 
B.A.T.M.A.N. does have elements of classical routing protocols: It detects other B.A.T.M.A.N. nodes and finds the best way (route) to these. It also keeps track of new nodes and informs its neighbors about their existence.
In static networks, network administrators or technicians decide which computer is reached via which way or cable. As radio networks undergo constant changes and low participation-thresholds are a vital part of the "Freifunk"-networks' foundation, this task has to be automated as much as possible.
On a regular basis, every node sends out a broadcast, thereby informing all its neighbors about its existence. The neighbors then relay this message to their neighbors, and so on. This carries the information to every node in the network. In order to find the best way to a certain node, B.A.T.M.A.N. counts the originator-messages received and logs which neighbor the message came in through.
Like distance-vector protocols, B.A.T.M.A.N. does not try to determine the entire route, but, by using the originator-messages, only the packet's first step in the right direction. The data is handed over to the next neighbor in that direction, which in turn uses the same mechanism. This process is repeated until the data reaches its destination.
In addition to radio networks, B.A.T.M.A.N. can also be used with common cable connections, such as Ethernet.
The task was to create a protocol which was to be as easy, as small and as fast as possible. It seemed therefore sensible to split the development in several phases and implement complex functions using an iterative process:
In the first phase, the routing algorithm was implemented and tested for its practicality and suitability for the task at hand. For the sending and receiving of originator-messages (information about existence), the UDP port 1966 was chosen.
The version one algorithm made a significant assumption: As soon as a node receives existence data from another node, it assumes it can also send data back. In radio networks however, it may very well be that only one-way communication is possible. A mechanism was incorporated into the protocol to allow for this and to solve the arising problems. The mechanism enables the node to determine whether a neighbouring node provides bidirectional communication. Only bidirectional nodes are being considered part of the network, and one-way nodes are no longer fully included.
The greatest innovation in this version is B.A.T.M.A.N.'s support of multiple network devices. A computer or router running B.A.T.M.A.N. can be deployed in a central location, like a church or another high building, and have several wired or wireless network interfaces attached to it. When so deployed, B.A.T.M.A.N. can relay network data in more than one direction without any retransmission delay.
Certain unusual phenomena and special circumstances could appear during the determination of the best route through the network. These have been tackled and counteracted to prevent circular routing (which can prevent data reaching its destination) from occurring.
A node can inform the network that it provides access to the Internet. Other nodes use this information to evaluate whether there is a connection to the Internet close to them and how much bandwidth is available. They can either use a specific gateway or allow B.A.T.M.A.N. to determine which gateway to use, based on criteria such as connection speed.
Announcing devices not running B.A.T.M.A.N. themselves was also included in this[which?] version. Usually, this method is used to connect home networks to mesh-networks. An antenna installation on the roof will connect to the wireless network through B.A.T.M.A.N. and the rest of the building will simply be announced, thus also be reachable.
BatMan-eXperimental (BMX) aims to approximate the real exponent by also sending OGMs multiple times in independent broadcast datagrams.
- Secure B.A.T.M.A.N.: http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:453358
- Netsukuku is a project with similar goals
- Robin-Mesh RO.B.IN - ROuting Batman Inside
- OLSR Optimized Link State Routing Protocol (OLSR)
- Ad hoc On-Demand Distance Vector Routing (AODV)
- Ad hoc routing protocol list
- List of open source routing platforms
- Mobile ad hoc network (MANET)
- Linux 2 6 38 Linux Kernel Newbies
- M. Abolhasan, B. Hagelstein, J. C.-P. Wang (2009). "Real-world performance of current proactive multi-hop mesh protocols".
- J. Chroboczek. "A few comments on the BATMAN routing protocol".
- Official website
- Freifunk Web-User Interface with B.A.T.M.A.N.
- NIGHTWING batman zero-conf mesh addon to OpenWrt firmware - can be installed on Atheros based routers with 4 Mb flash/16Mb ram
-  - ROBIN forum
-  - Wireless LAN Mesh Whitepaper based on B.A.T.M.A.N.