B.A.T.M.A.N December 2010

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

18 participants
23 discussions

Re: [B.A.T.M.A.N.] New BMX website at www.bmx6.net
by Sven Eckelmann 15 Mar '11

15 Mar '11

Axel Neumann wrote: > > Does that mean that your svn directories and git repositories at > > open-mesh.org can be dropped > > In the long term yes! But please not right now. I want to update links in > other repositories like openWrt first and give users some time to update > their checkout as well so that the build process does not fail. Lets say > in February. Ok, sounds good. > > (at least it seems that no branch has common > > ancestors with your branches)? > > For branches/bmx-0.3.x/ I used git-svn to create the git repository which > I expected to create common ancestors. Some confusion leaked in when I > moved the directory from trunk/batman-experimental to branches/bmx-0.3.x > (some deleted files like LIESMICH,.. were not deleted which I fixed with > the last git commit). The problem is that you (sry, no offence meant) did a quite bad job to convert it. bmxd.git has these weird git-svn-id lines in the commit messages, "random" commiter names+mails, missing parts of the history, dangling symlinks, ... Please take a look at git://git.open-mesh.org/ecsv/test/bmx.git I don't say that it is the holy grail of svn-to-git conversation, but I think it could be a better conversation than your bmxd.git Best regards, Sven

2 3

[B.A.T.M.A.N.] Fwd: BATMAN routing
by hlabishi kobo 28 Feb '11

28 Feb '11

---------- Forwarded message ---------- From: hlabishi kobo <hlabishik(a)gmail.com> Date: Sun, 28 Nov 2010 22:06:01 +0200 Subject: Fwd: BATMAN routing To: lindner_marek(a)yahoo.de Hi Thank you very much for your reply. The reason why i sent this to you and your colleague is that i have tried the mail list before and all my post kept on being returned, i used this address b.a.t.m.a.n-owner(a)lists.open-mesh.org. I would really appreciate it if this can reach the mailing list public (i will keep on trying). i will send you a follow up on the full explanation of the concept like you requested. Regards Hlabishi ---------- Forwarded message ---------- From: <b.a.t.m.a.n-owner(a)lists.open-mesh.org> Date: Sat, Nov 27, 2010 at 12:58 AM Subject: Fwd: BATMAN routing To: hlabishik(a)gmail.com Message rejected by filter rule match ---------- Forwarded message ---------- From: hlabishi kobo <hlabishik(a)gmail.com> To: b.a.t.m.a.n(a)lists.open-mesh.org Date: Sat, 27 Nov 2010 00:58:09 +0200 Subject: Fwd: BATMAN routing ---------- Forwarded message ---------- From: Marek Lindner <lindner_marek(a)yahoo.de> Date: Fri, Nov 26, 2010 at 5:23 PM Subject: Re: BATMAN routing To: hlabishi kobo <hlabishik(a)gmail.com>, Linus Lüssing < linus.luessing(a)web.de> Cc: siwu(a)hrz.tu-chemnitz.de Hi, welcome to the project! :-) > Firstly my apologies for sending this email to your personal email. My name > is Hlabishi Isaac Kobo at the, an Msc computer science student at the > University of the Western Cape in South Africa, I am doing a research on > routing in a hybrid (combination of static and mobile dynamic routers) > mesh. I don't see a good reason to apologize, just wondering why you are not sending this mail to the public list ? > I want to use the mesh potatoes as well as the batphone (android > version of batman) to create a mesh model. What is the "batphone" ? A project name or a nick name you invented ? :-) Note: Various tests have shown that running a mobile device (smartphone/tablet/etc) in adhoc mode plus running a mesh protocol on top is a battery killer, hence not practical in real world scenarios (in addition of the hassle to install and configure the mesh software on each and every device). This was one of the main reasons to start developing batman-adv as it allows mobile devices to take advantage of the mesh (e.g. roaming) without having to run the mesh on the device itself. You might be aware of this - I am just mentioning it because many people are not. > First we say the recently received OGMs will give a clear indication on the > reliability on the link, so we give the recently received OGMs from the > sliding window a priority in deciding the best next hop link towards a > destination. We want to count and add the indexes were an OGM was recorded > in an interval (seconds), (hence the recently received OGM will have more > weight). At the end the link with more recent OGMs will have more weight > and hence become the current best link. This is a good idea. We are in the process of redesigning the current protocol and welcome any input. Giving older OGMs less "weight" was also one of the ideas we had. Would you mind explaining your concept in greater detail ? > I went through the source code so many times and I got few questions about > this: Are we talking about the batman daemon source code or the batman-adv kernel module ? All my answers will refer to the kernel module as this is the place where most of the development is going on at the moment. > 1. What structure is used to keep track of the sliding window? If its the > has how does it get updated based on the sliding packet range? Each "struct orig_node" has a bitarray to keep track of its own seqnos repeated by its neighbors (bcast_own) and each "struct neigh_node" having a bitarray for its own OGMs (real_bits). > 2. How are the OGM's recorded, is in a form of binary where 1 will > represent the received OGM and 0 otherwise? Correct. > 3. I looked in the source and still not sure of where the ranking decisions > are made, can you enlighten me on that? You mean which function changes the route when a better neighbor was found ? That would be update_orig() in routing.c. > On the second approach we want to use mac layer stats to estimate the > signal strength and probably the congestion rate of the top N ranked links. > We acknowledge the fact that usually links with lower signal strength will > loose more OGM's which results in an automatic low rank, however in a > frequently changing topology, current signal strength is crucial. We plan > to use SNR or RSSI in this case. The concept is known since a while but nobody has implemented it so far because its implementation is fairly complex. Do you have an idea how it should work in the end ? > 1. How can i get the RSSI/LQI of th neighbor links? I don't get this question. You intend to use RSSI but you don't know how ? > I would really appreciate your opinions and advices in this regard more > specially how to go about implementing changes in BATMAN protocol. This is a little abstract. Usually, we discuss specific concepts / ideas in our IRC channel or on the mailing list long before starting to implement them. The past has shown it is often better to let other people dive into your ideas and comment because routing is a rather complex subject. As I mentioned above: We are in a redesign phase right now and welcome anyone interested to join. As the next step we envisioned a collection of routing scenarios in which the current implementation behaves poorly. All routing protocol changes have to go through this collection of scenarios to estimate its impact. What do you think about this idea ? Regards, Marek

8 19

[B.A.T.M.A.N.] HNAs Announcements and Roaming management v2]
by Antonio Quartulli 18 Feb '11

18 Feb '11

Hello to everyone, This is the second version of the HNAs announcement mechanism/Roaming management paper. Please, consider it still a draft. A lot of things have changed since the previous version of this paper. As usual, feel free to comment it. I'll wait for your feedback :) Link: http://www.open-mesh.org/attachment/wiki/hna-improvements/handover.pdf Ragards, -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto "Che" Guevara

2 2

[B.A.T.M.A.N.] Weighting the local packet count; Optimizations for multi-interface nodes
by Daniel Seither 04 Feb '11

04 Feb '11

Hi there, I found an interesting paper today that covers mobility of some nodes in a batman-adv network: > Stefano Annese, Claudio Casetti, Carla F. Chiasserini, Paolo > Cipollone, Andrea Ghittino, and Massimo Reineri. 2009. Assessing > mobility support in mesh networks. In Proceedings of the 4th ACM > international workshop on Experimental evaluation and > characterization (WINTECH '09). http://portal.acm.org/citation.cfm?id=1614297 Unfortunately, the paper is not freely available on the web. If you're blessed with access to the ACM digital library by your school or employer, you can download it free of charge; in other cases you'll have to buy it for USD 15. In the following, I will summarize relevant parts: I) Weighting the local packet count The authors found that when each entry in the sliding window is weighed with the same weight as it is done in the current version of batman-adv, routing loops can occur when mobility is present. They greatly improve their results by weighting with the following function (i = 0..S-1 where S is the window size; 0 means freshest packet): weight(i) := max(1, floor(i * S / e^i)) This function seems to be suboptimal as it weights entry 0 with 1 while the following few entries are boosted with a weight of up to 20 (see attachment). Adding 1 to i should deal with this flaw. However, this weighting function lead to big improvements in the authors' simulations, so I think you are on the right track when thinking about introducing some kind of weighting or moving average to boost the weight of current packets. Here's the Octave/Matlab code I used to create the plot (if you want to do plots for other weighting functions that are discussed, just replace the definition of w and don't forget to use .* and ./ instead of * and / to enforce elementwise operations): > x = 0:63 > w = max(1, x.*64./exp(x)) > stem(x,w) > xlabel('age') > ylabel('weight') II) Optimizations for multi-interface nodes The authors used nodes with 2 radios. They did roughly the following on the mobile nodes (not on the fixed ones): 1) In regular intervals, scan the forwarding tables for each interface to check if any neighbors are known. If an interface has no contact to any neighbor, go to 2) 2) Use the interface without known neighbors to scan all channels except the channel that the other interface is listening to. Don't send OGMs but simply listen for OGMs from other stations. If a channel is found that has a neighbor sending, stay on this channel and start to behave like a normal batman-adv node (send OGMs etc.). I'm not sure if this will be benefitial in other scenarios than in the vehicular network scenario of the paper, but I wanted to share my findings with you. - Daniel

4 4

[B.A.T.M.A.N.] performance patches (v3)
by Marek Lindner 19 Jan '11

19 Jan '11

Hi, the performance patches progress step by step. A few patches already went into the repository the rest is waiting for more review. Thanks to Sven's feedback quite some bugs were squashed. Changes since v2: * code rebased on top of the trunk * some more neigh_node protected by reference counters * call_rcu and kref_put race condition fixed Known issues: * bonding / alternating candidates are not secured by refcounting [see find_router()] - ideas welcome Regards, Marek

2 10

[B.A.T.M.A.N.] NDP patches v4
by Linus Lüssing 12 Jan '11

12 Jan '11

Hi everyone, thanks for all the feedback and reviewing again. The following updated patches address Marek's comments and suggestions: * Introducing a commit for renaming only * batman_packet_ogm -> ogm_packet, batman_packet_ndp -> ndp_packet * BAT_UNICAST followed by BAT_UNICAST_FRAG * structs introduced in the patches where they're used, not earlier (ndp_packet, neigh_entry) * moved own_ndp_send_time to ndp.c * checkpatch cleaning * avoid losing ndp-interval setting on interface down/up * fixed a potential memory leak in error cases * skb_copy instead of skb_clone * rebased to trunk * removal of unnecessary include * hlist instead of doubly linked list * added a break in one list traversal * secure neigh_list with rcu-locking + ref-counting * rename rq_real_bits to ndp_rq_window * use msecs_to_jiffies instead of manual HZ multiplication * fix get_batman_if_by_netdev usage / refcounting * adding licenses Furthermore I've changed the following: * use dev_kfree_skb instead of kfree_skb in case of successful ndp packet reception and processing (so no simple NET_RX_DROP return value) * adding include guards for ndp.h * use "= seqno - 1" in ndp_create_neighbor(), otherwise ndp_update_neighbor_lq() does not update tq/rq/last_valid on first ndp packet Would be great if someone could check the usage of rcu-locking + refcounting. I was also a little confused because in "Documentation/RCU/listRCU.txt" list_del_rcu() and list_add_rcu() are not protected with a spinlock for the list here, but in the batman-adv code we are usually having those extra locks. Do I have to leave those spinlocks or can I remove them for adding/deleting entries in the neigh_list? Cheers, Linus

4 14

[B.A.T.M.A.N.] NDP patches v3
by Linus Lüssing 28 Dec '10

28 Dec '10

Hi everyone, another small, but important update on the NDP patches: * linearize NDP packet's skb before looking at its neighbor entries * Avoid disabling bottom halves twice when receiving/processing OGMs Cheers, Linus

3 19

[B.A.T.M.A.N.] [PATCH] batman-adv: Modifing hna_local_fill_buffer() return value
by Antonio Quartulli 21 Dec '10

21 Dec '10

After changeset 1888, the return value of hna_local_fill_buffer() has not been changed to _count_. In this way an eroneous num_hna was calculated before sending the new OGM packet. --- translation-table.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/translation-table.c b/translation-table.c index a19e16c..a633b5a 100644 --- a/translation-table.c +++ b/translation-table.c @@ -162,7 +162,7 @@ int hna_local_fill_buffer(struct bat_priv *bat_priv, atomic_set(&bat_priv->hna_local_changed, 0); spin_unlock_bh(&bat_priv->hna_lhash_lock); - return i; + return count; } int hna_local_seq_print_text(struct seq_file *seq, void *offset) -- 1.7.2.2

2 1

[B.A.T.M.A.N.] [PATCH] batman-adv: Modifing hna_local_fill_buffer() return value
by Antonio Quartulli 21 Dec '10

21 Dec '10

After changeset 1888, the return value of hna_local_fill_buffer() has not been changed to _count_. In this way an eroneous num_hna was calculated before sending the new OGM packet.

1 0

Re: [B.A.T.M.A.N.] New BMX website at www.bmx6.net
by Sven Eckelmann 20 Dec '10

20 Dec '10

Axel Neumann wrote: > On Montag 20 Dezember 2010, you wrote: > > Please take a look at git://git.open-mesh.org/ecsv/test/bmx.git > > I don't say that it is the holy grail of svn-to-git conversation, but I > > think it could be a better conversation than your bmxd.git > > I am kind of git newbie. You are right and I see what you mean. Finally I > decided to simply fetch the bmx-0.3.x branch from the repository you > mentioned and offer it as a bare master branch at > git://git.bmx6.net/bmxd.git . > > Is there a one line command you used to create this? Essentially I used: > git svn init http://downloads.open-mesh.org/svn/batman/trunk/batman- > experimental/ > to create my former repository but obviously this missed some initial > commits, full names,...:-( No, not really. I tried different things in the past, but none was really able to create an useful export. For example the batman-adv repo was created using following command: $ git svn clone --minimize-url --follow-parent --use-log-author -A \ /home/batman/batman-adv-sync/batman-svn-git-sync/.git/AUTHORS \ --no-metadata http://downloads.open-mesh.org/svn/batman/trunk/batman-adv/ But your history is a little bit more complex. For example git-svn will not resolve the symbolic links - but also svn-all-fast-export wasn't able to export all those things correctly when I tried it. My solution was to write a simple exporter with a static mapping [1] which was optimized for the needs of open-mesh.org. It is a little bit hacky, but at least it solved all problems quite well. Best regards, Sven [1] http://gitorious.org/git-conversation-svn

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N December 2010