fixed quotes, add CVS Id

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

Shorewall-docs/troubleshoot.xml

@@ -3,6 +3,8 @@
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 <!-- $Id$ -->
 <article id="usefull_links">
+  <!--$Id$-->
+
   <articleinfo>
     <title>Shorewall Troubleshooting Guide</title>
 
@@ -32,9 +34,9 @@
 
   <graphic align="center" fileref="images/obrasinf.gif" />
 
-  <para><emphasis role="bold">&#34;If you think you can you can; if you think
+  <para><emphasis role="bold"><quote>If you think you can you can; if you
-  you can&#39;t you&#39;re right. If you don&#39;t believe that you can, why
+  think you can&#39;t you&#39;re right. If you don&#39;t believe that you can,
-  should someone else?&#34; -- Gunnar Tapper</emphasis> </para>
+  why should someone else?</quote> -- Gunnar Tapper</emphasis></para>
 
   <section>
     <title>First Steps</title>
@@ -59,15 +61,15 @@
   </section>
 
   <section>
-    <title>&#34;shorewall start&#34; and &#34;shorewall restart&#34; Errors</title>
+    <title><quote>shorewall start</quote> and <quote>shorewall restart</quote>
+    Errors</title>
 
     <para>If you receive an error message when starting or restarting the
-    firewall and you can&#39;t determine the cause, then do the following:
+    firewall and you can&#39;t determine the cause, then do the following:</para>
-    </para>
 
     <itemizedlist>
       <listitem>
-        <para>Make a note of the error message that you see. </para>
+        <para>Make a note of the error message that you see.</para>
       </listitem>
 
       <listitem>
@@ -96,8 +98,8 @@
         iptables: No chain/target/match by that name
         Terminated</programlisting>
 
-      <para>A search through the trace for &#34;No chain/target/match by that
+      <para>A search through the trace for <quote>No chain/target/match by
-      name&#34; turned up the following:</para>
+      that name</quote> turned up the following:</para>
 
       <programlisting>        + echo &#39;Adding Common Rules&#39;
         + add_common_rules
@@ -108,10 +110,10 @@
         iptables: No chain/target/match by that name
 </programlisting>
 
-      <para>The command that failed was: &#34;iptables -A reject -p tcp -j
+      <para>The command that failed was: <quote>iptables -A reject -p tcp -j
-      REJECT --reject-with tcp-reset&#34;. In this case, the user had compiled
+      REJECT --reject-with tcp-reset</quote>. In this case, the user had
-      his own kernel and had forgotten to include REJECT target support (see
+      compiled his own kernel and had forgotten to include REJECT target
-      <ulink url="kernel.htm">kernel.htm</ulink>) </para>
+      support (see <ulink url="kernel.htm">kernel.htm</ulink>)</para>
     </example>
   </section>
 
@@ -119,8 +121,7 @@
     <title>Your Network Environment</title>
 
     <para>Many times when people have problems with Shorewall, the problem is
-    actually an ill-conceived network setup. Here are several popular snafus:
+    actually an ill-conceived network setup. Here are several popular snafus:</para>
-    </para>
 
     <itemizedlist>
       <listitem>
@@ -131,12 +132,12 @@
       <listitem>
         <para>Changing the IP address of a local system to be in the external
         subnet, thinking that Shorewall will suddenly believe that the system
-        is in the &#39;net&#39; zone.</para>
+        is in the <quote>net</quote> zone.</para>
       </listitem>
 
       <listitem>
         <para>Multiple interfaces connected to the same HUB or Switch. Given
-        the way that the Linux kernel respond to ARP &#34;who-has&#34;
+        the way that the Linux kernel respond to ARP <quote>who-has</quote>
         requests, this type of setup does NOT work the way that you expect it
         to. If you are running Shorewall version 1.4.7 or later, you can test
         using this kind of configuration if you specify the <emphasis
@@ -159,11 +160,11 @@
 
     <para>I also recommend against setting all of your policies to ACCEPT in
     an effort to make something work. That robs you of one of your best
-    diagnostic tools - the &#34;Shorewall&#34; messages that Netfilter will
+    diagnostic tools - the <quote>Shorewall</quote> messages that Netfilter
-    generate when you try to connect in a way that isn&#39;t permitted by your
+    will generate when you try to connect in a way that isn&#39;t permitted by
-    rule set.</para>
+    your rule set.</para>
 
-    <para>Check your log (&#34;/sbin/shorewall show log&#34;). If you
+    <para>Check your log (<quote>/sbin/shorewall show log</quote>). If you
     don&#39;t see Shorewall messages, then your problem is probably NOT a
     Shorewall problem. If you DO see packet messages, it may be an indication
     that you are missing one or more rules -- see <ulink url="FAQ.htm#faq17">FAQ
@@ -188,9 +189,8 @@
       <itemizedlist>
         <listitem>
           <para>all2all:REJECT - This packet was REJECTed out of the all2all
-          chain -- the packet was rejected under the
+          chain -- the packet was rejected under the <quote>all</quote>-&#62;<quote>all</quote>
-          &#34;all&#34;-&#62;&#34;all&#34; REJECT policy (see <ulink
+          REJECT policy (see <ulink url="FAQ.htm#faq17">FAQ 17</ulink>).</para>
-          url="FAQ.htm#faq17">FAQ 17</ulink>).</para>
         </listitem>
 
         <listitem>
@@ -218,8 +218,8 @@
         </listitem>
       </itemizedlist>
 
-      <para>In this case, 192.168.2.2 was in the &#34;dmz&#34; zone and
+      <para>In this case, 192.168.2.2 was in the <quote>dmz</quote> zone and
-      192.168.1.3 is in the &#34;loc&#34; zone. I was missing the rule:</para>
+      192.168.1.3 is in the <quote>loc</quote> zone. I was missing the rule:</para>
 
       <programlisting>ACCEPT    dmz    loc    udp    53</programlisting>
     </example>
@@ -228,9 +228,9 @@
   <section>
     <title>Ping Problems</title>
 
-    <para> Either can&#39;t ping when you think you should be able to or are
+    <para>Either can&#39;t ping when you think you should be able to or are
     able to ping when you think that you shouldn&#39;t be allowed?
-    Shorewall&#39;s &#39;Ping&#39; Management is <ulink url="ping.html">described
+    Shorewall&#39;s <quote>Ping</quote> Management is <ulink url="ping.html">described
     here</ulink>.</para>
   </section>
 
@@ -240,7 +240,7 @@
     <itemizedlist>
       <listitem>
         <para>Seeing rejected/dropped packets logged out of the INPUT or
-        FORWARD chains? This means that: </para>
+        FORWARD chains? This means that:</para>
 
         <orderedlist>
           <listitem>
@@ -262,12 +262,12 @@
 
       <listitem>
         <para>Remember that Shorewall doesn&#39;t automatically allow ICMP
-        type 8 (&#34;ping&#34;) requests to be sent between zones. If you want
+        type 8 (<quote>ping</quote>) requests to be sent between zones. If you
-        pings to be allowed between zones, you need a rule of the form:</para>
+        want pings to be allowed between zones, you need a rule of the form:</para>
 
         <programlisting>&#x00A0;&#x00A0;&#x00A0; ACCEPT&#x00A0;&#x00A0;&#x00A0; <emphasis>&#60;source zone&#62;</emphasis>&#x00A0;&#x00A0;&#x00A0; <emphasis>&#60;destination zone&#62;</emphasis>&#x00A0;&#x00A0;&#x00A0; icmp&#x00A0;&#x00A0;&#x00A0; echo-request</programlisting>
 
-        <para> The ramifications of this can be subtle. For example, if you
+        <para>The ramifications of this can be subtle. For example, if you
         have the following in <ulink url="NAT.htm">/etc/shorewall/nat</ulink>:</para>
 
         <programlisting>&#x00A0;&#x00A0;&#x00A0; 10.1.1.2&#x00A0;&#x00A0;&#x00A0; eth0&#x00A0;&#x00A0;&#x00A0; 130.252.100.18</programlisting>
@@ -278,7 +278,7 @@
       </listitem>
 
       <listitem>
-        <para>If you specify &#34;routefilter&#34; for an interface, that
+        <para>If you specify <quote>routefilter</quote> for an interface, that
         interface must be up prior to starting the firewall.</para>
       </listitem>
 
@@ -298,21 +298,20 @@
         <para>Some versions of LRP (EigerStein2Beta for example) have a shell
         with broken variable expansion. You can get a corrected shell from the
         <ulink url="ftp://ftp.shorewall.net/pub/shorewall/ash.gz">Shorewall
-        Errata download site</ulink>. </para>
+        Errata download site</ulink>.</para>
       </listitem>
 
       <listitem>
         <para>Do you have your kernel properly configured? <ulink
-        url="kernel.htm">Click here to see my kernel configuration</ulink>.
+        url="kernel.htm">Click here to see my kernel configuration</ulink>.</para>
-        </para>
       </listitem>
 
       <listitem>
-        <para>Shorewall requires the &#34;ip&#34; program. That program is
+        <para>Shorewall requires the <quote>ip</quote> program. That program
-        generally included in the &#34;iproute&#34; package which should be
+        is generally included in the <quote>iproute</quote> package which
-        included with your distribution (though many distributions don&#39;t
+        should be included with your distribution (though many distributions
-        install iproute by default). You may also download the latest source
+        don&#39;t install iproute by default). You may also download the
-        tarball from <ulink url="ftp://ftp.inr.ac.ru/ip-routing">ftp://ftp.inr.ac.ru/ip-routing</ulink>
+        latest source tarball from <ulink url="ftp://ftp.inr.ac.ru/ip-routing">ftp://ftp.inr.ac.ru/ip-routing</ulink>
         .</para>
       </listitem>