commits March 2021

commits@lists.open-mesh.org

1 participants
26 discussions

[linux-merge]linux integration; annotated tag, batadv-next-pullrequest-20210208, deleted. v5.11-rc1-4-g25d81f9307ff
by postmaster＠open-mesh.org 11 Mar '21

11 Mar '21

The annotated tag, batadv-next-pullrequest-20210208 has been deleted was ac27a7b5d51a5329e36a7747ef230ee646dd869a ----------------------------------------------------------------------- tag batadv-next-pullrequest-20210208 This feature/cleanup patchset is an updated version of the pull request of Feb 2nd (batadv-next-pullrequest-20210202) and includes the following patches: - Bump version strings, by Simon Wunderlich (added commit log) - Drop publication years from copyright info, by Sven Eckelmann (replaced the previous patch which updated copyright years, as per our discussion) - Avoid sizeof on flexible structure, by Sven Eckelmann (unchanged) - Fix names for kernel-doc blocks, by Sven Eckelmann (unchanged) -----BEGIN PGP SIGNATURE----- iQJKBAABCgA0FiEE1ilQI7G+y+fdhnrfoSvjmEKSnqEFAmAhbUkWHHN3QHNpbW9u d3VuZGVybGljaC5kZQAKCRChK+OYQpKeoR7yEACMhdCzMoVPJQwOYWe5p6QwgaBz 85QRT56x9gpFhV5dXCyg7DK3Qt2JRfTfBtMOeZQatFxcACYaGunZSS1L6gDVATpT 5vB+5UwQK8AW7cjkwVS6vJWW9Wmll9IwNe0/1DGvSBjEWwmU/wlRzAPa2uAT2uw5 AxrErEuXo5M3U4mDfJckVD4XA+pKkd9ylLEQ7llcZA4rOaTsr5sNAy5mbxO5EXD9 yP1vq9BoXtsf0FyZbQrMnYre6teAkxVxrvkTn6v44vsFKsi69JaxDiKQ4T7vakZR 1rIQq/8XbkH0dQXEu4C2FtWTzrg9P4KNHBPiT06b+KxlROpfYivcWhIqlofmW2FJ 5bWlumyNg3WoUmaM9kLGTFHagAp8M968W8zsI5fLi0meX0pEzFe/E1iBfkQaYyHh R8Xpt7z1ORYUavFhVXqMw8x92WOLWmdFZjSGaW6sNyCxMFIU7qR16gYcXmucrJyU RY6o159D9AKVOdX/GdX50mvyHjn/lC3KUEGQLUVxXMdJHpj7avn7aEiCWHUvgAxQ jIHLOy0CRsUlCFPmzSqwGs3dAJEZeFbvqMwZjFJ/UXlKwBgPVMy76wIUk57+FWKz 3DTcg+6RIiW+bWazn/Hdbn9JXUNZnp5C6oH62GFPw7G6ywfe/yPex4qubF7feyog T9H6ho+KW3SmRsHY5Q== =fX7f -----END PGP SIGNATURE----- 25d81f9307ffc166427d93152498f45178f5936a batman-adv: Fix names for kernel-doc blocks ----------------------------------------------------------------------- -- linux integration

1 0

[linux-merge]linux integration; annotated tag, v5.12-rc2, created. v5.12-rc2
by postmaster＠open-mesh.org 06 Mar '21

06 Mar '21

The annotated tag, v5.12-rc2 has been created at b3c1bf1d9bc8e536db0c8e0572336f534ae7a46b (tag) tagging a38fd8748464831584a19438cbb3082b5a2dab15 (commit) replaces v5.12-rc1 tagged by Linus Torvalds on Fri Mar 5 17:33:41 2021 -0800 - Shortlog ------------------------------------------------------------ Linux 5.12-rc2 -----BEGIN PGP SIGNATURE----- iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmBC2/UeHHRvcnZhbGRz QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGJIAIAJS/qPY8Jk8tczjO xvfokb1KmLE9zij6YH8jzpgAjvgpNFrvEMxASedhwFMqL4RtFeI3RJ0cA980vFlZ 5QK+AVCiFvmeQ8poVAekHARcZ6NiRCLj2+7qsC5iGeRonjDPIJ7zHRawj9NYEUku HUQqLWbi7fws5ANrscpZcqkP8DP6SlFLfYJgAdv6ml1DIZw9q8CB+vFS3ueMD3n4 b0Pt8CiJLhrRkR8Z90/Ayw778RLwUGZfWpWbcEsF9jMkG87N85xvHoPt/cgkUp1C 96joiWihjpjPhhpdOCH3z+n6Dst3Tnm9L5C6dDxEk2lJqlDyPLLn84eM+z70JhkU eV0eyy0= =UocC -----END PGP SIGNATURE----- ----------------------------------------------------------------------- -- linux integration

1 0

[doc] master: Merge branch 'backup-redmine/2021-03-06' (5af6ea9)
by postmaster＠open-mesh.org 06 Mar '21

06 Mar '21

Repository : ssh://git@diktynna/doc On branch : master >--------------------------------------------------------------- commit 5af6ea98e3c2053759ae5c351a4bb1f844141ec4 Merge: a985ae6 36caac2 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Mar 6 09:31:06 2021 +0100 Merge branch 'backup-redmine/2021-03-06' >--------------------------------------------------------------- 5af6ea98e3c2053759ae5c351a4bb1f844141ec4 batman-adv/Gateway-Selection-Issue.rst | 161 +++++ batman-adv/bcast-3x.dia | Bin 1003 -> 7363 bytes batman-adv/bcast-arp-req-gw.dia | Bin 1478 -> 16476 bytes batman-adv/broadcast.dia | Bin 1677 -> 17059 bytes .../{Bw1.dia => gateway-selection-issue.dia} | 781 ++++++++++----------- batman-adv/gateway-selection-issue.svg | 64 ++ batman-adv/noflood-sign.dia | Bin 995 -> 5866 bytes 7 files changed, 609 insertions(+), 397 deletions(-) diff --cc batman-adv/Gateway-Selection-Issue.rst index 0000000,0000000..60180cf new file mode 100644 --- /dev/null +++ b/batman-adv/Gateway-Selection-Issue.rst @@@ -1,0 -1,0 +1,161 @@@ ++.. SPDX-License-Identifier: GPL-2.0 ++ ++Gateway Selection Issue ++======================= ++ ++Scenario ++-------- ++ ++|image0| ++ ++*A batman-adv gateway client selecting a gateway behind the actual best ++gateway* ++ ++The scenario consists of BATMAN V nodes. GW1, GW2, GW3 and N1 have 1 ++Gbit/s links. While N2 is behind N1 with a considerably lower ++throughput, here 50 Mbit/s. ++ ++While node N1 selects the correct, best gateway it is directly connected ++to, node N1 only selects GW1 with a 33% chance. And by a 66% selects ++either GW2 or GW3. Leading to an unnecessarily long route. ++ ++Issue Description ++----------------- ++ ++On N1, the gateway table looks as follows: ++ ++:: ++ ++ <code> ++ N1$ batctl gw ++ client (selection class: 5.0 MBit) ++ N1$ batctl gwl ++ [B.A.T.M.A.N. adv openwrt-2019.2-10, MainIF/MAC: primary0/<orig-mac> (bat0/<bat0-mac> BATMAN_V)] ++ Router ( throughput) Next Hop [outgoingIf] Bandwidth ++ * GW1 ( 1000.0) GW1 [ mesh-vpn]: 1000.0/1000.0 MBit ++ GW2 ( 941.1) GW1 [ mesh-vpn]: 1000.0/1000.0 MBit ++ GW3 ( 941.1) GW1 [ mesh-vpn]: 1000.0/1000.0 MBit ++ </code> ++ ++Node N1 correctly selects GW1 as its best gateway thanks to the hop ++penalty which reduces the throughput by 230/255 = 5.9%. The difference ++is larger than the configured 5.0 MBit selection class, so node N1 will ++always select GW1 as its gateway for the unicasted DHCP packets. ++ ++On node N2 however the table gateway table looks as follows: ++ ++:: ++ ++ <code> ++ N2$ batctl gw ++ client (selection class: 5.0 MBit) ++ N2$ batctl gwl ++ [B.A.T.M.A.N. adv openwrt-2019.2-10, MainIF/MAC: primary0/<orig-mac> (bat0/<bat0-mac> BATMAN_V)] ++ Router ( throughput) Next Hop [outgoingIf] Bandwidth ++ * GW3 ( 50.0) GW1 [ wlan0]: 1000.0/1000.0 MBit ++ GW1 ( 50.0) GW1 [ wlan0]: 1000.0/1000.0 MBit ++ GW2 ( 50.0) GW1 [ wlan0]: 1000.0/1000.0 MBit ++ </code> ++ ++On node N2 the BATMAN V metric to all gateways is 50 MBit/s because ++BATMAN V calculates the minimum of the received throughput in the OGM ++(to GW1: 1000, to GW2: 941.1, to GW3: 941.1) and the link throughput ++towards the destination (50 Mbit/s). ++ ++This leads to node N2 selecting the gateway which it first heard an OGM ++from. So it "randomly" selects one of the three available gateways. The ++probability to select the correct, best gateway decreases the more ++gateways are behind GW1 for N2. ++ ++Node N1 had more, better information for selecting the best gateway ++which got lost by calculating the minimum. ++ ++In theory this issue could happen with BATMAN IV, too. However it is a ++lot less likely to happen because BATMAN IV multiplies the link quality ++to the received TQ value instead of calculating a minimum. Therefore for ++BATMAN IV the 5.9% lower TQ to GW2/GW3 created by the hop penalty will ++persist (as long as the hop penalty is not reduced / configured to a ++lower value). ++ ++Solution (approaches) ++--------------------- ++ ++Redirecting unicasted DHCP messages ++~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ++ ++Node N1 could detect that it knows a better gateway than the one N2 has ++selected: It could check the DHCP messages send by N2 via a batman-adv ++unicast frame and rewrite its destination to GW1. ++ ++Issue: Could probably loop? ++ ++Sinking unicasted DHCP messages. ++~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ++ ++A gateway server, here GW1, could check if it is about to forward a ++unicasted DHCP message to another gateway server. And if so, refrain ++from forwarding and deliver it to its own bat0 instead. ++ ++Issue: A DHCP client sends multiple messages to a DHCP server. We might ++break the DHCP handshake if the routes switched in between the ++handshake. ++ ++Filtering Gateway Announcements ++~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ++ ++Nodes could filter out gateway announcements from OGMs before forwarding ++them. A gateway server could always filter out gateway announcements ++from other gateways. A non-gateway-server node could filter out gateway ++announcements from OGMs from each gateway server which does **not** have ++the highest path throughput (or TQ for BATMAN IV). ++ ++Issue: The gateway announcement TVLV handler is called with ++BATADV_TVLV_HANDLER_OGM_CIFNOTFND. If a node were receiving OGMs from ++two different neighbors where one would have the gateway announcement ++TVLV and the other one wouldn��t then this would lead to gateway ++selection flapping with each received OGM. The ++BATADV_TVLV_HANDLER_OGM_CIFNOTFND would need to be removed and replaced ++by a timeout. Which however would lead to reduced responsiveness / ++delays if a gateway disabled its gateway server mode. And more ++importantly, it would break compatibility, it��d need yet another ++TVLV/flag to propagate this capability. And only if all nodes were ++announcing this capability nodes could change their behaviour. ++ ++Another issue is that it might render the stickiness client option void ++if for a forwarding node the gateway with the highest path throughput ++switches often. Which would lead to gateway flapping for gateway client ++even if it set a selection class / stickiness. ++ ++Flagging Best Gateway Announcements ++~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ++ ++An additional flag could be added to the gateway announcements. Instead ++of filtering gateway announcements a node would unset this flag if it is ++not from its "best" gateway. A gateway server forwarding gateway ++announcements of other gateway servers would always unset this flag. The ++original gateway server would always set the flag in its gateway ++announcements when originating them. ++ ++A gateway is considered "best" for keeping the flag set if: ++ ++- ++ ++Question: Should we re-set the flag when receiving a gateway ++announcement with the flag unset if it is our best gateway via a ++different neighbor? Or would we avoid resending this OGM anyway due to ++how the BATMAN algorithm works? ++ ++Issues: The stickiness would need to be disregarded for the first OGM ++sequence number(s) or would need to be disregarded periodically to be ++able to converge to the best gateway. ++ ++General issues with filtering or flagging: ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++While currently BATMAN V only takes the announced download bitrate into ++consideration, if a gateway client would want to select the best gateway ++by upload rate in the future that information would not be available ++anymore. In other words, a forwarding node might have other criteria for ++its best gateway than the final gateway clients. ++ ++.. |image0| image:: gateway-selection-issue.svg diff --cc batman-adv/bcast-3x.dia index 6ed7397,6ed7397..765c43f Binary files differ diff --cc batman-adv/bcast-arp-req-gw.dia index 0064923,0064923..036204c Binary files differ diff --cc batman-adv/broadcast.dia index 48131ae,48131ae..c74e2b4 Binary files differ diff --cc batman-adv/gateway-selection-issue.dia index b97b677,540f4a7..cabc5e3 Binary files differ diff --cc batman-adv/gateway-selection-issue.svg index 0000000,0000000..f9cd5a3 new file mode 100644 --- /dev/null +++ b/batman-adv/gateway-selection-issue.svg @@@ -1,0 -1,0 +1,64 @@@ ++<?xml version="1.0" encoding="UTF-8" standalone="no"?> ++<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd"> ++<svg width="34cm" height="21cm" viewBox="319 229 662 412" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> ++ <defs/> ++ <g id="Background"> ++ <ellipse style="fill: #ffa500; fill-opacity: 1; stroke-opacity: 1; stroke-width: 2; stroke: #000000" cx="610" cy="490" rx="30" ry="30"/> ++ <ellipse style="fill: #add8e6; fill-opacity: 1; stroke-opacity: 1; stroke-width: 2; stroke: #000000" cx="770" cy="570" rx="30" ry="30"/> ++ <ellipse style="fill: #ffa500; fill-opacity: 1; stroke-opacity: 1; stroke-width: 2; stroke: #000000" cx="430" cy="490" rx="30" ry="30"/> ++ <ellipse style="fill: #ffa500; fill-opacity: 1; stroke-opacity: 1; stroke-width: 2; stroke: #000000" cx="520" cy="350" rx="30" ry="30"/> ++ <ellipse style="fill: #add8e6; fill-opacity: 1; stroke-opacity: 1; stroke-width: 2; stroke: #000000" cx="950" cy="570" rx="30" ry="30"/> ++ <text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="412" y="492"> ++ <tspan x="412" y="492">GW2</tspan> ++ </text> ++ <text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="592" y="492"> ++ <tspan x="592" y="492">GW1</tspan> ++ </text> ++ <text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="502" y="352"> ++ <tspan x="502" y="352">GW3</tspan> ++ </text> ++ <text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="760" y="572"> ++ <tspan x="760" y="572">N1</tspan> ++ </text> ++ <text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="940" y="572"> ++ <tspan x="940" y="572">N2</tspan> ++ </text> ++ <line style="fill: none; stroke-opacity: 1; stroke-width: 10; stroke: #000000" x1="536.754" y1="376.062" x2="593.246" y2="463.938"/> ++ <line style="fill: none; stroke-opacity: 1; stroke-width: 10; stroke: #000000" x1="503.246" y1="376.062" x2="446.754" y2="463.938"/> ++ <line style="fill: none; stroke-opacity: 1; stroke-width: 10; stroke: #000000" x1="579.008" y1="490" x2="460.992" y2="490"/> ++ <line style="fill: none; stroke-opacity: 1; stroke-width: 10; stroke: #000000" x1="742.305" y1="556.152" x2="637.695" y2="503.848"/> ++ <line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke-dasharray: 4; stroke: #000000" x1="800.992" y1="570" x2="919.008" y2="570"/> ++ <text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="716" y="340"> ++ <tspan x="716" y="340">GW1, GW2, GW3: Gateway server mode</tspan> ++ </text> ++ <text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="780" y="360"> ++ <tspan x="780" y="360">N1, N2: Gateway client mode</tspan> ++ </text> ++ <line style="fill: none; stroke-opacity: 1; stroke-width: 10; stroke: #000000" x1="764" y1="384" x2="814" y2="384"/> ++ <text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="824" y="388"> ++ <tspan x="824" y="388">: 1000 Mbit/s link</tspan> ++ </text> ++ <text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="824" y="416"> ++ <tspan x="824" y="416">: 50 Mbit/s link</tspan> ++ </text> ++ <line style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke-dasharray: 4; stroke: #000000" x1="764" y1="412" x2="814" y2="412"/> ++ <text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="640" y="630"> ++ <tspan x="640" y="630">Selected GW: GW1</tspan> ++ </text> ++ <g> ++ <path style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #90ee90" d="M 748.786,591.214 A 96.8203,96.8203 0 0 1 612.024,529.486"/> ++ <polygon style="fill: #90ee90; fill-opacity: 1; stroke-opacity: 1; stroke-width: 2; stroke: #90ee90" fill-rule="evenodd" points="610.356,522.207 616.886,531.283 611.552,529.612 607.014,532.877 "/> ++ </g> ++ <text font-size="12.8" style="fill: #000000; fill-opacity: 1; stroke: none;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="860" y="520"> ++ <tspan x="860" y="520">Selected GW: GW3</tspan> ++ </text> ++ <g> ++ <path style="fill: none; stroke-opacity: 1; stroke-width: 2; stroke: #ff3f00" d="M 925.2 551.4 C 885.2,521.4 823.334,540 780,530 C 736.666,520 670,480 640,460 C 610,440 661,350 560.736,350"/> ++ <polygon style="fill: #ff3f00; fill-opacity: 1; stroke-opacity: 1; stroke-width: 2; stroke: #ff3f00" fill-rule="evenodd" points="553.236,350 563.236,345 560.736,350 563.236,355 "/> ++ </g> ++ <ellipse style="fill: #ffffff; fill-opacity: 1; stroke-opacity: 1; stroke-width: 2; stroke: #000000" cx="350" cy="610" rx="30" ry="30"/> ++ <ellipse style="fill: #ffffff; fill-opacity: 1; stroke-opacity: 1; stroke-width: 2; stroke: #000000" cx="390" cy="260" rx="30" ry="30"/> ++ <line style="fill: none; stroke-opacity: 1; stroke-width: 10; stroke: #000000" x1="494.506" y1="332.35" x2="415.494" y2="277.65"/> ++ <line style="fill: none; stroke-opacity: 1; stroke-width: 10; stroke: #000000" x1="412.808" y1="515.789" x2="367.192" y2="584.211"/> ++ </g> ++</svg> diff --cc batman-adv/noflood-sign.dia index 1e63ecf,1e63ecf..ab1a0cf Binary files differ

1 0

[doc] backup-redmine/2021-03-06,master: doc: batman-adv/gateway-selection-issue.dia (0441576)
by postmaster＠open-mesh.org 06 Mar '21

06 Mar '21

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2021-03-06,master >--------------------------------------------------------------- commit 044157642e552e3d1fe32dd2cc3bc933aa5a2b18 Author: Linus L��ssing <linus.luessing(a)c0d3.blue> Date: Sat Feb 20 22:09:25 2021 +0000 doc: batman-adv/gateway-selection-issue.dia >--------------------------------------------------------------- 044157642e552e3d1fe32dd2cc3bc933aa5a2b18 batman-adv/gateway-selection-issue.dia | Bin 0 -> 2295 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/batman-adv/gateway-selection-issue.dia b/batman-adv/gateway-selection-issue.dia new file mode 100644 index 0000000..540f4a7 Binary files /dev/null and b/batman-adv/gateway-selection-issue.dia differ

1 0

[doc] backup-redmine/2021-03-06,master: doc: batman-adv/gateway-selection-issue.png (f289b86)
by postmaster＠open-mesh.org 06 Mar '21

06 Mar '21

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2021-03-06,master >--------------------------------------------------------------- commit f289b864c04e885e465c76ab4424abd3c2f05475 Author: Linus L��ssing <linus.luessing(a)c0d3.blue> Date: Sat Feb 20 22:10:11 2021 +0000 doc: batman-adv/gateway-selection-issue.png >--------------------------------------------------------------- f289b864c04e885e465c76ab4424abd3c2f05475 batman-adv/gateway-selection-issue.png | Bin 0 -> 170802 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/batman-adv/gateway-selection-issue.png b/batman-adv/gateway-selection-issue.png new file mode 100644 index 0000000..5979aae Binary files /dev/null and b/batman-adv/gateway-selection-issue.png differ

1 0

[doc] backup-redmine/2021-03-06,master: doc: batman-adv/Gateway-Selection-Issue (54c02da)
by postmaster＠open-mesh.org 06 Mar '21

06 Mar '21

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2021-03-06,master >--------------------------------------------------------------- commit 54c02dae9e9f6d48fba682795b2b133dafab5638 Author: Linus L��ssing <linus.luessing(a)c0d3.blue> Date: Sun Feb 21 00:47:22 2021 +0000 doc: batman-adv/Gateway-Selection-Issue >--------------------------------------------------------------- 54c02dae9e9f6d48fba682795b2b133dafab5638 batman-adv/Gateway-Selection-Issue.textile | 86 ++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) diff --git a/batman-adv/Gateway-Selection-Issue.textile b/batman-adv/Gateway-Selection-Issue.textile new file mode 100644 index 0000000..2398a15 --- /dev/null +++ b/batman-adv/Gateway-Selection-Issue.textile @@ -0,0 +1,86 @@ +h1. Gateway Selection Issue + +h2. Scenario + +!gateway-selection-issue.png! + +_A batman-adv gateway client selecting a gateway behind the actual best gateway_ + +The scenario consists of BATMAN V nodes. GW1, GW2, GW3 and N1 have 1 Gbit/s links. While N2 is behind N1 with a considerably lower throughput, here 50 Mbit/s. + +While node N1 selects the correct, best gateway it is directly connected to, node N1 only selects GW1 with a 33% chance. And by a 66% selects either GW2 or GW3. Leading to an unnecessarily long route. + +h2. Issue Description + +On N1, the gateway table looks as follows: + +<pre><code> +N1$ batctl gw +client (selection class: 5.0 MBit) +N1$ batctl gwl +[B.A.T.M.A.N. adv openwrt-2019.2-10, MainIF/MAC: primary0/<orig-mac> (bat0/<bat0-mac> BATMAN_V)] + Router ( throughput) Next Hop [outgoingIf] Bandwidth +* GW1 ( 1000.0) GW1 [ mesh-vpn]: 1000.0/1000.0 MBit + GW2 ( 941.1) GW1 [ mesh-vpn]: 1000.0/1000.0 MBit + GW3 ( 941.1) GW1 [ mesh-vpn]: 1000.0/1000.0 MBit +</code></pre> + +Node N1 correctly selects GW1 as its best gateway thanks to the hop penalty which reduces the throughput by 230/255 = 5.9%. The difference is larger than the configured 5.0 MBit selection class, so node N1 will always select GW1 as its gateway for the unicasted DHCP packets. + +On node N2 however the table gateway table looks as follows: +<pre><code> +N2$ batctl gw +client (selection class: 5.0 MBit) +N2$ batctl gwl +[B.A.T.M.A.N. adv openwrt-2019.2-10, MainIF/MAC: primary0/<orig-mac> (bat0/<bat0-mac> BATMAN_V)] + Router ( throughput) Next Hop [outgoingIf] Bandwidth +* GW2 ( 50.0) GW1 [ wlan0]: 1000.0/1000.0 MBit + GW1 ( 50.0) GW1 [ wlan0]: 1000.0/1000.0 MBit + GW3 ( 50.0) GW1 [ wlan0]: 1000.0/1000.0 MBit +</code></pre> + +On node N2 the BATMAN V metric to all gateways is 50 MBit/s because BATMAN V calculates the minimum of the received throughput in the OGM (to GW1: 1000, to GW2: 941.1, to GW3: 941.1) and the link throughput towards the destination (50 Mbit/s). + +This leads to node N2 selecting the gateway which it first heard an OGM from. So it "randomly" selects one of the three available gateways. The probability to select the correct, best gateway decreases the more gateways are behind GW1 for N2. + +Node N1 had more, better information for selecting the best gateway which got lost by calculating the minimum. + +In theory this issue could happen with BATMAN IV, too. However it is a lot less likely to happen because BATMAN IV multiplies the link quality to the received TQ value instead of calculating a minimum. Therefore for BATMAN IV the 5.9% lower TQ to GW2/GW3 created by the hop penalty will persist (as long as the hop penalty is not reduced / configured to a lower value). + +h2. Solution (approaches) + +h3. Redirecting unicasted DHCP messages + +Node N1 could detect that it knows a better gateway than the one N2 has selected: It could check the DHCP messages send by N2 via a batman-adv unicast frame and rewrite its destination to GW1. + +Issue: Could probably loop? + +h3. Sinking unicasted DHCP messages. + +A gateway server, here GW1, could check if it is about to forward a unicasted DHCP message to another gateway server. And if so, refrain from forwarding and deliver it to its own bat0 instead. + +Issue: A DHCP client sends multiple messages to a DHCP server. We might break the DHCP handshake if the routes switched in between the handshake. + +h3. Filtering Gateway Announcements + +Nodes could filter out gateway announcements from OGMs before forwarding them. A gateway server could always filter out gateway announcements from other gateways. A non-gateway-server node could filter out gateway announcements from OGMs from each gateway server which does *not* have the highest path throughput (or TQ for BATMAN IV). + +Issue: The gateway announcement TVLV handler is called with BATADV_TVLV_HANDLER_OGM_CIFNOTFND. If a node were receiving OGMs from two different neighbors where one would have the gateway announcement TVLV and the other one wouldn't then this would lead to gateway selection flapping with each received OGM. The BATADV_TVLV_HANDLER_OGM_CIFNOTFND would need to be removed and replaced by a timeout. Which however would lead to reduced responsiveness / delays if a gateway disabled its gateway server mode. And more importantly, it would break compatibility, it'd need yet another TVLV/flag to propagate this capability. And only if all nodes were announcing this capability nodes could change their behaviour. + +Another issue is that it might render the stickiness client option void if for a forwarding node the gateway with the highest path throughput switches often. Which would lead to gateway flapping for gateway client even if it set a selection class / stickiness. + +h3. Flagging Best Gateway Announcements + +An additional flag could be added to the gateway announcements. Instead of filtering gateway announcements a node would unset this flag if it is not from its "best" gateway. A gateway server forwarding gateway announcements of other gateway servers would always unset this flag. The original gateway server would always set the flag in its gateway announcements when originating them. + +A gateway is considered "best" for keeping the flag set if: + +* + +Question: Should we re-set the flag when receiving a gateway announcement with the flag unset if it is our best gateway via a different neighbor? Or would we avoid resending this OGM anyway due to how the BATMAN algorithm works? + +Issues: The stickiness would need to be disregarded for the first OGM sequence number(s) or would need to be disregarded periodically to be able to converge to the best gateway. + +h4. General issues with filtering or flagging: + +While currently BATMAN V only takes the announced download bitrate into consideration, if a gateway client would want to select the best gateway by upload rate in the future that information would not be available anymore. In other words, a forwarding node might have other criteria for its best gateway than the final gateway clients. \ No newline at end of file

1 0

[doc] backup-redmine/2021-03-06,master: doc: batman-adv/Gateway-Selection-Issue (36caac2)
by postmaster＠open-mesh.org 06 Mar '21

06 Mar '21

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2021-03-06,master >--------------------------------------------------------------- commit 36caac2eb411099bbccfef903978805eedfb9eb5 Author: Linus L��ssing <linus.luessing(a)c0d3.blue> Date: Sun Feb 21 00:56:36 2021 +0000 doc: batman-adv/Gateway-Selection-Issue >--------------------------------------------------------------- 36caac2eb411099bbccfef903978805eedfb9eb5 batman-adv/Gateway-Selection-Issue.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/batman-adv/Gateway-Selection-Issue.textile b/batman-adv/Gateway-Selection-Issue.textile index 2398a15..c10ac1f 100644 --- a/batman-adv/Gateway-Selection-Issue.textile +++ b/batman-adv/Gateway-Selection-Issue.textile @@ -34,9 +34,9 @@ client (selection class: 5.0 MBit) N2$ batctl gwl [B.A.T.M.A.N. adv openwrt-2019.2-10, MainIF/MAC: primary0/<orig-mac> (bat0/<bat0-mac> BATMAN_V)] Router ( throughput) Next Hop [outgoingIf] Bandwidth -* GW2 ( 50.0) GW1 [ wlan0]: 1000.0/1000.0 MBit +* GW3 ( 50.0) GW1 [ wlan0]: 1000.0/1000.0 MBit GW1 ( 50.0) GW1 [ wlan0]: 1000.0/1000.0 MBit - GW3 ( 50.0) GW1 [ wlan0]: 1000.0/1000.0 MBit + GW2 ( 50.0) GW1 [ wlan0]: 1000.0/1000.0 MBit </code></pre> On node N2 the BATMAN V metric to all gateways is 50 MBit/s because BATMAN V calculates the minimum of the received throughput in the OGM (to GW1: 1000, to GW2: 941.1, to GW3: 941.1) and the link throughput towards the destination (50 Mbit/s).

1 0

[linux-merge]linux integration; annotated tag, v5.12-rc1-dontuse, created. v5.12-rc1
by postmaster＠open-mesh.org 03 Mar '21

03 Mar '21

The annotated tag, v5.12-rc1-dontuse has been created at d1da37c58e65c4800cce768533c563fa3c89c62f (tag) tagging fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8 (commit) replaces v5.11 tagged by Linus Torvalds on Sun Feb 28 16:05:19 2021 -0800 - Shortlog ------------------------------------------------------------ Linux 5.12-rc1 -----BEGIN PGP SIGNATURE----- iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmA8L78eHHRvcnZhbGRz QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGSOAH/RoIqzKVaV0PCrij JJIyRU1m1efazLE2Sv2sN9u4OugDvqf8zGigSZMDqNOdXZUxsszV0FCaFudejH+p COO4Av7pPqkWbV0/8LjbtLoN0NYqNqledViWS8REWi+KHjbwp78F2ilRwBq7Rv+e YD6lX03R/mDhShtynAeMApmUzkP/Ihp7GDFR5HeivJy0+ECaEY13e/NiulBveN63 zHMzMjWet0BLxuzFMX19GjS57KvNYD7g+y0gvy0re9iWgU3mMAAyWkkBYd6IVCpd o8E8dd7uwI7xXyHC7lsjO/6Nkm/cZ4PVakoVhHKKQLfpVHaOMtZ+OFRp1xau67JX R7K6mxI= =v0mq -----END PGP SIGNATURE----- Jakub Kicinski (1): Merge tag 'batadv-next-pullrequest-20210208' of git://git.open-mesh.org/linux-merge Masahiro Yamada (1): net: remove redundant 'depends on NET' Simon Wunderlich (1): batman-adv: Start new development cycle Sven Eckelmann (3): batman-adv: Drop publication years from copyright info batman-adv: Avoid sizeof on flexible structure batman-adv: Fix names for kernel-doc blocks ----------------------------------------------------------------------- -- linux integration

1 0

[linux-merge]linux integration; annotated tag, v4.4.258, created. v4.4.258
by postmaster＠open-mesh.org 02 Mar '21

02 Mar '21

The annotated tag, v4.4.258 has been created at 3bc962a9c9ec92df45e23f159b8d28feca14f347 (tag) tagging 312b5d65a03db01974224c76481c0db1786c41ae (commit) replaces v4.4.257 tagged by Greg Kroah-Hartman on Tue Feb 23 13:58:32 2021 +0100 - Shortlog ------------------------------------------------------------ This is the 4.4.258 stable release -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmA0+/gACgkQONu9yGCS aT4x+BAAv7Ed0vFdpB4gJuNW2XRb74U5r1Br2s+vQ5v+DHhrzRVK2eA12NKIJdJu 0tvj2PHMiy/FPnwURElJ4Eck4H91EUc0HMpzSByT6otP2AqLExQ4KrEvUUN5kt4q xC9U6ki+oEDvlVAZsfxwdBXu8T5AnyWptu4j80px5uxt/ZdatfmipzDlMtz2KI+w Dfik+qhV4dJoTD7QYYDuovLzWFxuif6bpOhR8co2KGgKH+UrJ5FzGWG31zHmAz3T jU5krdluLIQwz7/kS4dzVWibx0VgUEvzy7SZ7Hy0c8B0mchbG4eaEKtEU3P0eKQu ipEWCfQGjcAav55ACjbIymH4UPlomeygctfHR/VXSjDgUcgT7dqZ5Wt53VBFOPpm +qONIBo90bvtvYgHzON9eJ6oYXbsH90fmQg9maefWST+CSsR/Y3MlcEuQ4enbwhe E6zS9dekgrgMOE9/BiMn6ynKO6v64unMOCkw9HBf2fJQZOngmGD2STBXKmGbp1XG ZLImDiJcIBnYSN1BjfAftb65gFJD1n0wTtA+JbKLUuRucg0EhvjOQtrBncxNuStb gIK+j7RjwkzTsEBPLojW5Qkl1zH0o/2Ls3DF5U+OGXR1HePBG3uLiLIU0Q2rg0Hy 9v8zy6mgPJHSPDTa21Se9P1i6S0OMREfGzWGFLFLI/bKS4co/kE= =s8p7 -----END PGP SIGNATURE----- ----------------------------------------------------------------------- -- linux integration

1 0

[linux-merge]linux integration; annotated tag, v4.9.258, created. v4.9.258
by postmaster＠open-mesh.org 02 Mar '21

02 Mar '21

The annotated tag, v4.9.258 has been created at 401075e99f97d4c1dc724caf3e788c2260c062a8 (tag) tagging 5b1d078507bd33ebf6c2083fa363cf5832809c19 (commit) replaces v4.9.257 tagged by Greg Kroah-Hartman on Tue Feb 23 13:59:41 2021 +0100 - Shortlog ------------------------------------------------------------ This is the 4.9.258 stable release -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmA0/D0ACgkQONu9yGCS aT4YVRAAnUz584VShUJYJONEbbp/HToHlU1eamwhVOeYykveR01UZcN4TQccU71R 80zc9fg3YG0QJMLwGMjPXP1E9Xd0THn3Igcles1qTaWx06JeuyPQqNK0JV1e1ruL qD1kAr5ON4BiQpOEo+u+t/dvyFJgRppPs+ud+Q81skySUpElMRQg7Am5FDkFVVg2 Pun1f4+6c6in3M8Gu+3WaZzPkrXoR8Bg8FnvzY4OMFxO1kElIj4FbXCTUFg6tUVp uTUI4RJH2GAN7NUru0lI45VIOkcmE8M7TFr/i/v0rXhTCVQPGtgYw1hCokGwKCiM yfLDR6cry/hFw0aE3CgVqW8p4iJKkoKl/8hjCmqh5n56dR0Cf75CtS+pE55z1lfF DAUk044+e+QVqumw4Ky9guakhrgn6cepy6xU29t1Agb6OwCBwUatWV+NJ3AYM/f+ 7eE+0m+WR+ehgtDPNL6nsHlGfFrARw6lpYg8Cy7q18zZl2v4GxauuLfnVW0pgCnj yvl0Xs/dwlVay8QVWf9RlENmDV9dWGJzM/4e9FCPqgu+RzF2pfDdN+2RZ8ExF78n h456Vx2iM6eWEwz396JjrHgM9NUb4TVlKfZWg5naI3mmTUeAV0JZy5/m/ZIIiiT1 lUjOmIr3XCloaLPxJDhnap8nEHWXPeuzri4O/25ZX69nmmekBKs= =ebCa -----END PGP SIGNATURE----- ----------------------------------------------------------------------- -- linux integration

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits March 2021