Hi!
Ubiquiti provides OpenWrt based SDK for their firmware. To my
information, it contains some proprietary madwifi-based WiFi drivers
with some older OpenWrt version. My question is how it would be
possible to run Batman on top of their firmware (thus not latest
OpenWrt). As Batman is in kernel, is is enough kernel-backwards
compatible to be able to run also on older (2.6) kernel versions? For
olsrd it is much simpler: you just install olsrd package and this is
it.
Mitar
I have an interesting hardware setup I'd like to explore.
Basically, I would like to take commodity ubiquiti and/or openmesh
hardware and build a mesh with two different node types, some having
just 1 radio and others having multiple radios, a standard node and a
super node.
the standard node is:
a picostation flashed to openwrt running batman-adv and running the
radio in Ad-Hoc mode. Alternately an OM2P flashed to openwrt. This
is the basic client radio
the super node is:
a group of picostations or nanostations, flashed openwrt in adhoc
mode, but acting only as the L2 transport with a router at the center
running batman-adv.
The idea is that the super nodes have multiple radios in multiple
channels and can take advantage of link alternation allowing super
nodes to keep much higher bandwidth between them while the standard
nodes are cheap. The 'router' MIGHT also have a radio for client
access (unifi station flashed to openwrt maybe, or an ALIX board)
The supernode will have more CPU and also be the target of
backhaul/shorthaul links to cut down on hop count. The main router
would also be a batman-adv device, probably an x86 server, and would
be the border router for the mesh.
some questions,
I know that the supernodes will have higher throughput capabilities
due to dual mesh radios, but how will batman-adv know this or how
would I tell it? Is the internal mechanism for determining the best
path going to take this into account? Is there a way to identify a
supernode as being a better path above and beyond the automatic
batman-adv mechanisms?
Is having separate radios connected to a batman-adv router going to
behave how I presume? That multiple node2node connections will be
identified and the links be alternated when appropriate?
If the supernodes have 2 mesh radios, 1 in 5Ghz and 1 in 2.4Ghz, then
the standard nodes will only be able to connect to the 2.4Ghz channel
which might make it inappropriate to do link alternating on these two
links because of the shared traffic. Should batman-adv automatically
stop alternating the tx/rx on these links when one of the channels
starts to get saturated?
some other info:
the supernodes may have a link directly to the main distribution
point, but may also be linked just to another supernode and not to the
main distribution point, or possibly both.
the supernodes are likely to have more than 2 mesh radios as some of
these could be direction antennas. A supernode might have 3x 2.4Ghz
radios for mesh, 2x 5Ghz radios for mesh, and a 2.4Ghz radio for
non-mesh clients. These would most likely all be connected to a
switch port and only be on a single ethernet interface as far as
batman-adv is concerned.
During an OGM-interval (time between two different OGM sendings) the same client
could roam away and then roam back to us. In this case the node would add two
events to the events list (that is going to be sent appended to the next OGM). A
DEL one and an ADD one. Obviously they will only increase the overhead (either in
the air and on the receiver side) and eventually trigger wrong states/events
without producing any real effect.
For this reason we can safely delete any ADD event with its related DEL one.
Signed-off-by: Antonio Quartulli <ordex(a)autistici.org>
---
changes in v3:
- rebased on top of the last patches for code restyling
translation-table.c | 40 +++++++++++++++++++++++++++++++++++++---
1 file changed, 37 insertions(+), 3 deletions(-)
diff --git a/translation-table.c b/translation-table.c
index cb1d3a8..2c8266a 100644
--- a/translation-table.c
+++ b/translation-table.c
@@ -156,7 +156,9 @@ batadv_tt_orig_list_entry_free_ref(struct tt_orig_list_entry *orig_entry)
static void batadv_tt_local_event(struct bat_priv *bat_priv,
const uint8_t *addr, uint8_t flags)
{
- struct tt_change_node *tt_change_node;
+ struct tt_change_node *tt_change_node, *entry, *safe;
+ bool event_removed = false;
+ bool del_op_requested, del_op_entry;
tt_change_node = kmalloc(sizeof(*tt_change_node), GFP_ATOMIC);
@@ -166,13 +168,45 @@ static void batadv_tt_local_event(struct bat_priv *bat_priv,
tt_change_node->change.flags = flags;
memcpy(tt_change_node->change.addr, addr, ETH_ALEN);
+ del_op_requested = flags & TT_CLIENT_DEL;
+
+ /* check for ADD+DEL or DEL+ADD events */
spin_lock_bh(&bat_priv->tt_changes_list_lock);
+ list_for_each_entry_safe(entry, safe, &bat_priv->tt_changes_list,
+ list) {
+ if (!batadv_compare_eth(entry->change.addr, addr))
+ continue;
+
+ /* DEL+ADD in the same orig interval have no effect and can be
+ * removed to avoid silly behaviour on the receiver side. The
+ * other way around (ADD+DEL) can happen in case of roaming of
+ * a client still in the NEW state. Roaming of NEW clients is
+ * now possible due to automatically recognition of "temporary"
+ * clients
+ */
+ del_op_entry = entry->change.flags & TT_CLIENT_DEL;
+ if (!del_op_requested && del_op_entry)
+ goto del;
+ if (del_op_requested && !del_op_entry)
+ goto del;
+ continue;
+del:
+ list_del(&entry->list);
+ kfree(entry);
+ event_removed = true;
+ goto unlock;
+ }
+
/* track the change in the OGMinterval list */
list_add_tail(&tt_change_node->list, &bat_priv->tt_changes_list);
- atomic_inc(&bat_priv->tt_local_changes);
+
+unlock:
spin_unlock_bh(&bat_priv->tt_changes_list_lock);
- atomic_set(&bat_priv->tt_ogm_append_cnt, 0);
+ if (event_removed)
+ atomic_dec(&bat_priv->tt_local_changes);
+ else
+ atomic_inc(&bat_priv->tt_local_changes);
}
int batadv_tt_len(int changes_num)
--
1.7.9.4
On Thursday, May 31, 2012 21:21:19 you wrote:
> i'm sorry but in the makefile of openwrt package the mantainer is
> marek linder......
>
> ???
Guess that due to copy & paste. Maybe you simply send a patch to the openwrt-
devel list ?
Marek
Hello everyone, i'm trying to setup an emulation environment and i
have some questions:
* although i downloaded the vde2-2.3.1 source and the appropriate
patches (vde2-2.3.1_colour.patch and
vde2-2.3.1-wirefilter-ethertype.patch ) the wirefilter patch could not
be applied giving the following output
$patch <vde2-2.3.1-wirefilter-ethertype.patch
patching file wirefilter.c
Hunk #1 FAILED at 59.
Hunk #2 FAILED at 524.
Hunk #3 FAILED at 1391.
Hunk #4 FAILED at 1402.
Hunk #5 FAILED at 1421.
Hunk #6 FAILED at 1475.
6 out of 6 hunks FAILED -- saving rejects to file wirefilter.c.rej
any tips on how I can find why it failed and how to apply the patch?
*I ran the script without the wirefilter patch and I got a blank
terminal,is this expected?
* how can I get the dmesg(and generally any command) output
from the qemu instances?
*provided i have built open-wrt with batman and have put the
appropriate script in wrt's ./files/etc/rc.local batman should start
as a daemon right?
given that, I should be seeing batman packets in the capture, right?
*wireshark should recognize that a given packet is an ogm packet or
there is another way to filter only the relevant ones?
Thank you for your time
Hi all,
there is an error in /etc/hotplug.d/net/99-batman-adv at line 9.
The function that be called is bat_config and not config_bat
Could someone fix it in latest batman-adv stable release?
Rgds
--
Filippo Sallemi