Shorewall 4.5.0 is now ready for testing.
----------------------------------------------------------------------------
K N O W N P R O B L E M S
----------------------------------------------------------------------------
1) There is a syntax error in /sbin/shorewall. Patch is attached.
2) Specifying icmp or icmpv6 in /etc/shorewall/tcpri results in an error.
I'll provide a fix later today.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 0
----------------------------------------------------------------------------
1) The shorewall.conf options WIDE_TC_MARKS and HIGH_ROUTE_MARKS are
now deprecated in favor of a new set of options that define the layout
of the 32-bit packet/connection mark.
TC_BITS Number of bits at the least-significant end
of the mark used for traffic shaping. Marks
used for traffic shaping must have a value
between 1 and 2**TC_BITS - 1.
PROVIDER_OFFSET The offset in bits from the least-significant
end of the mark where the provider mark field
begins. If zero, the provider mark occupies
the same area as the traffic shaping
mark. Otherwise, the value specified must
be greater than or equal to MASK_BITS
(below). Shorewall will automatically adjust
a non-zero PROVIDER_OFFSET to meet this
requirement.
PROVIDER_BITS Number of bits reserved for routing
marks. Provider marks must have a value
between 2**PROVIDER_OFFSET and
2**(PROVIDER_OFFSET + PROVIDER_BITS) - 1.
MASK_BITS Number of 1 bits in the default mask when
specifying a test on the packet or connection
mark. These tests appear in the TEST column
of shorewall-tcrules (5) and in the MARK
columns of shorewall-accounting (5),
shorewall-masq (5) and shorewall-tos (5). The
bits defined by the default mask are also
retained after a packet is routed when
PROVIDER_OFFSET is non-zero. The remaining
bits are cleared.
The default values of these new options depend on WIDE_TC_MARKS and
HIGH_ROUTE_MARKS as follows:
WIDE_TC_MARKS=No and HIGH_ROUTE_MARKS=No; both the traffic shaping
mark and the provider mark occupy the low-order 8 bits of the mark.
TC_BITS 8
PROVIDER_OFFSET 0
PROVIDER_BITS 8
MASK_BITS 8
WIDE_TC_MARKS=No and HIGH_ROUTE_MARKS=Yes; the traffic shaping
mark occupies the low-order 8 bits of the mark and the provider
mark occupies the next 8 bits.
TC_BITS 8
PROVIDER_OFFSET 8
PROVIDER_BITS 8
MASK_BITS 8
WIDE_TC_MARKS=Yes and HIGH_ROUTE_MARKS=No; the traffic shaping
mark occupies the low-order 14 bits of the mark and the
provider mark occupies the low-order 8 bits.
TC_BITS 14
PROVIDER_OFFSET 0
PROVIDER_BITS 8
MASK_BITS 16
WIDE_TC_MARKS=Yes and HIGH_ROUTE_MARKS=Yes; the traffic shaping
mark occupies the low-order 14 bits of the mark followed by two
unused bits followed by the 8-bit provider mark.
TC_BITS 14
PROVIDER_OFFSET 16
PROVIDER_BITS 8
MASK_BITS 16
These defaults provide behavior that is compatable with the earlier
implementation. They may be overridden by setting the new options
directly.
At verbosity levels 1 and 2, the compiler provides information as
follows (this example is with HIGH_ROUTE_MARKS=Yes and
WIDE_TC_MARKS=Yes and none of the new options set explicitly):
******** Packet/Connection Mark Information ********
TC Mark Values = 1 - 16383 (0x3fff)
Default Mask = /0xffff
Provider Mark Values = 0x10000 - 0xff0000
****************************************************
As shown, the information includes the range of acceptable TC mark
values, the default mask in MARK columns (TEST column in
/etc/shorewall/tcrules) and the range of acceptable provider mark
values. The default mask is determined by the setting of MASK_BITS.
2) The OPTIMIZE option value is now a bit-map with each bit
controlling a separate set of optimizations.
- The low-order bit (value 1) controls optimizations available in
earlier releases.
- The next bit (value 2) suppresses superfluous ACCEPT rules in a
policy chain that implements an ACCEPT policy. Any ACCEPT rules
that immediately preceed the final blanket ACCEPT rule in the
chain are now omitted.
3) Shorewall now combines identical logging chains. Previously, a
separate chain was created for each logging rule.
4) Beginning with Shorewall 4.5.0, accounting can be disabled by
setting ACCOUNTING=No in shorewall.conf. This allows you to keep a
set of accounting rules configured in /etc/shorewall/accounting and
to then enable and disable them by simply toggling the setting of
ACCOUTING.
Similarly, dynamic blacklisting can be disabled by setting
DYNAMIC_BLACKLIST=No. This saves a jump rule in filter chains INPUT
and FORWARD.
5) Shorewall can now automatically assign mark values to providers in
cases where 'track' is specified (or TRACK_PROVIDERS=Yes) but
packet marking is otherwise not used for directing connections to a
particular provider. Simplly specify '-' in the MARK column and
Shorewall will automatically assign a mark value equal to the last
used mark value + 1.
6) It is now possible to enable a simplified traffic shaping
facility by setting TC_ENABLED=Simple in shorewall.conf.
See http://www.shorewall.net/simple_traffic_shaping.html for
details.
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
diff --git a/Shorewall/shorewall b/Shorewall/shorewall index 98cfe0b..584e3e6 100755 --- a/Shorewall/shorewall +++ b/Shorewall/shorewall @@ -1785,6 +1785,7 @@ case "$COMMAND" in get_config [ -n "$debugging" ] && set -x [ $# -eq 1 ] && usage 1 + if shorewall_is_started ; then [ -n "$nolock" ] || mutex_on block $COMMAND Rejected $* [ -n "$nolock" ] || mutex_off
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
