Don't send MTU probes smaller than 512 bytes.

If MTU discovery comes up with an MTU smaller than 512 bytes (e.g. due
to massive packet loss), it's pretty much guaranteed to be wrong. Even
if it's not, most Internet applications assume the MTU will be at least
512, so fixing the MTU to a small value is likely to cause trouble
anyway.

This also makes the discovery algorithm converge even faster, since the
interval it has to consider is smaller.

diff --git a/src/net_packet.c b/src/net_packet.c
index 1397060..626114c 100644 (file)
--- a/src/net_packet.c
+++ b/src/net_packet.c
@@ -927,13 +927,13 @@ static void try_mtu(node_t *n) {
                const length_t probes_per_cycle = 8;
 
                /* This magic value was determined using math simulations.
-                  It will result in a 1339-byte first probe, followed (if there was a reply) by a 1417-byte probe.
-                  Since 1417 is just below the range of tinc MTUs over typical networks,
+                  It will result in a 1329-byte first probe, followed (if there was a reply) by a 1407-byte probe.
+                  Since 1407 is just below the range of tinc MTUs over typical networks,
                   this fine-tuning allows tinc to cover a lot of ground very quickly. */
-               const float multiplier = 0.982;
+               const float multiplier = 0.97;
 
                const float cycle_position = probes_per_cycle - (n->mtuprobes % probes_per_cycle) - 1;
-               const length_t minmtu = MAX(n->minmtu, 64);
+               const length_t minmtu = MAX(n->minmtu, 512);
                const float interval = n->maxmtu - minmtu;
 
                /* The core of the discovery algorithm is this exponential.