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.] Fwd: Fwd: Beacons colliding with OGMs
by Carlos Rey-Moreno 13 Feb '13

13 Feb '13

> > Don't know who sent you here but this list does not seem like the right spot > for your questions. Most of them center around madwifi, ahdemo mode and > beaconing - none of these are related to batman-adv (unless I misunderstand?). I though I could ask them here too, but you are right,they are more related to madwifi, I have posted them there. > > > > If you wish to avoid packet collisions in the air I suggest sending less > packets, hence make the intervals longer. Suggesting exact values is a little > hard as those always depend on your environment & setup. I'd recommend to > experiment with these values to find out what works for you. Thanks, I will play them. best, carlos -- Note that I am using a new email account carlos.reymoreno(a)gmail.com, and that the former email address crey(a)ehas.org will be disappearing soon. Thanks for changing this in your contact list. Carlos Rey-Moreno Research Assistant Office 1.28 Department of Computer Science University of the Western Cape Private Bag X17 - Bellville, 7535 Cape Town - South Africa Tel: +27 (0) 21 959 2562 Cel: +27 (0) 76 986 3633 Skype: carlos.reymoreno Twitter: Creym

1 0

[B.A.T.M.A.N.] Fwd: Beacons colliding with OGMs
by Carlos Rey-Moreno 12 Feb '13

12 Feb '13

Hi everyone, I'm new to the list, although I've been using batman-adv for a year now via a couple of networks I've deployed using Mesh Potatoes (based on openwrt). Thank you very much for the work, the result is very, very good. In one of the networks I'm facing from the beginning some problems due to collisions, thus reducing the TQ in some links, that I'd like to avoid in order to optimize performance. One of the messages that could be colliding with the OGMs are the WiFi beacons. I'm a bit confused about the beacon transmission. I posted these questions in the villagetelco list, but they recommended me to ask them here too. Hope you can help me. The mesh is created using ahdemo and according to Madwifi this mode does not use beacons. However, athstats is showing many beacons being transmitted. I guess those are the ones transmitted from the VAP also configured in the same physical interface as the ahdemo. The option sw_merge is recommended to be active in the ahdemo interface to avoid the hardware to try to synchronize the timestamps from the beacons. In addition, it is recommended to create the VAP with option nosbeacon activated for the same reason. According to athstats, beacons are being tx, I guess those from the VAP. However, I'm not sure if athstats is reporting properly, since the chipset does not have diversity for TX, but athstats is reporting so. - If there are no beacons in the mesh (due to ahdemo), or even if there are (from the VAP), and we disable the synchronization of timestamps with the options sw_merge and nosbeacon, how the MPs get their time synchronization as for sharing the same reference when using protocol timers (slottimes, DIFS, etc...) so important for avoiding collisions? - If there are no beacons in the mesh, how do the nodes get the information contained in the beacons about the capabilities of their neighbors (protection, short preamble, etc) as for allowing 11bg seamless operation, from the VAP beacons? - Given the network it is going to be, at least during some months, very static (both in mesh nodes and clients) and assuming the beacons are coming from the VAP, what values would make sense to use as beacon interval and OGM interval, respectively, for avoiding collisions and keeping performance? Thank you very much in advance, Regards carlos -- Note that I am using a new email account carlos.reymoreno(a)gmail.com, and that the former email address crey(a)ehas.org will be disappearing soon. Thanks for changing this in your contact list. Carlos Rey-Moreno Research Assistant Office 1.28 Department of Computer Science University of the Western Cape Private Bag X17 - Bellville, 7535 Cape Town - South Africa Tel: +27 (0) 21 959 2562 Cel: +27 (0) 76 986 3633 Skype: carlos.reymoreno Twitter: Creym

2 1

[B.A.T.M.A.N.] create batman-adv interfaces with netlink v2
by Marek Lindner 09 Feb '13

09 Feb '13

Hi folks, here the updated patchset conceived by Sven Eckelmann for netlink interface creation. Since the first version the following has happened: * the code has been rebased on top of master * batadv_add_slave() / batadv_del_slave() / batadv_interface_free() were renamed to follow general naming conventions * introduced batadv_softif_destroy_netlink() dedicated to netlink deletion * adding clear name separation between batadv_softif_init_early() / batadv_softif_init_late() Apparently, busybox "ip link" does not support creating interfaces through netlink which is why I was unable to actually test the code in my OpenWrt environments. If any if you know a way of making this work on OpenWrt or are brave enough to run the code natively I'd be interested in getting feedback on whether or not this works. I am certain the code was bug free and ran perfectly fine before I touched it. :) Cheers, Marek

3 14

[B.A.T.M.A.N.] [PATCH v2] batman-adv: Remove unused variable
by Emil Goode 07 Feb '13

07 Feb '13

The below commit removed one node parameter from iterators. ed242d01bbe22ea0877472db49b2752d866c921c (hlist: drop the node parameter from iterators) This patch removes a hlist_node struct that is no longer used. Sparse gives a warning: net/batman-adv/originator.c:411:21: warning: unused variable ‘node_tmp’ [-Wunused-variable] Signed-off-by: Emil Goode <emilgoode(a)gmail.com> --- This patch applies to the linux-next tree. v2: Added complete hash and message of dependant commit. net/batman-adv/originator.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/batman-adv/originator.c b/net/batman-adv/originator.c index 43d0f89..96fb80b 100644 --- a/net/batman-adv/originator.c +++ b/net/batman-adv/originator.c @@ -408,7 +408,6 @@ int batadv_orig_seq_print_text(struct seq_file *seq, void *offset) struct net_device *net_dev = (struct net_device *)seq->private; struct batadv_priv *bat_priv = netdev_priv(net_dev); struct batadv_hashtable *hash = bat_priv->orig_hash; - struct hlist_node *node_tmp; struct hlist_head *head; struct batadv_hard_iface *primary_if; struct batadv_orig_node *orig_node; -- 1.7.10.4

2 1

[B.A.T.M.A.N.] [PATCH] batman-adv: Remove unused variable
by Emil Goode 06 Feb '13

06 Feb '13

The commit ed242d01 removed a node parameter from iterators. This patch removes a hlist_node struct that is no longer used. Sparse gives a warning: net/batman-adv/originator.c:411:21: warning: unused variable ‘node_tmp’ [-Wunused-variable] Signed-off-by: Emil Goode <emilgoode(a)gmail.com> --- net/batman-adv/originator.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/batman-adv/originator.c b/net/batman-adv/originator.c index 43d0f89..96fb80b 100644 --- a/net/batman-adv/originator.c +++ b/net/batman-adv/originator.c @@ -408,7 +408,6 @@ int batadv_orig_seq_print_text(struct seq_file *seq, void *offset) struct net_device *net_dev = (struct net_device *)seq->private; struct batadv_priv *bat_priv = netdev_priv(net_dev); struct batadv_hashtable *hash = bat_priv->orig_hash; - struct hlist_node *node_tmp; struct hlist_head *head; struct batadv_hard_iface *primary_if; struct batadv_orig_node *orig_node; -- 1.7.10.4

3 6

[B.A.T.M.A.N.] The B.A.T.M.A.N. project endorses the Battle of the Mesh v6
by Simon Wunderlich 05 Feb '13

05 Feb '13

The Wireless Battle of the Mesh[1] is an event that aims to bring together people from across the globe to test the performance of different routing protocols for ad-hoc networks, like Babel, B.A.T.M.A.N., BMX, OLSR, and 802.11s. Of course, new protocols (working on OpenWRT[2]) are always welcome! This year the even will take place from Monday 15th till Sunday 21st of April at the University of Aalborg, Denmark. The B.A.T.M.A.N. project endorses and supports the Battle of the Mesh v6 because of the efforts made by its community to advance the field of wireless mesh networking and foster the development of grassroots community networks. As last year, many members of the B.A.T.M.A.N. team will gather at the event to attend the B.A.T.M.A.N. developer meeting and present, discuss and experiment with new ideas. Above all, we are all looking forward to connect with interesting people at this event! The B.A.T.M.A.N. project will support the event by: * help to promote the event * numerous members of the B.A.T.M.A.N. community have already confirmed their attendance * co-fund travel costs for attendees from South America * give talks about advancement of our community in certain aspects * help setting up testbed for protocol testing Of course, we are available for discussions, ideas, and live tests! Many other communities endorse and support the Wireless Battle of The Mesh v6, an up to date list of the endorsers[3] of the Battlemesh v6 can be found at the main Battlemesh website[4]. Happy routing, The B.A.T.M.A.N. team [1] http://battlemesh.org/ [2] http://openwrt.org/ [3] http://battlemesh.org/Endorsements2013 [4] http://battlemesh.org/BattleMeshV6

1 0

[B.A.T.M.A.N.] Help and Suggestions Please! :)
by Ashwin Chauhan 04 Feb '13

04 Feb '13

I'm a Computer Science Final Year Undergraduate student. We are a group of Four students and are wanting to do our final group project on B.A.T.M.A.N protocol. Can you help us with the simulating a simple sample network. Also I was thinking, If instead of Broadcasting the OGM Packets every time into the network, we could broadcast them the first time a node joins the network and then just Multicast the OGM packets to its one-hop neighbours from the next time. So that their immediate nodes are still informed about the existence of the node in the network. This way we can reduce the unnecessary flooding of packets. Also when a node moves out of the network its immediate node would know about it much faster and can then broadcast it to other nodes. Trying to do our final year project in this area. Also can someone suggest us some ideas to work upon as our final year Project. :) -- Ashwin

2 1

[B.A.T.M.A.N.] [PATCHv2] batman-adv: Fix alignment of batadv_nc_hash_key_gen
by Martin Hundebøll 31 Jan '13

31 Jan '13

Move second argument to first line and align third argument to the opening parenthesis. Signed-off-by: Martin Hundebøll <martin(a)hundeboll.net> --- v2: Use two lines for arguments instead of three... network-coding.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/network-coding.c b/network-coding.c index 262061b..e6b192c 100644 --- a/network-coding.c +++ b/network-coding.c @@ -371,9 +371,8 @@ static void batadv_nc_purge_paths(struct batadv_priv *bat_priv, * @src: source ethernet mac address going into the hash key * @dst: destination ethernet mac address going into the hash key */ -static void batadv_nc_hash_key_gen(struct batadv_nc_path *key, - const char *src, - const char *dst) +static void batadv_nc_hash_key_gen(struct batadv_nc_path *key, const char *src, + const char *dst) { memcpy(key->prev_hop, src, sizeof(key->prev_hop)); memcpy(key->next_hop, dst, sizeof(key->next_hop)); -- 1.8.1.2

2 1

[B.A.T.M.A.N.] Using BATMAN to create a repeater
by Rip route 30 Jan '13

30 Jan '13

All, I am trying to create a WiFi repeater using hardware that cannot accommodate a normal "bridged repeater" mode. Is it possible to create this type of repeater using BATMAN adv? Thanks Rip

2 3

[B.A.T.M.A.N.] [PATCH] batman-adv: Fix alignment of batadv_nc_hash_key_gen
by Martin Hundebøll 30 Jan '13

30 Jan '13

Make second and third arguments correctly aligned to the opening parenthesis. Signed-off-by: Martin Hundebøll <martin(a)hundeboll.net> --- network-coding.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/network-coding.c b/network-coding.c index 262061b..f97d6cd 100644 --- a/network-coding.c +++ b/network-coding.c @@ -372,8 +372,8 @@ static void batadv_nc_purge_paths(struct batadv_priv *bat_priv, * @dst: destination ethernet mac address going into the hash key */ static void batadv_nc_hash_key_gen(struct batadv_nc_path *key, - const char *src, - const char *dst) + const char *src, + const char *dst) { memcpy(key->prev_hop, src, sizeof(key->prev_hop)); memcpy(key->next_hop, dst, sizeof(key->next_hop)); -- 1.8.1.2

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