From patchwork Tue Mar 6 23:58:19 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Antonio Quartulli X-Patchwork-Id: 1571 Return-Path: Received: from latitanza.investici.org (latitanza.investici.org [82.94.249.234]) by open-mesh.org (Postfix) with ESMTPS id CB91F6007E1 for ; Wed, 7 Mar 2012 00:59:34 +0100 (CET) Authentication-Results: open-mesh.org; dkim=pass (1024-bit key) header.i=@autistici.org; dkim-adsp=pass Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: ordex@autistici.org) by localhost (Postfix) with ESMTPSA id 0B20F983A4; Tue, 6 Mar 2012 23:59:33 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org 0B20F983A4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=autistici.org; s=stigmate; t=1331078374; bh=dhoHVPZUZkWs+ASUVs5OqRElTWvKvIbczWH+gsK4ciM=; h=From:To:Cc:Subject:Date:Message-Id; b=lIUlyOPYzABs1xUw4pkdPTNXrRJnzeJdj+VZT7nqdhgo605J/syW1ra/hdOtvgL5d LGx4MvybYZ8KWvNwggnTkNRbe4JU71VJD0dvWerb5sBE/7B0l27T99+Hs9Mmy/+14Z EeYlu7vHK1TAdA8CoTAKfW6kHtwk3f7QSMLlxVoU= From: Antonio Quartulli To: b.a.t.m.a.n@lists.open-mesh.org Date: Wed, 7 Mar 2012 00:58:19 +0100 Message-Id: <1331078299-2984-1-git-send-email-ordex@autistici.org> X-Mailer: git-send-email 1.7.3.4 Subject: [B.A.T.M.A.N.] [PATCH] batman-adv: fix PENDING flag behaviour in case of multiple roamings X-BeenThere: b.a.t.m.a.n@lists.open-mesh.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: The list for a Better Approach To Mobile Ad-hoc Networking List-Id: The list for a Better Approach To Mobile Ad-hoc Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 23:59:35 -0000 In case of multiple romaings always between the same two nodes (going back and forth from one to the other) within the same originator interval (this is much more suitable in setups where the orig_interval last longer than one sec), the flags should not be messed up and should eventually converge to a correct status. In particular, if we marked a LOCAL client as PENDING due to the roaming, if the client comes back to us we have to simply reset the PENDING flag and remove the DEL event from the sending queue. This is possible because the DEL operation has not been committed and advertised yet. If we don't do that, the client is deleted and then re-added, this can create connection problems to the client and would also create useless noise in the network due to the advertisement overhead. Signed-off-by: Antonio Quartulli --- translation-table.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/translation-table.c b/translation-table.c index 9f4d706..4bd9490 100644 --- a/translation-table.c +++ b/translation-table.c @@ -206,6 +206,15 @@ void tt_local_add(struct net_device *soft_iface, const uint8_t *addr, if (tt_local_entry) { tt_local_entry->last_seen = jiffies; + + /* in case of multiple roaming in the same orig interval we + * should correctly handle the client flags: a client which was + * marked as pending can now be unmarked because it came back */ + if (tt_local_entry->common.flags & TT_CLIENT_PENDING) { + tt_local_entry->common.flags &= ~TT_CLIENT_PENDING; + goto reinsertion; + } + goto out; } @@ -242,7 +251,7 @@ void tt_local_add(struct net_device *soft_iface, const uint8_t *addr, tt_local_entry_free_ref(tt_local_entry); goto out; } - +reinsertion: tt_local_event(bat_priv, addr, tt_local_entry->common.flags); /* remove address from global hash if present */