Update news for 3.0.9 -- take 2

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4664 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb

web/News.htm

@@ -28,7 +28,9 @@ Documentation License</a></span>”.<br>
 <span style="font-weight: bold;">2006-10-6 Shorewall 3.0.9<br>
 </span><span style="font-weight: bold;"></span>
 <pre>Problems corrected in 3.0.9<br><br>1)  When using a light-weight shell like ash or dash, "shorewall<br>    [re]start" fails when using the built-in traffic shaper. The error<br>    messages resemble these:<br><br>    local: 3: eth0:: bad variable name<br>    ERROR: Command "tc class add dev eth0 parent 1: classid 1:1 htb rate 800kbit mtu" Failed<br><br>2)  The output formating of the 'hits' command under BusyBox 1.2.0 has<br>    been corrected.<br><br>3)  In prior versions, setting 'mss=' in /etc/shorewall/zones did not<br>    affect traffic to/from the firewall zone. That has been corrected.<br><br>4)  Previously, using IP address ranges in the accounting file could<br>    cause non-fatal iptables errors during shorewall [re]start.<br><br>Other changes in 3.0.9<br><br>1)  It is now possible to use the special value 'detect' in the ADDRESS<br>    column of /etc/shorewall/masq. This allows you to specify SNAT (as<br>    opposed to MASQUERADE) without having to know the ip address of the<br>    external interface. Shorewall must be restarted each time that the<br>    external address (the address of the interface named in the<br>    INTERFACE column) changes.<br><br>2)  Experimental optimization for PPP devices has been added to the<br>    providers file. If you omit the GATEWAY column for a ppp device (or<br>    enter "-" in the column) then Shorewall will generate routes<br>    for the named INTERFACE that do not specify a gateway IP address<br>    (the peer address will be assumed).<br><br>3)  Normally, Shorewall tries to protect users from themselves by<br>    preventing PREROUTING and OUTPUT tcrules from being applied to<br>    packets that have been marked by the 'track' option in<br>    /etc/shorewall/providers.<br><br>    If you really know what you are doing and understand packet marking<br>    thoroughly, you can set TC_EXPERT=Yes in shorewall.conf and<br>    Shorewall will not include these cautionary checks.<br><br>4)  Previously, CLASSIFY tcrules were always processed out of the<br>    POSTROUTING chain. Beginning with this release, they are processed<br>    out of the POSTROUTING chain *except* when the SOURCE is<br>    $FW[:&lt;address&gt;] in which case the rule is processed out of the<br>    OUTPUT chain.<br></pre>
-<span style="font-weight: bold;">2006-09-27 Shorewall 3.2.4<br>
+<span style="font-weight: bold;"></span>
+<hr style="width: 100%; height: 2px;"><span style="font-weight: bold;">2006-09-27
+Shorewall 3.2.4<br>
 </span><span style="font-weight: bold;"></span>
 <pre>Shorewall Problems corrected in 3.2.4<br><br>1)  Previously, the directory name in the command "shorewall start<br>    &lt;directory name&gt;" was being dropped by "/sbin/shorewall".<br><br>2)  Previous, when /usr/share/shorewall/xmodules had been copied to<br>    /etc/shorewall/modules, Shorewall was not looking in the correct<br>    directory for the "xt_..." modules. There are two parts to the fix:<br><br>    - The /usr/share/shorewall/xmodules file has been removed. The<br>      /usr/share/shorewall/modules file will now load all required<br>      modules regardless of which kernel version you are running.<br>    - The MODULESDIR option can now contain a colon-separated list of<br>      directories to search for modules with the default being:<br><br>      /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter:/lib/modules/$(uname -r)/kernel/net/netfilter<br><br>3)  Rules in /etc/shorewall/tos which specify zones defined<br>    using entries in /etc/shorewall/hosts applied to all traffic<br>    to/from the zone interfaces (the bridge port, ipset or IP<br>    address(es) in the zone definition were ignored).<br><br>4)  Previously, 'shorewall-lite dump' did not report traffic shaping<br>    information even if TC_ENABLED was set to Yes or Internal in the<br>    shorewall.conf file used to compile the exported firewall script.<br><br>    To correct this problem, the firewall script must be recompiled and<br>    re-exported.<br><br>5)  Previously, errors during the compile phase were not reflected in<br>    the exit status of /sbin/shorewall. Thanks to Tuomo Soini for<br>    finding and correcting this problem.<br><br>Other Shorewall changes in 3.2.4<br><br>1)  Previously, scripts compiled for export (-e option) depended on<br>    /usr/share/shorewall-lite/functions in order to run correctly. This<br>    made it possible for a compiled script to be incompatible with the<br>    version of Shorewall Lite installed on a firewall system.<br><br>    Beginning with Shorewall 3.2.4, this dependency is removed such<br>    that version incompatibility between Shorewall and Shorewall Lite<br>    should not be a concern going forward.<br><br>2)  Two new macros have been added, courtesy of Tuomo Soini<br><br>        macro.Finger<br>        macro.Telnets<br><br>3)  The output of "shorewall show macros" has been enhanced to show<br>    macros in each directory in the CONFIG_PATH.<br><br>Shorewall Lite problems corrected in 3.2.4<br><br>1)  Previous, when /usr/share/shorewall-lite/xmodules had been copied to<br>    /etc/shorewall-lite/modules, Shorewall was not looking in the correct<br>    directory for the "xt_..." modules. There are two parts to the fix:<br><br>    - The /usr/share/shorewall-lite/xmodules file has been removed. The<br>      /usr/share/shorewall-lite/modules file will now load all required<br>      modules regardless of which kernel version you are running.<br>    - The MODULESDIR option can now contain a colon-separated list of<br>      directories to search for modules with the default being:<br><br>      /lib/modules/$(uname<br>      -r)/kernel/net/ipv4/netfilter:/lib/modules/$(uname<br>      -r)/kernel/net/netfilter<br><br>     /usr/share/shorewall-lite/modules contains a *lot* of modules. If<br>     you use module autoloading (which non-embedded Linux distributions<br>     do), then you can improve your "shorewall [re]start" time by<br>     trimming all but the helper modules from the file. To do that,<br>     create the file /etc/shorewall-lite/modules with the following<br>     entries:<br><br>        loadmodule ip_conntrack_amanda<br>        loadmodule ip_conntrack_ftp<br>        loadmodule ip_conntrack_irc<br>        loadmodule ip_conntrack_netbios_ns<br>        loadmodule ip_conntrack_pptp<br>        loadmodule ip_conntrack_tftp<br>        loadmodule ip_nat_amanda<br>        loadmodule ip_nat_ftp<br>        loadmodule ip_nat_irc<br>        loadmodule ip_nat_pptp<br>        loadmodule ip_nat_snmp_basic<br>        loadmodule ip_nat_tftp<br><br>Other Shorewall Lite changes in 3.2.4<br><br>None.<br></pre>
 <span style="font-weight: bold;"></span>