[B.A.T.M.A.N.] [PATCH] batman-adv: avoid ap_isolated check for broadcast packet

[B.A.T.M.A.N.] [PATCH] batman-adv: avoid ap_isolated check for broadcast packet

[Antonio Quartulli]

in case of a broadcast packet, the result of the ap_isolated check is always
false (since we have no ff:ff:ff:ff:ff:ff client to check for TT_CLIENT_WIFI),
therefore we can avoid searching the translation table and we can return false
directly

Signed-off-by: Antonio Quartulli <ordex@autistici.org>
---

- Yes, it's just an optimisation that aims to avoid accessing the hash table
  when we already know that it is not needed.


 translation-table.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/translation-table.c b/translation-table.c
index 9a07882..2e16882 100644
--- a/translation-table.c
+++ b/translation-table.c
@@ -2034,6 +2034,11 @@ bool is_ap_isolated(struct bat_priv *bat_priv, uint8_t *src, uint8_t *dst)
 	if (!atomic_read(&bat_priv->ap_isolation))
 		return false;
 
+	/* if we are dealing with a broadcast packet, we can avoid to search the
+	 * translation table */
+	if (is_broadcast_ether_addr(dst))
+		return false;
+
 	tt_local_entry = tt_local_hash_find(bat_priv, dst);
 	if (!tt_local_entry)
 		goto out;
-- 
1.7.3.4

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: avoid ap_isolated check for broadcast packet

[Marek Lindner]

On Monday, March 05, 2012 15:51:51 Antonio Quartulli wrote:
> in case of a broadcast packet, the result of the ap_isolated check is
> always false (since we have no ff:ff:ff:ff:ff:ff client to check for
> TT_CLIENT_WIFI), therefore we can avoid searching the translation table
> and we can return false directly

How about also checking the source address ? You probably also should add 
similar checks for tt_local_add() ? Or do we have "legal" cases in which we 
announce multicast addresses ?

Cheers,
Marek

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: avoid ap_isolated check for broadcast packet

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

On Tue, Mar 06, 2012 at 03:52:46AM +0800, Marek Lindner wrote:
> On Monday, March 05, 2012 15:51:51 Antonio Quartulli wrote:
> > in case of a broadcast packet, the result of the ap_isolated check is
> > always false (since we have no ff:ff:ff:ff:ff:ff client to check for
> > TT_CLIENT_WIFI), therefore we can avoid searching the translation table
> > and we can return false directly
> 
> How about also checking the source address ?

Actually I assumed that "legal" data only is passed to this function and so
there should be no need to check for the source address as well.

But I think this assumption is wrong, right? Actually the "internal" data of a
unicast/broadcast packet is never checked and so I should not assume that the
addresses passed to this function are legal.

> You probably also should add similar checks for tt_local_add() ?

Yep, we probably want to have the same checks in tt_local_add() because a wired
client could send any spoofed packet and we should protect our tables from them.

> Or do we have "legal" cases in which we announce multicast addresses ?

Not that I know (right now)


Cheers,
and greetings from Bruxelles

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]