B.A.T.M.A.N May 2013

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

16 participants
80 discussions

[B.A.T.M.A.N.] [PATCHv2 0/7] make the Translation Table component VLAN-aware
by Antonio Quartulli 24 May '13

24 May '13

Hello people, with this patchset I want to introduce a new feature in the TT code which makes it VLAN aware. This means that now clients belonging to different VLANs created on top of a generic bat0 are treated differently. This change gives the possibility to: - enable AP isolation only on a selected VLAN rather than on all the traffic - make DAT work correctly when the same IP subnet is used on different VLANs - leave the possibility to future developers to implement more VLAN specific attributes This patchset is based on top of: "batman-adv: use htons when possible" This is version v2, and this are the changes from v1: - improved kernel doc - created batadv_get_vid() function - improved documentation for CRC computation - added compat code for kfree_rcu (struct batadv_priv_vlan) Cheers, Antonio Quartulli (7): batman-adv: add the VLAN ID attribute to the TT entry batman-adv: use vid when computing local and global TT CRC batman-adv: print the VID together with the TT entries batman-adv: make the GW module correctly talk to the new VLAN-TT batman-adv: make the Distributed ARP Table vlan aware batman-adv: add per VLAN interface attribute framework batman-adv: make the AP isolation attribute VLAN specific bridge_loop_avoidance.c | 37 ++--- compat.c | 9 ++ distributed-arp-table.c | 125 +++++++++++------ gateway_client.c | 18 ++- main.c | 74 +++++++++- main.h | 12 +- packet.h | 12 ++ routing.c | 28 ++-- send.c | 8 +- send.h | 16 ++- soft-interface.c | 114 ++++++++++++--- sysfs.c | 140 +++++++++++++++++++ sysfs.h | 10 ++ translation-table.c | 364 ++++++++++++++++++++++++++++++++++++------------ translation-table.h | 21 +-- types.h | 27 ++++ 16 files changed, 810 insertions(+), 205 deletions(-) -- 1.8.1.5

2 9

[B.A.T.M.A.N.] [PATCHv4] batman-adv: use htons when possible
by Antonio Quartulli 24 May '13

24 May '13

When comparing a network ordered value with a constant, it is better to convert the constant at compile time by means of htons() instead of converting the value at runtime using ntohs(). This refactoring may slightly improve the code performance. Moreover substitute __constant_htons() with htons() since the latter increase readability and it is smart enough to be as efficient as the former Signed-off-by: Antonio Quartulli <ordex(a)autistici.org> --- v2: - patch rebased on top of "batman-adv: use VLAN_ETH_HLEN instead of sizeof(struct vlan_eth_hdr)" v3: - use __constant* for vlan_insert_tag() argument v4: - use htons instead of __constant_htons bridge_loop_avoidance.c | 12 ++++++------ gateway_client.c | 14 +++++++------- hard-interface.c | 2 +- send.c | 4 ++-- soft-interface.c | 4 ++-- 5 files changed, 18 insertions(+), 18 deletions(-) diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c index 9e691b0..ab537ec 100644 --- a/bridge_loop_avoidance.c +++ b/bridge_loop_avoidance.c @@ -863,25 +863,25 @@ static int batadv_bla_process_claim(struct batadv_priv *bat_priv, struct arphdr *arphdr; uint8_t *hw_src, *hw_dst; struct batadv_bla_claim_dst *bla_dst; - uint16_t proto; + __be16 proto; int headlen; unsigned short vid = BATADV_NO_FLAGS; int ret; ethhdr = eth_hdr(skb); - if (ntohs(ethhdr->h_proto) == ETH_P_8021Q) { + if (ethhdr->h_proto == htons(ETH_P_8021Q)) { vhdr = (struct vlan_ethhdr *)ethhdr; vid = ntohs(vhdr->h_vlan_TCI) & VLAN_VID_MASK; vid |= BATADV_VLAN_HAS_TAG; - proto = ntohs(vhdr->h_vlan_encapsulated_proto); + proto = vhdr->h_vlan_encapsulated_proto; headlen = sizeof(*vhdr); } else { - proto = ntohs(ethhdr->h_proto); + proto = ethhdr->h_proto; headlen = ETH_HLEN; } - if (proto != ETH_P_ARP) + if (proto != htons(ETH_P_ARP)) return 0; /* not a claim frame */ /* this must be a ARP frame. check if it is a claim. */ @@ -1375,7 +1375,7 @@ int batadv_bla_is_backbone_gw(struct sk_buff *skb, ethhdr = (struct ethhdr *)(((uint8_t *)skb->data) + hdr_size); - if (ntohs(ethhdr->h_proto) == ETH_P_8021Q) { + if (ethhdr->h_proto == htons(ETH_P_8021Q)) { if (!pskb_may_pull(skb, hdr_size + VLAN_ETH_HLEN)) return 0; diff --git a/gateway_client.c b/gateway_client.c index 3a27408..131136f 100644 --- a/gateway_client.c +++ b/gateway_client.c @@ -637,7 +637,7 @@ bool batadv_gw_is_dhcp_target(struct sk_buff *skb, unsigned int *header_len) *header_len += ETH_HLEN; /* check for initial vlan header */ - if (proto == __constant_htons(ETH_P_8021Q)) { + if (proto == htons(ETH_P_8021Q)) { if (!pskb_may_pull(skb, *header_len + VLAN_HLEN)) return false; @@ -648,7 +648,7 @@ bool batadv_gw_is_dhcp_target(struct sk_buff *skb, unsigned int *header_len) /* check for ip header */ switch (proto) { - case __constant_htons(ETH_P_IP): + case htons(ETH_P_IP): if (!pskb_may_pull(skb, *header_len + sizeof(*iphdr))) return false; iphdr = (struct iphdr *)(skb->data + *header_len); @@ -659,7 +659,7 @@ bool batadv_gw_is_dhcp_target(struct sk_buff *skb, unsigned int *header_len) return false; break; - case __constant_htons(ETH_P_IPV6): + case htons(ETH_P_IPV6): if (!pskb_may_pull(skb, *header_len + sizeof(*ipv6hdr))) return false; ipv6hdr = (struct ipv6hdr *)(skb->data + *header_len); @@ -680,12 +680,12 @@ bool batadv_gw_is_dhcp_target(struct sk_buff *skb, unsigned int *header_len) *header_len += sizeof(*udphdr); /* check for bootp port */ - if ((proto == __constant_htons(ETH_P_IP)) && - (ntohs(udphdr->dest) != 67)) + if ((proto == htons(ETH_P_IP)) && + (udphdr->dest != htons(67))) return false; - if ((proto == __constant_htons(ETH_P_IPV6)) && - (ntohs(udphdr->dest) != 547)) + if ((proto == htons(ETH_P_IPV6)) && + (udphdr->dest != htons(547))) return false; return true; diff --git a/hard-interface.c b/hard-interface.c index 9746600..5edbe52 100644 --- a/hard-interface.c +++ b/hard-interface.c @@ -379,7 +379,7 @@ int batadv_hardif_enable_interface(struct batadv_hard_iface *hard_iface, { struct batadv_priv *bat_priv; struct net_device *soft_iface, *master; - __be16 ethertype = __constant_htons(ETH_P_BATMAN); + __be16 ethertype = htons(ETH_P_BATMAN); int ret; if (hard_iface->if_status != BATADV_IF_NOT_IN_USE) diff --git a/send.c b/send.c index 23c7f79..f2ec99c 100644 --- a/send.c +++ b/send.c @@ -63,11 +63,11 @@ int batadv_send_skb_packet(struct sk_buff *skb, ethhdr = eth_hdr(skb); memcpy(ethhdr->h_source, hard_iface->net_dev->dev_addr, ETH_ALEN); memcpy(ethhdr->h_dest, dst_addr, ETH_ALEN); - ethhdr->h_proto = __constant_htons(ETH_P_BATMAN); + ethhdr->h_proto = htons(ETH_P_BATMAN); skb_set_network_header(skb, ETH_HLEN); skb->priority = TC_PRIO_CONTROL; - skb->protocol = __constant_htons(ETH_P_BATMAN); + skb->protocol = htons(ETH_P_BATMAN); skb->dev = hard_iface->net_dev; diff --git a/soft-interface.c b/soft-interface.c index a6ab9e4..4696142 100644 --- a/soft-interface.c +++ b/soft-interface.c @@ -147,7 +147,7 @@ static int batadv_interface_tx(struct sk_buff *skb, struct batadv_hard_iface *primary_if = NULL; struct batadv_bcast_packet *bcast_packet; struct vlan_ethhdr *vhdr; - __be16 ethertype = __constant_htons(ETH_P_BATMAN); + __be16 ethertype = htons(ETH_P_BATMAN); static const uint8_t stp_addr[ETH_ALEN] = {0x01, 0x80, 0xC2, 0x00, 0x00, 0x00}; static const uint8_t ectp_addr[ETH_ALEN] = {0xCF, 0x00, 0x00, 0x00, @@ -304,7 +304,7 @@ void batadv_interface_rx(struct net_device *soft_iface, struct vlan_ethhdr *vhdr; struct batadv_header *batadv_header = (struct batadv_header *)skb->data; unsigned short vid __maybe_unused = BATADV_NO_FLAGS; - __be16 ethertype = __constant_htons(ETH_P_BATMAN); + __be16 ethertype = htons(ETH_P_BATMAN); bool is_bcast; is_bcast = (batadv_header->packet_type == BATADV_BCAST); -- 1.8.1.5

3 2

[B.A.T.M.A.N.] [RFC 0/7] add network wide multi interface optimization
by Simon Wunderlich 23 May '13

23 May '13

From: Simon Wunderlich <simon(a)open-mesh.com> This patchset adds the network wide multi interface optimization as proposed in our wiki [1] for BATMAN IV. The main purpose is to do interface alternating and bonding by considering multi interface capabilities globally and not just for the (next) link, otherwise non-optimal links may be chosen. This patchset needs to change a lot of core data structures and routing, please review it carefully. It is based on the current master plus the "batman-adv: forward late OGMs from best next hop" patch. A local development branch exists on the public git repo [2]. Things to discuss from my end are: * are there any metric proposals for the wifi half duplex penalty? I've just used "half" for now, but this makes the TQ degrade very quickly over the links. * Note also that this change will generally change the TQ propagation behaviour even for single interface networks, i.e. the TQ will degrade fast in any case in this networks after this change. This is inevitable if we want to mix single/multi interface devices * anything to consider for network coding? * this code was used in my virtual VMs only, I'd like to test it on multi-interface devices if the direction I go here can be confirmed. :) As always, any comments are appreciated! Thanks, Simon [1] http://www.open-mesh.org/projects/batman-adv/wiki/network-wide-multi-link-o… [2] http://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/simon/network-w… Simon Wunderlich (7): batman-adv: remove useless find_router look up batman-adv: remove bonding and interface alternating batman-adv: split tq information in neigh_node struct batman-adv: split out router from orig_node batman-adv: add WiFi penalty batman-adv: consider outgoing interface in OGM sending batman-adv: add bonding again bat_iv_ogm.c | 654 +++++++++++++++++++++++++++++++---------------- distributed-arp-table.c | 3 +- gateway_client.c | 78 ++++-- hard-interface.c | 2 +- hard-interface.h | 1 + icmp_socket.c | 2 +- network-coding.c | 9 +- originator.c | 324 ++++++++++++++++++++--- originator.h | 14 +- routing.c | 413 ++++++++++-------------------- routing.h | 11 +- send.c | 42 ++- translation-table.c | 14 +- types.h | 79 ++++-- 14 files changed, 1037 insertions(+), 609 deletions(-) -- 1.7.10.4

1 7

[B.A.T.M.A.N.] [PATCHv4 0/3] Fragmentation version 2
by Martin Hundebøll 23 May '13

23 May '13

This is the fourth revision of a few patches to remove the current fragmentation code and replace it with a new version that supports more packet types and more fragments per packet, thus allowing bigger payloads. The patches are based on current master and are meant for the next big bump in compat number. Revision 4 is changed according to Antonios latest review. Martin Hundebøll (3): batman-adv: Remove old fragmentation code batman-adv: Receive fragmented packets and merge batman-adv: Fragment and send skbs larger than mtu Makefile.kbuild | 2 +- distributed-arp-table.c | 11 +- fragmentation.c | 485 ++++++++++++++++++++++++++++++++++++++++++++++++ fragmentation.h | 50 +++++ hard-interface.c | 1 - main.c | 8 +- main.h | 9 + originator.c | 19 +- packet.h | 41 ++-- routing.c | 145 ++++++--------- routing.h | 4 +- send.c | 195 ++++++++++++++++++- send.h | 36 ++++ soft-interface.c | 15 +- types.h | 63 +++++-- unicast.c | 478 ----------------------------------------------- unicast.h | 92 --------- 17 files changed, 936 insertions(+), 718 deletions(-) create mode 100644 fragmentation.c create mode 100644 fragmentation.h delete mode 100644 unicast.c delete mode 100644 unicast.h -- 1.8.2.3

2 6

[B.A.T.M.A.N.] [PATCH] batman-adv: forward late OGMs from best next hop
by Simon Wunderlich 23 May '13

23 May '13

From: Simon Wunderlich <simon(a)open-mesh.com> When a packet is received from another node first and later from the best next hop, this packet is dropped. However the first OGM was sent with the BATADV_NOT_BEST_NEXT_HOP flag and thus dropped by neighbors. The late OGM from the best neighbor is then dropped because it is a duplicate. If this situation happens constantly, a node might end up not forwarding the "valid" OGMs anymore, and nodes behind will starve from not getting valid OGMs. Fix this by changing the is_duplicate behaviour: It will only mark duplicates which are received for the same neighbor. OGMs which are not from the best next hop will be dropped within batadv_iv_ogm_forward() anyway. Therefore, late OGMs are forwarded now and not dropped as duplicates. Signed-off-by: Simon Wunderlich <simon(a)open-mesh.com> Signed-off-by: Antonio Quartulli <ordex(a)autistici.org> --- bat_iv_ogm.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/bat_iv_ogm.c b/bat_iv_ogm.c index 8d87f87..bcd2527 100644 --- a/bat_iv_ogm.c +++ b/bat_iv_ogm.c @@ -948,7 +948,7 @@ batadv_iv_ogm_update_seqnos(const struct ethhdr *ethhdr, struct batadv_priv *bat_priv = netdev_priv(if_incoming->soft_iface); struct batadv_orig_node *orig_node; struct batadv_neigh_node *tmp_neigh_node; - int is_duplicate = 0; + int is_dup = 0; int32_t seq_diff; int need_update = 0; int set_mark, ret = -1; @@ -972,16 +972,16 @@ batadv_iv_ogm_update_seqnos(const struct ethhdr *ethhdr, rcu_read_lock(); hlist_for_each_entry_rcu(tmp_neigh_node, &orig_node->neigh_list, list) { - is_duplicate |= batadv_test_bit(tmp_neigh_node->real_bits, - orig_node->last_real_seqno, - seqno); - neigh_addr = tmp_neigh_node->addr; if (batadv_compare_eth(neigh_addr, ethhdr->h_source) && - tmp_neigh_node->if_incoming == if_incoming) + tmp_neigh_node->if_incoming == if_incoming) { + is_dup |= batadv_test_bit(tmp_neigh_node->real_bits, + orig_node->last_real_seqno, + seqno); set_mark = 1; - else + } else { set_mark = 0; + } /* if the window moved, set the update flag. */ need_update |= batadv_bit_get_packet(bat_priv, @@ -1001,7 +1001,7 @@ batadv_iv_ogm_update_seqnos(const struct ethhdr *ethhdr, orig_node->last_real_seqno = seqno; } - ret = is_duplicate; + ret = is_dup; out: spin_unlock_bh(&orig_node->ogm_cnt_lock); -- 1.7.10.4

2 1

[B.A.T.M.A.N.] [PATCHv3 0/3] Fragmentation version 2
by Martin Hundebøll 23 May '13

23 May '13

These are the second revision of a few patches to remove the current fragmentation code and replace it with a new version that supports more packet types and more fragments per packet, thus allowing bigger payloads. The patches are based on current master and are meant for the next big bump in compat number. Revision 3 is changed according to Antonios review. Martin Hundebøll (3): batman-adv: Remove old fragmentation code batman-adv: Receive fragmented packets and merge batman-adv: Fragment and send skbs larger than mtu Makefile.kbuild | 2 +- distributed-arp-table.c | 11 +- fragmentation.c | 485 ++++++++++++++++++++++++++++++++++++++++++++++++ fragmentation.h | 50 +++++ hard-interface.c | 1 - main.c | 8 +- main.h | 9 + originator.c | 19 +- packet.h | 41 ++-- routing.c | 145 ++++++--------- routing.h | 4 +- send.c | 195 ++++++++++++++++++- send.h | 36 ++++ soft-interface.c | 15 +- types.h | 63 +++++-- unicast.c | 478 ----------------------------------------------- unicast.h | 92 --------- 17 files changed, 936 insertions(+), 718 deletions(-) create mode 100644 fragmentation.c create mode 100644 fragmentation.h delete mode 100644 unicast.c delete mode 100644 unicast.h -- 1.8.2.3

2 10

[B.A.T.M.A.N.] (no subject)
by Antonio Quartulli 23 May '13

23 May '13

Hello David, this is another small patch for net/linux-3.10. It is preventing a double free of the bat_counters in case of mesh initialisation failure. Sorry for sending such small pull requests (I guess this is not that bad since they target net :-)), but these are small glitches we are finding while testing new features. Please pull or let me know if there is any problem. Thanks a lot, Antonio The following changes since commit 3ccfc1b1d2fa78f8ece83646027982916fcc794b: Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless (2013-05-20 14:05:22 -0700) are available in the git repository at: git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem for you to fetch changes up to f69ae770e74df420fbcf93aae81b30a5dcc73b7d: batman-adv: Avoid double freeing of bat_counters (2013-05-21 21:34:36 +0200) ---------------------------------------------------------------- Included change: - fix double free in case of failure during mesh initialisation ---------------------------------------------------------------- Martin Hundebøll (1): batman-adv: Avoid double freeing of bat_counters net/batman-adv/main.c | 1 + net/batman-adv/soft-interface.c | 1 + 2 files changed, 2 insertions(+)

2 3

[B.A.T.M.A.N.] Fwd: Re: [Freifunk.luebeck-devel] [Freifunk-Bonn] On compat version 15 in the Freifunk-KBU network
by Jan Luehr 19 May '13

19 May '13

Hello, sorry for forwarding - mail got filtered... Betreff: Re: [Freifunk.luebeck-devel] [Freifunk-Bonn] [B.A.T.M.A.N.] On compat version 15 in the Freifunk-KBU network Datum: Sun, 19 May 2013 14:49:45 +0200 Von: Jan Lühr <ff(a)jluehr.de> An: "Allgemeine Mailingliste zum Freifunk Köln, Bonn und Umgebung" <freifunk-bonn(a)lists.bonn.freifunk.net> CC: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n(a)lists.open-mesh.org>, freifunk.luebeck-devel(a)asta.uni-luebeck.de Hello, Am 19.05.2013 um 12:40 schrieb Simon Wunderlich: > Hello yanosz, > > On Sun, May 19, 2013 at 10:52:01AM +0200, Jan Lühr wrote: >> Hello folks, >> >> I'd like to give some thought's for the upcoming batman-adv release, especially on compat version 15. This somewhat summarizes my discussion with T_X on the wireless community weekend (WCW -- 2013-05-10 - 2013-05-12). (...) >> It's not my intention to bash on batman-adv in general or to start flame-wars (like: batman-adv vs. olsr or something else) - I'd like to provide some statement on the impact of the upcoming protocol changes. > > Thanks for your feedback. Yes, we are preparing a compat bump (actually for a long time now) and it's good to discuss it. :) Thanks for your detailed answer - I'll cut some parts for better readability. > >> >> 1. The upcoming protocol change appears to be painful - we have no suitable migration strategy. (...) >> 13 nodes in the next months - by that, we'll probably have some compat 13 ones for at least 1/2 year. There is no way of telling newer nodes to use compat version 13. Since some "supernodes" (dedicated servers) are part of the batman-adv cloud, we need twice the servers as well. >> Upgrading to compat version 15 will require a huge amount of work: New infrastructure (servers) must be deployed and nodes meshing with each other must be upgraded in parallel. > > > Btw, it's interesting that you use compat version 13 - only one release had that included, and we are > on compat 14 for quite some time ... > [1] http://www.open-mesh.org/projects/batman-adv/wiki/Compatversion (...) - yes, I know. Theses nodes are quite old. I guess this somewhat illustrates the upcoming situation. >> >> 2. Backwards-compatilibilty doesn't seem to be a design target. > > Actually, that is one of the main design targets. We are aware that with our current packet type design, > we cannot change even parts of the protocol without breaking compatibility. This has bothered us for quite > some time and we have worked on solutions to prevent compat bumps as good as possible. We have introduced > different means [2,3] to be able to add new features, change features, let sub-features update their > protocols (by using TVLVs) without breaking the rest and ensure compatibility on their own [3], route even > yet unknown packets on their own [2], ... Actually the TVLV thing is pretty similar to other protocols > (e.g. IEEE 802.11) which use that to ensure backwards compatiblity for years. The goal is to keep the > compat bump stable for at least a decade now, if not longer. No guarantees of course, but this compat > bump is made to CREATE backwards compatiblity. :) > > Note that the compat bump is not released yet but still only in our development branch. > > [2] http://www.open-mesh.org/projects/batman-adv/wiki/Packet-types > [3] http://www.open-mesh.org/projects/batman-adv/wiki/TVLV Thanks for the details. I understand your reasons for changing the protocol - and I'm perfectly fine with that. I know that manets are an area of active research. Bit this won't be a problem at all, if upcoming batman-adv versions are capable if "speaking" older compat versions. If done so, we (as in Freifunk-KBU) would be able to simple "choose" the compat version for our network - and pick a newer one if needed. >> Since batman-adv depends on the kernel (old batman-adv versions won't build with recent kernels) using 14 will not be an option in a few months: If some router hardware requires recent Kernel / OpenWRT releases version 14 might no longer be used. > > I think it would be possible to maintain older releases of batman-adv and add compatibility code for > newer kernels. We are doing the same now to provide compatibility for older kernels [4]. We would > be happy if someone (you?) would take over that job, I guess it would mostly mean to test new kernels > and add a little bit of compat code like we do for the old kernels. You are welcome to contribute > such "stable" versions. :) > > [4] http://git.open-mesh.org/batman-adv.git/blob/refs/heads/master:/compat.h Hmm... well, I'm not into kernel development, but I could maintain some CI services for testing. I'll ask some our folks on our next community meeting. > >> -> We're aware, that we cannot use version 14 in some months >> -> At the point, when 14 becomes unusable (introduced into OpenWRT Kernels / release we need -- or Debian), we will almost certainly discontinue batman-adv and go one with sth. else. (Due to kernel deps it's easier to run batman-adv / olsr in parallel than two different version of batman-adv) > > I don't see that by releasing batman-adv with the new compat version, suddenly your network breaks > - in Debian you usually keep the same kernel for YEARS, and in OpenWRT you can just keep the batman-adv > package at the desired version number. The only problem you might run into is that newer kernels might > not work, as stated above. Actually, it has consequences: About 5-8 months ago (don't remember the details). 2011.2 didn't build on Attitude Adjustment (12.09) (OpenWRT issue? Kernel Issue? I don't remember ...), while newer TP Link 1043nd models needed 12.09 (brick, otherwise). At that time we're eager of deploying compat 14 releases - succeeding about 3,5 months ago. But in the aftermath of it, we noticed that we did not succeed in upgrading the whole network - since upgrading some nodes is still impossible because of organizational issues. Some people complained about the effort needed - for valid reasons, imho (although we provided free vodka at our release party ;-) ) To be honest: I don't like to be stuck at this, again. With compat 15 on the horizon, we're in the need of finding adequate strategies. Do you have something in your mind? >> -> Maybe, some future version of batman-adv addresses backwards-compatibility. Maybe, in 2018 we will have a look at batman-adv again - noticing, that batman-adv remained stable (or migratable) over the last years and start using it again. Maybe, batman-adv will fit our needs, then. > > You are free to use whatever you want. I think I've made a clear point that this compat bump is designed > to address the compat issues we had. What you roll out then is up to you (personally I'd be interested > what you'll use instead) - but I guess you'll miss a lot of very nice features of batman-adv. ;) Yeah - I guess I'll miss some features - and there is no decision yet (not even candidates). However - in retrospect - kernel-dependencies will be taken into account this time. Greetz, yanosz

1 0

[B.A.T.M.A.N.] On compat version 15 in the Freifunk-KBU network
by Jan Lühr 19 May '13

19 May '13

Hello folks, I'd like to give some thought's for the upcoming batman-adv release, especially on compat version 15. This somewhat summarizes my discussion with T_X on the wireless community weekend (WCW -- 2013-05-10 - 2013-05-12). As some of you may know already, we're running a small freifunk network in western Germany (Köln-Bonn-area) - about ~100 nodes in total; ~40 are online at the moment. It's not my intention to bash on batman-adv in general or to start flame-wars (like: batman-adv vs. olsr or something else) - I'd like to provide some statement on the impact of the upcoming protocol changes. 1. The upcoming protocol change appears to be painful - we have no suitable migration strategy. Compat version 14 and 15 will be incompatible. Nodes will loose mesh connectivity (to older nodes). Since we cannot upgrade all nodes at once, we'll have to run different networks in parallel. In fact, we're running two networks at the moment (compat 13 and 14). We aren't able to upgrade the existing compat 13 nodes in the next months - by that, we'll probably have some compat 13 ones for at least 1/2 year. There is no way of telling newer nodes to use compat version 13. Since some "supernodes" (dedicated servers) are part of the batman-adv cloud, we need twice the servers as well. Upgrading to compat version 15 will require a huge amount of work: New infrastructure (servers) must be deployed and nodes meshing with each other must be upgraded in parallel. 2. Backwards-compatilibilty doesn't seem to be a design target. Looking at other routing protocols (BGP-4 - for example) - they provide decent ways for protocol extension while still providing backwards compatibility for the version specified 7 years ago. Looking at batman-adv a lot of protocol changes have been introduced in the past years - but no backwards compatibility is there. Eg. - There will be no flag for using compat 14 version in newer version of batman-adv - if 15 is out. - Nodes using 14 and 15 cannot mesh. Since batman-adv depends on the kernel (old batman-adv versions won't build with recent kernels) using 14 will not be an option in a few months: If some router hardware requires recent Kernel / OpenWRT releases version 14 might no longer be used. 3. Conclusion -> Freifunk KBU will not use compat version 15 in the foreseeable future -> We're aware, that we cannot use version 14 in some months -> At the point, when 14 becomes unusable (introduced into OpenWRT Kernels / release we need -- or Debian), we will almost certainly discontinue batman-adv and go one with sth. else. (Due to kernel deps it's easier to run batman-adv / olsr in parallel than two different version of batman-adv) -> We'd by very happy if someone forks batman-adv to provide modules for recent kernels still using version 14 -> Maybe, some future version of batman-adv addresses backwards-compatibility. Maybe, in 2018 we will have a look at batman-adv again - noticing, that batman-adv remained stable (or migratable) over the last years and start using it again. Maybe, batman-adv will fit our needs, then. Thanks for your time, greetz, yanosz

3 2

[B.A.T.M.A.N.] [PATCHv3] batman-adv: use __constant_htons when possible
by Antonio Quartulli 19 May '13

19 May '13

When comparing a network ordered value with a constant, it is better to convert the constant at compile time by means of __constant_htons() instead of converting the value at runtime using ntohs(). This refactoring may slightly improve the code performance. Signed-off-by: Antonio Quartulli <ordex(a)autistici.org> --- v2: - patch rebased on top of "batman-adv: use VLAN_ETH_HLEN instead of sizeof(struct vlan_eth_hdr)" v3: - use __constant* for vlan_insert_tag() argument bridge_loop_avoidance.c | 14 +++++++------- gateway_client.c | 4 ++-- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c index 9e691b0..de02e7c 100644 --- a/bridge_loop_avoidance.c +++ b/bridge_loop_avoidance.c @@ -343,7 +343,7 @@ static void batadv_bla_send_claim(struct batadv_priv *bat_priv, uint8_t *mac, } if (vid & BATADV_VLAN_HAS_TAG) - skb = vlan_insert_tag(skb, htons(ETH_P_8021Q), + skb = vlan_insert_tag(skb, __constant_htons(ETH_P_8021Q), vid & VLAN_VID_MASK); skb_reset_mac_header(skb); @@ -863,25 +863,25 @@ static int batadv_bla_process_claim(struct batadv_priv *bat_priv, struct arphdr *arphdr; uint8_t *hw_src, *hw_dst; struct batadv_bla_claim_dst *bla_dst; - uint16_t proto; + __be16 proto; int headlen; unsigned short vid = BATADV_NO_FLAGS; int ret; ethhdr = eth_hdr(skb); - if (ntohs(ethhdr->h_proto) == ETH_P_8021Q) { + if (ethhdr->h_proto == __constant_htons(ETH_P_8021Q)) { vhdr = (struct vlan_ethhdr *)ethhdr; vid = ntohs(vhdr->h_vlan_TCI) & VLAN_VID_MASK; vid |= BATADV_VLAN_HAS_TAG; - proto = ntohs(vhdr->h_vlan_encapsulated_proto); + proto = vhdr->h_vlan_encapsulated_proto; headlen = sizeof(*vhdr); } else { - proto = ntohs(ethhdr->h_proto); + proto = ethhdr->h_proto; headlen = ETH_HLEN; } - if (proto != ETH_P_ARP) + if (proto != __constant_htons(ETH_P_ARP)) return 0; /* not a claim frame */ /* this must be a ARP frame. check if it is a claim. */ @@ -1375,7 +1375,7 @@ int batadv_bla_is_backbone_gw(struct sk_buff *skb, ethhdr = (struct ethhdr *)(((uint8_t *)skb->data) + hdr_size); - if (ntohs(ethhdr->h_proto) == ETH_P_8021Q) { + if (ethhdr->h_proto == __constant_htons(ETH_P_8021Q)) { if (!pskb_may_pull(skb, hdr_size + VLAN_ETH_HLEN)) return 0; diff --git a/gateway_client.c b/gateway_client.c index f59e58d..3cf92f8 100644 --- a/gateway_client.c +++ b/gateway_client.c @@ -682,11 +682,11 @@ bool batadv_gw_is_dhcp_target(struct sk_buff *skb, unsigned int *header_len) /* check for bootp port */ if ((proto == __constant_htons(ETH_P_IP)) && - (ntohs(udphdr->dest) != 67)) + (udphdr->dest != __constant_htons(67))) return false; if ((proto == __constant_htons(ETH_P_IPV6)) && - (ntohs(udphdr->dest) != 547)) + (udphdr->dest != __constant_htons(547))) return false; return true; -- 1.8.1.5

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N May 2013