From: Antonio Quartulli <ordex@autistici.org>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: avoid ap_isolated check for broadcast packet
Date: Tue, 6 Mar 2012 00:11:06 +0100 [thread overview]
Message-ID: <20120305231105.GD31430@ritirata.org> (raw)
In-Reply-To: <201203060352.47058.lindner_marek@yahoo.de>
[-- 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 --]
prev parent reply other threads:[~2012-03-05 23:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-05 7:51 [B.A.T.M.A.N.] [PATCH] batman-adv: avoid ap_isolated check for broadcast packet Antonio Quartulli
2012-03-05 19:52 ` Marek Lindner
2012-03-05 23:11 ` Antonio Quartulli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120305231105.GD31430@ritirata.org \
--to=ordex@autistici.org \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.