B.A.T.M.A.N

b.a.t.m.a.n@lists.open-mesh.org

15 participants
4308 discussions

[B.A.T.M.A.N.] [PATCH-maint] batman-adv: Calculate extra tail size based on queued fragments
by Sven Eckelmann 08 Dec '14

08 Dec '14

3 2

[B.A.T.M.A.N.] Bridging multiple mesh segments across WAN
by tjhowse 02 Dec '14

02 Dec '14

Hi All, I've partially covered a large site in routers running batman-adv. The mesh is used for mobile access to equipment on a static site copper and fibre network around the site. A few of the routers have WAN connections to the site network. The routers with WAN connections are configured as gateways in batman-adv. There are gaps in the mesh; typically there is no route between WAN-connected routers via the mesh. I would like to join up the separate mesh segments, via the site network, such that a client to one segment can ping a client of another network, having the traffic transparently tunnel via the WAN. Has anyone looked at doing this in the past? Thanks, Travis.

2 3

Re: [B.A.T.M.A.N.] [PATCH 30/31] batman-adv: packet.h, add some missing includes
by Sven Eckelmann 02 Dec '14

02 Dec '14

Hi, please explain how this file can now be used unmodified in userspace (batctl) and kernel. If it cannot be done without modifying the file then please provide patches to modify the daily checks which make sure that the files in both repos are the same. I think the batman-adv developers can give you the original scripts. Kind regards, Sven

2 4

Re: [B.A.T.M.A.N.] [PATCH 08/31] batman-adv: hash, remove function implementations from header
by Sven Eckelmann 02 Dec '14

02 Dec '14

Hi, just for your information about the hashtable helper functions and why I think all related patches should be rejected: https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2010-September/003458.html https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2010-October/003495.html Kind regards, Sven

2 1

[B.A.T.M.A.N.] [RFC] batman-adv: Calculate extra tail size based on queued fragments
by Sven Eckelmann 01 Dec '14

01 Dec '14

The fragmentation code was replaced in 9b3eab61754d74a93c9840c296013fe3b4a1b606 ("batman-adv: Receive fragmented packets and merge"). The new code provided a mostly unused parameter skb for the merging function. It is used inside the function to calculate the additionally needed skb tailroom. But instead of increasing its own tailroom, it is only increasing the tailroom of the first queued skb. This is not correct in most situations because the first queued entry can be a different one than the parameter. An observed problem was: 1. packet with size 104, total_size 1464, fragno 1 was received - packet is queued 2. packet with size 1400, total_size 1464, fragno 0 was received - packet is queued at the end of the list 3. enough data was received and can be given to the merge function (1464 == (1400 - 20) + (104 - 20)) - merge functions gets 1400 byte large packet as skb argument 4. merge function gets first entry in queue (104 byte) - stored as skb_out 5. merge function calculates the required extra tail as total_size - skb->len - pskb_expand_head tail of skb_out with 64 bytes 6. merge function tries to squeeze the extra 1380 bytes from the second queued skb (1400 byte aka skb parameter) in the 64 extra tail bytes of skb_out Instead take only skbs from the queue to merge a packet and remove the problematic parameter. Signed-off-by: Sven Eckelmann <sven(a)narfation.org> Reported-by: Philipp Psurek <philipp.psurek(a)gmail.com> --- This patch requires also the patch "Check total_size when reassembling fragments" to be applied. This is only compile tested. fragmentation.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/fragmentation.c b/fragmentation.c index c741318..aeaf1ab 100644 --- a/fragmentation.c +++ b/fragmentation.c @@ -228,18 +228,13 @@ err: * Returns the merged skb or NULL on error. */ static struct sk_buff * -batadv_frag_merge_packets(struct hlist_head *chain, struct sk_buff *skb) +batadv_frag_merge_packets(struct hlist_head *chain) { struct batadv_frag_packet *packet; struct batadv_frag_list_entry *entry; struct sk_buff *skb_out = NULL; int size, hdr_size = sizeof(struct batadv_frag_packet); - - /* Make sure incoming skb has non-bogus data. */ - packet = (struct batadv_frag_packet *)skb->data; - size = ntohs(packet->total_size); - if (size > batadv_frag_size_limit()) - goto free; + int extra_tail; /* Remove first entry, as this is the destination for the rest of the * fragments. @@ -249,11 +244,17 @@ batadv_frag_merge_packets(struct hlist_head *chain, struct sk_buff *skb) skb_out = entry->skb; kfree(entry); + packet = (struct batadv_frag_packet *)skb_out->data; + size = ntohs(packet->total_size); + /* Make room for the rest of the fragments. */ - if (pskb_expand_head(skb_out, 0, size - skb->len, GFP_ATOMIC) < 0) { - kfree_skb(skb_out); - skb_out = NULL; - goto free; + if (size > skb_out->len) { + extra_tail = size - skb_out->len; + if (pskb_expand_head(skb_out, 0, extra_tail, GFP_ATOMIC) < 0) { + kfree_skb(skb_out); + skb_out = NULL; + goto free; + } } /* Move the existing MAC header to just before the payload. (Override @@ -304,7 +305,7 @@ bool batadv_frag_skb_buffer(struct sk_buff **skb, if (hlist_empty(&head)) goto out; - skb_out = batadv_frag_merge_packets(&head, *skb); + skb_out = batadv_frag_merge_packets(&head); if (!skb_out) goto out_err; -- 2.1.3

2 5

[B.A.T.M.A.N.] Fragmentation and padding in batman-adv
by Sven Eckelmann 01 Dec '14

01 Dec '14

Hi, I've just noticed that the padding by the underlying network protocol seems not to be handled by the fragmentation. Maybe Martin can correct me. I will now use following assumptions: * the fragmentation code is sending first the last part of the packet and tries to fill the complete skb (max 1400 byte) * the mtu of the underlying device is 1400 * the minimum packet size (user data + eth header) of the underlying device is 70 * the packet send by the user would end up to be 1401 bytes before fragmentation Ok, then I would guess that the fragmentation code would try to generate fragments with the max_fragment_size 1366 (+headers of course, not sure why the code assumes that the ethernet header is part of the MTU). This would mean that the 1401 byte packet is split into a 1366 byte fragment (+header) and a 35 byte fragment (+header). But the 35 byte fragment containing the first part of the packet is (even with the headers) still smaller than the required packet size of the underlying device. Now some extra bytes are added as padding to the last fragment (containing the first part of the original packet). The receiving node cannot merge the fragments anymore because the length of the last fragment skb will be too large and therefore the total_size < chain->size. Even when it could be merged (because of some bug in the size check) then the resulting packet would have a padding byte in the middle of of the original byte. And just in case somebody has something against the imaginary 70 bytes padding (802.3 has 60): I had to work with virtual devices in the past which had a fixed MTU of ~1400 and a minimum packet size of ~1400. And yes, I am fully aware of the workaround of using an extra virtual device between batman-adv and the actual device which only adds a header with the payload length and restores this length on the receiver site. This (or at least something similar) was used by me in the other project with the MTU/min packet size of ~1400 device. Any comments, corrections? Kind regards, Sven

2 2

[B.A.T.M.A.N.] [PATCH-maint] batman-adv: Check total_size when reassembling fragments
by Sven Eckelmann 01 Dec '14

01 Dec '14

The fragmentation code was replaced in 9b3eab61754d74a93c9840c296013fe3b4a1b606 ("batman-adv: Receive fragmented packets and merge") by an implementation which handles the queueing+merging of fragments based on their size and the total_size of the non-fragmented packet. This total_size is announced by each fragment. The new implementation doesn't check if the the total_size information of the packets inside one chain is consistent. This allows an attacker to inject packets belonging to the same fragmentation sequence number with varying total_size information. The missing validation can cause a crash when the fragments are merged because the total_size information is only retrieved from the first packet by batadv_frag_merge_packets. But the queueing function batadv_frag_insert_packet always uses the total_size from the latest packet to check if the fragmented packet was transferred completely and is now ready to be merged. Assume two packets with the size x and y. 1. first packet (fragno 1) is sent with a size x and the total_size x+y' (y' < y) 2. second packet (fragno 0) is sent with a size y and the total_size x+y The fragmentation code would try to merge the two packets because the accumulated packets have a combined size of x+y and the second packet was sent with total_size of x+y. The fragments merging code only took the information from the first packet with the total_size x+y' and created a buffer with enough space for x+y' bytes. But the second packet cannot be copied inside the prepared free space because it is y-y' bytes larger than the remaining space. Signed-off-by: Sven Eckelmann <sven(a)narfation.org> Acked-by: Martin Hundebøll <martin(a)hundeboll.net> --- This is only a resend of the patch https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-November/012584.html This was necessary because the mail thread was hijacked by others who started to discuss a different problem which may or may not be caused by the fragmentation code (or batman-adv at all). At least they removed me from the Cc so I had not received their "responses". This also gave me the opportunity to change some words in the commit message. --- fragmentation.c | 7 +++++-- types.h | 2 ++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/fragmentation.c b/fragmentation.c index 362e91a..3a19d4d 100644 --- a/fragmentation.c +++ b/fragmentation.c @@ -161,6 +161,7 @@ static bool batadv_frag_insert_packet(struct batadv_orig_node *orig_node, hlist_add_head(&frag_entry_new->list, &chain->head); chain->size = skb->len - hdr_size; chain->timestamp = jiffies; + chain->total_size = ntohs(frag_packet->total_size); ret = true; goto out; } @@ -195,9 +196,11 @@ static bool batadv_frag_insert_packet(struct batadv_orig_node *orig_node, out: if (chain->size > batadv_frag_size_limit() || - ntohs(frag_packet->total_size) > batadv_frag_size_limit()) { + chain->total_size != ntohs(frag_packet->total_size) || + chain->total_size > batadv_frag_size_limit()) { /* Clear chain if total size of either the list or the packet - * exceeds the maximum size of one merged packet. + * exceeds the maximum size of one merged packet. Don't allow + * packets to have different total_size. */ batadv_frag_clear_chain(&chain->head); chain->size = 0; diff --git a/types.h b/types.h index 462a70c..c4d7d24 100644 --- a/types.h +++ b/types.h @@ -132,6 +132,7 @@ struct batadv_orig_ifinfo { * @timestamp: time (jiffie) of last received fragment * @seqno: sequence number of the fragments in the list * @size: accumulated size of packets in list + * @total_size: expected size of the assembled packet */ struct batadv_frag_table_entry { struct hlist_head head; @@ -139,6 +140,7 @@ struct batadv_frag_table_entry { unsigned long timestamp; uint16_t seqno; uint16_t size; + uint16_t total_size; }; /** -- 2.1.3

1 1

[B.A.T.M.A.N.] [PATCH] batman-adv: Check size information when reassembling fragments
by Sven Eckelmann 30 Nov '14

30 Nov '14

The fragmentation code doesn't check if the the total_size information of the packets inside one chain is consistent. This allows an attacker to inject packets belonging to the same fragmentation sequence number with different total_size. This can cause a crash when these are assembled because the total_size information is only parsed from the first packet in batadv_frag_merge_packets but the queueing function always uses the total_size of the latest packet. Assume two packets with the size x and y. 1. first packet is sent with a size x and the total_size x+y' (y' < y) 2. second packet is sent with a size y and the total_size x+y The fragmentation code would try to assemble the two packets because the accumulated packets have a combined size of x+y and the second packet had the total_size of x+y. The fragmentation assembling code only took the information from the first packet with the total_size x+y' and create a packet with enough space for x+y' bytes. But the second packet cannot be copied inside the prepared free space because it is y-y' bytes larger than the remaining space. Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- This is only build tested. I've never spend time in creation of these packets to verify my claim. fragmentation.c | 7 +++++-- types.h | 2 ++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/fragmentation.c b/fragmentation.c index 362e91a..3a19d4d 100644 --- a/fragmentation.c +++ b/fragmentation.c @@ -161,6 +161,7 @@ static bool batadv_frag_insert_packet(struct batadv_orig_node *orig_node, hlist_add_head(&frag_entry_new->list, &chain->head); chain->size = skb->len - hdr_size; chain->timestamp = jiffies; + chain->total_size = ntohs(frag_packet->total_size); ret = true; goto out; } @@ -195,9 +196,11 @@ static bool batadv_frag_insert_packet(struct batadv_orig_node *orig_node, out: if (chain->size > batadv_frag_size_limit() || - ntohs(frag_packet->total_size) > batadv_frag_size_limit()) { + chain->total_size != ntohs(frag_packet->total_size) || + chain->total_size > batadv_frag_size_limit()) { /* Clear chain if total size of either the list or the packet - * exceeds the maximum size of one merged packet. + * exceeds the maximum size of one merged packet. Don't allow + * packets to have different total_size. */ batadv_frag_clear_chain(&chain->head); chain->size = 0; diff --git a/types.h b/types.h index 462a70c..c4d7d24 100644 --- a/types.h +++ b/types.h @@ -132,6 +132,7 @@ struct batadv_orig_ifinfo { * @timestamp: time (jiffie) of last received fragment * @seqno: sequence number of the fragments in the list * @size: accumulated size of packets in list + * @total_size: expected size of the assembled packet */ struct batadv_frag_table_entry { struct hlist_head head; @@ -139,6 +140,7 @@ struct batadv_frag_table_entry { unsigned long timestamp; uint16_t seqno; uint16_t size; + uint16_t total_size; }; /** -- 2.1.3

4 13

[B.A.T.M.A.N.] mib for batman-adv
by Lucas Aimaretto 28 Nov '14

28 Nov '14

Hi All, A simple question: is there any snmp MIB for batman-adv so we can gather routing information, that otherwise can only obtained by using batctl? Thanks! Lucas -- "Antes teníamos hambre y mirábamos el reloj para saber qué hora era. Ahora miramos el reloj para saber si tenemos hambre." -- Ernesto Sábato

2 1

[B.A.T.M.A.N.] wired only gigabit / 10 gigabit batman-adv mesh
by Mehul Sharma 28 Nov '14

28 Nov '14

Ok this is my 3rd attempt to see if this message makes it to the list :) .... during the attempts i have had the opportunity to understand some aspects clearly, thanks to the nice documentation and comments in the code. Hi Marek, Thanks for the explanation. One of the aims of the project (i.e the network part of it) is to use a mix of topologies (wired ethernet) with out the use of external switches (eg. top of the rack) / routers to connect machines (servers). The idea is to increase the bandwidth, increase the link utilization, bring about multiple paths to deal with link failures & also hop reduction to some sectors of the cluster. I am able to do this now with: 1) standard bridge + stp 2) standard bridge with no stp + logic to stop and forward traffic depending on the paths taken, hops involved and link utilization -- this is a hack on top of the ebtables and ip tables with code monitoring across the network. 3) use layer 3 OSPF or OLSR + layer 2 on top of it using meshed TINC VPN 4) proxy arp with separate forward / reverse rules (i.e separate routing tables / policy routing) + layer 2 tinc mesh on top of it The bottom line I am looking for something standard & flexible. Point 1, is standard and stable but not the flexibility i am looking for. Eg. with stp on, it puts a link (ethx device) in blocked mode where it detects a loop, to me this is a waste of a valid 10 gigabit or gigabit link which will only be utilized when a fail over happens. I would like to see more utilization of the link. So, i hacked up step 2, it would have been great if i had a majority of my time dedicated to it to build a kind of automation logic, but otherwise it is a manual time consuming setup. Point 3 works also but i would like to avoid pushing layer 2 over layer 3. Point 4, also works well, but i have to spend time convincing people that it is not arp-poisoning but rather arp-sweetening :) and most don't get that part :) (even if i tell them that your actual network (layer 2) will never see the communication at layer 3 below it. So, here i am, after years for some weird reason went back to the olsr page to see if there were some optimizations so that i could try / use it in place of ospf, and i came across batman-adv (it had been a while since i had done some deep dive wireless stuff), and quite frankly i could not believe it (i found it to have the best logic for next generation mesh networks ... others are entitled to their feelings / opinions). I took a look at the logic and architecture and got the feeling it had the potential to work in many ways better on wired ethernet than on wireless networks (due to the the wireless layer 1 link, frequency switching, CSMA and related complexities) .... i would like to continue the feeling for the sake of positivity and intuition :) What i saw (which could be my assumptive beliefs) was that batman-adv: 1) Most importantly could help in link utilization -- i read about network wide multi link optimizations [ alternating and bonding + alternating] 2) Path fail over -- use another path if the one it is currently using cannot be reached or another hop gets added. 3) Ease of setup -- adding the ethx devices to bat0 and adding bat0 to the bridge where other tap devices (virtual machines) and ethernet devices of existing wired network are present. 4) migration of non mesh clients, which might work for virtual machine migrations as well (not sure) 5) multicast, default gateway optimizations and wired back-bone loop prevention Yes, i understand that transmit quality (pertaining to link quality) is one of the main things batman-adv depends on for wireless networks (here i don't mean it might be checking quality of every link but instead checking if it sent / received certain internal packets within a certain time duration) , may be something of that nature for wired networks could be obtained by looking at hops involved per interface to reach the target and then setting penalty to that interface which has more hops (i think batman-adv might already be doing this). When compared with the bridge forwarding table look ups and then the actual forwarding, batman-adv's new network wide optimizations with maintaining separate routing table / list for separate interfaces involved in the mesh should not be a deterrent to speed, from my understanding the encapsulation of the ethernet frame into a batman-adv header may be an area of slow down comparatively (but then again this is done in kernel so speed should not be an issue especially with server cores involved). Just some thoughts, intuitive assumptions which may be totally wrong :) ..... i look forward to understanding more. Thanks & Best Regards, Mehul On Sun, Nov 16, 2014 at 1:08 AM, Marek Lindner <mareklindner(a)neomailbox.ch> wrote: Hi, > Good Afternoon from Boston. I really love Batman-Adv ... > brilliant layer 2 functionality. > > I want to use batman-adv in a wired (gigabit and 10-gigabit) only mesh and > wanted to know your insights. makes me happy to hear you love our project. Typically, we communicate via our public mailing list allowing various sources to chime in at any point. Since I don't see any reason for privacy I am cc'ing the mailing list in my answer. > The example case scenario is as follows: > > 1) 4 to 6 AMD servers with 6 10-Gigabit NICs each. > > 2) 2 or 3 10-Gigabit NICs used for batman-adv, which are then connected > in ring or torus topology directly (no external switch involved) > > 3) the remaining interfaces on the server are connected to the LAN > (switches, routers etc) > > 4) the virtual machine (qemu-kvm) tap interfaces, the physical > non-batman-adv ethernet and bat0 interfaces are put in a bridge (brctl), so > now we have the ability for virtual machines, wired hosts on the lan to go > via batman-adv and talk to each other. > > Is there any, down size to doing this? I see at the most 2 - 100 servers in > one network.... > > From what i understand: > > 1) that the live migration of virtual machines (qemu-kvm) will be seen > just as a migrating non-mesh client so my assumption is that live migration > should work from that perspective. Also, what if the tap interfaces of the > virtual machines are given to bat0 itself (if it might help in live > migration / increasing throughput) ? > > 2) The MTU if set for 1500 or 9000 or higher (eg barman-adv reads -- > "define ETHERMTU ETH_DATA_LEN") would be taken automatically by batman-adv > and anything below 1500 would be fragmented, which gives me the idea that > higher MTUs would not be a problem for batman-adv to handle. > > 3) There is no restriction to the number of clients in batman-adv. > > am i somewhat close in understanding batman-adv? .... apologies if not... > > Also would layer 2 forwarding by batman-adv would be close, same or better > when compared to bridge (linux brctl) packet forwarding? > > I have built converged-unified distributed qemu-kvm system (all metadata > less design, with web-interface and cli, quite the opposite of vmware and > open-stack type centralized approaches) and was in the preliminary stage of > looking at the possibility of integrating batman-adv into the design. > > Your input will be valuable for me to give server and desktop > virtualization a mesh architecture on top of already distributed design. I keep your description intact to allow other people to comment as well. Before we dive into the batman-adv details I'd like to understand what advantage batman-adv brings to the table in your scenario. The batman-adv project aims to facilitate layer2 routing in primarily wireless setups with dynamically changing links due to link quality changes or links being modified in an uncontrolled fashion (community mesh network). While batman-adv also is able to run on wired backbones this never was the main target and bears a number of drawbacks compared to other technologies. A simple example to picture this: The standard Linux bridge (configurable via brctl) does not run any link layer protocol to estimate the quality of one link compared to another. This will give you huge advantages in terms of overhead with the cost of all links being treated equal. While this work fine on an all-wired setup it represents an unacceptable trade-off for wireless networks. >From what I can gather you are not running wireless but high throughput wired links. What has brought you to batman-adv ? Cheers, Marek

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N