The B.A.T.M.A.N. team is pleased to announce the immediate availability of batman-adv 2014.0.0 - a release coming with a rewritten packet handling engine and many new features almost uniquely tailored to preserve backward compatibility in the future. 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:
http://downloads.open-mesh.org/batman/releases/batman-adv-2014.0.0/
as well as prepackaged binaries in your distribution.
Important changes -----------------
*Compatibility break*: In 2011, batman-adv broke backward compatibility with the introduction of the translation table mechanism. Since then, interests have been divided between those who wish a stable network with as little changes as possible and those who wish to experiment with new features to bring meshing to the next level. To accommodate both groups the batman-adv developers dedicated a lot of effort on building code infrastructure allowing to mix stable nodes with new features without breaking compatibility. This new system is incompatible to the pre-2014.0.0 versions, but it has been designed to stay compatible with future versions for the next decade or so.
At the same time, the legacy visualization support was removed from the kernel module. The alfred user space module provides an adequate replacement.
Thanks ------
Thanks to all people sending in patches:
* Antonio Quartulli antonio@meshcoding.com * Joe Perches joe@perches.com * Linus Lüssing linus.luessing@web.de * Marco Dalla Torre marco.dallato@gmail.com * Marek Lindner mareklindner@neomailbox.ch * Martin Hundebøll martin@hundeboll.net * Simon Wunderlich sw@simonwunderlich.de * Spyros Gasteratos morfeas3000@gmail.com * Sven Eckelmann sven@narfation.org * Tan Xiaojun tanxiaojun@huawei.com
batman-adv ----------
Transforming a rather static design to a module architecture in the interest of preserving backward compatibility requires modifications on a multitude of levels. The principal idea behind the TVLV (type-version-length-value) infrastructure is to break up mesh management data into logic chunks (containers) which can be extended in the future while preserving backward compatibility. If a mesh participant receives an unknown TVLV type or version of a certain container it can simply skip the current container and proceed with the next. Therefore, all non-routing data sent with OGMs (e.g. gateway advertisement, translation table data, etc) were transformed to TVLV containers that are still attached to OGMs. In addition, translation table request & response packets as well as roaming advertisement packets were transformed to TVLV containers too. While designing the containers a couple of feature requests were also addressed: The compressed download & upload gateway bandwidth (known as 'gateway class') was replaced by uncompressed bandwidth information permitting granular gateway bandwidth announcement. DAT and network coding feature support is communicated into the mesh through TVLV containers as both subsystems optimize their performance based on the knowledge which mesh participant has the feature enabled. In the interest of backward compatibility on the packet forwarding level batman-adv received a general unicast packet forwarding mechanism. This mechanism forwards or drops unknown packet types based on the packet type numbering.
The batman-adv built-in packet fragmentation has been redesigned and rewritten as part of the 'fragmentation 2' Google Summer of Code project. Major design goals include: Variable number of fragments (up to 16), generic fragmentation framework capable of handling all types of traffic (the 'old' fragmentation code was limited to payload unicast packets) and 'upper layer' transparency through early re-assembly. The maximum of local clients the translation table is able to handle went up by a factor of 16 (the maximum number of fragmented packets) as full translation table exchanges are able to take advantage of the newly introduced generic fragmentation. If the fragmentation is disabled or the MTU altered the local translation table is automatically reduced to fit the new maximum translation table size. Part of the increased maximum table size is the transition from CRC16 consistency checksumming to CRC32 to reduce collision probability and take advantage of hardware acceleration support. The translation table also gained full VLAN awareness making it the final component receiving full VLAN support. Non-mesh clients are now entirely separated on a per-VLAN basis. As a consequence, the bridge loop avoidance is capable of resolving bridge loops more elegantly (one VLAN might be bridged into the LAN while another one is not), the Distributed ARP Table (DAT) builds its distributed IP-MAC address hash on a per-VLAN basis and the AP isolation allows fine-grained control over which VLAN should be isolated and which should not.
The kernel module sets a dummy rx mode handler on batman-adv' virtual interface creation to be able to accepts static multicast listener configurations on top of the batX interface. In order to help wireless drivers to select the suitable traffic queue (e.g. WMM queues), batman-adv peeks into the encapsulated payload IP or VLAN header and sets the skb priority field accordingly. This priority field is used whenever the lower layer drivers (like wireless or ethernet drivers) are unable to retrieve the prioritization themselves due to the batman-adv traffic encapsulation.
batctl ------
As part of our ongoing effort for better IPv6 support quite a few missing pieces have been tackled: The IP-address-to-MAC-address resolver was extended to also support IPv6 addresses. This was achieved by porting the internal resolver from the '/proc/net/arp' based approach to the RTNL API. As a result the translate, ping and traceroute commands accept IPv6 addresses as destination argument which batctl tries to convert back to MAC addresses in similar to the IPv4 conversion. Furthermore, the tcpdump component was enriched with an IPv6 parser being able to decapsulate TCP, UDP and common ICMPv6 packet types. The vis export feature has been removed as the kernel module no longer supports the visualization protocol. A number of cleanups and smaller fixes such as marking local functions as static, adding header include guards and more found their way into this release as well.
alfred ------
The missing libmath linker flag of the alfred-gpsd component was fixed and its manpage installation arranged.
Happy routing, The B.A.T.M.A.N. team
Hello
Withing the next month or 2 i will be deploying new firmware in my mesh overseas. I am now testing 2014 and if everything seems ok; the new builds will have and i can report results. (my current build that was to be deployed has 2013.4.0-1 v14.
Has anyone started any tests ? If so any results or conclusions in comparison to previous versions ?
Regarding the docs @ http://www.open-mesh.org/projects/batman-adv/wiki/Batman-adv-openwrt-config are they to be updated or to stay as they are ?
The reason i ask is because there seems to be necessary changes such as:
batman_adv: bat0: The MTU of interface adhoc0 is too small (1528) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1546 would solve the problem.
Are there any other changes hat may need to be done for 2014 ?
On 01/07/2014 07:53 AM, Marek Lindner wrote:
The B.A.T.M.A.N. team is pleased to announce the immediate availability of batman-adv 2014.0.0 - a release coming with a rewritten packet handling engine and many new features almost uniquely tailored to preserve backward compatibility in the future. 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:
http://downloads.open-mesh.org/batman/releases/batman-adv-2014.0.0/
as well as prepackaged binaries in your distribution.
Important changes
*Compatibility break*: In 2011, batman-adv broke backward compatibility with the introduction of the translation table mechanism. Since then, interests have been divided between those who wish a stable network with as little changes as possible and those who wish to experiment with new features to bring meshing to the next level. To accommodate both groups the batman-adv developers dedicated a lot of effort on building code infrastructure allowing to mix stable nodes with new features without breaking compatibility. This new system is incompatible to the pre-2014.0.0 versions, but it has been designed to stay compatible with future versions for the next decade or so.
At the same time, the legacy visualization support was removed from the kernel module. The alfred user space module provides an adequate replacement.
Thanks
Thanks to all people sending in patches:
- Antonio Quartulli antonio@meshcoding.com
- Joe Perches joe@perches.com
- Linus Lüssing linus.luessing@web.de
- Marco Dalla Torre marco.dallato@gmail.com
- Marek Lindner mareklindner@neomailbox.ch
- Martin Hundebøll martin@hundeboll.net
- Simon Wunderlich sw@simonwunderlich.de
- Spyros Gasteratos morfeas3000@gmail.com
- Sven Eckelmann sven@narfation.org
- Tan Xiaojun tanxiaojun@huawei.com
batman-adv
Transforming a rather static design to a module architecture in the interest of preserving backward compatibility requires modifications on a multitude of levels. The principal idea behind the TVLV (type-version-length-value) infrastructure is to break up mesh management data into logic chunks (containers) which can be extended in the future while preserving backward compatibility. If a mesh participant receives an unknown TVLV type or version of a certain container it can simply skip the current container and proceed with the next. Therefore, all non-routing data sent with OGMs (e.g. gateway advertisement, translation table data, etc) were transformed to TVLV containers that are still attached to OGMs. In addition, translation table request & response packets as well as roaming advertisement packets were transformed to TVLV containers too. While designing the containers a couple of feature requests were also addressed: The compressed download & upload gateway bandwidth (known as 'gateway class') was replaced by uncompressed bandwidth information permitting granular gateway bandwidth announcement. DAT and network coding feature support is communicated into the mesh through TVLV containers as both subsystems optimize their performance based on the knowledge which mesh participant has the feature enabled. In the interest of backward compatibility on the packet forwarding level batman-adv received a general unicast packet forwarding mechanism. This mechanism forwards or drops unknown packet types based on the packet type numbering.
The batman-adv built-in packet fragmentation has been redesigned and rewritten as part of the 'fragmentation 2' Google Summer of Code project. Major design goals include: Variable number of fragments (up to 16), generic fragmentation framework capable of handling all types of traffic (the 'old' fragmentation code was limited to payload unicast packets) and 'upper layer' transparency through early re-assembly. The maximum of local clients the translation table is able to handle went up by a factor of 16 (the maximum number of fragmented packets) as full translation table exchanges are able to take advantage of the newly introduced generic fragmentation. If the fragmentation is disabled or the MTU altered the local translation table is automatically reduced to fit the new maximum translation table size. Part of the increased maximum table size is the transition from CRC16 consistency checksumming to CRC32 to reduce collision probability and take advantage of hardware acceleration support. The translation table also gained full VLAN awareness making it the final component receiving full VLAN support. Non-mesh clients are now entirely separated on a per-VLAN basis. As a consequence, the bridge loop avoidance is capable of resolving bridge loops more elegantly (one VLAN might be bridged into the LAN while another one is not), the Distributed ARP Table (DAT) builds its distributed IP-MAC address hash on a per-VLAN basis and the AP isolation allows fine-grained control over which VLAN should be isolated and which should not.
The kernel module sets a dummy rx mode handler on batman-adv' virtual interface creation to be able to accepts static multicast listener configurations on top of the batX interface. In order to help wireless drivers to select the suitable traffic queue (e.g. WMM queues), batman-adv peeks into the encapsulated payload IP or VLAN header and sets the skb priority field accordingly. This priority field is used whenever the lower layer drivers (like wireless or ethernet drivers) are unable to retrieve the prioritization themselves due to the batman-adv traffic encapsulation.
batctl
As part of our ongoing effort for better IPv6 support quite a few missing pieces have been tackled: The IP-address-to-MAC-address resolver was extended to also support IPv6 addresses. This was achieved by porting the internal resolver from the '/proc/net/arp' based approach to the RTNL API. As a result the translate, ping and traceroute commands accept IPv6 addresses as destination argument which batctl tries to convert back to MAC addresses in similar to the IPv4 conversion. Furthermore, the tcpdump component was enriched with an IPv6 parser being able to decapsulate TCP, UDP and common ICMPv6 packet types. The vis export feature has been removed as the kernel module no longer supports the visualization protocol. A number of cleanups and smaller fixes such as marking local functions as static, adding header include guards and more found their way into this release as well.
alfred
The missing libmath linker flag of the alfred-gpsd component was fixed and its manpage installation arranged.
Happy routing, The B.A.T.M.A.N. team
Hi,
On 2014-01-14 23:04, cmsv wrote:
batman_adv: bat0: The MTU of interface adhoc0 is too small (1528) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1546 would solve the problem.
Did you enable network coding? That would explain the message, as NC uses a larger header to make decoding possible at the receiver side.
As far as I can tell from a quick look in packet.h, the required MTU should be 1532 now. (10 bytes unicast + 8 bytes extra for unicast_4addr + 14 ethernet = 32 bytes). Or am I bad at counting bytes?
// Martin
inline:
On 01/15/2014 02:00 AM, Martin Hundebøll wrote:
Hi,
On 2014-01-14 23:04, cmsv wrote:
batman_adv: bat0: The MTU of interface adhoc0 is too small (1528) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1546 would solve the problem.
Did you enable network coding? That would explain the message, as NC uses a larger header to make decoding possible at the receiver side.
Yes it is enabled by default as it was with batavd 2013.4.0 with 1528 mtu
As far as I can tell from a quick look in packet.h, the required MTU should be 1532 now. (10 bytes unicast + 8 bytes extra for unicast_4addr
- 14 ethernet = 32 bytes). Or am I bad at counting bytes?
Regardless of being properly counted or not; dmesg outputs the message complaining about the need to make mtu 1546.
// Martin
On 15/01/14 12:13, cmsv wrote:
inline:
On 01/15/2014 02:00 AM, Martin Hundebøll wrote:
Hi,
On 2014-01-14 23:04, cmsv wrote:
batman_adv: bat0: The MTU of interface adhoc0 is too small (1528) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1546 would solve the problem.
Did you enable network coding? That would explain the message, as NC uses a larger header to make decoding possible at the receiver side.
Yes it is enabled by default as it was with batavd 2013.4.0 with 1528 mtu
As far as I can tell from a quick look in packet.h, the required MTU should be 1532 now. (10 bytes unicast + 8 bytes extra for unicast_4addr
- 14 ethernet = 32 bytes). Or am I bad at counting bytes?
Regardless of being properly counted or not; dmesg outputs the message complaining about the need to make mtu 1546.
If you disable network coding the message will change.
The overhead is dynamic depending on NC being enabled or not and now the message in dmesg tells you exactly what MTU you need.
Cheers,
On 01/15/2014 06:15 AM, Antonio Quartulli wrote:
On 15/01/14 12:13, cmsv wrote:
inline:
On 01/15/2014 02:00 AM, Martin Hundebøll wrote:
Hi,
On 2014-01-14 23:04, cmsv wrote:
batman_adv: bat0: The MTU of interface adhoc0 is too small (1528) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1546 would solve the problem.
Did you enable network coding? That would explain the message, as NC uses a larger header to make decoding possible at the receiver side.
Yes it is enabled by default as it was with batavd 2013.4.0 with 1528 mtu
As far as I can tell from a quick look in packet.h, the required MTU should be 1532 now. (10 bytes unicast + 8 bytes extra for unicast_4addr
- 14 ethernet = 32 bytes). Or am I bad at counting bytes?
Regardless of being properly counted or not; dmesg outputs the message complaining about the need to make mtu 1546.
If you disable network coding the message will change.
The overhead is dynamic depending on NC being enabled or not and now the message in dmesg tells you exactly what MTU you need.
Yes i understand that but it keeps on increasing. [ 28.600000] batman_adv: bat0: The MTU of interface adhoc0 is too small (1546) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1560 would solve the problem.
Cheers,
On 21/01/14 21:01, cmsv wrote:
Yes i understand that but it keeps on increasing. [ 28.600000] batman_adv: bat0: The MTU of interface adhoc0 is too small (1546) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1560 would solve the problem.
Have you tried applying this patch before testing it once again?
http://git.open-mesh.org/batman-adv.git/commit/746d6436f88899a79c1cb3b27af06...
Cheers,
On 22/01/14 01:00, Antonio Quartulli wrote:
On 21/01/14 21:01, cmsv wrote:
Yes i understand that but it keeps on increasing. [ 28.600000] batman_adv: bat0: The MTU of interface adhoc0 is too small (1546) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1560 would solve the problem.
Have you tried applying this patch before testing it once again?
http://git.open-mesh.org/batman-adv.git/commit/746d6436f88899a79c1cb3b27af06...
Actually this patch is already part of the batman-adv package in openwrt. Therefore the question turns in: did you update the batman-adv package before performing your second test?
Cheers,
In regards to incompatibility with pre-2014.0.0 versions; will 2013.4.0 branch have any continued support with patches or even updated version or any support pre-2014.0.0 is not expected or planed ?
On 01/07/2014 07:53 AM, Marek Lindner wrote:
Important changes
*Compatibility break*: In 2011, batman-adv broke backward compatibility with the introduction of the translation table mechanism. Since then, interests have been divided between those who wish a stable network with as little changes as possible and those who wish to experiment with new features to bring meshing to the next level. To accommodate both groups the batman-adv developers dedicated a lot of effort on building code infrastructure allowing to mix stable nodes with new features without breaking compatibility. This new system is incompatible to the pre-2014.0.0 versions, but it has been designed to stay compatible with future versions for the next decade or so.
At the same time, the legacy visualization support was removed from the kernel module. The alfred user space module provides an adequate replacement.
Thanks
On 10/02/14 20:45, cmsv wrote:
In regards to incompatibility with pre-2014.0.0 versions; will 2013.4.0 branch have any continued support with patches or even updated version or any support pre-2014.0.0 is not expected or planed ?
The core group (read: the most active developers) are not going to maintain any pre-2014.0.0 branch. The code base in 2014.0.0 is rather different wrt older versions therefore any "backport" will be really expensive in terms of time and effort.
Only crucial bugfixes are going to be ported to older versions (by means of our maint branch - for a limited time - and the stable kernel releases).
However nobody prevents anyone from the community to take over this task.
Cheers,
On Mon, Feb 10, 2014 at 02:45:11PM -0500, cmsv wrote:
In regards to incompatibility with pre-2014.0.0 versions; will 2013.4.0 branch have any continued support with patches or even updated version or any support pre-2014.0.0 is not expected or planed ?
We are planning to mantain a compat-14 branch for a couple of months here:
https://github.com/freifunk-gluon/batman-adv-legacy
Contributions welcome :).
Cheers, Linus
On Monday 10 February 2014 22:49:09 Linus Lüssing wrote:
On Mon, Feb 10, 2014 at 02:45:11PM -0500, cmsv wrote:
In regards to incompatibility with pre-2014.0.0 versions; will 2013.4.0 branch have any continued support with patches or even updated version or any support pre-2014.0.0 is not expected or planed ?
We are planning to mantain a compat-14 branch for a couple of months here:
https://github.com/freifunk-gluon/batman-adv-legacy
Contributions welcome :).
As already mentioned on IRC: We can easily host your batman-adv-legacy code on open-mesh.org next to the other repositories. That'll make it easier for other people to find it and may appear to be more 'official'.
Cheers, Marek
b.a.t.m.a.n@lists.open-mesh.org