B.A.T.M.A.N April 2012

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

25 participants
63 discussions

[B.A.T.M.A.N.] Backwards Compatibility
by NorthPole 15 Apr '12

15 Apr '12

Hello Everyone! I'm Spyros (hopefully)one of the gsoc students. The project is to integrate information element syntax for various information in the packets and as a consequence implement backwards compatibility. there is a number of ways to do this though and since it affects most of you (every info should be transmited in information element syntax) it would be good if you shared your opinions. To get us started there is a wiki page http://www.open-mesh.org/wiki/batman-adv/BackwardsCompatibility which briefly explains the concept Thank you, Spyros

2 3

[B.A.T.M.A.N.] [RFC] endianness bugs in net/batman-adv/
by Al Viro 14 Apr '12

14 Apr '12

Let's start with net/batman-adv/translation-table.c:send_tt_request(). Its tt_crc argument gets stored into skb as-is and skb goes on the wire. OK, so it's fixed-endian, right? That sucker comes straight from the (only) caller - tt_update_orig(). There it gets compared with ->tt_crc of struct orig_node instances. Fine, except that just prior to that comparison we assign to ->tt_crc the return value of tt_global_crc(). Which is built on crc16_byte() and clearly returns a host-endian value. Additionally, orig_node ->tt_crc is getting compared to tt_request->tt_data in send_other_tt_response(), which ultimately comes from recv_tt_query() where it's flipped from net-endian to host-endian. It gets even funnier - we have 3 structures with ->tt_crc in them; one is struct orig_node (see above), another is struct batman_ogv_packet and then there's the weirdest one - struct bat_priv. Where ->tt_crc is atomic_t, of all things. With exactly two things ever done to it: batman_ogm_packet->tt_crc = htons((uint16_t) atomic_read(&bat_priv->tt_crc)); in bat_iv_ogm_schedule() and atomic_set(&bat_priv->tt_crc, tt_local_crc(bat_priv)); in prepare_packet_buffer(). What the hell does that have to do with atomic_t? At least that one is definitely host-endian all along (tt_local_crc() is the same kind of built-on-crc16_byte() thing). And then there's batman_ogv_packet, where we flip the damn field from net-endian to host-endian and back. That's where the argument of tt_update_orig() comes from, AFAICS always in host-endian form. IOW, unless I'm misreading that code we have bat_priv ->tt_crc: host-endian, no need to make it atomic_t orig_node ->tt_crc: host-endian tt_update_orig()/send_tt_request() tt_crc argument: host-endian the value put into the packet in send_tt_request(): broken; should be net-endian, in reality it's host-endian. Missing htons() at the very least. Could somebody familiar with that code comment on that?

2 2

[B.A.T.M.A.N.] [PATCHv2 0/3] clean up patches
by Antonio Quartulli 13 Apr '12

13 Apr '12

This v2 patchset is equal to v1 except for a little fix in 1/3, where I removed a wrongly duplicated line. Cheers, Antonio

2 8

[B.A.T.M.A.N.] Migration to Batman
by Mitar 13 Apr '12

13 Apr '12

Hi! I really liked your client roaming support presented at Battlemesh. But I am still afraid to deploy Batman in the network. As I understand, we should be migrating the whole network at same time each time a new version of Batman (or Linux kernel) is released, because you do not keep things backwards compatible? How serious is this limitation in practice? I am also a bit afraid of L2 meshing. How problematic are floods in the network in practice? Like people broadcasting stuff and so on? Are there any filters possible for this? We have a setup where nodes have WiFi connections and VPN links to central server. We are thinking of migration OpenVPN to L2TP tunnels, so on the central server there will be many tunnels dynamically created as nodes connect and disconnect. Is Batman able to add interfaces it operates during run-time? Probably we should not just bridge all tunnels and run Batman on top of that? This would probably hide that there are different links bellow from Batman? Or not? (For example, on OLSR we should not do this, because then nodes would discover each other over server as one hop/direct neighbors.) Mitar

7 21

[B.A.T.M.A.N.] [PATCH 0/3] clean up patches
by Antonio Quartulli 12 Apr '12

12 Apr '12

** this patches are for batman-ad/next *** After my first pull request, David S. Miller hardly suggested me to fix some problems that I am going to summarise here. Please respect such suggestions in your next patches: 1) Multi-line comments must end with */ on a new line: /* .. * .. */ 2) if we use #ifdef in our headers to redefine some functions depending on the fact that we are compiling a component or not, we must use static inline functions doing nothing with the correct parameters instead of simple "foo(...)". In this way we can allow the compiler to check for the types and the number of arguments: Instead of: #define bla_init(...) (1) we must do: static inline bla_init(struct bat_priv *bat_priv) { return 1; } Other than David's complaining I also get a suggestion from Bernd Petrovitsch about the type of stp_addr (it should be "static const uint8_t []" instead of "uint8_t []" only). I applied such change in patch 2/3. Cheers,

4 10

[B.A.T.M.A.N.] pull request: batman-adv 2012-04-11
by Antonio Quartulli 11 Apr '12

11 Apr '12

Hello, this is our new set of patches (actually there has been no modification from the last pull request issued on 2011-04-07) which is now based on top of the current net-next/master branch (commit id: 06eb4eafbdc0796d741d139a44f1253278da8611). Let me know if there is something else wrong. Thank you very much, Antonio

3 22

[B.A.T.M.A.N.] pull request: batman-adv 2012-04-07
by Antonio Quartulli 10 Apr '12

10 Apr '12

Hello, this is the updated and cleaned up version of our last pull request (sent on 2012-04-05). In this patchset I fixed the two problems you told me about (comments ending with */ not on a newline and usage of "func(...)" instead of static inline ones). In patch 14 I also changed the type of "stp_addr[ETH_ALEN]" from "uint8_t" to "static const uint8_t" (as suggested by Bernd Petrovitsch). Thank you, Antonio The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: git://git.open-mesh.org/linux-merge.git tags/batman-adv-for-davem for you to fetch changes up to 369a2792da3265eae09cf10e09bcaf95ceb521e5: batman-adv: add bridge loop avoidance compile option (2012-04-07 12:54:52 +0200) ---------------------------------------------------------------- Included changes: * add my name to the maintainers list of batman-adv * some clean up fixes * increases the default hop-penalty in order to encourage the routing protocol to choose shorter routes * renew the bridge loop avoidance mechanism The latter mechanism was already present in batman-adv but recently the concept has been discussed again and here comes the new implementation. Moreover we added a compile option in order to let expert people, which think that this mechanism is not helpful at all, disable it and save some space. ---------------------------------------------------------------- Antonio Quartulli (3): MAINTAINERS: add additional maintainer for net/batman-adv batman-adv: clean up Kconfig batman-adv: use ETH_ALEN instead of hardcoded numeric constants Marek Lindner (1): batman-adv: encourage batman to take shorter routes by changing the default hop penalty Simon Wunderlich (10): batman-adv: remove old bridge loop avoidance code batman-adv: add basic bridge loop avoidance code batman-adv: make bridge loop avoidance switchable batman-adv: export claim tables through debugfs batman-adv: allow multiple entries in tt_global_entries batman-adv: don't let backbone gateways exchange tt entries batman-adv: add broadcast duplicate check batman-adv: drop STP over batman batman-adv: form groups in the bridge loop avoidance batman-adv: add bridge loop avoidance compile option Sven Eckelmann (2): batman-adv: Replace bitarray operations with bitmap batman-adv: Remove declaration of only locally used functions Documentation/ABI/testing/sysfs-class-net-mesh | 9 + Documentation/networking/batman-adv.txt | 19 +- MAINTAINERS | 1 + net/batman-adv/Kconfig | 27 +- net/batman-adv/Makefile | 1 + net/batman-adv/bat_debugfs.c | 19 +- net/batman-adv/bat_iv_ogm.c | 15 +- net/batman-adv/bat_sysfs.c | 8 +- net/batman-adv/bitarray.c | 118 +- net/batman-adv/bitarray.h | 26 +- net/batman-adv/bridge_loop_avoidance.c | 1583 ++++++++++++++++++++++++ net/batman-adv/bridge_loop_avoidance.h | 98 ++ net/batman-adv/hard-interface.c | 18 +- net/batman-adv/main.c | 9 +- net/batman-adv/main.h | 11 +- net/batman-adv/originator.c | 3 +- net/batman-adv/packet.h | 43 +- net/batman-adv/routing.c | 29 +- net/batman-adv/routing.h | 1 - net/batman-adv/soft-interface.c | 498 +------- net/batman-adv/soft-interface.h | 2 - net/batman-adv/translation-table.c | 435 +++++-- net/batman-adv/translation-table.h | 8 - net/batman-adv/types.h | 77 +- 24 files changed, 2263 insertions(+), 795 deletions(-) create mode 100644 net/batman-adv/bridge_loop_avoidance.c create mode 100644 net/batman-adv/bridge_loop_avoidance.h

3 19

[B.A.T.M.A.N.] [PATCH 0/4] batman-adv: tt code fixes and temporary client detection
by Antonio Quartulli 10 Apr '12

10 Apr '12

This set of patches aims to first clean & fix the code a little bit in order to prepare it for the temporary client recognition (patch 5/5). Temporary client recognition: In the current implementation, whenever a client joins the network it has to wait the next OGM in order to be announced to the whole network (by means of the known TT mechanism). Before that time, the client will be unable to communicate to whichever else client, so generating some delay that usually leads to DHCP (or any other service) timeout. This problem is amplified is for large originator interval. Patch 4/4 add a temporary recognition mechanism which make every node in the network "autodetect" the location (namely the node serving) the node yet announced client *** VERSION 2 *** TT_CLIENT_PENDING fix has been committed and so we do not need to refix it now.

2 7

[B.A.T.M.A.N.] [RFC 0/2] Create counters for measuring behaviour
by Martin Hundebøll 10 Apr '12

10 Apr '12

Before sending an RFC on my work with network coding/catwoman, I would like some feedback on this stats-feature I build to measure the behaviour of catwoman. It is basically a set of counters that are incremented on various places in the code as a more detailed alternative to the interface statistics. Currently, my catwoman branch uses these counters (e.g. to tell how many packets are coded together), but other counters can easily be added. E.g. counters relevant to the BLA, DAT, OGM/ELP code. If this feature is unneeded/unwanted, I will remove the dependency in catwoman. Martin Hundebøll (2): batman-adv: Add interface to keep stats batman-adv: Increment stat counters on rx, tx, fwd Makefile | 2 + Makefile.kbuild | 1 + bat_debugfs.c | 17 +++++++ bat_stats.c | 132 ++++++++++++++++++++++++++++++++++++++++++++++++ bat_stats.h | 60 ++++++++++++++++++++++ gen-compat-autoconf.sh | 1 + main.c | 6 +++ routing.c | 2 + soft-interface.c | 3 ++ types.h | 20 ++++++++ 10 files changed, 244 insertions(+) create mode 100644 bat_stats.c create mode 100644 bat_stats.h -- 1.7.9.5

2 11

[B.A.T.M.A.N.] Security for batman-adv
by xjodoin＠gmail.com 09 Apr '12

09 Apr '12

Hi, I will like to know if batman-adv have plan to support MACsec (802.1AE) to add security on the layer 2. Xavier

2 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 April 2012