bmx6

{{>toc}}

h1. BMX6

Bmx6 is a routing protocol for Linux based operating systems.

The following intro provides kind of tutorial to get started.

h2. Installation

h3. Requirements

The following tools are needed to obtain, compile, and install bmx6

* git (debian package: git-core)

* gcc

* make

h3. Downloading

Latest development sources are available from bmx6 git repository

<pre>

git clone git://qmp.cat/bmx6.git

cd bmx6

</pre>

h3. Compile and Install

To only compile the main bmx6 daemon (no bmx6 plugins)

<pre>

make

sudo make install

</pre>

h2. Usage (hello mesh)

In its most simple configuration, the only required parameter are the interfaces names that should be used for meshing.

The following example starts bmx6 on interface wlan0:

<pre>

root@mlc1001:~# bmx6 dev=eth0

</pre>

However, to let this simple command work as expected also check the following basic requirements:

* bmx6 must be executed in root context (with super user permissions). If you are not already root, prepend all commands with sudo (eg: @ sudo bmx6 dev=eth0 @ ).

* NO IP address needs to be configured. By default bmx6 assumes IPv6 and autoconfigures an ULA based IPv6 address for each interface based on the MAC address of the device. Just, the interfaces must be UP. The linux ip command can do this for you (eg: @ ip link set wlan0 up @). Also, if you are using a wireless interface, the wireless interface settings must be set correctly so that link-layer connectivity is given with bmx6 daemons running on other nodes (computers). The good old iwconfig command may help to achieve that. For example @ iwconfig wlan0 mode ad-hoc ap 02:ca:ff:ee:ba:be channel 11 essid my-mesh-network @ is a typical configuration for a wireless mesh setup.

* Bmx6 (by default) works in daemon mode, thus sends itself to background and gives back a prompt. To let it run in foreground specify a debug level with the startup command like: @ bmx6 debug=0 dev=eth0 @ . Of course you may need to kill a previously started bmx6 daemon beforehand (@ killall bmx6 @)

If everything went fine bmx6 is running now, searching for neighboring bmx6 daemons via the configured link, and coordinates with them to learn about existence-of and routes-to all other bmx6 nodes in the network.

To access status information of the bmx6 daemon which has just been started, a second bmx6 process can be launched in client mode (with the --connect or -c parameter) to connect to the main bmx6 daemon and retrieve the desired information.

In the following, a few example will be discussed:

<pre>

root@mlc1001:~# bmx6 -c status

version        compatibility codeVersion globalId                     primaryIp                       myLocalId uptime     cpu nodes 

BMX6-0.1-alpha 16            9           mlc1001.E0F9E33CD42EF2980443 fd66:66:66:0:a2cd:efff:fe10:101 24100101  0:00:56:37 0.3 3

</pre>

So apart from version, compatibility number, and code, the status reveals the daemon's global and local ID, its primary (self-configured) IPv6 address, the time since when it is running (56 minutes), its current cpu consumption (0.3%) and the total number of learned nodes in the network (including itself).

Typical types of accessible information are: status, interfaces, links, originators, descriptions, tunnels

These required types can be combined. Also the above given example shows kind of shortcut. The long argument would be

@ bmx6 connect show=status @. So a more informative case using the long form would be:

<pre>

root@mlc1001:~# bmx6 connect show=status show=interfaces show=links show=originators show=tunnels

status:

version        compatibility codeVersion globalId                     primaryIp                       myLocalId uptime     cpu nodes 

BMX6-0.1-alpha 16            9           mlc1001.6480B336E87B8F8DA8D7 fd66:66:66:0:a2cd:efff:fe10:102 8C100101  0:04:14:15 0.7 3    

interfaces:

devName state type     rateMin rateMax llocalIp                    globalIp                           multicastIp primary 

eth0    UP    ethernet 1000M   1000M   fe80::a2cd:efff:fe10:101/64 fd66:66:66:0:a2cd:efff:fe10:101/64 ff02::2     1       

links:

globalId                     llocalIp                 viaDev  rxRate txRate bestTxLink routes wantsOgms nbLocalId 

mlc1002.4CA9926CF823599148DF fe80::a2cd:efff:fe10:201 eth0    100    100    1          1      1         3D100201  

mlc1000.2C4BA11B70E50B889B90 fe80::a2cd:efff:fe10:1   eth0    100    100    1          1      1         DA100001  

originators:

globalId                     blocked primaryIp                       routes viaIp                    viaDev  metric lastDesc lastRef 

mlc1000.2C4BA11B70E50B889B90 0       fd66:66:66:0:a2cd:efff:fe10:1   1      fe80::a2cd:efff:fe10:1   eth0    999M   14925    2      

mlc1001.6480B336E87B8F8DA8D7 0       fd66:66:66:0:a2cd:efff:fe10:101 0      ::                       ---     128G   14928    0      

mlc1002.4CA9926CF823599148DF 0       fd66:66:66:0:a2cd:efff:fe10:201 1      fe80::a2cd:efff:fe10:201 eth0    999M   14928    2      

</pre>

Only if relevant information for a requested type is available it will be shown.

In this example no tunnels are configured nor offered by other nodes and therefore no tunnel information is shown.

The loop argument can be prepended to the connect argument to continuously show the requested information.

Many of the long arguments are usable via a short notation, like l for loop, c for connect, s for show, d for debug.

And there is another shortcut summarizing my current favorite information types via debug level 8

The following commands do the same as above: @ bmx6 -lc status interfaces links originators tunnels @ or just @ bmx6 -lcd8 @.

Reviewing the provided info:

* interfaces: followed by one line per configured interface

** dev: the interface name

** state and type: whether the interface is UP or DOWN and its assumed link-layer type.

** rateMin and rateMax: the min and maximum transmit rates assumed for this interface.

** llocalIp: the IPv6 link-local address (used as source address for all outgoing protocol data).

** globalIp: the autoconfigured address used for sending network traffic via this interface and which is propagated to other nodes.

** multicastIp: the multicast IP (used as destination address for all bmx6 protocol traffic send via this interface).

** primary: indicates whether the global ip of this interface is used as primary ip for this daemon.

* links: followed by one line per detected neighboring bmx6 node.

** globalId: the globalId of that neighbor.

** llocalIp: the llocalIp of the neighbor's interface building the other side of the link.

** viaDev: the interface of this node for the link.

** rxRate: the measured receive rate in percent for the link.

** txRate: the measured transmit rate in percent for the link.

** bestTxLink: indicates whether this link is the best link to a neighboring nodes.

** routes: indicates for how much routes to other nodes this link is used.

** wantsOgms: indicates whether the neighboring node has requested (this node) to propagate originator messsages (OGMs) via this link.

** nbLocalId: the neighbors local ID.

* originators: followed by one line per aware originator in the network (including itself).

** globalId: the globalId of that neighbor (see: [Wiki#Global ID]] ).

** blocked: indicates whether this node is currently blocked (see: [[Wiki#Blocked]] ).

** primaryIp:

** routes:

** viaIp:

** viaDev:

** metric:

** lastDesc:

** lastRef:

h2. Concepts

h3. Global ID

h3. Unicast Host Network Announcements (UHNA)

h3. Tunnel Announcements

h3. Descriptions

h3. Blocked

Nodes may be blocked by other nodes.

The decision for blocking another node is done locally based on the detection of duplicate claimed unique resources.

This happens if two nodes are declaring themselves as the owner of a unique resource. Then one of those two nodes (usually the latter) is blocked to avoid the propagation of conflicting state. Duplicate address usage is the most common reason for such events which happens if two nodes are using (and announcing) the same primary IPs. Another typical reason for such events is the rebooting of a node. Once the bmx6 daemon restarts it appears as a new node to the network but announcing the same address as the previous process. Since the resources allocated by the previous resources are still in the database of other nodes in the mesh they will block the new process until this information expires (by default after 100 seconds).

h2. Bmx6 Plugins

h3. Config Plugin

h4. Requirements

uci libs are needed for the bmx6-config plugin.

To install it do:

<pre>

wget http://downloads.openwrt.org/sources/uci-0.7.5.tar.gz

tar xzvf uci-0.7.5.tar.gz

cd uci-0.7.5

make

sudo make install

</pre>

Depending on your system there happens to be an error during compilation.

Then edit cli.c and change line 465 to: @ char *argv[MAX_ARGS+2]; @

h4. Compile and Install

To compile the bmx6 daemon and bmx6 plugins

<pre>

make build_all

sudo make install_all

</pre>

h4. Usage

h3. Json Plugin

h4. Requirements

* json-c for bmx6_json plugin (debian package: libjson0 libjson0-dev)

json-c developer libs are needed!

For further reading check: http://json.org/ or https://github.com/jehiah/json-c

Note for debian sid:

The debian package libjson0-dev 0.10-1 seems to miss the file /usr/include/json/json_object_iterator.h

Manually copying it from the below mentioned json-c_0.10.orig.tar.gz archive helps.

To install manually (only if NOT installed via debian or other package management system):

<pre>

wget http://ftp.de.debian.org/debian/pool/main/j/json-c/json-c_0.10.orig.tar.gz

tar xzvf json-c_0.10.orig.tar.gz

cd json-c..

./configure ; make ; make install; ldconfig

</pre>

h4. Compile and Install

To compile the bmx6 daemon and bmx6 plugins

<pre>

make build_all

sudo make install_all

</pre>

h4. Usage

h3. SMS Plugin

h3. Quagga Plugin

*Misc*

[[Tunnel]]