OLSR ARPROAMING PLUGIN An adhoc wireless mesh routing daemon  Valid HTML 4.01 Transitional  SourceForge - Find free open source software.

Home | Download | Usage | Details | Contact
Problem given

Using wireless networks in a dynamic way (see Roaming) without forcing users to change settings requires some technical effort. However, the major problem is reliably determining of new clients very quickly and also removing them if disconnected. For this purpose the plugin uses ARP requests/replies for both detecting new and already gone clients.

Basic idea

In regard to the OSI Reference Model layer 2 was designed to provide data link services. A quick capture of networking data using tcpdump introduces us into ARP:

000000 ARP, Request who-has 10.8.128.2 tell 10.8.128.1, length 28
000004 ARP, Reply 10.8.128.2 is-at 00:2c:7f:11:e6:a7, length 28

Host '10.8.128.1' is asking for '10.8.128.2' on layer 2 using the broadcast mac ('ff:ff:ff:ff:ff:ff') or its previous stored mac address as a destination. Since the host was alive response returned to '10.8.128.1' quickly (about 4 μs) containing the mac address as well.
Now using this lookup functionality connected clients could be easily verified once they were added to the client register. But how do they get in in the first place?

If a new client connects to the network (using DHCP or static IP address) it will always perform ARP requests in order to get information e.g. about the default gateway (if an outgoing connection attempt was made by user). Doing so generates an entry in kernel's ARP table which can be easily obtained using the proc filesystem node '/proc/net/arp':

10.8.128.2 0x1 0x2 00:2c:7f:11:e6:a7 * wlan0

The marked flag '0x2' is an important indicator for alive status. There's a set of flags given in the include file '/usr/include/linux/neighbour.h' (location may differ on other systems):

/* Neighbor Cache Entry States. */

#define NUD_INCOMPLETE 0x01
#define NUD_REACHABLE 0x02
#define NUD_STALE 0x04
#define NUD_DELAY 0x08
#define NUD_PROBE 0x10
#define NUD_FAILED 0x20

Since reading '/proc/net/arp' as a file directly is bad coding style and depends on formatting issues the plugin uses the rtnetlink library to get relevant information and to send/receive ARP data also. Whenever some host reaches flag '0x2' (or at least '0x8' for faster roaming) it will be added to the client register (if not already there).

Implementation / Workflow

The plugin code is periodically called from OLSRd main thread using a callback function named 'arproaming_schedule_event()'. Basically two jobs have to be done: for one finding new clients and for the other update (or delete if timed out) existing clients:

[arproaming_schedule_event]
arproaming_client_add
+ Capture all clients having flag 0x2/0x8 set
+ Check whether single host is already there
+ Add new host to list if necessary, announce via HNA
arproaming_client_update
+ Search for host entries with exceeded timeout
+ Send ARP request, waiting for response (1 second timeout)
+ Renew timeout value or delete from list if not responding (remove HNA also)

Dependency graph

The following chart generated by ncc shows how functions are relying on system calls (click to enlarge):