B.A.T.M.A.N Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Reyer <are@lihas.de>
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.] No rebroadcast on mesh links
Date: Tue, 29 Mar 2016 10:37:17 +0200	[thread overview]
Message-ID: <20160329083717.GA32035@r2d2.s.lihas.de> (raw)
In-Reply-To: <20160328235247.GA4528@otheros>

Hi,

On Tue, Mar 29, 2016 at 01:52:47AM +0200, Linus Lüssing wrote:
> At least this approach would cover everything we care about for
> current Freifunk setups for now and many more. Without the user
> being able to misconfigure something that easily. (usually a user
> would not set a TRANSITIVE flag on the interface, but e.g. drivers
> and applications creating the interface would)

The interface doesn't have the information needed, so the (assumed) huge
effort of bringing in a new flag for all types of network interfaces is
somewhat useless.
In my eyes we have two types to consider here:
1. lossy links, this is what can be 'fixed' be repeatedly sending a
broadcast out
2. different listeners, e.g. due to wifi range. If we have the same
listeners for everyone on an interface we don't need a re-broadcast at
all.
There are many different possibilities to generate the different
combinations of 1 and 2 with common hardware.
- wifi AP-mode: lossy, same listener
- wifi adhoc mode: lossy, different listeners
- ethernet cable on a switch with the listeners on: non-lossy, same
  listeners
- ethernet cable towards a wifi-bridge in adhoc mode
- ethernet cable towards a wifi-bridge in ap mode
- various types of vpn with and without meshing
- SoC with wifi attached via vlan in adhoc, station or ap mode
- network technologies stacked on others, e.g. tagged vlan a into
  openvSwitch and the lossy wifi link is the untagged vlan a, while
  tagged vlan b is plugged into a solid vpn.
- add bridges to the game, old style or ovs
- add other stuff like ppp, slip, atm, ...
I advocate an admin-settable flag for batman, defaulting to the current
behaviour. Nothing breaks that way, only batman needs to be adjusted and
the patch already exists and is tested. Admins can set the flag if they
think they have use for it and they do it knowingly. If they do it 'by
accident' it is as little batmans fault as if they earased their disk
with some dd-command. Default is sane, just more traffic than necessary
in some common szenarios.
Even if someone decided that flag would not be needed anymore in some
near or far future and therefore it is decided to remove it, only those
that wanted to use it get an error message, it is still a functional
system. However, I seriously doubt there is a good alternative to
manually setting that flag within batman in the forseeable future.

Best regards,
	    Adrian
-- 
LiHAS - Adrian Reyer - Hessenwiesenstraße 10 - D-70565 Stuttgart
Fon: +49 (7 11) 78 28 50 90 - Fax:  +49 (7 11) 78 28 50 91
Mail: lihas@lihas.de - Web: http://lihas.de
Linux, Netzwerke, Consulting & Support - USt-ID: DE 227 816 626 Stuttgart

  reply	other threads:[~2016-03-29  8:37 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 [this message]
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

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=20160329083717.GA32035@r2d2.s.lihas.de \
    --to=are@lihas.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