Project

General

Profile

News

Batman-adv 2013.2.0 released

Added by Marek Lindner almost 12 years ago

The B.A.T.M.A.N. team is delighted to announce its latest release - batman-adv 2013.2.0 - introducing a complete new submodule for optimized packet transport, new features and our regular set of bugfixes. 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.2.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

The highlight of this release certainly is the newly added network coding support. Network Coding aims to improve transmission efficiency to preserve precious air time. The principle behind network coding builds upon wireless being a shared medium and exploiting this fact to our advantage (given that the situation allows to do so). The increased efficiency is achieved by combining two packets into a single transmission that is received by 2 destinations at the same time (due to the aforementioned shared medium characteristics). Tests have shown an increase in performance of up to 60% due to this clever mechanism. Exhaustive documentation has been made available for the curious reader explaining every detail regarding configuration, implementation and future work.

Henceforward, batman-adv interfaces can be configured via the rtnl interface configuration API in addition to the known sysfs API. The rtnl API offers a generic approach to configure all modern Linux interfaces which is used by utilities like 'ip'. As part of the interface API restructuring batman-adv also gained the ability to automatically resolve duplicate interface usage. For example, adding an interface to batman-adv while the interface still is part of a bridge will now result in the removal of the interface from the bridge without manual intervention. The identification of own mac addresses in multi-meshes setups (multiple batX interfaces on the same host) has been fixed and a necessary length check when parsing OGMs has been added.

batctl

To complement the network coding submodule a variety of new features went into batctl. It is now possible to enable/disable the network coding at runtime via a new commandline switch. Furthermore, batctl is able to print the network coding neighbor table and allows to configure the network coding log level for advanced debugging.
The minimal unicast 4addr dissector had incorrect size expectations which was fixed. The 4addr dissector learned to print the unicast 4addr subtype in order to facilitate keeping the individual 4addr types apart.

Happy routing,

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

Batman-adv 2013.1.0 released

Added by Marek Lindner about 12 years ago

Today, the B.A.T.M.A.N. team publishes batman-adv 2013.1.0 - a stability and bugfix release, addressing bugs and open issues only. No new features were added to ensure maximum stability. 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.1.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:

batman-adv

The translation table has been further polished by not adding multicast addresses to avoid interfering with multicast traffic. The output of the translation tables has been modified to not print the 'last seen' values for batX interfaces (these entries are never subject to purging). Moreover, the CRC consistency checksums are printed along with the rest of the table to facilitate debugging. As part of our ongoing effort to document the code itself the entire types.h file was 'kernel doc'-ified, thereby documenting the bulk of all struct definitions and defines used throughout the batman-adv code base. While reviewing and documenting all these definitions a few unused but forgotten variables we identified and removed, reducing the memory consumption by a few bytes.

The previously added distributed ARP table (DAT) received more testing and reviews which led to a number of fixes: ARP packets with invalid MAC or IP addresses are not added to the ARP table anymore. A potential crash due to a NULL pointer dereference in the hash collision avoidance section was fixed. The batman-adv interface removal could lead to deadlock in the kernel if it was triggered at the wrong moment. To resolve the issue the internal interface cleanup is delayed until all necessary locks can safely be acquired. The initialization of the lockdep class keys for has structures inside batman-adv has been improved to mitigate false warnings when running lockdep to find problems in the locking routines.

batctl

The snprintf() handling in various components has been revised to avoid a potential crash due to missing '\0' delimiter at the end of the string.

Happy routing,

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

The B.A.T.M.A.N. project endorses the Battle of the Mesh v6

Added by Simon Wunderlich about 12 years ago

The Wireless Battle of the Mesh is an event that aims to bring together people from across the globe to test the performance of different routing protocols for ad-hoc networks, like Babel, B.A.T.M.A.N., BMX, OLSR, and 802.11s. Of course, new protocols (working on OpenWRT ) are always welcome!

This year the even will take place from Monday 15th till Sunday 21st of April at the University of Aalborg, Denmark.

The B.A.T.M.A.N. project endorses and supports the Battle of the Mesh v6 because of the efforts made by its community to advance the field of wireless mesh networking and foster the development of grassroots community networks. As last year, many members of the B.A.T.M.A.N. team will gather at the event to attend the B.A.T.M.A.N. developer meeting and present, discuss and experiment with new ideas. Above all, we are all looking forward to connect with interesting people at this event!

The B.A.T.M.A.N. project will support the event by:

  • help to promote the event
  • numerous members of the B.A.T.M.A.N. community have already confirmed their attendance
  • co-fund travel costs for attendees from South America
  • give talks about advancement of our community in certain aspects
  • help setting up testbed for protocol testing

Of course, we are available for discussions, ideas, and live tests!

Many other communities endorse and support the Wireless Battle of The Mesh v6, an up to date list of the endorsers of the Battlemesh v6 can be found at the main Battlemesh website.

Batman-adv 2013.0.0 released

Added by Marek Lindner over 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 over 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 over 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 over 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. 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 over 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 over 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 over 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

(71-80/121)

Also available in: Atom