Your API file in only 6 steps

  1. Call up 
  2. Fill in the information about your community in the form and press “OK – generate…”. Mandatory fields are marked with an asterisk. The more information you enter, the better. 
  3. Your results will be displayed on the right hand side. If information is missing or fields are incorrectly filled, you will see it marked under the text box. Fill in or correct the information and generate the API file again.
  4. Save the content of the text box to a text file on your computer or press the download button.
  5. Upload the file created under point 4. to the Internet on to your Web space, in your content management system or our freifunk wiki. You will need a link to that file.
  6. The link must be added to the API directory. If you trust yourself, create a pull request, or you can send the link via contact form. If you chose the later, select “question about the API” as subject.

Please note: If you want to update, download or edit your API file, you can choose to do so after the entering the API directory, in the drop-down menu on the top right. The file must however be resaved or downloaded and uploaded to the Web server again.  

Please also use the possibilities to update information such as the number of nodes or services automatically and regularly. Gluon developers have written an examplary script, and there is a solution for OLSR-based networks on Github

You can find background information on the API in the blog and on  

The most recent changes are summarized here.

Translation by Karin Kuschel.

Wireless OpenHardware

Hi all,

at the fantastic WSFII meeting during SAX at in Spain we started to specify two wireless hardware devices. There were people from various free wireless network communites from Europe and the US. We had a three hour workshop and tried to define our wish list for cheap free open source software compatible open wireless hardware. Now we are trying to find the manufacturers who is willing to build those devices.

If you have any contacts that could help, please talk to them and show them our results. The company should best sell those products direct to the communites over webshop and only ship the bulk boards in charges of 20,50,100 or more. We think, that’s the best way to make them as cheep as possible.

There are quite a lot of people willing to help in e.g. software/driver-development or hardware-design. I am very positive that sooner or later some manufacturer is going to see their chance in our global movement!



1. Simple Node
– single wireless a/b/g radio device with support for virtual access points
– single Ethernet port with high tolerance PoE support (4-30V)
– power system must resist reverse polarity
– 4 Mbyte Flash
– 16 Mbyte RAM
– 200 MHz CPU
– serial port
– JTAG interface
– one Antenna plug (reverse SMC) and no explicit need for diversity
– for outdoor usage (which is regarded to be a standard scenario) the
board does not need a box and does not need to be shipped with antenna
and power supply
– power consumption should be as little as possible (solar systems!)

Comment: Finding the consensus on the design for the simple node was
quite easy and did not take very long. It seams that the needs and
wishes of the different groups represented by the attendees are very

2. Super Node
– two embedded wireless a/b/g radio devices with support for virtual
access points
– two Ethernet ports with standard 802.3af PoE support
– power system must resist reverse polarity
– 8 Mbyte Flash
– 32 Mbyte RAM
– 500 MHz CPU
– two USB 2.0 ports
– two miniPCI slots (both stackable up to 8 cards)
– serial port
– JTAG interface
– two Antenna plugs (reverse SMC) and no explicit need for diversity
– for outdoor usage (which is regarded to be a standard scenario) the
board does not need a box and does not need to be shipped with antennas
and power supply
– power consumption should be as little as possible (solar systems!)

Comment: Finding a compromise on the super node really was a hard time,
because there can be different ways to achieve the same goals. For
example, if wireless USB devices had a better FOSS support, many of the
super nodes could just easily be built without the need for miniPCI.
Also super nodes can be built with simple wireless bridges connected
over ethernet (high power consumption?). But anyway, after many looong
discussions the group had a consensus on the points listed above.

3. wireless USB devices
As already mentioned, super nodes could well be build using wireless USB
devices instead of mini PCI cards (less expensive cabling, less
interference between the devices). But to be able to use them, people
need FOSS drivers for them, which support all wireless modes (managed,
ad-hoc, AccessPoint), and the USB devices should have a reverse SMC
antenna connector.


B.A.T.M.A.N.-Release-Party at the c-base in Berlin

(via Marek Lindner) Time: Wednesday 20th June
2007 / Place: c-base berlin

The B.A.T.M.A.N.-developer team would
be happy to celebrate with YOU the 0.2 release of B.A.T.M.A.N. at
the C-Base (in Berlin). FYI, there will also be a free barrel of cool
beer waiting to be flushed. Version 0.2 can reasonably be called
stable now. It works quite performant, supports multiple interfaces,
has a low CPU-load, a robustly working algorithm underneath, and
autonomously negotiates UDP-Tunnels to GWs  which ultimately
enables long-term and stable internet connections. A number of users
reported quite excitedly about the amazing experiences they made with
this protocol. Well, we want to stay neutral so join in to hear them
and try batman for yourself.

Currently B.A.T.M.A.N is
available for Linux only. The ports for Mac OS-X and BSD have fallen
asleep and are waiting for a diligent bee … Maybe there will once
also exist a windows port.

Many thanks to all the people who
helped to realize this in such a short amount of time.

are thinking about printing further T-shirts with the
B.A.T.M.A.N.-Logo (as you can see on
) and sell them at the cost of expenses. Unfortunately the price is
not clear by now but will be about or less than 15 Euro. If you are
interested please send a mail with your size and the limit you are
willing to pay.

Considerations for the parallel operation of
OLSR and
Berlin we are now facing a phase in which both routing protocols will
be used in parallel. Currently we are aware of one issue where this
can cause problems. This is in case of OLSR-Internet traffic passing
a dual-stack (OLSR and B.A.T.M.A.N.) node where the B.A.T.M.A.N
daemon is configured for tunneled GW selection. Then each
OLSR-towards-internet packet will be magically caught and warped to
the currently selected (and maybe several hops away) B.A.T.M.A.N. GW.
where the packets pop-up again and follow their usual path through
the internet to their final destination. This has caused confusion
since also programs like traceroute do not show the intermediate hops
which the packet has passed (tunnelled)  between the related
B.A.T.M.A.N. node and the GW.

This is because such a
dual-stack mesh node (where the B.A.T.M.A.N daemon is configured for
tunneled GW selection) consequently has two default routes. One due
to OLSR and another due to B.A.T.M.A.N.. The thing is, that both are
ending up in the same routing table and one of them (the latter) has
a higher priority than the other. So every packet passing along with
a destination address matching only the default entry of the routing
table will end up in the tunnel to the currently selected
B.A.T.M.A.N. GW.

The Internet-GW selection mode of
B.A.T.M.A.N. is optional and should be disabled or used with care
especially on nodes with a dedicated RF-postion (and such used by
many others as an intermediate hop) like churches and other high
buildings. Enduser using Notebooks or PDAs should be able to use this
feature without causing trouble.

order to make the parallel deployment of both protocols even more
smoothly, a number of new features have found their way into 0.3.
Then it will also be possible to maintain and use a the OLSR and the
B.A.T.M.A.N. default route in parallel.

Therefore we will also
release the first version of the upcoming B.A.T.M.A.N. generation
(0.3 alpha).

At the same time we already began working on the
next generation of B.A.T.M.A.N. which will be called B.A.T.M.A.N.
Advanced. It works on Layer 2 and creates a virtual network switch of
all nodes participating. It offers a bunch of new possibilities and
features which wait for you to be explored. To offer you a stable
plattform you can experiment with we will release 0.1 alpha. We will
also provide a set of tools (the B.A.T.M.A.N. toolchain – battool)
to bring you in the position to observe the magic and to debug your
setup or our daemon.  😉