Update News for 3.4.2

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

web/News.htm

@@ -24,7 +24,11 @@ Documentation License</a></span>”.<br>
 </p>
 <hr style="width: 100%; height: 2px;">
 <p></p>
-<!-- Shorewall Release 3.0.5 --> <span style="font-weight: bold;">2007-03-15
+<!-- Shorewall Release 3.0.5 --> <span style="font-weight: bold;">2007.04-01
+Shorewall 3.4.2<br>
+</span><span style="font-weight: bold;"></span>
+<pre>Problems corrected in Shorewall 3.4.2<br><br>1)  The /usr/share/shorewall[-lite]/modules file has been updated for<br>    kernel 2.6.20.<br><br>2)  The /proc/net/ip_conntrack pseudo-file has been inexplicably<br>    renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli<br>    library has been updated to look for both files.<br><br>3)  Shoreall 3.4 was not consistent with respect to its treatment of<br>    log level 'none' and 'none!' and built-in actions. In particular,<br>    specifying 'none' with the Limit action produced a run-time error.<br>    Shorewall now correctly suppresses generation of log messages when<br>    a log level of 'none' or 'none!' is given to a built-in action.<br><br>4)  Tunnels of type 'ipsecnat' would sometimes fail to work because of<br>    a missing rule.<br></pre>
+<span style="font-weight: bold;">2007-03-15
 Shorewall 3.4.1<br>
 </span><span style="font-weight: bold;"></span>
 <pre>Problems Corrected in 3.4.1<br><br>1)  The "shorewall-[lite] [re]start and stop" commands reset the<br>    proxy_arp flag on all interfaces on the system making it impossible<br>    to control proxy arp manually with Shorewall installed. There was a<br>     partial fix included in 3.4.0; unfortunately, it did not correct the<br>    problem completely. Shorewall 3.4.1 includes the rest of the change <br>    necessarey to only clear proxy arp if there were entries in<br>    /etc/shorewall/proxyarp the last time that Shorewall was<br>    [re]started.<br><br>2)  If the log-prefix in a log message exceeded 29 characters, <br>    'shorewall restart' fails with 'truncate: command not found' and a<br>    possible segmentation fault in iptables.<br><br>3)  Log messages specifying a log tag had two spaces appended to the<br>    log prefix. This could cause mysterious "log-prefix truncated"<br>    messages. <br><br>4)  When nested zones were defined in the /etc/shorewall/zones file and<br>    IMPLICIT_CONTINUE=Yes was given in /etc/shorewall/shorewall.conf,<br>    shell error messages ( usually '&lt;zone&gt;: not found' ) during<br>    compilation resulted.<br><br>5)  Use of CONTINUE policies lead to startup errors with a message<br>    such as the following:<br><br>       Applying Policies...<br>       iptables v1.3.7: Couldn't load target<br>       `CONTINUE':/usr/local/lib/iptables/libipt_CONTINUE.so: cannot open<br>       shared object file: No such file or directory<br><br>       Try `iptables -h' or 'iptables --help' for more information.<br>       <br>          ERROR: Command "/sbin/iptables -A net2c148 -j CONTINUE"<br>          Failed<br><br>6)  If there were hosts defined as 'critical' in<br>    /etc/shorewall/routestopped then problems occured in two cases:<br><br>    i) On a Shorewall Lite system when 'shorewall stop' or 'shorewall<br>    clear' was issued.<br><br>    ii) On Shorewall or Shorewall lite system when 'start' or 'restart'<br>    failed during execution of the compiled script and there was no saved<br>    configuration ('shorewall[-lite] save' has not been issued).<br><br>    The symptoms were that the following shell messages were issued and<br>    the 'critical' hosts were not enabled:<br><br>      /var/lib/shorewall/.start: line nnn: source_ip_range: command not found<br>      /var/lib/shorewall/.start: line nnm: dest_ip_range: command not found<br><br>Other changes in 3.4.1<br><br>1)  Several changes are included which allow testing of experimental<br>    versions of Shorewall on systems with 3.4.1 and later 3.4 releases<br>    installed. Among these changes is the detection and reporting of<br>    "Address Type Match" which may be used in future 3.4 releases.<br>    These changes have no effect on normal Shorewall operation. </pre>