B.A.T.M.A.N February 2013

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

12 participants
21 discussions

[B.A.T.M.A.N.] [PATCH 1/2] batman-adv: free an hard-interface before adding it
by Antonio Quartulli 16 Feb '13

16 Feb '13

When adding a new hard interface (e.h. wlan0) to a soft interface (e.g. bat0) and the former is already enslaved in another virtual interface (e.g. a software bridge) batman-adv has to free the it first and then continue with the adding mechanism. In this way the behaviour becomes consistent with what "ip link set master" does. At the moment batman-adv enslaves the hard interface without checking for the master device, possibly causing strange behaviours which are never wanted by the users. Reported-by: Marek Lindner <lindner_marek(a)yahoo.de> Signed-off-by: Antonio Quartulli <ordex(a)autistici.org> --- ** Work based on top of the 6 patches adding the new rtnl interface for interface enslaving. Cheers, hard-interface.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/hard-interface.c b/hard-interface.c index c08e39e..fd99e42 100644 --- a/hard-interface.c +++ b/hard-interface.c @@ -311,7 +311,7 @@ int batadv_hardif_enable_interface(struct batadv_hard_iface *hard_iface, const char *iface_name) { struct batadv_priv *bat_priv; - struct net_device *soft_iface; + struct net_device *soft_iface, *master; __be16 ethertype = __constant_htons(ETH_P_BATMAN); int ret; @@ -321,11 +321,6 @@ int batadv_hardif_enable_interface(struct batadv_hard_iface *hard_iface, if (!atomic_inc_not_zero(&hard_iface->refcount)) goto out; - /* hard-interface is part of a bridge */ - if (hard_iface->net_dev->priv_flags & IFF_BRIDGE_PORT) - pr_err("You are about to enable batman-adv on '%s' which already is part of a bridge. Unless you know exactly what you are doing this is probably wrong and won't work the way you think it would.\n", - hard_iface->net_dev->name); - soft_iface = dev_get_by_name(&init_net, iface_name); if (!soft_iface) { @@ -347,6 +342,13 @@ int batadv_hardif_enable_interface(struct batadv_hard_iface *hard_iface, goto err_dev; } + /* check if the interface is enslaved in another virtual one and + * in that case unlink it first + */ + master = netdev_master_upper_dev_get(hard_iface->net_dev); + if (master) + netdev_upper_dev_unlink(hard_iface->net_dev, master); + hard_iface->soft_iface = soft_iface; bat_priv = netdev_priv(hard_iface->soft_iface); -- 1.8.1.2

2 5

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

16 Feb '13

Hi, here the third patch series to get the netlink interface creation into shape. Changes since v2: * Reference counting bugfix in batadv_add_slave() & batadv_del_slave() * Master settings & compat support Kudos to Antonio for providing the compat support and debugging the interface to the bitter end! Cheers, Marek

2 15

[B.A.T.M.A.N.] Android mesh networking app in the works
by Jon Roland 15 Feb '13

15 Feb '13

http://www.networkworld.com/community/blog/android-phones-are-connecting-wi… -- Jon ---------------------------------------------------------- Constitution Society http://constitution.org 2900 W Anderson Ln C-200-322 twitter.com/lex_rex Austin, TX 78757 512/299-5001 jon.roland(a)constitution.org ----------------------------------------------------------

2 2

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: Fix NULL pointer dereference in DAT hash collision avoidance
by Antonio Quartulli 15 Feb '13

15 Feb '13

On Tue, Feb 12, 2013 at 11:18:45AM +0100, Pau Koning wrote: > An entry in DAT with the hashed position of 0 can cause a NULL pointer > dereference when the first entry is checked by batadv_choose_next_candidate. > This first candidate automatically has the max value of 0 and the max_orig_node > of NULL. Not checking max_orig_node for NULL in batadv_is_orig_node_eligible > will lead to a NULL pointer dereference when checking for the lowest address. > > This problem was added in 785ea1144182c341b8b85b0f8180291839d176a8 > ("batman-adv: Distributed ARP Table - create DHT helper functions"). > > Signed-off-by: Pau Koning <paukoning(a)gmail.com> Hello Pau, thank you very much for this fix, this was not an easy one! However, next time please CC our mailing list as well (get_maintainer.pl will give you all the needed addresses), otherwise it may be the case that we overlook such patches and: 1) we don't review it 2) we don't merge it into our repository (which is where the real development goes on). Both 1) and 2) happened with this patch and, in my humble opinion, it is not a good idea to merge such delicate fixes without having a reply from the maintainers. Therefore, please keep us in the loop when sending patches. It would be really appreciated. Regards, -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto "Che" Guevara

1 0

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N February 2013