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;
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
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
b.a.t.m.a.n@lists.open-mesh.org
-
Antonio Quartulli -
Marek Lindner