Wifi has different modes it can use where the most used are managed, master and monitor.
From iwconfig man pages:
mode Set the operating mode of the device, which depends on the net‐
work topology. The mode can be Ad-Hoc (network composed of only
one cell and without Access Point), Managed (node connects to a
network composed of many Access Points, with roaming), Master
(the node is the synchronisation master or acts as an Access
Point), Repeater (the node forwards packets between other wire‐
less nodes), Secondary (the node acts as a backup mas‐
ter/repeater), Monitor (the node is not associated with any cell
and passively monitor all packets on the frequency) or Auto.
iwconfig eth0 mode Managed
iwconfig eth0 mode Ad-Hoc
Managed mode is where your wifi card is used to connect to your access point and surf the web, browse your samba shares and so on. This is what regular users use it for and all wifi cards support this mode.
Master mode is where your wifi card is set up as an access point and shares resources. This can be a gateway or just a hub for a service you want to provide. Not all drivers/wifi cards support it. Some cards flat out don’t support it and others just need an driver update for it to work.
Monitor mode is used for testing purposes. Not all drivers support this but for the most part I’ve never encountered a card that doesn’t support it.
Ad-Hoc mode is where a wifi card is used to connect two systems (laptop, desktop etc.) together without the use of a access point. The problem with this setup is that you only get the routing that is setup for that network. Let’s say you have a Ad-Hoc network of 5 systems where two of them has internet access. If the route is setup so that system 1 is the gateway and system 1 goes down the others loose their path out to the internet. To rectify this problem you must change the route settings to the other system that has internet access. When system 1 is online again the route is still pointing to the other system. Some operating systems also support just one Ad-Hoc connection so there can only be two computers in the network.
This is where Mesh networking comes in to play. It can be seen as an Ad-Hoc system with a lot of masters but none of them have actual control or authoritative control of the network. A mesh network tries to route the packages dynamically by choosing which route it thinks is the best. If one host goes down the network updates and tries to route around that missing host and when it goes online again the route is reestablished. The biggest problem with a mesh network is that is has to do a lot of link checking to be sure that it’s neighbors are online and where they point to so you get some bandwidth use that is not actual user traffic. The bigger the network, the bigger the bandwidth usage and congestion.
In the first post in the mesh section I mentioned Babel and Batman. There is also OSLR, which stand for Optimized Link State Routing. I think I’ll be trying out Batman first and see if I can get a mesh net up at least.
From what I have read and if I understand everything, Batman used to be in userspace and worked on layer three of the OSI model. But now it is in the kernel and runs on layer two.
Copied from the batman-adv wiki:
Most other wireless routing protocol implementations (e.g. the batman daemon) operate on layer 3 which means they exchange routing information by sending UDP packets and bring their routing decision into effect by manipulating the kernel routing table. Batman-adv operates entirely on ISO/OSI Layer 2 - not only the routing information is transported using raw ethernet frames but also the data traffic is handled by batman-adv. It encapsulates and forwards all traffic until it reaches the destination, hence emulating a virtual network switch of all nodes participating. Therefore all nodes appear to be link local and are unaware of the network's topology as well as unaffected by any network changes.
This design bears some interesting characteristics:
network-layer agnostic - you can run whatever you wish on top of batman-adv: IPv4, IPv6, DHCP, IPX ..
nodes can participate in a mesh without having an IP
easy integration of non-mesh (mobile) clients (no manual HNA fiddling required)
roaming of non-mesh clients
optimizing the data flow through the mesh (e.g. interface alternating, multicast, forward error correction, etc)
running protocols relying on broadcast/multicast over the mesh and non-mesh clients (Windows neighborhood, mDNS, streaming, etc
I’ll do an install on both laptops that I’m going to try it on and see where it gets me 😀