commits

commits@lists.open-mesh.org

1 participants
12373 discussions

[doc] backup-redmine/2024-03-02,main: doc: batman-adv/Multicast-Packet-Type: remove "draft" mentions, add remark to v2024.0 (652ae89e)
by postmaster＠open-mesh.org 02 Mar '24

02 Mar '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2024-03-02,main >--------------------------------------------------------------- commit 652ae89ede70c7ece9a6df80dcc99fbaf6e77aa3 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Thu Feb 22 23:57:53 2024 +0000 doc: batman-adv/Multicast-Packet-Type: remove "draft" mentions, add remark to v2024.0 >--------------------------------------------------------------- 652ae89ede70c7ece9a6df80dcc99fbaf6e77aa3 batman-adv/Multicast-Packet-Type.textile | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/batman-adv/Multicast-Packet-Type.textile b/batman-adv/Multicast-Packet-Type.textile index af9d9515..b5025d0f 100644 --- a/batman-adv/Multicast-Packet-Type.textile +++ b/batman-adv/Multicast-Packet-Type.textile @@ -1,8 +1,6 @@ -h1. DRAFT - Multicast Packet Type +h1. Multicast Packet Type -_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 +Available since: "v2024.0":https://www.open-mesh.org/news/115. h2. Brief

1 0

[doc] main: Merge branch 'backup-redmine/2024-03-02' (1e8e5812)
by postmaster＠open-mesh.org 02 Mar '24

02 Mar '24

Repository : ssh://git@diktynna/doc On branch : main >--------------------------------------------------------------- commit 1e8e5812ad3e1cc1f23f2324c0a8468c6d798397 Merge: 4f3758cd 652ae89e Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Mar 2 09:14:21 2024 +0100 Merge branch 'backup-redmine/2024-03-02' >--------------------------------------------------------------- 1e8e5812ad3e1cc1f23f2324c0a8468c6d798397 batman-adv/Feature-History.rst | 6 +- batman-adv/Multicast-Packet-Type.rst | 27 +++-- batman-adv/Multicast-Packet-Type.textile | 175 ------------------------------- 3 files changed, 17 insertions(+), 191 deletions(-) diff --cc batman-adv/Feature-History.rst index aeae7fc9,00000000..75840f11 mode 100644,000000..100644 --- a/batman-adv/Feature-History.rst +++ b/batman-adv/Feature-History.rst @@@ -1,86 -1,0 +1,90 @@@ +.. SPDX-License-Identifier: GPL-2.0 + ++=============== +Feature History +=============== + +- **AP Isolation** + + - Initial support: 2011.4.0 + - Extended AP Isolation: v2014.1.0 + +- **BLA** + + - Initial support: v2011.0.0 + - BLA v2: v2012.2.0 + - Enabled by default: v2015.1 + - Detection of complex bridge loops: v2016.2 + +- **Bonding** + + - v2010.1.0 + +- **Broadcast** + + - 3x broadcast: v0.2 + - Retransmissions only on wireless: v2013.3.0 + - Broadcast Avoidances: v2016.5 + +- **DAT** + + - Initial support: v2013.0.0 + - DHCP-ACK snooping: v2019.1 + - Before timeout refreshing: v2019.2 + +- **Fragmentation** + + - Initial support: v2010.2.0 + - Fragmentation v2: v2014.0.0 + +- **Gateway Feature** + + - Initial support: v2011.0.0 + +- **Interface Alternating** + + - Initial support: v2010.1.0 + - Interface Alternating v2: v2014.1.0 + +- **Multicast Optimizations** + + - Multicast TT + TVLV support: v2014.2.0 + - Bridge support: v2016.3 + - Multicast-to-multi-unicast: v2019.2 + - Preliminary routable IPv6 multicast address support: v2019.3 - - Full, MRD based routable IPv4/IPv6 multicast address support: v2021.2 ++ - Full, MRD based routable IPv4/IPv6 multicast address support: ++ v2021.2 ++ - Stateless batman-adv multicast packet type support: v2024.0 + +- **Network Coding** + + - v2013.2.0 + +- **BATMAN IV** + + - v0.1 + +- **BATMAN V** + + - OGMv2 / ELP / Throughput metric: v2016.1 + - WLAN TX bitrate fallback: v2020.0 + +- **TT** + + - Initial support: 2011.3.0 + - Speedy Join: v2012.4.0 + +- **TVLV support (compat 15):** + + - v2014.0.0 + +- **Vis** + + - removed in: v2014.0.0 + +- **Misc:** + + - Hop-penalty 15 -> 30: v2014.4.0 (and in v2012.2.0? how much?) + - Multiple mesh interfaces: v2010.2.0 + - Netlink: v2016.3 (+ v2016.4, v2016.5, …) ++ - Netlink in unprivileged containers: v2022.0 diff --cc batman-adv/Multicast-Packet-Type.rst index d9f03680,00000000..a5615a36 mode 100644,000000..100644 --- a/batman-adv/Multicast-Packet-Type.rst +++ b/batman-adv/Multicast-Packet-Type.rst @@@ -1,294 -1,0 +1,291 @@@ +.. SPDX-License-Identifier: GPL-2.0 + - ============================= - DRAFT - Multicast Packet Type - ============================= ++===================== ++Multicast Packet Type ++===================== + - *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/multicas…>`__ ++Available since: `v2024.0 <https://www.open-mesh.org/news/115>`__. + +Brief +===== + +Reduce number of packets / overhead by introducing a new batman-adv +multicast packet type which is capable of holding multiple destination +addresses. + +Current State +============= + +batman-adv now has IP multicast group awareness. And with that can +detect in advance which other nodes want to receive an IPv4/IPv6 +multicast packet for a specific multicast destination/multicast group. + +The sender algorithm so far is simply either sending a packet via one +batman-adv unicast packet for each interested destination node: + +.. image:: basic-multicast-multiple-receivers.svg + +Or when the number of destination is larger than 16 (default, +configurable) it will fall back to using a single batman-adv broadcast +packet: + +.. image:: basic-multicast-many-receivers.svg + +The former method is more efficient when the number of interested nodes +is rather small. And allows bothering less nodes in the mesh and by that +then generating less overhead in the overall mesh. However it still +often leads to duplicated transmissions of the multicast IP packet +especially on the first hops. + +For more details see: + +* :doc:`Multicast Optimizations <Multicast-optimizations>` + +Technical Specification +======================= + +MCAST packet type header +------------------------ + +:: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Type | Version | TTL | reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TVLV length | MCAST Tracker TVLV ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | ... | Data ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +* Packet Type: BATADV_MCAST (0x05) +* Version: 15 +* TTL: +* reserved: 0x00 +* TVLV length: +* Data: Encapsulated ethernet frame with 2 byte alignment (to make IP + packets 4 byte aligned) + +MCAST Tracker TVLV - ~~~~~~~~~~~~~~~~~~ ++------------------ + +:: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TVLV Type | TVLV Version | TVLV Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | #Num Dests (N) | Dest 1 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Dest 2 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | Dest N ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ... | [padding] | ++ | ... | [padding] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +* TVLV Type: 0x07 +* TVLV Version: 1 +* #Num Dests: Number of destinations (originator MAC addresses) +* [padding]: Optional 2 byte padding, only present if #Num Dests are + even, to make Tracker TVLV 4 byte aligned (to make encapsulated IP + packets 4 byte aligned) + +OGM Multicast TVLV flags +------------------------ + +The following flag is added to the - :ref:`MCAST flags <batman-adv-multicast-optimizations-tech-multicast-tvlv>` in the ++:ref:`MCAST flags <batman-adv-multicast-optimizations-tech-multicast-tvlv>` in the +multicast TVLV of an OGM: + +BATADV_MCAST_HAVE_MC_PTYPE_CAPA (Bit 5): +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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. + +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) + +Extensibility +============= + +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. + +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. - * 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 outer ethernet frame), then the batman-adv - multicast packet type cannot/will not be used. Example limits: ++* 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 outer 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 <https://en.wikipedia.org/wiki/Ethernet_frame#Payload>`__ + without a VLAN) + +If such a limitation is reached then batman-adv will either fall back 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. + +Open questions +============== + +[STRIKEOUT:#Num Dests size] +--------------------------- + +| [STRIKEOUT:\* 1 or 2 bytes for #Num Dests for Address X?] +| - If limit of entries were reached, we could just send another +| mcast packet? (~6*256 = 1536). Or do we want to be prepared +| for jumbo frames?- + - +-> going for 2 bytes / potential jumbo frame support + +[STRIKEOUT:Non ideal splits] +---------------------------- + +[STRIKEOUT: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.] + +[STRIKEOUT: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.] + +[STRIKEOUT: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.] + +-> Going for just one multicast packet instead of up to mcast_fanout to +start with, for simplicity. + +[STRIKEOUT:Fragmentation / MTUs:] +--------------------------------- + +[STRIKEOUT: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.] + +[STRIKEOUT:Workaround A):] + +[STRIKEOUT: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.] + +[STRIKEOUT:Solution B)] + +[STRIKEOUT: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. + +[STRIKEOUT:Adding a sequence number? / How to avoid loops with tracker marking later?] +-------------------------------------------------------------------------------------- + +[STRIKEOUT: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:] + +[STRIKEOUT: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.] + +[STRIKEOUT:Solution:] + +[STRIKEOUT:Don’t mark paths. Instead use the tracker TVLV to fill a +cache with the mcast/dests lists and assign a hash to this information. +Then later send the multicast data with a TVLV containing only this hash +instead of the full mcast/dests list. Therefore a specific list of +destinations is still maintained and routing decisions still happen on +the go, loopfree, instead of trying to a maintain a loopfree, adjacent +multicast routing table.] + +-> Don’t add a sequence number, we don’t need it now. And a new +hashing/caching TVLV described above should work fine later. diff --cc batman-adv/Multicast-Packet-Type.textile index af9d9515,b5025d0f..00000000 deleted file mode 100644,100644 --- a/batman-adv/Multicast-Packet-Type.textile +++ /dev/null @@@ -1,175 -1,173 +1,0 @@@ - h1. DRAFT - Multicast Packet Type - - _This is a draft and not upstream yet._ -h1. Multicast Packet Type -- - Implementation: "linus/multicast-packet-type":https://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/linus/multicast-packet-type -Available since: "v2024.0":https://www.open-mesh.org/news/115. -- --h2. Brief -- --Reduce number of packets / overhead by introducing a new batman-adv multicast packet type which is capable of holding multiple destination addresses. -- --h2. Current State -- --batman-adv now has IP multicast group awareness. And with that can detect in advance which other nodes want to receive an IPv4/IPv6 multicast packet for a specific multicast destination/multicast group. -- --The sender algorithm so far is simply either sending a packet via one batman-adv unicast packet for each interested destination node: -- --!{width: 66%;}https://www.open-mesh.org/attachments/download/888/basic-multicast-mul…! -- --Or when the number of destination is larger than 16 (default, configurable) it will fall back to using a single batman-adv broadcast packet: -- --!{width: 66%;}https://www.open-mesh.org/attachments/download/890/basic-multicast-man…! -- --The former method is more efficient when the number of interested nodes is rather small. And allows bothering less nodes in the mesh and by that then generating less overhead in the overall mesh. However it still often leads to duplicated transmissions of the multicast IP packet especially on the first hops. -- --For more details see: --* [[Multicast-optimizations]] -- --h2. Technical Specification -- --h3. MCAST packet type header -- --<pre><code> 0 1 2 3 -- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- | Packet Type | Version | TTL | reserved | -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- | TVLV length | MCAST Tracker TVLV ... | -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| -- | ... | Data ... | -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| -- | ... | -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --</code></pre> -- --* Packet Type: BATADV_MCAST (0x05) --* Version: 15 --* TTL: --* reserved: 0x00 --* TVLV length: --* Data: Encapsulated ethernet frame with 2 byte alignment (to make IP packets 4 byte aligned) -- --h3. MCAST Tracker TVLV -- --<pre><code> 0 1 2 3 -- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- | TVLV Type | TVLV Version | TVLV Length | -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- | #Num Dests (N) | Dest 1 ... | -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- | ... | -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- | Dest 2 ... | -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- | ... | Dest N ... | -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- | ... | [padding] | -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --</code></pre> -- --* TVLV Type: 0x07 --* TVLV Version: 1 --* #Num Dests: Number of destinations (originator MAC addresses) --* [padding]: Optional 2 byte padding, only present if #Num Dests are even, to make Tracker TVLV 4 byte aligned (to make encapsulated IP packets 4 byte aligned) -- --h3. OGM Multicast TVLV flags -- --The following flag is added to the [[Multicast-optimizations-tech#Multicast-TVLV|MCAST flags]] in the multicast TVLV of an OGM: -- --h4. BATADV_MCAST_HAVE_MC_PTYPE_CAPA (Bit 5): -- --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 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. -- --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. --* 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 outer 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":https://en.wikipedia.org/wiki/Ethernet_frame#Payload without a VLAN) -- --If such a limitation is reached then batman-adv will either fall back 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 or 2 bytes for #Num Dests for Address X?- ---** If limit of entries were reached, we could just send another -- mcast packet? (~6*256 = 1536). Or do we want to be prepared -- for jumbo frames?- -- ----- -- ---> going for 2 bytes / potential jumbo frame support -- --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.- -- ---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.- -- ----- -- ---> Going for just one multicast packet instead of up to mcast_fanout to start with, for simplicity. -- --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.- -- ---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.- -- ---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.- -- ----- -- ---> 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?- -- ---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.- -- ---Solution:- -- ---Don't mark paths. Instead use the tracker TVLV to fill a cache with the mcast/dests lists and assign a hash to this information. Then later send the multicast data with a TVLV containing only this hash instead of the full mcast/dests list. Therefore a specific list of destinations is still maintained and routing decisions still happen on the go, loopfree, instead of trying to a maintain a loopfree, adjacent multicast routing table.- -- ----- -- ---> Don't add a sequence number, we don't need it now. And a new hashing/caching TVLV described above should work fine later.

1 0

[linux-merge]linux integration; annotated tag, v6.8-rc6, created. v6.8-rc6
by postmaster＠open-mesh.org 26 Feb '24

26 Feb '24

The annotated tag, v6.8-rc6 has been created at 8bf1e5a08989cf5c8d9c117ebc47554951a08d6d (tag) tagging d206a76d7d2726f3b096037f2079ce0bd3ba329b (commit) replaces v6.8-rc5 tagged by Linus Torvalds on Sun Feb 25 15:46:06 2024 -0800 - Shortlog ------------------------------------------------------------ Linux 6.8-rc6 -----BEGIN PGP SIGNATURE----- iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmXb0T4eHHRvcnZhbGRz QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG5YQH/3eCV90sNGch0Y94 8rtTdqFrVx7QPNl0pz+Mo6OUIKUUHvTuwime16ckLxG+3x2Y3I0MjP1edd1NB99C Kje//JTpaZBPpTZ/jY4u8B1Shov2Drdx/J4NFnE/9rG6yXzKQBtvON/xAxXDCVHT mLhst2LR0FeCSMk9jAX6CoqUPEgwlylNyAetKxaDQgoHl4GTZC7FDO17WxyjpIxe 1rVHsrV9Eq8kD4uxrzpTYWgZrwTObPmlZjvefa1JfzSwRNABIBJj/C1nra1Zc1oi b7xVaXS1cMOxrtuuG00fmHsPnWivu0tuND7H3/yLd1mRCZAPSsVbVvrI/KNtoeV4 1euINlY= =7IFt -----END PGP SIGNATURE----- ----------------------------------------------------------------------- -- linux integration

1 0

[batman-adv] ecsv/pu,main,main: batman-adv: Drop usage of export.h (737a0703)
by postmaster＠open-mesh.org 24 Feb '24

24 Feb '24

Repository : ssh://git@diktynna/batman-adv On branches: ecsv/pu,main,main >--------------------------------------------------------------- commit 737a0703379f4f68b783fcfd2579835361078267 Author: Sven Eckelmann <sven(a)narfation.org> Date: Mon Jan 22 14:10:22 2024 +0100 batman-adv: Drop usage of export.h The linux/export.h include was introduced in commit f6977d91a992 ("batman-adv: Introduce missing headers for genetlink restructure") to have access to THIS_MODULE. But with commit 5b20755b7780 ("init: move THIS_MODULE from <linux/export.h> to <linux/init.h>"), it was moved and the include for export.h is no longer needed. Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- 737a0703379f4f68b783fcfd2579835361078267 net/batman-adv/netlink.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/batman-adv/netlink.c b/net/batman-adv/netlink.c index cda99753..6aff7cc1 100644 --- a/net/batman-adv/netlink.c +++ b/net/batman-adv/netlink.c @@ -15,7 +15,6 @@ #include <linux/cache.h> #include <linux/err.h> #include <linux/errno.h> -#include <linux/export.h> #include <linux/genetlink.h> #include <linux/gfp.h> #include <linux/if_ether.h>

1 0

[batman-adv] ecsv/pu,main,main: batman-adv: Improve exception handling in batadv_throw_uevent() (73828bad)
by postmaster＠open-mesh.org 24 Feb '24

24 Feb '24

Repository : ssh://git@diktynna/batman-adv On branches: ecsv/pu,main,main >--------------------------------------------------------------- commit 73828bad18df5e6376cc49db35b291919b6cbcc4 Author: Markus Elfring <elfring(a)users.sourceforge.net> Date: Tue Jan 2 07:52:21 2024 +0100 batman-adv: Improve exception handling in batadv_throw_uevent() The kfree() function was called in up to three cases by the batadv_throw_uevent() function during error handling even if the passed variable contained a null pointer. This issue was detected by using the Coccinelle software. * Thus adjust jump targets. * Reorder kfree() calls at the end. Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> Acked-by: Sven Eckelmann <sven(a)narfation.org> Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- 73828bad18df5e6376cc49db35b291919b6cbcc4 net/batman-adv/main.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/net/batman-adv/main.c b/net/batman-adv/main.c index 5fc754b0..75119f1f 100644 --- a/net/batman-adv/main.c +++ b/net/batman-adv/main.c @@ -691,29 +691,31 @@ int batadv_throw_uevent(struct batadv_priv *bat_priv, enum batadv_uev_type type, "%s%s", BATADV_UEV_TYPE_VAR, batadv_uev_type_str[type]); if (!uevent_env[0]) - goto out; + goto report_error; uevent_env[1] = kasprintf(GFP_ATOMIC, "%s%s", BATADV_UEV_ACTION_VAR, batadv_uev_action_str[action]); if (!uevent_env[1]) - goto out; + goto free_first_env; /* If the event is DEL, ignore the data field */ if (action != BATADV_UEV_DEL) { uevent_env[2] = kasprintf(GFP_ATOMIC, "%s%s", BATADV_UEV_DATA_VAR, data); if (!uevent_env[2]) - goto out; + goto free_second_env; } ret = kobject_uevent_env(bat_kobj, KOBJ_CHANGE, uevent_env); -out: - kfree(uevent_env[0]); - kfree(uevent_env[1]); kfree(uevent_env[2]); +free_second_env: + kfree(uevent_env[1]); +free_first_env: + kfree(uevent_env[0]); if (ret) +report_error: batadv_dbg(BATADV_DBG_BATMAN, bat_priv, "Impossible to send uevent for (%s,%s,%s) event (err: %d)\n", batadv_uev_type_str[type],

1 0

[batman-adv] ecsv/pu,main,main: batman-adv: Return directly after a failed batadv_dat_select_candidates() in batadv_dat_forward_data() (bfeb9d0e)
by postmaster＠open-mesh.org 24 Feb '24

24 Feb '24

Repository : ssh://git@diktynna/batman-adv On branches: ecsv/pu,main,main >--------------------------------------------------------------- commit bfeb9d0ea60a5f6099a5d3b3d41df44003c7fc92 Author: Markus Elfring <elfring(a)users.sourceforge.net> Date: Tue Jan 2 07:27:45 2024 +0100 batman-adv: Return directly after a failed batadv_dat_select_candidates() in batadv_dat_forward_data() The kfree() function was called in one case by the batadv_dat_forward_data() function during error handling even if the passed variable contained a null pointer. This issue was detected by using the Coccinelle software. * Thus return directly after a batadv_dat_select_candidates() call failed at the beginning. * Delete the label “out” which became unnecessary with this refactoring. Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> Acked-by: Sven Eckelmann <sven(a)narfation.org> Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- bfeb9d0ea60a5f6099a5d3b3d41df44003c7fc92 net/batman-adv/distributed-arp-table.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/batman-adv/distributed-arp-table.c b/net/batman-adv/distributed-arp-table.c index 28a939d5..4c7e8553 100644 --- a/net/batman-adv/distributed-arp-table.c +++ b/net/batman-adv/distributed-arp-table.c @@ -684,7 +684,7 @@ static bool batadv_dat_forward_data(struct batadv_priv *bat_priv, cand = batadv_dat_select_candidates(bat_priv, ip, vid); if (!cand) - goto out; + return ret; batadv_dbg(BATADV_DBG_DAT, bat_priv, "DHT_SEND for %pI4\n", &ip); @@ -728,7 +728,6 @@ free_orig: batadv_orig_node_put(cand[i].orig_node); } -out: kfree(cand); return ret; }

1 0

[batman-adv] ecsv/pu,main,main: batman-adv: Start new development cycle (d53299d0)
by postmaster＠open-mesh.org 24 Feb '24

24 Feb '24

Repository : ssh://git@diktynna/batman-adv On branches: ecsv/pu,main,main >--------------------------------------------------------------- commit d53299d062e0347fd029b916cf619012ebdf7c7b Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Thu Feb 1 10:59:49 2024 +0100 batman-adv: Start new development cycle Signed-off-by: Simon Wunderlich <sw(a)simonwunderlich.de> >--------------------------------------------------------------- d53299d062e0347fd029b916cf619012ebdf7c7b net/batman-adv/main.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h index 870dcd7f..8ca854a7 100644 --- a/net/batman-adv/main.h +++ b/net/batman-adv/main.h @@ -13,7 +13,7 @@ #define BATADV_DRIVER_DEVICE "batman-adv" #ifndef BATADV_SOURCE_VERSION -#define BATADV_SOURCE_VERSION "2024.0" +#define BATADV_SOURCE_VERSION "2024.1" #endif /* B.A.T.M.A.N. parameters */

1 0

[batman-adv] main,main: Merge branch 'stable' (fa7059d9)
by postmaster＠open-mesh.org 24 Feb '24

24 Feb '24

Repository : ssh://git@diktynna/batman-adv On branches: main,main >--------------------------------------------------------------- commit fa7059d922e5e2a60f35b92b80b6b89c1c557179 Merge: 737a0703 05f6eadb Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Feb 24 07:58:55 2024 +0100 Merge branch 'stable' >--------------------------------------------------------------- fa7059d922e5e2a60f35b92b80b6b89c1c557179 net/batman-adv/translation-table.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

1 0

[batman-adv] main,stable,main,stable: batman-adv: Avoid infinite loop trying to resize local TT (05f6eadb)
by postmaster＠open-mesh.org 24 Feb '24

24 Feb '24

Repository : ssh://git@diktynna/batman-adv On branches: main,stable,main,stable >--------------------------------------------------------------- commit 05f6eadbbddc834669249ae204026c383445b571 Author: Sven Eckelmann <sven(a)narfation.org> Date: Mon Feb 12 14:32:13 2024 +0100 batman-adv: Avoid infinite loop trying to resize local TT If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet. But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110) in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more. There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes. While this should be handled proactively when: * interface with too low MTU is added * VLAN is added * non-purgeable local mac is added * MTU of an attached interface is reduced * fragmentation setting gets disabled (which most likely requires dropping attached interfaces) not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present. Cc: stable(a)vger.kernel.org Fixes: f7f2fe494388 ("batman-adv: limit local translation table max size") Reported-by: syzbot+a6a4b5bb3da165594cff(a)syzkaller.appspotmail.com Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- 05f6eadbbddc834669249ae204026c383445b571 net/batman-adv/translation-table.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c index b95c3676..2243cec1 100644 --- a/net/batman-adv/translation-table.c +++ b/net/batman-adv/translation-table.c @@ -3948,7 +3948,7 @@ void batadv_tt_local_resize_to_mtu(struct net_device *soft_iface) spin_lock_bh(&bat_priv->tt.commit_lock); - while (true) { + while (timeout) { table_size = batadv_tt_local_table_transmit_size(bat_priv); if (packet_size_max >= table_size) break;

1 0

[linux-merge]linux integration; annotated tag, v6.8-rc5, created. v6.8-rc5
by postmaster＠open-mesh.org 18 Feb '24

18 Feb '24

The annotated tag, v6.8-rc5 has been created at 7e311d420f96ef38326a0f3b7d8cffa3dee32ae5 (tag) tagging b401b621758e46812da61fa58a67c3fd8d91de0d (commit) replaces v6.8-rc4 tagged by Linus Torvalds on Sun Feb 18 12:56:25 2024 -0800 - Shortlog ------------------------------------------------------------ Linux 6.8-rc5 -----BEGIN PGP SIGNATURE----- iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmXSbvkeHHRvcnZhbGRz QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGi3kH/iM5AcKeQfee07to TJP3WORLBt5UrUMgAQbJdNAruCj6brHA6YnZ6AjdhdNZ41RO06h69kTpb+y/CYJz +ogGK5qhWsC8ETM6rJCioo8uI4GU70p84fGiMfLw8o6vUvmtyI5qH3531Y30Edxt qqMVtQrVe9J5JcHQjJ/mQo8nAuvZdQQGM90zLGqFP+JheP3CzsCokraIITqoebDC PCVAsnSbXT/uMjwSr03kdnMnnY++fxz/TyHb/QRMPq/4xU8nz0Z2hlOOYrVkOINu lkIYtCDGTk0QR3hdDiO9yt+k1OsWi+oBkrhjAQmAk9x3riiXq1NKvZZLDArt7PH5 gSyo9sE= =h5Ei -----END PGP SIGNATURE----- ----------------------------------------------------------------------- -- linux integration

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits