there was a bug for core61, I found a problem with OpenVPN. The discussion is at http://forum.ipfire.org/index.php/topic,6773.0.html. This problem still exists in the beta.
ummeegge created a patch that repairs the issue, and it should be put into ovpnmain.cgi. It appears, in the tests I ran, to solve the issue.
Rod
As mentioned on the forums thread, it is unacceptable that all client packages need to be re-installed. The patch cannot break any existing configuration!
Michael
On Thu, 2012-09-06 at 01:39 -0500, R. W. Rodolico wrote:
there was a bug for core61, I found a problem with OpenVPN. The discussion is at http://forum.ipfire.org/index.php/topic,6773.0.html. This problem still exists in the beta.
ummeegge created a patch that repairs the issue, and it should be put into ovpnmain.cgi. It appears, in the tests I ran, to solve the issue.
Rod _______________________________________________ Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
I continued the discussion in the thread. The issue is, the core61 issue with openvpn breaks existing installations by its requirement for fragment to be included in the server configuration. That was how I discovered the issue in the first place. The patch ummeegge created simply allows fragment to be completely removed.
However, please wait on this issue until I have had time for further tests, which I will attempt to complete today.
Rod
On 09/06/2012 04:34 AM, Michael Tremer wrote:
As mentioned on the forums thread, it is unacceptable that all client packages need to be re-installed. The patch cannot break any existing configuration!
Michael
On Thu, 2012-09-06 at 01:39 -0500, R. W. Rodolico wrote:
there was a bug for core61, I found a problem with OpenVPN. The discussion is at http://forum.ipfire.org/index.php/topic,6773.0.html. This problem still exists in the beta.
ummeegge created a patch that repairs the issue, and it should be put into ovpnmain.cgi. It appears, in the tests I ran, to solve the issue.
Rod _______________________________________________ Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
Ok, I did some additional tests. Note that I am talking about a change in core61 (and apparently used in thirteen also) which breaks existing installs. Forcing the optional parameter fragment to be used by the server breaks existing installs; this was what alerted me to the issue when I got a complaint from a client using OpenVPNGUI on their Windows machine.
Additionally, the default clean install of core61 has the same issue, as verfified by both myself and ummeegge, ie doing a clean install and clean config of OpenVPN results in an unworkable system until fragment is manually removed from the server.conf file.
Strongly recommend ummeegge's patch be applied to thirteen.
Everything else appears to be working well on thirteen (at least the parts I use). Going to stress test the QOS in a few minutes.
Rod
On 09/06/2012 04:34 AM, Michael Tremer wrote:
As mentioned on the forums thread, it is unacceptable that all client packages need to be re-installed. The patch cannot break any existing configuration!
Michael
On Thu, 2012-09-06 at 01:39 -0500, R. W. Rodolico wrote:
there was a bug for core61, I found a problem with OpenVPN. The discussion is at http://forum.ipfire.org/index.php/topic,6773.0.html. This problem still exists in the beta.
ummeegge created a patch that repairs the issue, and it should be put into ovpnmain.cgi. It appears, in the tests I ran, to solve the issue.
Rod _______________________________________________ Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
Hey Rod,
I must have something misunderstood.
The patch reverts some of the broken changes from core update 61 and does not break anything else.
So, it someone did not touch the settings since core update 60, they won't experience any trouble. That's what I want.
Installations done with core update 61 have screwed up already.
If you both, Rod and Erik, can confirm that, I will merge the patch for core update 63.
Michael
On Thu, 2012-09-06 at 17:25 -0500, R. W. Rodolico wrote:
Ok, I did some additional tests. Note that I am talking about a change in core61 (and apparently used in thirteen also) which breaks existing installs. Forcing the optional parameter fragment to be used by the server breaks existing installs; this was what alerted me to the issue when I got a complaint from a client using OpenVPNGUI on their Windows machine.
Additionally, the default clean install of core61 has the same issue, as verfified by both myself and ummeegge, ie doing a clean install and clean config of OpenVPN results in an unworkable system until fragment is manually removed from the server.conf file.
Strongly recommend ummeegge's patch be applied to thirteen.
Everything else appears to be working well on thirteen (at least the parts I use). Going to stress test the QOS in a few minutes.
Rod
On 09/06/2012 04:34 AM, Michael Tremer wrote:
As mentioned on the forums thread, it is unacceptable that all client packages need to be re-installed. The patch cannot break any existing configuration!
Michael
On Thu, 2012-09-06 at 01:39 -0500, R. W. Rodolico wrote:
there was a bug for core61, I found a problem with OpenVPN. The discussion is at http://forum.ipfire.org/index.php/topic,6773.0.html. This problem still exists in the beta.
ummeegge created a patch that repairs the issue, and it should be put into ovpnmain.cgi. It appears, in the tests I ran, to solve the issue.
Rod _______________________________________________ Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
All of my tests so far have shown the patch to be effective. I agree that it was likely a bug that crept in on the new code (would be nice to have some effective beta testing -- oops, I'm the one that should have done that).
Rod
On 09/07/2012 09:41 AM, Michael Tremer wrote:
Hey Rod,
I must have something misunderstood.
The patch reverts some of the broken changes from core update 61 and does not break anything else.
So, it someone did not touch the settings since core update 60, they won't experience any trouble. That's what I want.
Installations done with core update 61 have screwed up already.
If you both, Rod and Erik, can confirm that, I will merge the patch for core update 63.
Michael
On Thu, 2012-09-06 at 17:25 -0500, R. W. Rodolico wrote:
Ok, I did some additional tests. Note that I am talking about a change in core61 (and apparently used in thirteen also) which breaks existing installs. Forcing the optional parameter fragment to be used by the server breaks existing installs; this was what alerted me to the issue when I got a complaint from a client using OpenVPNGUI on their Windows machine.
Additionally, the default clean install of core61 has the same issue, as verfified by both myself and ummeegge, ie doing a clean install and clean config of OpenVPN results in an unworkable system until fragment is manually removed from the server.conf file.
Strongly recommend ummeegge's patch be applied to thirteen.
Everything else appears to be working well on thirteen (at least the parts I use). Going to stress test the QOS in a few minutes.
Rod
On 09/06/2012 04:34 AM, Michael Tremer wrote:
As mentioned on the forums thread, it is unacceptable that all client packages need to be re-installed. The patch cannot break any existing configuration!
Michael
On Thu, 2012-09-06 at 01:39 -0500, R. W. Rodolico wrote:
there was a bug for core61, I found a problem with OpenVPN. The discussion is at http://forum.ipfire.org/index.php/topic,6773.0.html. This problem still exists in the beta.
ummeegge created a patch that repairs the issue, and it should be put into ovpnmain.cgi. It appears, in the tests I ran, to solve the issue.
Rod _______________________________________________ Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
On Fri, 2012-09-07 at 12:26 -0500, R. W. Rodolico wrote:
All of my tests so far have shown the patch to be effective. I agree that it was likely a bug that crept in on the new code (would be nice to have some effective beta testing -- oops, I'm the one that should have done that).
Indeed :D
I am waiting for some more responses about the patch. I think we are clear to go, but still need more people to test it.
Michael
Hi all, the patch is working for me, after patching the ovpnmain.cgi the package size is per default 1400 MTU and fragment and mssfix doesn´t appear. If i adjust a value for fragment and activate mssfix, both are displayed with the same values in the configuration files for the server and also for the client configuration file, also the MTU can be adjusted and the values are also printed to both configuration files.
But i have had some strange messages after patching the ovpnmain.cgi . The logs said that the keepalive value aren´t set for the server and as i controlled the server.conf there wasn´t the keepalive 10 60 value findable. After a manual edit over the WUI, keepalive 10 60 was also printed to server.conf.
So this patch: --- ovpnmain.cgi.61 2012-09-01 06:49:41.385539818 +0200 +++ ovpnmain.cgi 2012-09-01 06:41:15.804679610 +0200 @@ -356,14 +356,11 @@ if ($sovpnsettings{CLIENT2CLIENT} eq 'on') { print CONF "client-to-client\n"; } - if ($sovpnsettings{'DPROTOCOL'} eq 'udp') { - if ($sovpnsettings{MSSFIX} eq 'on') { - print CONF "mssfix\n"; - } - if ($sovpnsettings{'FRAGMENT'} eq '' || $sovpnsettings{'FRAGMENT'} eq 0) { - $sovpnsettings{'FRAGMENT'} = '1300'; - } - print CONF "fragment $sovpnsettings{'FRAGMENT'}\n"; + if ($sovpnsettings{MSSFIX} eq 'on') { + print CONF "mssfix\n"; + } + if ($sovpnsettings{FRAGMENT} ne '' && $sovpnsettings{'DPROTOCOL'} ne 'tcp') { + print CONF "fragment $sovpnsettings{'FRAGMENT'}\n"; } if ($sovpnsettings{KEEPALIVE_1} > 0 && $sovpnsettings{KEEPALIVE_2} > 0) { print CONF "keepalive $sovpnsettings{'KEEPALIVE_1'} $sovpnsettings{'KEEPALIVE_2'}\n"; @@ -532,7 +529,7 @@ } } if ($cgiparams{'MSSFIX'} ne 'on') { - $vpnsettings{'MSSFIX'} = 'off'; + delete $vpnsettings{'MSSFIX'}; } else { $vpnsettings{'MSSFIX'} = $cgiparams{'MSSFIX'}; } @@ -1906,12 +1903,6 @@ if ($cgiparams{'LOG_VERB'} eq '') { $cgiparams{'LOG_VERB'} = '3'; } - if ($cgiparams{'MSSFIX'} eq '') { - $cgiparams{'MSSFIX'} = 'on'; - } - if ($cgiparams{'FRAGMENT'} eq '') { - $cgiparams{'FRAGMENT'} = '1300'; - } $checked{'CLIENT2CLIENT'}{'off'} = ''; $checked{'CLIENT2CLIENT'}{'on'} = ''; $checked{'CLIENT2CLIENT'}{$cgiparams{'CLIENT2CLIENT'}} = 'CHECKED';
doesn´t contain changes for keepalive so i´am pretty unsure where it comes from. Does someone have similar log entries or is it maybe only a individual problem?
Erik
Am 10.09.2012 um 10:08 schrieb Michael Tremer:
On Fri, 2012-09-07 at 12:26 -0500, R. W. Rodolico wrote:
All of my tests so far have shown the patch to be effective. I agree that it was likely a bug that crept in on the new code (would be nice to have some effective beta testing -- oops, I'm the one that should have done that).
Indeed :D
I am waiting for some more responses about the patch. I think we are clear to go, but still need more people to test it.
Michael
Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
The patch has been applied to the next branch.
Please please please test.
Michael
On Mon, 2012-09-10 at 11:02 +0200, Erik K. wrote:
Hi all, the patch is working for me, after patching the ovpnmain.cgi the package size is per default 1400 MTU and fragment and mssfix doesn´t appear. If i adjust a value for fragment and activate mssfix, both are displayed with the same values in the configuration files for the server and also for the client configuration file, also the MTU can be adjusted and the values are also printed to both configuration files.
But i have had some strange messages after patching the ovpnmain.cgi . The logs said that the keepalive value aren´t set for the server and as i controlled the server.conf there wasn´t the keepalive 10 60 value findable. After a manual edit over the WUI, keepalive 10 60 was also printed to server.conf.
So this patch: --- ovpnmain.cgi.61 2012-09-01 06:49:41.385539818 +0200 +++ ovpnmain.cgi 2012-09-01 06:41:15.804679610 +0200 @@ -356,14 +356,11 @@ if ($sovpnsettings{CLIENT2CLIENT} eq 'on') { print CONF "client-to-client\n"; }
- if ($sovpnsettings{'DPROTOCOL'} eq 'udp') {
if ($sovpnsettings{MSSFIX} eq 'on') {print CONF "mssfix\n";}if ($sovpnsettings{'FRAGMENT'} eq '' || $sovpnsettings{'FRAGMENT'} eq 0) {$sovpnsettings{'FRAGMENT'} = '1300';}print CONF "fragment $sovpnsettings{'FRAGMENT'}\n";
- if ($sovpnsettings{MSSFIX} eq 'on') {
- print CONF "mssfix\n";
- }
- if ($sovpnsettings{FRAGMENT} ne '' && $sovpnsettings{'DPROTOCOL'} ne 'tcp') {
- print CONF "fragment $sovpnsettings{'FRAGMENT'}\n"; } if ($sovpnsettings{KEEPALIVE_1} > 0 && $sovpnsettings{KEEPALIVE_2} > 0) { print CONF "keepalive $sovpnsettings{'KEEPALIVE_1'} $sovpnsettings{'KEEPALIVE_2'}\n";
@@ -532,7 +529,7 @@ } } if ($cgiparams{'MSSFIX'} ne 'on') {
$vpnsettings{'MSSFIX'} = 'off';
delete $vpnsettings{'MSSFIX'};@@ -1906,12 +1903,6 @@ if ($cgiparams{'LOG_VERB'} eq '') { $cgiparams{'LOG_VERB'} = '3'; }
- if ($cgiparams{'MSSFIX'} eq '') {
$cgiparams{'MSSFIX'} = 'on';- }
- if ($cgiparams{'FRAGMENT'} eq '') {
$cgiparams{'FRAGMENT'} = '1300';- } $checked{'CLIENT2CLIENT'}{'off'} = ''; $checked{'CLIENT2CLIENT'}{'on'} = ''; $checked{'CLIENT2CLIENT'}{$cgiparams{'CLIENT2CLIENT'}} = 'CHECKED';
doesn´t contain changes for keepalive so i´am pretty unsure where it comes from. Does someone have similar log entries or is it maybe only a individual problem?
Erik
Am 10.09.2012 um 10:08 schrieb Michael Tremer:
On Fri, 2012-09-07 at 12:26 -0500, R. W. Rodolico wrote:
All of my tests so far have shown the patch to be effective. I agree that it was likely a bug that crept in on the new code (would be nice to have some effective beta testing -- oops, I'm the one that should have done that).
Indeed :D
I am waiting for some more responses about the patch. I think we are clear to go, but still need more people to test it.
Michael
Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
-
Erik K. -
Michael Tremer -
R. W. Rodolico