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 part of the code instead:
>
> options.c - line 3567
> -------------------------------------------------------------------------
> #ifdef ENABLE_FRAGMENT
> else if (streq (p[0], "mtu-dynamic"))
> {
> VERIFY_PERMISSION (OPT_P_GENERAL);
> msg (msglevel, "--mtu-dynamic has been replaced by --fragment");
> goto err;
> }
> else if (streq (p[0], "fragment") && p[1])
> {
> VERIFY_PERMISSION (OPT_P_MTU);
> options->fragment = positive_atoi (p[1]);
> }
> #endif
> -------------------------------------------------------------------------
>
> Here we have a "goto err" if mtu-dynamic is used. But we want to allow it,
> because if backward compatibility ... so the code probably would need to be
> something like this:
> -------------------------------------------------------------------------
> #ifdef ENABLE_FRAGMENT
> else if ((streq (p[0], "mtu-dynamic") || streq (p[0], "fragment"))
> && p[1]))
> {
> VERIFY_PERMISSION (OPT_P_GENERAL);
> if( (streq (p[0], "mtu-dynamic")
> {
> msg (msglevel, "--mtu-dynamic has been replaced by
> --fragment");
> }
>
> VERIFY_PERMISSION (OPT_P_MTU);
> options->fragment = positive_atoi (p[1]);
> }
> #endif
> -------------------------------------------------------------------------
>
> This would then preserve backward compatibility and give a warning.
>
> But if this option is not longer supported, and has been deprecated for
> over 5 years, that would mean OpenVPN 1.x-something ... wouldn't it be
> about time to upgrade the software package then? Such old software could
> just as well be a potential security breach.
>
>
> Kind regards,
>
> David S.
>
>
> James Yonan wrote:
>
>> 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" instead of "fragment". The solution that preserves
>> backward compatibility is to continue using "mtu-dynamic", but do a
>> search/replace of "mtu-dynamic" -> "fragment" on the warning string
>> before it is output.
>>
>> Actually if that's the worst bug you guys can find, we're probably ready
>> to release 2.1 :)
>>
>> James
>>
>> David Sommerseth wrote:
>>
>>> I'm guessing the following patch would correct this ....
>>>
>>>
>>> --- options.c.orig 2008-09-08 08:32:05.000000000 +0200
>>> +++ options.c 2008-09-08 08:31:10.000000000 +0200
>>> @@ -2236,7 +2236,7 @@
>>>
>>> #ifdef ENABLE_FRAGMENT
>>> if (o->fragment)
>>> - buf_printf (&out, ",mtu-dynamic");
>>> + buf_printf (&out, ",fragment");
>>> #endif
>>>
>>> #ifdef USE_CRYPTO
>>>
>>>
>>> Seems to me like it's just a typo when preparing the argument parsing.
>>>
>>>
>>> kind regards,
>>>
>>> David Sommerseth
>>>
>>>
>>>
>>>
>>> Dave wrote:
>>>
>>>> ..
>>>>
>>>>> 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" AFAICS.
>>>>>
>>>>> This is with 2.1_rc9.
>>>>>
>>>> ...
>>>>
>>>> Nice bug! --mtu-dynamic is an ancient option, it was dropped in
>>>> version 1.5
>>>> about 5 years ago.
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>>
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>> great prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>>> world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> Openvpn-devel mailing list
>>>> Openvpn-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Openvpn-devel mailing list
>>> Openvpn-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
>
I've tried to told some clients of mine about that, but it would only be
upgraded in case of a OS upgrade. So i bet there are a lot of openvpn
1.X servers in production around. OpenVPN is so stable, even the 1.X
versions, that many people just won't consider replace it. I guess it's
the odds of being such a nice piece of software. I know openvpn has
bugs, but never heard of anyone hacked by one of them so, i consider it
very secure. But i believe that 2.1 is the release to break things. The
little inconvenient of having to upgrade, will pay the effort. So, i
vote for removing all compatibility options that are around because of
openvpn 1.X servers.
--
Giancarlo Razzolini
http://lock.razzolini.adm.br
Linux User 172199
Red Hat Certified Engineer no:804006389722501
Verify:https://www.redhat.com/certification/rhce/current/
Moleque Sem Conteudo Numero #002
OpenBSD Stable
Ubuntu 8.04 Hardy Heron
4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85
