Project

General

Profile

News

Batman-adv 2013.0.0 released

Added by Marek Lindner almost 12 years ago

On January 15th, the B.A.T.M.A.N. team has released batman-adv 2013.0.0, bringing many new features, performance improvements and tweaks under the hood. As the kernel module always depends on the Linux kernel it was compiled against, it does not make sense to provide binaries on our website. As usual, you will find the signed tarballs in our download section:

https://downloads.open-mesh.org/batman/releases/batman-adv-2013.0.0/

as well as prepackaged binaries in your distribution.

Thanks

Thanks to all people sending in patches:

and to all those that supported us with good advice or rigorous testing:

batman-adv

In summer 2011, the B.A.T.M.A.N. project participated in Google's Summer of Code for the first time. One of the two projects was about implementing a distributed ARP table for batman-adv (short: DAT), enabling a mesh node to speed up the ARP discovery phase for its non-mesh clients by intelligently caching & retrieving IPv4 address/MAC address translations. Many obstacles like clean code, lack of time and kernel maintainer objections had to be taken before DAT could finally be merged. This release finally brings the long-awaited distributed ARP table. The wiki features basic DAT documentation as well as technical insights for those who are interested.
The batman-adv Ethernet type (0x4305) was accepted as "official" Ethernet type inside the Linux kernel to help avoiding future collisions with other protocols. Only the IEEE is entitled to raise our Ethernet type to the level of "standard" recognized beyond the realm of Linux but this step still moves us forward.

Thanks to a hint from David Miller we began removing the famously known "__packed" attribute from our packet definitions as it allows the compiler to generate slightly faster code on some platforms. He also encouraged us to implement a minor modification in our hash code to squeeze a little more performance out of it. The translation table was enhanced with the ability to handle multiple roaming events during a single OGM interval (especially useful in environments with higher OGM intervals). The bridge loop avoidance drops ECTP traffic to avoid packets looping around. In addition, various race conditions during the bridge loop avoidance initialization phase have been identified & fixed. An unusual speedy join / bridge loop avoidance interaction bug caught our attention and was addressed soon thereafter.

batctl

The batctl utility was enriched with a couple of tools completing the distributed ARP table support: A switch to enable / disable DAT at runtime, an ARP cache viewer and a minimal unicast 4addr dissector (unicast 4addr packets are used to exchange DAT packets). This release also features small but useful 'translation' helpers: Whenever an IP or MAC address needs to be 'translated' to the originator mac address responsible for the IP or MAC the 'batctl translate' functionality can be used. It is now also possible to call 'batctl ping' and 'batctl traceroute' with an IP or MAC address because these tools will take advantage of the 'translate' functionality internally. Beware: layer 2 ping and traceroute will still only work across batman-adv enabled nodes.
All of batctl's output errors are redirected to stderr instead of stdout. To save space on embedded devices 'batctl bisect' was turned into a compile-time option which is turned off by default. The manpage explaining gateway functionality received some attention as well.

Happy routing,

The B.A.T.M.A.N. team

Guest article: batman-adv in South America

Added by Marek Lindner about 12 years ago

At some point I thought it would be nice to describe a small real world batman-adv implementation. Many times I've seen mails from people doing simulations or whatnot, to decide whether or not batman-adv works as expected... and I guess they would appreciate reading about real word use cases. :)

This thing started1 back in February 2012 in Cordoba, Argentina with Nico Echaniz et al

Shortly after DeltaLibre followed, replicating the model. From the very beginning we aimed at building the cheapest possible, high performance multi-radio mesh node.

Ten months later, although there's still room for improvement, we are very happy looking back at the path that took us here :). Starting with the decision of choosing batman-adv, as explained in a Spanish reply to Esteban Municio2

2012/9/10 Esteban Municio:
Was there any reason why you chose batman-adv over other protocol?

Layer 2! no subnet configuration, "Just Works", it's easy to forget batman-adv is down there doing all the magic - A routing protocol that stays out of your way, is priceless.

Which were your main issues working with batman-adv?

With batman-adv... almost none :)
Main difficulties until now were on phy level (interference) or layer 1 (hardware, drivers, firmware)

With batman-adv, we bumped into 2 or 3 bugs, reported to the mailing list, and received prompt solutions thanks to the daily work that the developers put into it. Last version 2012.3.0 includes all those fixes.

Pending issues as of today, are a strange behavior where avahi packets are lost (can't assure batman-adv is the culprit) and an open ticket3 about adding RAs mangling support to gw_mode, extending the DHCPv4 segmentation logic to SLAAC networks as well. As it is today, you can't put 2 ipv6 gateways doing SLAAC for different prefixes in the same batman-adv cloud. So far is not a showstopper for us, but we would love to be able to do that.

Some numbers: With the deployed hardware4 (TL-MR3220 and WN722N) throughput in point-to-point links maxes out at 30 or 40mbps respectively (Lite-N HT20). With our dual-radio mesh nodes, we can sustain that transfer speed over at least 3 hops, using channels 1 and 11 for alternating interfaces. Given the small size of the networks, a longer path is currently not possible, but when using a single radio, or interfering channels, that same path throughput quickly drops to about 6 mbps, as predicted by the models.
This is not news for many, but as said in the beginning of the email, i see some folks "doubting" about the performance, or overhead, of batman-adv...
In tests we made, over a single hop (that is, from A to C as in A --> B --> C where point to point links reach ~30mbps), static routing reached 30mbps +/- 1mbps, and using batman-adv 29.5mbps +/- 1mbps
A real bargain for the bat-benefits :)

To easily share, publish and keep track of config tweaks between our networks we setup a hg5 repo6 and eventually added bat-graphs for some basic context7. That can't possibly be maintained at a larger scale, but still proves incredibly useful at research stages.
It has been used by an independent group (Gabriel Tolon et al) to make their equipment compatible with DeltaLibre network at their lab, then bring the nodes into the region, plug and Just worked, with little intervention on our part.

We pull the overlays with a bash hack named ruci8 and use that too to push and stage experimental configs to the whole network without fear of locking us out because of a config mistake or typo.

(I'm aware this has been addressed by multiple solutions, but ruci was born back in February while we didn't have a decent internet access to research previous art - we have changed tactics since then, trying to integrate with the rest of the movements :) )

Finally, some obligatory pictures9 of representative nodes last months' smokeping stats10 and cacti11 and as a bonus, a crude video12 filmed by Al Cano from guifi.net while visiting DeltaLibre back in May, enjoying seamless roaming along 6 nodes while literally navigating through the batman-adv mesh :)

In QuintanaLibre (Quintana is a mountain-region small town with <500 inhabitants) you can spot kids using their OLPC netbooks while sitting in a (resting) horse' back. With almost no cellphone signal nor landlines whatsoever, you can imagine how much they appreciate having a WCN at their hometown.

This short story can't possibly express how grateful we are with you batpeople, but I hope it gives a glimpse ;)

1 https://blog.altermundi.net/article/timeline-february-september-2012/

2 https://listas.altermundi.net/pipermail/redeslibres/2012-October/001438.html

3 issue #159

4 http://docs.altermundi.net/RedesMiniMaxi/Equipamiento

5 https://bitbucket.org/guidoi/deltalibre-configs

6 https://bitbucket.org/nicoechaniz/quintanalibre-configs

7 https://bitbucket.org/guidoi/deltalibre-configs/src/tip/files/deltalibre_2012-08-14.svg

8 https://bitbucket.org/guidoi/ruci/

9 https://blog.altermundi.net/article/algunas-imagenes-de-deltalibre/

10 http://ping.deltalibre.org.ar/

11 http://graficas.deltalibre.org.ar/

12 http://es.wiki.guifi.net/wiki/Archivo:Paseo_en_canoa_conectado_a_BATMAN-Advanced_por_Delta_Libre.ogv

Batman-adv 2012.4.0 released

Added by Marek Lindner about 12 years ago

The B.A.T.M.A.N. team proudly presents its newest release, batman-adv 2012.4.0, mostly dedicating itself to stability with some smaller enhancements to improve the user experience. As the kernel module always depends on the Linux kernel it was compiled against, it does not make sense to provide binaries on our website. As usual, you will find the signed tarballs in our download section:

https://downloads.open-mesh.org/batman/releases/batman-adv-2012.4.0/

as well as prepackaged binaries in your distribution.

Thanks

Thanks to all people sending in patches:

batman-adv

The translation table (the core system for managing all non-mesh clients across the mesh network) has been supplemented by the "speedy join" mechanism. Speedy join was designed to make the location of non-mesh clients known throughout the mesh without depending on OGM messages. As soon as non-mesh clients issue a DHCP or ARP request or any other broadcast message they are immediately full participants of the network. This will lead to a faster network connection experience, especially when the mesh network has been configured with higher OGM intervals.
All remaining traffic counters were converted to the recently introduced traffic counting framework and its ethtool API, thereby completely replacing the old traffic counter mechanism for the purpose of better scalability. The bridge loop avoidance comes with an additional backbone gateway table (exported via debugfs) allowing to retrieve the list of all detected backbone gateways attached to the same LAN, regardless of whether or not it has claimed any non-mesh client.

Several reports about packet loss in combination with vlan tagging encouraged us to investigated the cause. A bug was found in the Linux kernel vlan code and a patch was submitted. At the same time a workaround was added to our out-of-tree kernel module which automatically takes effect for kernel versions older than Linux 3.8 (which contains the proper fix). This release also comes with a few bug fixes concerning the batman-adv code directly: with the intent of suppressing duplicate broadcast packets in the mesh the bridge loop avoidance computes CRC checksums for each broadcast packet it receives and compares them to a list of already received broadcast checksums. The check-summing code miscalculated the CRC leading to overly aggressive broadcast packet drops. Also addressed was the missing "no purge" flag for the batX mac addresses after manually changing its mac address. The code refactoring regression leading to route flapping in multiple interfaces setup was corrected along with wrong OGM counting on Intel x86.

batctl

As gradually more functionality of the batman-adv kernel module is optional and can be compiled out, batctl won't be able to find the corresponding files in sysfs or debugfs. Therefore, batctl now maintains a list of optional features and informs the user about a possibly deactivated optional feature. At the same time the sysfs / debugfs code has been refactored to remove redundant boilerplate code. Also removed was the code querying the traffic statistics through the old API because all statistics can be retrieved via the new API. The batctl utility also gained an option to display the newly added backbone gateway table.

Happy routing,

The B.A.T.M.A.N. team

GSoC 2012: Edo Monticelli's Final Report

Added by Simon Wunderlich about 12 years ago

The throughput meter is a tool to measure network performance between two batman nodes. With userspace programs like iperf or netperf, data must be copied between user space and kernel space and the TCP header and/or payload must be aligned. On devices with limited resources, like routers, the context switching between userspace and the kernel and memory aligning are expensive operations, leading to packet loss and to falsified test results. The Throughput Meter is implemented entirely in kernel space and provides an aligned protocol similar to TCP, so it should give a reasonable approximation of the results that would be obtained by TCP. Tests are initiated through batctl - a brief concept description follows.

Throughput Meter

The throughput meter test can be started through batctl:

# batctl bw 00:13:02:43:e3:1a
Throughput meter called towards 00:13:02:43:e3:1a
Test over in 3564 ms.
         sent 70000000 bytes.
Throughput 19640000 Byte/s

The following illustration shows how, after launching the above batctl command, the test is triggered: batctl sends a message through a local socket to the local batman-adv kernel module. The module generates and sends packets to the specified remote host. When the test is over, a message is returned to batctl, which prints the results. The test can be aborted with the typical SIGINT (CTRL-C) or SIGTERM signals.

Protocol Overview and Possible Enhancements

The currently implemented protocol is Go-back-N, with cumulative acknowledgement and a fixed window size. In our experiments, the achieved protocol throughput does not match up with TCP and under certain network conditions the difference can be significant. For sure the absence of a dynamic window and of a dynamic RTT/Timeout limits the protocol performance: since the maximum throughput (number of packets) is limited to one "window" per RTT, the protocol performance is strongly bound to the relation between the window size and the RTT.

The used protocol must adapt to the parameters of the network, like available throughput or packet loss. For example, if the window size changed dynamically, the protocol performance should reflect the available throughput more realistically. Another element that could enhance performance is something similar to TCP's "fast retransmission": When a single packet is lost the throughput meter waits for the timeout (400 ms) before retransmitting the the lost packets. In the future, the throughput meter could guess that a packet was lost if it received several ACKs belonging to later packets and resend the missing packet without waiting for the timeout.

Further Information

It might take a while before the code is merged with master, because we need to break compatibility, so until then you find the code in a separate repository for batman-adv and batctl. Technical specification is given at the throughput meter protocol page and questions are welcome on the mailing list.

GSoC 2012: Spyros Gasteratos' Final Report

Added by Marek Lindner about 12 years ago

My GSoC 2012 task centered around the question how batman-adv could better handle backward compatibility when new features requiring packet format changes are added. The batman-adv packets already carry a compatibility number but it was time to introduce a less obtrusive mechanism on top of it - the TVLV infrastructure.

Introduction

While looking at the originator packet (OGM) which is used for the routing algorithm and announcing features the dilemma becomes quite obvious. The OGM contains the aforementioned compatibility number along with a number of fields needed for the routing (like interval, sequence number, TQ, etc) plus some features fields (for example gateway flags, tt version, etc).

Illustration of an OGM packet:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Packet Type  |    Version    |     TTL       |     Flags     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Sequence Number                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Originator Address                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Originator Address       |    Previous Sender Address    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Previous Sender Address                     | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Gateway Flags |       TQ      |TT Num Changes |     TT VN     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            TT CRC             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here, the task of the compatibility number is to ensure that a node receiving an OGM packet is able to parse it and that every node interprets the routing information contained in the packet in the same way. There is not much we can do about the latter but many newly added features only need some form of announcement and can be useful even if only some nodes support it (as long as the feature does not touch vital parts of the mesh network).

A real world example: The soon to-be-added distributed ARP table (DAT) allows to retrieve the mac address belonging to a client without going through a time consuming ARP discovery operation. Nodes with this new feature enabled could perform the fast lookup for their clients while the non-DAT nodes can still use the standard ARP mechanism. The fast lookup requires to know which of the peer nodes also supports the fast lookup and which nodes don't. This can easily be addressed by advertising DAT support via OGMs.

TVLV Concept

The project's goal is to provide the infrastructure for sending, receiving and parsing information 'containers' while preserving backward compatibility. TVLV (based on the commonly known Type Length Value technique) was chosen as the format for those containers.

TVLV layout:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   TVLV Type   |    Version    |    Length     |  Value
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 'tvlv type' field describes the content of 'value' and the 'length' field the number of bytes till the end of the container. Even if a node does not know the tvlv type of a certain container it can simply skip the current container and proceed with the next. Past experience has shown features evolve over time, so a 'version' field was added right from the start to allow differentiating between feature variants - hence the name: T(ype) V(ersion) L(ength) V(alue).

All the OGM will carry in the future are the bare routing information and a collection of TVLV containers. If a node wishes to send a new / unknown TVLV type it can do so without requiring each node in the network to be able to parse it. A lean TVLV API will be provided to make using the TVLV infrastructure as painless as possible.

Further information

All features currently taking advantage of the OGM to flood information through the network have to be converted to the TVLV infrastructure. Of course, TVLVs are not limited to OGM packets only. Other packet types may also benefit from this abstraction (TT_REQUEST and vis packets are good examples). Typical packet types not suitable for tvlv-ization are performance critical packets such as unicast payload. For those packets the overhead does not justify the gain in compatibility. The TVLV page contains an overview about the various TVLV types and the API as well as the state of development.

Keep in mind that by implementing the TVLV infrastructure batman-adv does not magically become backward compatible in every single aspect. TVLV is a starting point allowing individual features to build upon. How backward compatibility can be ensured and whether it is feasible has to be decided on a case-by-case basis. Each feature will have to implement a mechanism to handle 'old' versions of the same feature.

When TVLVs are going to be merged into the mainline repository the compatibility number has to be increased once more because the packet format changes. As a consequence, the TVLVs won't be merged before the tvlv-ization of the existing features has been completed.

Layer 2 fragmentation

Added by Marek Lindner about 12 years ago

As one of the three "batman-adv students" in this years Google Summer of Code (GSoC), I was selected to redesign and implement the fragmentation feature in batman-adv.

The old implementation was designed before features like Translation Tables (TT) were added to batman-adv and thus lacks certain features that we would like to see. So we started the projects by defining a set of goals for the new design and came up with the following:

---------------------------------------------
| Feature                       | Old | New |
---------------------------------------------
| All Unicast Types             |     |  x  |
---------------------------------------------
| Variable Number of Fragments  |     |  x  |
---------------------------------------------
| Encapsulation                 |     |  x  |
---------------------------------------------
| Early Merge                   |  x  |  x  |
---------------------------------------------
| TTVN Path Altering            |  x  |     |
---------------------------------------------

The new fragmentation supports both current and future unicast packet types; If needed it fragments packets into to more than two fragments; It uses encapsulation to be agnostic to other features in batman-adv; Intermediate hops on the path may merge the packet if it can be transmitted as one, but they cannot change the final destination if a client roams, because this requires information from the payload.

Operation

Packets too big to be transmitted on the selected outgoing interface are passed to the fragmentation code. Here, they are chopped into several smaller fragments and a fragment header is prepended to each fragment.

When being received by either the destination or an intermediate hop, the fragments are buffered until all fragments are received. When the last fragment arrives, the fragments are merged to the original packet, which is passed to the primary receive function in batman-adv.

Handling Very-Big-Translation-Tables™

The client handling system (also known as Translation Tables, TT, described here) occasionally needs to transmit a full table that might too large to be in one packet. Since the old fragmentation only handles unicast packets, it can not fragment these full table packets, and thus the TT code was made to simply cut of the end of the table if needed. This approach lead to a mismatch in checksums across the network and is more or less broken.

With the new fragmentation feature, full table packets (which are of a special unicast type) are now fragmented without the TT code knowing about it. This allows much bigger tables to be transmitted, but the size is now limited by the maximum number of fragments (16). To avoid sending truncated tables across the network, the TT code now checks size of the table before adding new entries, and thus always keeping the size of the table below the limit.

Further Information

Technical specification is given at the fragmentation page and questions are welcome on the mailing list.

Batman-adv 2012.3.0 released

Added by Marek Lindner about 12 years ago

The B.A.T.M.A.N. team is delighted to announce its latest release, batman-adv 2012.3.0, focused on cleanups, stability and bugfixes bundled with a few smaller features. As the kernel module always depends on the Linux kernel it was compiled against, it does not make sense to provide binaries on our website. As usual, you will find the signed tarballs in our download section:

https://downloads.open-mesh.org/batman/releases/batman-adv-2012.3.0/

as well as prepackaged binaries in your distribution.

Thanks

Thanks to all people sending in patches:

and to all those that supported us with good advice, code review and/or rigorous testing:

Special thanks to Sven Eckelmann who took on the nearly-impossible task of restyling / renaming of all existing variable declarations and function names throughout the code. With 68 patches he submitted about 5000 changes to achieve the goal of making the code more coherent.

batman-adv

David Miller, the Linux kernel network maintainer, wanted batman-adv to become a better Linux-citizen by conforming to the Linux namespace convention. Since this topic was neglected for quite some time a fair amount of code changes were required to comply with the convention. This renaming / restyling work represents the bulk of the changes coming with this release. The newly introduced extended traffic statistics support also is worth mentioning: Up until now batman-adv only collected statistics about the payload traffic. This release adds counters about mesh internal traffic like forwarded traffic, OGM and TT management traffic that can be accessed through the ethtool API.

Numerous components received bugfixes: The translation table handling code fixed a race condition in the full-table replacement logic and correctly handles endianness when forwarding TT Request packets. Furthermore, the cooperation between the routing protocol and the translation table has been abstracted to allow a smooth integration with the routing protocol API. The gateway code dealt with a regression which made it impossible to select a gateway on a client if a selection class smaller than 3 was chosen. The recently renovated bridge loop avoidance falsely dropped DHCP packets coming through the gateway code as it believed to prevent a loop. This has been addressed. The AP isolation was a little too aggressively dropping all broadcast traffic from WiFi clients which made it impossible, for example, to exchange mac address entries via ARP. The visualization output of the vis component does not fail on primary interfaces without neighbors anymore. Batman-adv was modified to initialize all reserved protocol fields with zero to ensure later compatibility when the packet format may be changed. A race condition in the hash implementation was found and fixed as well.

batctl

New in this release is the packet statistics retrieval component which displays the data gathered by batman-adv through a new command line switch. The mini-tcpdump allows to filter parsed packets by compatibility number only showing packets that match its own compat number. In addition, it learned the new bridge loop avoidance (BLA II) packet format to also display those packets. The ping and traceroute components properly initialize all ICMP fields to avoid unexpected behavior.

Happy routing,

The B.A.T.M.A.N. team

GSoC 2012 Midterm Interview

Added by Simon Wunderlich over 12 years ago

Half-time for our Google Summer of Code projects - time to pause for a moment and see what has been accomplished in the last few weeks. We asked our students Edo Monticelli, Martin Hundebøll and Spyros Gaster to bring their work to a state of a working prototype, which can be found in their respective git repositories on https://git.open-mesh.org/ or on the wiki in their respective project pages (Edo: GSOC2012_BW, Martin: Fragmentation, Spyros: BackwardsCompatibility). We have also interviewed them about their experiences with the Google Summer of Code, which we don't want to hold back. :)

Question: The midterm of your GSoC project has been reached. Can you describe in a few sentences what you have achieved so far and which tasks remain for the second half of this GSoC ?

Martin: I am working with a new implementation of the fragmentation feature in batman-adv. The current implementation only fragments packets of type BATADV_UNICAST, but a more and more features are added to batman-adv, other types should be fragmented as needed.

While we are at it, we also want to add support for more than two fragments per packet, and merging of fragments if they are forwarded on an interface with large enough MTU.

So far, I have developed a working prototype of the new fragmentation. It is (main-)feature complete in the sense that our goals for the new fragmentation are implemented and work: packet-type-independent, multiple fragments, routing of fragments. The solution is based on a encapsulation-of-encapsulation, where (the encapsulating batman-adv) packets with size bigger than MTU, are split and encapsulated with a fragment header.

Now I need to make the code SMP- and architecture-safe, and of course find and fix bugs. Also, my mentors will probably have a lot of suggestions that I need to consider and work with.

Spyros: My project is extending the batman-adv protocol to be backwards compatible through the use of tvlv(Type Version Length Value) information messages. So far I have made a working prototype for the project which transfers the gateway announcement tvlv. Now I have to polish the existing code, do some bug-fixes (thank you for your remarks everyone) and finally include the right function calls in various places in the code so as tvlvs are part of the protocol.

Edo: I am implementing in kernel space a protocol for the bandwidth measurement, in order to have a lightweight approximation of TCP behavior. At the moment the protocol is working with fixed size window and cumulative acknowledgment.

What should be done in the next month is a lot of testing and bugfixing. Some features are still missing, like the possibility to choose if a node is sender or receiver.

Question: Looking at the past weeks what have been your greatest challenges and how did you master them ?

Martin: It is always wonderful to live in the world of SKB-pointers, where the whole thing may break, if you forget to (re)set a single pointer in the skb-struct. I have spent quite some time with printk's and skb->foo's :)

Spyros: I had some trouble making myself comfortable with the linux kernel coding style and learn how to interpret the kernel panic logs. Even though I'm not a pro at both of them I have at some degree mastered them with a solid amount of help from the mentors and the community and some scolding of course.

Edo: The worst moment was at the beginning, when I had to start coding with very small knowledge of the batman code and no experience of kernel-space programming. The greatest difficulties were bound to kernel related techniques and features, like workqueue and locks.

I have been able to overcome difficulties by looking at the batman code that manages similar issues and with the community help (mentor and IRC people).

Question: What has been the most exciting experience relating to your GSoC project so far (e.g. mastering a technique, learning new approaches, successes, etc) ?

Edo: When the project worked. Also to solve some hard bug has been of great satisfaction!

Martin: I find it very exciting that I can develop and contribute an entire feature to batman-adv (i.e. fragmentation). By being the author of such a feature, one feel responsible for it and get to take one step up the "batman-adv-developer-ladder".

Spyros: Pretty much everything about gsoc has been exciting but if I have to pick just one aspect I choose the part that I'm working with others on a code-base written by them. So far I had only done university assignments which even though they were enlightening enough, they were just newbie-level example code compared to the GSoC requirements. Now I hope I get to see how the pros do it.

Question: Could the batman-adv organisation (website, community, mentors, individual supporters, etc) have done anything different to facilitate your life as GSoC student ? Was there something you considered too complicated or even scary ?

Spyros: No, the organisation has already provided more than enough for me. The mentors provide much of their time for feedback and tutoring meetings and the community is there when I have a question however stupid the question is.

Edo: In general I found the batman organization adequate and of great help.

Martin: I think my mentor(s) should visit me in Denmark. If not during the GSoC time, then at least within 2012.

If I should mention one serious improvement also, it could be more assistance when defining the project goals and writing the application.

Question: Do you have any advice, words of wisdom or valuable feedback you'd like to share with future batman-adv GSoC students (with regards to expectation, preparation and time consumption for example) ?

Edo: I found effective to agree with my mentor and the batman community on the tasks to develop and how to develop them, so that the project could benefit of their advice. So the help of the community for my has been fundamental.

Martin: If you want to be a GSoC-student with batman-adv in 2013, you might as well get started now. Download the batman-adv source, install it on three laptops and get your first mesh running. Then buy a book about SKB's and kernel development, and ask on IRC, if there are any low hanging fruits, that you can pick to become familiar with batman-adv.

By getting familiar before the beginning of next years GSoC, you make it a lot easier to fulfill the goals!

Spyros: Start early, never stop, familiarize yourself with everything first, listen to the mentors, and above all when in trouble and you cant find the answer online ask at the channel. You are in open source and the greatest thing is the community and the incredible geeks which are part of it. Oh and buy the mentors many beers when you see them, put that gsoc money to good use :P(kidding)

Thanks a lot to the students for their good work, keep it up!

Happy Routing,

The B.A.T.M.A.N. Team

Batman-adv 2012.2.0 released

Added by Marek Lindner over 12 years ago

Today, the B.A.T.M.A.N. team releases batman-adv 2012.2.0, packed with new features and improvements in various subsystems as well as the usual set of fixes and cleanups. As the kernel module always depends on the Linux kernel it was compiled against, it does not make sense to provide binaries on our website. As usual, you will find the signed tarballs in our download section:

https://downloads.open-mesh.org/batman/releases/batman-adv-2012.2.0/

as well as prepackaged binaries in your distribution.

Important changes

This release comes with a completely rewritten bridge loop avoidance (also known as bridge loop avoidance II). The concept of the first bridge loop avoidance was simple and worked well in small size LANs while larger networks suffered from the overhead. The new concept is very different and requires changes in your batman-adv configuration. If you were using the bridge loop avoidance you should consult our documentation before upgrading your network(s).

The default "per hop" penalty was increased to encourage batman-adv to take shorter routes. If you notice altered routing behavior and are unhappy with the result you should revisit the hop penalty configuration option.

Thanks

Thanks to all people sending in patches:

and to all those that supported us with good advice, code review and/or rigorous testing:

batman-adv

The new bridge loop avoidance certainly is the most prominent of the new features this release has to offer (completely replacing the old bridge loop avoidance mechanism). The major design goals were performance and scalability. Since the old implementation was relying on a single gateway to be the main gateway to the LAN for everybody else it created a performance bottleneck. Furthermore, the LAN was used to send traffic to and receive data from the main gateway. With the number of bridged gateways grew the amount of broadcast traffic in the LAN. The new bridge loop avoidance splits the client responsibility amongst all participating gateways. Each gateway "claims" the clients it feels responsible for and ignores the traffic from all other clients to avoid the bridge loop. It also is able to handle multiple VLANs on top of the batX interface connected to different topologies. All details about the loop avoidance mechanism are explained in our documentation section.

The routing code also received lots of attention: The recently added routing protocol abstraction was further polished and extended to better accommodate the needs of alternative routing protocols. B.A.T.M.A.N. IV protocol has been enhanced with an additional flag to apply stricter forwarding rules to OGMs which allows the protocol to avert routing loops in certain corner cases. Also, the B.A.T.M.A.N. IV sequence numbers are now randomized at startup to reduce the probability of a collision and thus, slowing down the protocol in the startup phase. Rerouting of unicast payload packets during a roaming phase is handled with greater efficiency to avoid as much packet loss while roaming as possible.

All manual HZ-jiffies-calculations have been replaced with the in-kernel jiffies_to_msecs() function. To facilitate comprehension of the code base the ETH_ALEN macro is used instead of hardcoded numeric constants. The batman-adv internal bitarray operations have been converted to the efficient in-kernel bitmap operations. It was discovered that the TT-Request packet did not always send the tt-crc field in network byte order, thereby invalidating the packet. This has been fixed alongside the suboptimal DHCP option list parser used by the gateway extension. OGM sequence numbers now are always printed as unsigned long to avoid misinterpretation while printing the numbers in the debug log.

batctl

The batctl utility supports the new bridge loop avoidance by providing an option to conveniently enable/disable the bridge loop avoidance and exports the bridge loop avoidance claim table. It will also warn about features that haven't been compiled into batman-adv such as debug log and bridge loop avoidance. The mini-tcpdump learned to display the newly added 'not best hop flag' when parsing OGMs.

Happy routing,

The B.A.T.M.A.N. team

GSOC 2012: The students and their projects

Added by Marek Lindner over 12 years ago

For this year's Google Summer of Code Freifunk granted us a total of 3 slots for students working on batman-adv. Many thanks to the Freifunk GSoC organizers for supporting us!

We asked the students to write a short introduction about themselves and their project as you can see below. Expect more information about each project to be published as the GSoC 2012 unfolds.

Edo Monticelli

Hi,

my name is Edo Monticelli, I was born in Cremona, Italy, 27 years ago. I am currently attending the last year of Master's in Computer Science at the University of Trento. My favourite programming languages are C and Python and I like functional programming too.

During my studies I attended several courses on various networking topics, including nomadic communications and mesh networking. I am really interested in Free Software philosophy and excited by the possibility to participate! I hope that Google Summer of Code will be a good way to further improve my coding skills and to help the community!

My GSOC project aims at the implementation of a tool for throughput measurement. This will be a lightweight, kernel space tool: user space programs, like iperf or netperf, need a larger amount of computational resources to align data and copy it between kernel and user memory. This workload may be too much on routers or similar devices and lead to wrong test results. My tool will implement a much simplified version of TCP to give an idea of the throughput that can be obtained between two nodes.

Further details and the project state can be found at the project wiki: bandwidth meter

Spyros Gasteratos

Hi,

My name is Spyros Gasteratos, I'm 22 years old, I live in Greece and I'm currently attending the 5th year of a Bachelor in Computer Science at the National University of Athens.
I got involved with batman-adv in the last battle-mesh(2012) and when I dont work for my project I try to get my degree.
My project is the implementation of backwards compatibility in batman-adv by use of TVLVs.
Further details and the project state can be found at the project wiki: TVLV project.

Martin Hundebøll

Hi,

my name is Martin Hundebøll, currently 27 summers old and living Denmark. I finished my master in Networks and Distributed Systems last summer and started my PhD in October. I got introduced to batman-adv through my master thesis, which was about Network Coding in Wireless Mesh Networks, for which we obviously needed a routing protocol :)

My current contributions to batman-adv are the catwoman branch found on the git page and various minor patches. Besides working with batman-adv, I do the practical work in our research group, which covers implementing new ideas (when analysed and simulated by other group members) and configuring and maintaining test setups.

My GSOC project is to improve the current fragmentation functionality to support arbitrary packet types instead of just unicast packets. More information about the projects and its progress is found at Fragmentation.

(71-80/118)

Also available in: Atom