From: Simon Wunderlich <sw@simonwunderlich.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] No rebroadcast on mesh links
Date: Wed, 30 Mar 2016 10:08:45 +0200 [thread overview]
Message-ID: <17187322.PaAoUXZz7c@prime> (raw)
In-Reply-To: <20160329000219.GB4528@otheros>
[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]
Hey Linus,
On Tuesday 29 March 2016 02:02:19 Linus Lüssing wrote:
> On Mon, Mar 28, 2016 at 11:19:09PM +0200, Roland Volkmann wrote:
> > Node A cannot know, whether you have scenario 1 or 2.
>
> But an ethernet driver or mac80211 with AP/STA interfaces
> (without ap-isolation) could. Or tinc with forwarding enabled
> would know. All these can be pretty sure that things are
> transitive and could set a TRANSITIVE flag quite safely.
>
> Any other interface type, driver etc. would leave the
> TRANSITIVE flag unset by default to be on the safe side.
what do you think the chances are for linux-net guys to adopt this flag? We
could send an RFC to see how they would feel about it. I remember last time I
wanted to change something in SKB struct, they didn't like that at all (maybe
for good reason). Could be that they don't want to "bloat" the flags too, but
we can/should try.
The other question would be more practical: This would not be backward
compatible with older kernels, so everyone who wants to use that new features
would need to upgrade the kernel (or wait until new kernels are available). Do
you agree?
Cheers,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2016-03-30 8:08 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-25 21:35 [B.A.T.M.A.N.] No rebroadcast on mesh links Roland Volkmann
2016-03-25 22:46 ` Sven Eckelmann
2016-03-25 23:19 ` Roland Volkmann
2016-03-27 2:38 ` Marek Lindner
2016-03-28 13:43 ` Roland Volkmann
2016-03-28 14:43 ` Marek Lindner
2016-03-28 19:11 ` Linus Lüssing
2016-03-28 21:19 ` Roland Volkmann
2016-03-28 23:52 ` Linus Lüssing
2016-03-29 8:37 ` Adrian Reyer
2016-03-29 9:50 ` Sven Eckelmann
2016-03-29 17:59 ` Adrian Reyer
2016-03-29 18:55 ` Sven Eckelmann
2016-03-29 23:37 ` Roland Volkmann
2016-03-30 2:15 ` Marek Lindner
2016-03-30 8:00 ` Sven Eckelmann
2016-03-30 9:09 ` Roland Volkmann
2016-03-30 12:23 ` Sven Eckelmann
2016-03-30 11:58 ` Simon Wunderlich
2016-03-30 13:58 ` Adrian Reyer
2016-03-30 16:08 ` Sven Eckelmann
2016-03-30 19:55 ` Adrian Reyer
2016-03-31 12:11 ` Simon Wunderlich
2016-03-31 12:21 ` Simon Wunderlich
2016-03-31 15:54 ` Antonio Quartulli
2016-03-31 16:25 ` Linus Lüssing
2016-03-31 15:35 ` Linus Lüssing
2016-03-31 15:49 ` Antonio Quartulli
2016-03-31 16:53 ` Linus Lüssing
2016-03-31 16:01 ` Antonio Quartulli
2016-03-31 17:17 ` Linus Lüssing
2016-04-13 12:17 ` Simon Wunderlich
2016-04-13 12:22 ` Sven Eckelmann
2016-03-29 0:02 ` Linus Lüssing
2016-03-29 6:38 ` Roland Volkmann
2016-03-30 8:08 ` Simon Wunderlich [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=17187322.PaAoUXZz7c@prime \
--to=sw@simonwunderlich.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox