Project

General

Profile

News

Open-Mesh: GSoC 2012: Edo Monticelli's Final Report

Added by Simon Wunderlich over 11 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.

Open-Mesh: GSoC 2012: Spyros Gasteratos' Final Report

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

Open-Mesh: Layer 2 fragmentation

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

Open-Mesh: Batman-adv 2012.3.0 released

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

Open-Mesh: GSoC 2012 Midterm Interview

Added by Simon Wunderlich over 11 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

Open-Mesh: Batman-adv 2012.2.0 released

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

Open-Mesh: GSOC 2012: The students and their projects

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

Open-Mesh: Translation table in a nutshell

Added by Marek Lindner almost 12 years ago

For quite some time the term "translation table" keeps showing up in emails, release announcements and patches but why making such a fuzz about it ? The initial translation table release (batman-adv 2011.3.0) appeared a number of months ago and still, code refinements as well as new translation table features find their way into each release. It is about time to shed some light on what makes the translation table a vital component of a batman-adv mesh network.

The translation table

In most batman-adv mesh networks you have the mesh nodes building the backbone of your network and a number of ordinary (non-mesh) clients using the mesh network to exchange data amongst each other or to connect to external networks (e.g. the internet). Since the non-mesh clients do not participate in the mesh itself a mechanism is needed to share the information about the client's location within the network. That is the primary task of the translation table: At every given moment it knows which non-mesh client is connected to the mesh network via which batman-adv node. Without this information non-mesh clients would not be able to receive any traffic because no other node would know where to send the packets to.

One of the new concepts introduced with the translation table is the versioning of local changes. All non-mesh clients connecting or disconnecting from a mesh node within an OGM interval belong to the same translation table version. Once the translation table changes the new version is published in the network allowing neighbor nodes to request a translation table diff instead of the whole table, thereby drastically reducing the overhead. It also is possible to ask his direct neighbor for the current translation table of any other mesh node in the network as the tables can be identified using the version number. Large mesh networks do not need to retrieve the translation table from the far end of the mesh but can simply query their neighbors.

More features

Due to the extensible nature of the translation table a number of features could be built on top of it. Notable examples are the AP Isolation and fast roaming support. With mobile devices getting more and more popular roaming is an often requested feature. To avoid connection loss while moving from one mesh node to the next it is imperative to sync all involved nodes about the non-mesh client's new location as fast as possible.

In order to illustrate the difficulty and how the translation table code handles this situation it is best to look at an example. Here we have a non-mesh client exchanging data with node1 while being connected to node9.

As soon as the non-mesh client roams from node9 to node10 the stream is disconnected until node1 learns the new location of our client. Depending on various parameters this synchronization can take a long time. This is how the old mechanism (pre translation table) recovered while running a 5sec OGM interval with 25% packet loss between each node (the blue bar marks the roaming event):

The old mechanism needed roughly 65 seconds to recover the stream from the client's roaming. Testing the translation table under the same circumstances looks much better:

Further reading

All this merely is the tip of the iceberg. The translation table is the key player when it comes to integrating non-mesh clients as efficiently as possible. A number of documents are available for the curious reader:

Happy routing,

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

Open-Mesh: Batman-adv 2012.1.0 released

Added by Marek Lindner almost 12 years ago

The B.A.T.M.A.N. team is delighted to announce its newest release, 2012.1.0, bringing mainly bug fixes and code cleanups. Also part of the release is a newly developed routing algorithm framework which allows switching between different routing algorithms. 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.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 or rigorous testing:

batman-adv

Most changes coming with this release happened under the hood to either improve stability or pave the way for new features, most notably the routing algorithm abstraction. Over the last months several ideas centering around the question how to improve the current routing algorithm have surfaced. To better experiment with these ideas while keeping a working system for our users the routing algorithm abstraction was added. It allows to easily develop and test new routing concepts while taking advantage of the existing batman-adv features and infrastructure. The API will be further refined with the next releases to enable alternative algorithms to be included as well.
The translation table code received further attention which led to the discovery of endless loops in the tt-request mechanism (under certain circumstances). This was addressed along with a TT_CLIENT_NEW flag race condition when a new client was added to the internal hash. All batman-adv internal timeouts have been converted to milliseconds for consistency purposes. Even the batman-adv makefile was modernized to provide an install target and a selection system for conveniently compiling features into the module.

batctl

Each batman-adv (layer 2) ICMP packet used to ping or traceroute a node comes with a sequence number to detect failures. Prior to this release batctl ping/traceroute did not compare the outgoing sequence number with the incoming sequence number to verify whether they indeed match. In WiFi environments exhibiting high packet loss and excessive packet retransmissions this missing check led to false results.
Furthermore, the return code of batctl ping was improved to properly indicate a failure.

Happy routing,

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

(71-80/115)

Also available in: Atom