David Sommerseth escreveu:
> Ahh! Sorry about that. Scratch my patch! I didn't think about that this
> could be sent over the wire. But I'm not sure that a search/replace of
> "mtu-dynamic" on the warning string would solve it completely neither, then
> something needs to be done with this p
Ahh! Sorry about that. Scratch my patch! I didn't think about that this
could be sent over the wire. But I'm not sure that a search/replace of
"mtu-dynamic" on the warning string would solve it completely neither, then
something needs to be done with this part of the code instead:
option
It's not so simple -- the "mtu-dynamic" string is passed across the
network which means the patch below will break backward compatibility
when one side of the connection is patched but the other side is not.
In fact, that's the reason why the options consistency protocol still
uses "mtu-dynamic
I'm guessing the following patch would correct this
--- options.c.orig 2008-09-08 08:32:05.0 +0200
+++ options.c 2008-09-08 08:31:10.0 +0200
@@ -2236,7 +2236,7 @@
#ifdef ENABLE_FRAGMENT
if (o->fragment)
-buf_printf (&out, ",mtu-dynamic");
+buf_printf (&ou
..
> Hi,
>
> When makins some inconsistency mistake with "--fragment"
> settings, I get an error message like:
>
> WARNING: 'mtu-dynamic' is present in local config but missing
> in remote config, local='mtu-dynamic'
>
> I guess this message has to be updates, as "--fragment" is
> meant to re
Hi,
When makins some inconsistency mistake with "--fragment" settings, I get
an error message like:
WARNING: 'mtu-dynamic' is present in local config but missing in remote config,
local='mtu-dynamic'
I guess this message has to be updates, as "--fragment" is meant to
replace "--mtu-dynamic" AFA
