When receiving a tt_response, we first delete the old entries and set the initialised flag to false, then add the new received entries, but forgot to set the initialised flag to true again. This may lead to endless loops of requests/responses, as a request is always issued if the initialised flag is not set.
Fix this by moving initialised = true from tt_update_changes() to _tt_update_changes().
Signed-off-by: Simon Wunderlich siwu@hrz.tu-chemnitz.de --- translation-table.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/translation-table.c b/translation-table.c index 27753a0..9a6f315 100644 --- a/translation-table.c +++ b/translation-table.c @@ -1434,6 +1434,7 @@ static void _tt_update_changes(struct bat_priv *bat_priv, */ return; } + orig_node->tt_initialised = true; }
static void tt_fill_gtable(struct bat_priv *bat_priv, @@ -1476,7 +1477,6 @@ static void tt_update_changes(struct bat_priv *bat_priv, tt_save_orig_buffer(bat_priv, orig_node, (unsigned char *)tt_change, tt_num_changes); atomic_set(&orig_node->last_ttvn, ttvn); - orig_node->tt_initialised = true; }
bool is_my_client(struct bat_priv *bat_priv, const uint8_t *addr)
On Sunday, January 22, 2012 21:15:53 Simon Wunderlich wrote:
When receiving a tt_response, we first delete the old entries and set the initialised flag to false, then add the new received entries, but forgot to set the initialised flag to true again. This may lead to endless loops of requests/responses, as a request is always issued if the initialised flag is not set.
Fix this by moving initialised = true from tt_update_changes() to _tt_update_changes().
This is a regression introduced by 8ef201e. Can we add this in the commit message somewhere ? As a reminder for me to squash these 2 patches when preparing the patches for David.
Thanks, Marek
When receiving a tt_response, we first delete the old entries and set the initialised flag to false, then add the new received entries, but forgot to set the initialised flag to true again. This may lead to endless loops of requests/responses, as a request is always issued if the initialised flag is not set.
This is a regression introduced by 8ef201e01c57e3bfbcb7f6db69405ff259c2b907.
Fix this by moving initialised = true from tt_update_changes() to _tt_update_changes().
Signed-off-by: Simon Wunderlich siwu@hrz.tu-chemnitz.de --- translation-table.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/translation-table.c b/translation-table.c index 27753a0..9a6f315 100644 --- a/translation-table.c +++ b/translation-table.c @@ -1434,6 +1434,7 @@ static void _tt_update_changes(struct bat_priv *bat_priv, */ return; } + orig_node->tt_initialised = true; }
static void tt_fill_gtable(struct bat_priv *bat_priv, @@ -1476,7 +1477,6 @@ static void tt_update_changes(struct bat_priv *bat_priv, tt_save_orig_buffer(bat_priv, orig_node, (unsigned char *)tt_change, tt_num_changes); atomic_set(&orig_node->last_ttvn, ttvn); - orig_node->tt_initialised = true; }
bool is_my_client(struct bat_priv *bat_priv, const uint8_t *addr)
On Monday, January 23, 2012 02:40:40 Simon Wunderlich wrote:
When receiving a tt_response, we first delete the old entries and set the initialised flag to false, then add the new received entries, but forgot to set the initialised flag to true again. This may lead to endless loops of requests/responses, as a request is always issued if the initialised flag is not set.
This is a regression introduced by 8ef201e01c57e3bfbcb7f6db69405ff259c2b907.
Applied in revision e4172b0.
Thanks, Marek
b.a.t.m.a.n@lists.open-mesh.org
-
Marek Lindner -
Simon Wunderlich