| Message ID | 1459340372-6971-2-git-send-email-sven@narfation.org (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers |
Return-Path: <b.a.t.m.a.n-bounces@lists.open-mesh.org> X-Original-To: patchwork@open-mesh.org Delivered-To: patchwork@open-mesh.org Received: from open-mesh.org (localhost [127.0.0.1]) by open-mesh.org (Postfix) with ESMTP id 0E571824C3; Wed, 30 Mar 2016 14:19:41 +0200 (CEST) Authentication-Results: open-mesh.org; dkim=fail reason="verification failed; unprotected key" header.d=narfation.org header.i=@narfation.org header.b=gTEuTFbb; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=79.140.41.39; helo=v3-1039.vlinux.de; envelope-from=sven@narfation.org; receiver=b.a.t.m.a.n@lists.open-mesh.org Authentication-Results: open-mesh.org; dmarc=pass header.from=narfation.org Received: from v3-1039.vlinux.de (narfation.org [79.140.41.39]) by open-mesh.org (Postfix) with ESMTPS id E1855824BE for <b.a.t.m.a.n@lists.open-mesh.org>; Wed, 30 Mar 2016 14:19:38 +0200 (CEST) Received: from sven-desktop.home.narfation.org (x5d84b5d1.dyn.telefonica.de [93.132.181.209]) by v3-1039.vlinux.de (Postfix) with ESMTPSA id 4ED051C8001; Wed, 30 Mar 2016 14:19:38 +0200 (CEST) Authentication-Results: v3-1039.vlinux.de; dmarc=none header.from=narfation.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=narfation.org; s=20121; t=1459340378; bh=OH66n+wKRIYfZ7jU9U2Yx8WVW7j2nno+ANF/ql0HQFk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gTEuTFbbw8ZH9B1wlxUDCDI+KvNbBVIox4ONjFbEXUkJgYbZeWsNV6cF6rybj7jBl PSKM3fmeQgJ3YvCMXD98ky3ALRdBE0LDMKBzAPKFn6Lt+HPy6lQFTOewtNp5GiPl12 QudW5YqPFDya01gXkcBRDOU6E3UX4wcoUdFtuVWg= From: Sven Eckelmann <sven@narfation.org> To: b.a.t.m.a.n@lists.open-mesh.org Date: Wed, 30 Mar 2016 14:19:32 +0200 Message-Id: <1459340372-6971-2-git-send-email-sven@narfation.org> X-Mailer: git-send-email 2.8.0.rc3 In-Reply-To: <1459340372-6971-1-git-send-email-sven@narfation.org> References: <1459340372-6971-1-git-send-email-sven@narfation.org> Subject: [B.A.T.M.A.N.] [RFC 2/2] batman-adv: Don't re-broadcast packets on non-wifi devices X-BeenThere: b.a.t.m.a.n@lists.open-mesh.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n.lists.open-mesh.org> List-Unsubscribe: <https://lists.open-mesh.org/mm/options/b.a.t.m.a.n>, <mailto:b.a.t.m.a.n-request@lists.open-mesh.org?subject=unsubscribe> List-Archive: <http://lists.open-mesh.org/pipermail/b.a.t.m.a.n/> List-Post: <mailto:b.a.t.m.a.n@lists.open-mesh.org> List-Help: <mailto:b.a.t.m.a.n-request@lists.open-mesh.org?subject=help> List-Subscribe: <https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n>, <mailto:b.a.t.m.a.n-request@lists.open-mesh.org?subject=subscribe> Reply-To: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n@lists.open-mesh.org> Errors-To: b.a.t.m.a.n-bounces@lists.open-mesh.org Sender: "B.A.T.M.A.N" <b.a.t.m.a.n-bounces@lists.open-mesh.org> |
Commit Message
Sven Eckelmann
March 30, 2016, 12:19 p.m. UTC
It is not necessary to re-broadcast a received broadcast packet on the
rx-device when it is a standard ethernet device. The link medium already
takes care of transporting it to all participants in the broadcast domain.
The re-broadcast on other devices is still necessary to allow the broadcast
packet to be received by devices which are using a different link medium.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
net/batman-adv/main.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 03/30/2016 02:19 PM, Sven Eckelmann wrote: > It is not necessary to re-broadcast a received broadcast packet on the > rx-device when it is a standard ethernet device. The link medium already > takes care of transporting it to all participants in the broadcast domain. > > The re-broadcast on other devices is still necessary to allow the broadcast > packet to be received by devices which are using a different link medium. > > Signed-off-by: Sven Eckelmann <sven@narfation.org> > --- I don't think completely disabling the rebroadcast here without a way to enable it again is a viable option. At least when using batman-adv over VPN tunnels, making batman-adv take care of establishing transitive connectivity may make sense, as batman-adv does this very well and without much configuration. This is actually the recommended setup for non-full-mesh setups using the VPN tool fastd (which is developed by me.) Regards, Matthias
On Thursday 31 March 2016 10:41:04 Matthias Schiffer wrote: [...] > I don't think completely disabling the rebroadcast here without a way to > enable it again is a viable option. > > At least when using batman-adv over VPN tunnels, making batman-adv take > care of establishing transitive connectivity may make sense, as batman-adv > does this very well and without much configuration. This is actually the > recommended setup for non-full-mesh setups using the VPN tool fastd (which > is developed by me.) Thanks for the feedback. There was also a small questionnaire answered by Adrian Reyer about fastd: https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-March/014803.html Kind regards, Sven
diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h index aad4a3a..ddad99d 100644 --- a/net/batman-adv/main.h +++ b/net/batman-adv/main.h @@ -96,7 +96,7 @@ #define BATADV_LOG_BUF_LEN 8192 /* has to be a power of 2 */ /* number of packets to send for broadcasts on different interface types */ -#define BATADV_NUM_BCASTS_SAMEIF 1 +#define BATADV_NUM_BCASTS_SAMEIF 0 #define BATADV_NUM_BCASTS_OTHERIF 1 #define BATADV_NUM_BCASTS_WIRELESS 3 #define BATADV_NUM_BCASTS_MAX 3