On Monday, October 17, 2011 14:25:13 Antonio Quartulli wrote:
> In the TT_RESPONSE packet, the number of carried entries is not correctly
> set. This leads to a wrong interpretation of the packet payload on the
> receiver side causing random entries to be added to the global translation
> table. Therefore the latter gets always corrupted, triggering a table
> recovery all the time.
Applied in revision ff7887c.
Thanks,
Marek
In the TT_RESPONSE message, the number of carried entries was not correctly set.
In case of TT_QUERY message of type TT_RESPONSE the data field represents the
number of entries that are going to be sent. Such number has to be set *after*
counting the number of successfully copied entries.
Signed-off-by: Antonio Quartulli <ordex(a)autistici.org>
---
translation-table.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/translation-table.c b/translation-table.c
index 6102cd2..b3e670b 100644
--- a/translation-table.c
+++ b/translation-table.c
@@ -1050,7 +1050,6 @@ static struct sk_buff *tt_response_fill_table(uint16_t tt_len, uint8_t ttvn,
tt_response = (struct tt_query_packet *)skb_put(skb,
tt_query_size + tt_len);
tt_response->ttvn = ttvn;
- tt_response->tt_data = htons(tt_tot);
tt_change = (struct tt_change *)(skb->data + tt_query_size);
tt_count = 0;
@@ -1076,6 +1075,10 @@ static struct sk_buff *tt_response_fill_table(uint16_t tt_len, uint8_t ttvn,
}
rcu_read_unlock();
+ /* store in the message the number of entries we have successfully
+ * copied */
+ tt_response->tt_data = htons(tt_count);
+
out:
return skb;
}
--
1.7.3.4
Currently the counter of tt_local_entry structures (tt_local_num) is incremented
each time the tt_local_reset_flags() is invoked causing the node to send wrong
TT_REPONSE packets containing a copy of non-initialised memory thus corrupting
other nodes global translation table and making higher level communication
impossible.
Reported-by: Junkeun Song <jun361(a)gmail.com>
Signed-off-by: Antonio Quartulli <ordex(a)autistici.org>
Acked-by: Junkeun Song <jun361(a)gmail.com>
---
translation-table.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/translation-table.c b/translation-table.c
index 2d2cfc1..d4a3917 100644
--- a/translation-table.c
+++ b/translation-table.c
@@ -1727,6 +1727,8 @@ static void tt_local_reset_flags(struct bat_priv *bat_priv, uint16_t flags)
rcu_read_lock();
hlist_for_each_entry_rcu(tt_local_entry, node,
head, hash_entry) {
+ if (!(tt_local_entry->flags & flags))
+ continue;
tt_local_entry->flags &= ~flags;
atomic_inc(&bat_priv->num_local_tt);
}
--
1.7.3.4
The TT_RESPONSE message can be linearised only if we plan to access the tt
payload (only if the message is directed to me). In all the other cases we can
avoid this memory operation
Signed-off-by: Antonio Quartulli <ordex(a)autistici.org>
---
corrected typo in the commit message
routing.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/routing.c b/routing.c
index f961cc5..20804f4 100644
--- a/routing.c
+++ b/routing.c
@@ -616,13 +616,14 @@ int recv_tt_query(struct sk_buff *skb, struct hard_iface *recv_if)
}
break;
case TT_RESPONSE:
- /* packet needs to be linearized to access the TT changes */
- if (skb_linearize(skb) < 0)
- goto out;
+ if (is_my_mac(tt_query->dst)) {
+ /* packet needs to be linearized to access the TT
+ * changes */
+ if (skb_linearize(skb) < 0)
+ goto out;
- if (is_my_mac(tt_query->dst))
handle_tt_response(bat_priv, tt_query);
- else {
+ } else {
bat_dbg(DBG_TT, bat_priv,
"Routing TT_RESPONSE to %pM [%c]\n",
tt_query->dst,
--
1.7.3.4
Hello!
Yesterday I have build an openwrt image with batman adv but i see that this
version is not complatible with past version, sniffing packets i see batman adv
v 14 instead of 12
Now i can update all openwrt nodes but the problem is that some nodes are
gentoo based, how to see the batman version and in what version of gentoo
kernel i can find the same as openwrt ?
many thanks!
In choose_orig and vis_choose the size agrument was int while the hash
result is uint32_t, then the argument has been fixed to uint32_t too.
The same apply for the returned type.
Signed-off-by: Antonio Quartulli <ordex(a)autistici.org>
---
hash.h | 2 +-
originator.h | 2 +-
vis.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hash.h b/hash.h
index d20aa71..588ef79 100644
--- a/hash.h
+++ b/hash.h
@@ -33,7 +33,7 @@ typedef int (*hashdata_compare_cb)(const struct hlist_node *, const void *);
/* the hashfunction, should return an index
* based on the key in the data of the first
* argument and the size the second */
-typedef int (*hashdata_choose_cb)(const void *, int);
+typedef uint32_t (*hashdata_choose_cb)(const void *, uint32_t);
typedef void (*hashdata_free_cb)(struct hlist_node *, void *);
struct hashtable_t {
diff --git a/originator.h b/originator.h
index cfc1f60..67765ff 100644
--- a/originator.h
+++ b/originator.h
@@ -42,7 +42,7 @@ int orig_hash_del_if(struct hard_iface *hard_iface, int max_if_num);
/* hashfunction to choose an entry in a hash table of given size */
/* hash algorithm from http://en.wikipedia.org/wiki/Hash_table */
-static inline int choose_orig(const void *data, int32_t size)
+static inline uint32_t choose_orig(const void *data, uint32_t size)
{
const unsigned char *key = data;
uint32_t hash = 0;
diff --git a/vis.c b/vis.c
index f81a6b6..a9cd152 100644
--- a/vis.c
+++ b/vis.c
@@ -66,7 +66,7 @@ static int vis_info_cmp(const struct hlist_node *node, const void *data2)
/* hash function to choose an entry in a hash table of given size */
/* hash algorithm from http://en.wikipedia.org/wiki/Hash_table */
-static int vis_info_choose(const void *data, int size)
+static uint32_t vis_info_choose(const void *data, uint32_t size)
{
const struct vis_info *vis_info = data;
const struct vis_packet *packet;
--
1.7.3.4
get_orig_node() tries to retrieves an orig_node object and possibly creates it if
not present. This is not the wanted behaviours in the translation-table code,
instead we want to get the orig_node only if it really exists, without creating
it.
Signed-off-by: Antonio Quartulli <ordex(a)autistici.org>
---
translation-table.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/translation-table.c b/translation-table.c
index 7de9960..6102cd2 100644
--- a/translation-table.c
+++ b/translation-table.c
@@ -1170,11 +1170,11 @@ static bool send_other_tt_response(struct bat_priv *bat_priv,
(tt_request->flags & TT_FULL_TABLE ? 'F' : '.'));
/* Let's get the orig node of the REAL destination */
- req_dst_orig_node = get_orig_node(bat_priv, tt_request->dst);
+ req_dst_orig_node = orig_hash_find(bat_priv, tt_request->dst);
if (!req_dst_orig_node)
goto out;
- res_dst_orig_node = get_orig_node(bat_priv, tt_request->src);
+ res_dst_orig_node = orig_hash_find(bat_priv, tt_request->src);
if (!res_dst_orig_node)
goto out;
@@ -1300,7 +1300,7 @@ static bool send_my_tt_response(struct bat_priv *bat_priv,
my_ttvn = (uint8_t)atomic_read(&bat_priv->ttvn);
req_ttvn = tt_request->ttvn;
- orig_node = get_orig_node(bat_priv, tt_request->src);
+ orig_node = orig_hash_find(bat_priv, tt_request->src);
if (!orig_node)
goto out;
--
1.7.3.4
The TT_RESPONSE m essage can be linearised only if we plan to access the tt
payload (only if the message is directed to me). In all the other cases we can
avoid this memory operation
Signed-off-by: Antonio Quartulli <ordex(a)autistici.org>
---
routing.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/routing.c b/routing.c
index f961cc5..1a5d046 100644
--- a/routing.c
+++ b/routing.c
@@ -616,13 +616,13 @@ int recv_tt_query(struct sk_buff *skb, struct hard_iface *recv_if)
}
break;
case TT_RESPONSE:
- /* packet needs to be linearized to access the TT changes */
- if (skb_linearize(skb) < 0)
- goto out;
+ if (is_my_mac(tt_query->dst)) {
+ /* packet needs to be linearized to access the TT changes */
+ if (skb_linearize(skb) < 0)
+ goto out;
- if (is_my_mac(tt_query->dst))
handle_tt_response(bat_priv, tt_query);
- else {
+ } else {
bat_dbg(DBG_TT, bat_priv,
"Routing TT_RESPONSE to %pM [%c]\n",
tt_query->dst,
--
1.7.3.4
Hey there,
as most of us are concentrating batman-advanced now, Marek suggested
that we should create a new logo for our next generation mesh technology. ;)
The "old" ascii logo is still great, but most people associate it with
the layer 3 BATMAN ...
Therefore, I made some sketches and would like to ask for opinions from
the list. Any comments, suggestions, criticism are welcome. My current draft
is this one:
http://packetmixer.de/batlogo/bat_gimped3.jpg
you can find some more sketches here (maybe you like another sketch more ...):
http://packetmixer.de/batlogo/
looking forward to your feedback,
Simon