commits

commits@lists.open-mesh.org

1 participants
12395 discussions

[doc] backup-redmine/2023-01-14,main: doc: open-mesh/MailingList (b97c86e8)
by postmaster＠open-mesh.org 14 Jan '23

14 Jan '23

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2023-01-14,main >--------------------------------------------------------------- commit b97c86e817bcbe5f52e7964d97ba086d1ffe2cf7 Author: Sven Eckelmann <sven(a)narfation.org> Date: Fri Jan 6 19:19:54 2023 +0000 doc: open-mesh/MailingList >--------------------------------------------------------------- b97c86e817bcbe5f52e7964d97ba086d1ffe2cf7 open-mesh/MailingList.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/MailingList.textile b/open-mesh/MailingList.textile index 43d35061..6f55f6a2 100644 --- a/open-mesh/MailingList.textile +++ b/open-mesh/MailingList.textile @@ -4,4 +4,4 @@ You can subscribe to our Mailing Lists "here":https://lists.open-mesh.org/. You +Note+: HTML email will be rejected - just plain text is allowed (this cuts the rate of SPAM mails dramatically). -Old messages can be read in the "B.A.T.M.A.N. archives":https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/. +Old messages can be read in the "B.A.T.M.A.N. archives":https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/. Or via the various subscription (or mirror) methods from "lore.kernel.org":https://lore.kernel.org/batman

1 0

[doc] backup-redmine/2023-01-14,main: doc: open-mesh/News-draft (600682f3)
by postmaster＠open-mesh.org 14 Jan '23

14 Jan '23

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2023-01-14,main >--------------------------------------------------------------- commit 600682f3f02447701da9cdb041d812afb626e480 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jan 7 14:43:40 2023 +0000 doc: open-mesh/News-draft >--------------------------------------------------------------- 600682f3f02447701da9cdb041d812afb626e480 open-mesh/News-draft.textile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/open-mesh/News-draft.textile b/open-mesh/News-draft.textile index 1882b1bd..270c1ba1 100644 --- a/open-mesh/News-draft.textile +++ b/open-mesh/News-draft.textile @@ -12,6 +12,7 @@ Thanks to all people sending in patches: * Jakub Kicinski <kuba(a)kernel.org> * Jason A. Donenfeld <Jason(a)zx2c4.com> +* Sven Eckelmann <sven(a)narfation.org> * Simon Wunderlich <sw(a)simonwunderlich.de> @@ -50,7 +51,7 @@ bugfixes 2023.0 (2023-01-10) =================== -* support latest kernels (4.9 - 6.2) +* support latest kernels (4.14 - 6.2) </pre> h2. batctl

1 0

[doc] backup-redmine/2023-01-14,main: doc: batman-adv/Multicast-Packet-Type (d93a058b)
by postmaster＠open-mesh.org 14 Jan '23

14 Jan '23

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2023-01-14,main >--------------------------------------------------------------- commit d93a058b2bdf5da621ef74e01d95e4def93a2e89 Author: Linus L��ssing <linus.luessing(a)c0d3.blue> Date: Mon Dec 26 15:25:13 2022 +0000 doc: batman-adv/Multicast-Packet-Type >--------------------------------------------------------------- d93a058b2bdf5da621ef74e01d95e4def93a2e89 batman-adv/Multicast-Packet-Type.textile | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/batman-adv/Multicast-Packet-Type.textile b/batman-adv/Multicast-Packet-Type.textile index c4b557ff..f8a21649 100644 --- a/batman-adv/Multicast-Packet-Type.textile +++ b/batman-adv/Multicast-Packet-Type.textile @@ -1,6 +1,8 @@ h1. DRAFT - Multicast Packet Type -_This is a draft and not implemented at the moment._ +_This is a draft and not upstream yet._ + +Implementation: "linus/multicast-packet-type":https://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/linus/multicast-packet-type h2. Brief @@ -87,13 +89,13 @@ Signalizes that: h2. Limitations -* Neither the BATMAN IV nor BATMAN V routing algorithm can currently perform path MTU discovery. And the batman-adv fragmentation is not yet capable of handling this new batman-adv packet type, nor is it capable of reassembling per hop. Therefore the easy solution for now is to require an interface MTU of at least 1280 bytes on each active hard interface. 1280 bytes is also the IPv6 minimum MTU, so this makes it already less likely to be undercut in practice. +* Neither the BATMAN IV nor BATMAN V routing algorithm can currently perform path MTU discovery. And the batman-adv fragmentation is not yet capable of handling this new batman-adv packet type, nor is it capable of reassembling per hop. Therefore the easy solution for now is to require an interface MTU of at least 1280 bytes on each active hard interface. 1280 bytes is also the "IPv6 minimum MTU":https://www.rfc-editor.org/rfc/rfc2460#section-5, so this makes it already less likely to be undercut in practice. * If the payload data's size together with the number destination nodes is too large, so if the final batman-adv multicast packet would exceed 1280 bytes (excluding the outter ethernet frame), then the batman-adv multicast packet type cannot/will not be used. Example limits: ** 2 destination nodes: 1222 bytes ethernet frame size ** 8 destination nodes: 1186 bytes ethernet frame size ** 32 destination nodes: 1030 bytes ethernet frame size ** 128 destination nodes: 454 bytes ethernet frame size -** 196 destination nodes: 46 bytes ethernet frame size (= minimum ethernet frame size without a VLAN) +** 196 destination nodes: 46 bytes ethernet frame size (= "minimum ethernet frame size":https://en.wikipedia.org/wiki/Ethernet_frame#Payload without a VLAN) If such a limitation is reached then batman-adv will either fallback to multicast via multiple batman-adv unicast packes. Or if that is not possible either, to classic flooding.

1 0

[doc] backup-redmine/2023-01-14,main: doc: batman-adv/Multicast-Packet-Type (7799aba0)
by postmaster＠open-mesh.org 14 Jan '23

14 Jan '23

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2023-01-14,main >--------------------------------------------------------------- commit 7799aba0a3b162dbdfa2e122476b4e92ad57963f Author: Linus L��ssing <linus.luessing(a)c0d3.blue> Date: Mon Dec 26 15:17:54 2022 +0000 doc: batman-adv/Multicast-Packet-Type >--------------------------------------------------------------- 7799aba0a3b162dbdfa2e122476b4e92ad57963f batman-adv/Multicast-Packet-Type.textile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/batman-adv/Multicast-Packet-Type.textile b/batman-adv/Multicast-Packet-Type.textile index d74b1595..c4b557ff 100644 --- a/batman-adv/Multicast-Packet-Type.textile +++ b/batman-adv/Multicast-Packet-Type.textile @@ -97,6 +97,8 @@ h2. Limitations If such a limitation is reached then batman-adv will either fallback to multicast via multiple batman-adv unicast packes. Or if that is not possible either, to classic flooding. +* Multicast fanout setting is not considered yet. A multicast payload packet will only use one or no batman-adv multicast packet for now, for reduced complexity. And a batman-adv node would not know how to best split destinations to reduce the number of resplits/retransmissions along the paths / multicast tree. + h2. Open questions h3. -#Num Dests size-

1 0

[doc] backup-redmine/2023-01-14,main: doc: batman-adv/Multicast-Packet-Type (62fecea0)
by postmaster＠open-mesh.org 14 Jan '23

14 Jan '23

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2023-01-14,main >--------------------------------------------------------------- commit 62fecea0137e663379673d40967eda7c0fa52f72 Author: Linus L��ssing <linus.luessing(a)c0d3.blue> Date: Mon Dec 26 17:06:21 2022 +0000 doc: batman-adv/Multicast-Packet-Type >--------------------------------------------------------------- 62fecea0137e663379673d40967eda7c0fa52f72 batman-adv/Multicast-Packet-Type.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Multicast-Packet-Type.textile b/batman-adv/Multicast-Packet-Type.textile index 69bdf686..4a720d4f 100644 --- a/batman-adv/Multicast-Packet-Type.textile +++ b/batman-adv/Multicast-Packet-Type.textile @@ -150,7 +150,7 @@ h3. -Fragmentation / MTUs:- h3. -Adding a sequence number? / How to avoid loops with tracker marking later?- --When later implementing a split control <-> data plane as originally envisioned, by allowing to send a multicast packet with only the tracker TVLV, without data. And caching this information to fill a multicast routing table. And then allowing to send a multicast packet without the tracker TVLV afterwards, there is the following issue:- +-When later implementing a split control <=> data plane as originally envisioned, by allowing to send a multicast packet with only the tracker TVLV, without data. And caching this information to fill a multicast routing table. And then allowing to send a multicast packet without the tracker TVLV afterwards, there is the following issue:- -When first a path is marked through the tracker TVLV, then paths change due to OGM updates. And then a tracker packet marks such new paths then the merger of both the old and newly tracker marked paths could create routing loops, as the old path is not automatically invalidated.-

1 0

[doc] backup-redmine/2023-01-14,main: doc: batman-adv/Multicast-Packet-Type (3b478e08)
by postmaster＠open-mesh.org 14 Jan '23

14 Jan '23

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2023-01-14,main >--------------------------------------------------------------- commit 3b478e08f378b4484f0d1357718be5ccc633d2b6 Author: Linus L��ssing <linus.luessing(a)c0d3.blue> Date: Mon Dec 26 15:51:40 2022 +0000 doc: batman-adv/Multicast-Packet-Type >--------------------------------------------------------------- 3b478e08f378b4484f0d1357718be5ccc633d2b6 batman-adv/Multicast-Packet-Type.textile | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/batman-adv/Multicast-Packet-Type.textile b/batman-adv/Multicast-Packet-Type.textile index f8a21649..69bdf686 100644 --- a/batman-adv/Multicast-Packet-Type.textile +++ b/batman-adv/Multicast-Packet-Type.textile @@ -87,6 +87,12 @@ Signalizes that: # This node is capable of receiving, parsing and forwarding a batman-adv multicast packet with a multicast tracker TVLV. # All hard interfaces of this node have an MTU of at least 1280. +h2. Extensibility + +Using an optional TVLV for receiver indication allows more flexibility between the data and control plane, to increase the number of receiving node and/or reducing overhead in the future. + +For instance a forwarding node could cache the destinations in the tracker TVLV with a hash in a _key:hash([dests]) -> [dests]_ database. And a sender could prefill this database by sending a multicast packet with a tracker TVLV, but without the actual payload data. Then a sender could later use a more compact tracker TVLV variant which only contains the _hash([dests])_ next to the payload data. + h2. Limitations * Neither the BATMAN IV nor BATMAN V routing algorithm can currently perform path MTU discovery. And the batman-adv fragmentation is not yet capable of handling this new batman-adv packet type, nor is it capable of reassembling per hop. Therefore the easy solution for now is to require an interface MTU of at least 1280 bytes on each active hard interface. 1280 bytes is also the "IPv6 minimum MTU":https://www.rfc-editor.org/rfc/rfc2460#section-5, so this makes it already less likely to be undercut in practice.

1 0

[doc] backup-redmine/2023-01-14,main: doc: batman-adv/Multicast-Packet-Type (118b60de)
by postmaster＠open-mesh.org 14 Jan '23

14 Jan '23

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2023-01-14,main >--------------------------------------------------------------- commit 118b60dede6c36cb21abb3d4ac63212b275ca251 Author: Linus L��ssing <linus.luessing(a)c0d3.blue> Date: Mon Dec 26 19:06:41 2022 +0000 doc: batman-adv/Multicast-Packet-Type >--------------------------------------------------------------- 118b60dede6c36cb21abb3d4ac63212b275ca251 batman-adv/Multicast-Packet-Type.textile | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/batman-adv/Multicast-Packet-Type.textile b/batman-adv/Multicast-Packet-Type.textile index 4a720d4f..a45b4ac6 100644 --- a/batman-adv/Multicast-Packet-Type.textile +++ b/batman-adv/Multicast-Packet-Type.textile @@ -87,6 +87,21 @@ Signalizes that: # This node is capable of receiving, parsing and forwarding a batman-adv multicast packet with a multicast tracker TVLV. # All hard interfaces of this node have an MTU of at least 1280. +h2. Statistics Counters + +__"$ batctl statistics"__ can be used to check if the batman-adv multicast packet type is used and working as expected. + +* *mcast_tx:* transmitted batman-adv multicast packets (for each outgoing ethernet frame) +* *mcast_tx_bytes:* bytes counter for __mcast_tx__ (encapsulated packet size, includes/assumes 14 bytes for outer ethernet frame) +* *mcast_tx_local:* counter for multicast packets which were locally encapsulated and transmitted as batman-adv multicast packets +* *mcast_tx_local_bytes:* bytes counter for __mcast_tx_local__ (decapsulated packet size, including the payload ethernet frame) +* *mcast_rx:* received batman-adv multicast packet counter (for each incoming ethernet frame) +* *mcast_rx_bytes:* bytes counter for __mcast_rx__ (encapsulated packet size, includes/assumes 14 bytes for outer ethernet frame) +* *mcast_rx_local:* counter for received batman-adv multicast packets which were forwarded to the local soft interface, ak. "bat0" +* *mcast_rx_local_bytes:* bytes counter for __mcast_rx_local__ (decapsulated packet size, including the payload ethernet frame) +* *mcast_fwd:* counter for received batman-adv multicast packets which were forwarded to other, neighboring nodes (for each incoming ethernet frame) +* *mcast_fwd_bytes:* bytes counter for __mcast_fwd__ (encapsulated packet size, includes/assumes 14 bytes for outer ethernet frame) + h2. Extensibility Using an optional TVLV for receiver indication allows more flexibility between the data and control plane, to increase the number of receiving node and/or reducing overhead in the future.

1 0

[doc] backup-redmine/2023-01-14,main: doc: batman-adv/Multicast-Packet-Type (0e4f97fe)
by postmaster＠open-mesh.org 14 Jan '23

14 Jan '23

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2023-01-14,main >--------------------------------------------------------------- commit 0e4f97fef50742ddce64e53373480112d4a8fce4 Author: Linus L��ssing <linus.luessing(a)c0d3.blue> Date: Tue Dec 27 08:49:37 2022 +0000 doc: batman-adv/Multicast-Packet-Type >--------------------------------------------------------------- 0e4f97fef50742ddce64e53373480112d4a8fce4 batman-adv/Multicast-Packet-Type.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Multicast-Packet-Type.textile b/batman-adv/Multicast-Packet-Type.textile index a45b4ac6..8293ab23 100644 --- a/batman-adv/Multicast-Packet-Type.textile +++ b/batman-adv/Multicast-Packet-Type.textile @@ -104,7 +104,7 @@ __"$ batctl statistics"__ can be used to check if the batman-adv multicast packe h2. Extensibility -Using an optional TVLV for receiver indication allows more flexibility between the data and control plane, to increase the number of receiving node and/or reducing overhead in the future. +Using an optional TVLV for receiver indication allows more flexibility between the data and control plane, to increase the number of receiving nodes and/or reducing overhead in the future. For instance a forwarding node could cache the destinations in the tracker TVLV with a hash in a _key:hash([dests]) -> [dests]_ database. And a sender could prefill this database by sending a multicast packet with a tracker TVLV, but without the actual payload data. Then a sender could later use a more compact tracker TVLV variant which only contains the _hash([dests])_ next to the payload data.

1 0

[doc] backup-redmine/2023-01-14,main: doc: batman-adv/Multicast-Packet-Type (1067866a)
by postmaster＠open-mesh.org 14 Jan '23

14 Jan '23

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2023-01-14,main >--------------------------------------------------------------- commit 1067866aab75b30931df9c94c0ec31c5412207b5 Author: Linus L��ssing <linus.luessing(a)c0d3.blue> Date: Mon Dec 26 15:01:32 2022 +0000 doc: batman-adv/Multicast-Packet-Type >--------------------------------------------------------------- 1067866aab75b30931df9c94c0ec31c5412207b5 batman-adv/Multicast-Packet-Type.textile | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/batman-adv/Multicast-Packet-Type.textile b/batman-adv/Multicast-Packet-Type.textile index f5daa29d..43c9defa 100644 --- a/batman-adv/Multicast-Packet-Type.textile +++ b/batman-adv/Multicast-Packet-Type.textile @@ -110,13 +110,13 @@ h3. #Num Dests size -> going for 2 bytes / potential jumbo frame support -h3. Non ideal splits +h3. -Non ideal splits- -If a packet with n destinations gets too large for the MTU then batman-adv would/should/could try to split it into m packets with n/3 destinations each. where m <= mcast_fanout. +-If a packet with n destinations gets too large for the MTU then batman-adv would/should/could try to split it into m packets with n/3 destinations each. where m <= mcast_fanout.- -However when splitting like this then such the splitting node does not know the best sorting into these m packets. Another node will likely later need to split again due to different next hops for the destinations in a packet. +-However when splitting like this then such the splitting node does not know the best sorting into these m packets. Another node will likely later need to split again due to different next hops for the destinations in a packet.- -A batman-adv node currently cannot anticipate this for optimized splitting, as it does not know the full topology. Which would potentially lead to more transmissions than necessary. +-A batman-adv node currently cannot anticipate this for optimized splitting, as it does not know the full topology. Which would potentially lead to more transmissions than necessary.- ---

1 0

[doc] backup-redmine/2023-01-14,main: doc: batman-adv/Multicast-Packet-Type (1919e9e4)
by postmaster＠open-mesh.org 14 Jan '23

14 Jan '23

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2023-01-14,main >--------------------------------------------------------------- commit 1919e9e4e33292a21379a0f9c18281d355d4892b Author: Linus L��ssing <linus.luessing(a)c0d3.blue> Date: Mon Dec 26 15:04:00 2022 +0000 doc: batman-adv/Multicast-Packet-Type >--------------------------------------------------------------- 1919e9e4e33292a21379a0f9c18281d355d4892b batman-adv/Multicast-Packet-Type.textile | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/batman-adv/Multicast-Packet-Type.textile b/batman-adv/Multicast-Packet-Type.textile index 43c9defa..d48136c7 100644 --- a/batman-adv/Multicast-Packet-Type.textile +++ b/batman-adv/Multicast-Packet-Type.textile @@ -122,17 +122,21 @@ h3. -Non ideal splits- -> Going for just one multicast packet instead of up to mcast_fanout to start with, for simplicity. -h3. Fragmentation / MTUs: +h3. -Fragmentation / MTUs:- -On transit a forwarding node might have an interface with a smaller MTU than the node which originated the packet. A node could try to split a packet into multiple packets with less destinations. However if the payload data is larger than the interface MTU already then it would still not fit. And the batman-adv fragmentation code won't be able to look into and split within a multicast packet type header. +-On transit a forwarding node might have an interface with a smaller MTU than the node which originated the packet. A node could try to split a packet into multiple packets with less destinations. However if the payload data is larger than the interface MTU already then it would still not fit. And the batman-adv fragmentation code won't be able to look into and split within a multicast packet type header.- -Workaround A): +-Workaround A):- -By default only apply multicast packet type if resulting packet is smaller than 1280 (minimum IPv6 packet size) or even 576 (minimum accepeted IPv4 datagram size?). Maybe add a configuration option, which defaults to 576 bytes? While in practice configuring it to 1280 should usually be fine these days with IPv6 capable networks. +-By default only apply multicast packet type if resulting packet is smaller than 1280 (minimum IPv6 packet size) or even 576 (minimum accepeted IPv4 datagram size?). Maybe add a configuration option, which defaults to 576 bytes? While in practice configuring it to 1280 should usually be fine these days with IPv6 capable networks.- -Solution B) +-Solution B)- -Later ideally the fragmentation code would be able to split the payload within a multicast packet type, while leaving multicast packet type headers in tact. A node should still forward packets if due to this splitting the mcast-fanout limit were violated, to avoid packet loss. +-Later ideally the fragmentation code would be able to split the payload within a multicast packet type, while leaving multicast packet type headers in tact. A node should still forward packets if due to this splitting the mcast-fanout limit were violated, to avoid packet loss.- + +--- + +-> Workaround C): We require a 1280 bytes MTU on all hard interfaces and only then set the multicast packet type capability flag. h3. Adding a sequence number? / How to avoid loops with tracker marking later?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits