Fix TOS processing; Update release notes

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@5731 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2007-03-28 17:43:09 +00:00
parent a983cc2a61
commit d08dca7c6b
3 changed files with 46 additions and 28 deletions

View File

@ -37,7 +37,8 @@ use Shorewall::Proc;
use strict;
our @ISA = qw(Exporter);
our @EXPORT = qw( add_common_rules
our @EXPORT = qw( process_tos
add_common_rules
setup_mac_lists
process_criticalhosts
process_routestopped
@ -59,13 +60,13 @@ my @rule_chains;
my $sectioned = 0;
sub process_tos() {
my $chain = 'pretos';
my $stdchain = 'PREROUTING';
my $chain = $capabilities{MANGLE_FORWARD} ? 'fortos' : 'pretos';
my $stdchain = $capabilities{MANGLE_FORWARD} ? 'FORWARD' : 'PREROUTING';
if ( -s "$ENV{TMP_DIR}/tos" ) {
progress_message2 'Setting up TOS...';
my $pretosref = new_chain 'mangle' , 'pretos';
my $pretosref = new_chain 'mangle' , $chain;
my $outtosref = new_chain 'mangle' , 'outtos';
open TOS, "$ENV{TMP_DIR}/tos" or fatal_error "Unable to open stripped tos file: $!";
@ -107,6 +108,9 @@ sub process_tos() {
}
close TOS;
add_rule $mangle_table->{$stdchain}, "-j $chain";
add_rule $mangle_table->{OUTPUT}, "-j outtos";
}
}

View File

@ -750,6 +750,10 @@ sub compiler( $ ) {
progress_message2 "$doing TC Rules...";
setup_tc;
#
# TOS
#
process_tos;
#
# Setup Masquerading/SNAT
#
progress_message2 "$doing Masq file...";

View File

@ -40,33 +40,35 @@ d) Use of the perl compiler is optional! The old slow clunky
The bad news:
There are a number of incompatibilities between the Perl-based compiler
and the Bourne-shell one.
and the Bourne-shell one. Some of these will probably go away by first
official release but some will not.
a) The Perl-based compiler requires the following capabilities in your
kernel and iptables.
- addrtype match
- conntrack match
- multiport match
- addrtype match (may be relaxed later)
- conntrack match (may be relaxed later)
- multiport match (will not be relaxed)
These capabilities are in current distributions.
b) The Bourne-shell compiler goes to great pain (in some cases) to
break very long port lists ( > 15 where port ranges in lists count
as two ports) into individual rules. I'm removing the ugliness
required to do that (at least initially). The new compiler just
gives you an error. It will also give you an error if you insert a
port range into a port list and you don't have extended multiport
support. Now that Netfilter has features to deal reasonably with
port lists, I see no reason to duplicate those features in
Shorewall.
as two ports) into individual rules. In the new compiler, I'm
avoiding the ugliness required to do that. The new compiler just
gives you an error if your list is too long. It will also give you
an error if you insert a port range into a port list and you don't
have extended multiport support. Now that Netfilter has features to
deal reasonably with port lists, I see no reason to duplicate those
features in Shorewall.
c) BRIDGING=Yes is not supported. The kernel code necessary to
support this option was removed in Linux kernel 2.6.20.
d) The BROADCAST column in the interfaces file is essentailly unused;
if you enter anything in this column but '-' or 'detect', you will
receive a warning.
receive a warning. This will be relaxed if and when the addrtype
match requirement is relaxed.
e) Because the compiler is now written in Perl, your compile-time
extension scripts from earlier versions will no longer work.
@ -83,7 +85,8 @@ g) Some run-time extension scripts are no longer supported because they
refresh
refreshed
h) The /etc/shorewall/tos file now has a format similar to the tcrules.
h) The /etc/shorewall/tos file now has zone-independent SOURCE and DEST
columns as do all other files except the rules and policy files.
The SOURCE column may be one of the following:
@ -95,6 +98,12 @@ h) The /etc/shorewall/tos file now has a format similar to the tcrules.
[all:]<address>[,...]
[all:]<interface>[:<address>[,...]]
This is a perminent change. The old zone-based rules have never
worked right and this is a good time to replace them. I've tried to
make the new syntax cover the most common cases without requiring
change to existing files. In particular, it will handle the tos file
released with Shorewall 1.4 and earlier.
i) Currently, support for ipsets is untested. That will change with
future releases but one thing is certain -- Shorewall is now out of the
ipset load/reload business. With scripts generated by the Perl-based
@ -135,21 +144,22 @@ Using the New compiler
By default, the old Bourne-shell based compiler will be used.
There is one change in Shorewall operation that is triggered when
/usr/share/shorewall-perl exists and is either a directory or a symbolic
link that points to a directory: Your params file will be processed
with the shell's '-a' option set which will automatically export any
variables that you set or create in that file. Since the params file is
processed before shorewall.conf, using the -a option assures that the
settings of your params variables are available to the new compiler
should it be used.
To use the new compiler, add this to shorewall.conf:
To actually use the new compiler, add this to shorewall.conf:
SHOREWALL_PERL=Yes
SHOREWALL_COMPILER=perl
If you add this setting to /etc/shorewall/shorewall.conf then by
default, the new compiler will be used on the system. If you add it to
shorewall.conf in a separate directory (such as a Shorewall-lite export
directory) then the new compiler will only be used when you compile
from that directory.
Regardless of the setting of SHOREWALL_COMPILER, there is one change in
Shorewall operation that is triggered simply by installing
shorewall-perl. Your params file will be processed with the shell's
'-a' option which causes any variables that you set or create in that
file to be automatically exported. Since the params file is processed
before shorewall.conf, using -a insures that the settings of your
params variables are available to the new compiler should it's use be
specified in shorewall.conf.