Repository : ssh://git@diktynna/doc

On branches: backup-redmine/2020-07-12,master

commit cb4fe5694dc7fb5930490d7d6f3f80292ecce4b1 Author: Sven Eckelmann sven@narfation.org Date: Sat Jun 20 21:16:05 2020 +0000

doc: batman-adv/Fragmentation-technical

cb4fe5694dc7fb5930490d7d6f3f80292ecce4b1 batman-adv/Fragmentation-technical.textile | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/batman-adv/Fragmentation-technical.textile b/batman-adv/Fragmentation-technical.textile index 1ca1c66..448e08c 100644 --- a/batman-adv/Fragmentation-technical.textile +++ b/batman-adv/Fragmentation-technical.textile @@ -61,13 +61,12 @@ h2. Configuration

First of all, fragmentation shouldn't be needed (except for tt-tables, see below). It is a fix for drivers/hardware that is unable to handle MTU's greater than 1528 bytes, it is slow (due to increase is packets), and is susceptible to packet loss.

-It can be enabled and disabled via batctl: +It can be turned on and off via batctl: <pre> -% batctl meshif bat0 fragmentation 1 # enable (default) -% batctl meshif bat0 fragmentation 0 # disable +% batctl meshif bat0 fragmentation 1 # on (default) +% batctl meshif bat0 fragmentation 0 # off </pre>

- h2. Limitations

If an intermediate node with an unexpectedly lower MTU exists, this scheme breaks. In the scenario "A <-> B <-> C", where A and C have MTU=1550 and B has MTU=1000 bytes, B cannot respond with nor forward very-big-full-tables from A to C. At the moment, batman-adv simply forwards the requests and hopes for the best.