Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Apr 2020 10:02:50 +0000 (UTC)
From:      Alex Dupre <ale@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r54041 - head/en_US.ISO8859-1/books/handbook/firewalls
Message-ID:  <202004071002.037A2oVL005017@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: ale
Date: Tue Apr  7 10:02:50 2020
New Revision: 54041
URL: https://svnweb.freebsd.org/changeset/doc/54041

Log:
  Fix typo in IPFW page and s/reassamble/reassemble/g
  
  PR:		245396
  Submitted by:	wout@canodus.be

Modified:
  head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml

Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml	Mon Apr  6 17:10:38 2020	(r54040)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml	Tue Apr  7 10:02:50 2020	(r54041)
@@ -2256,18 +2256,18 @@ ipfw -q nat 1 config if &dollar;pif same_ports unreg_o
       <para>The inbound <acronym>NAT</acronym> rule is inserted
 	<emphasis>after</emphasis> the two rules which allow all
 	traffic on the trusted and loopback interfaces and after the
-	reassamble rule but <emphasis>before</emphasis> the
+	reassemble rule but <emphasis>before</emphasis> the
 	<literal>check-state</literal> rule.  It is important that the
 	rule number selected for this <acronym>NAT</acronym> rule, in
 	this example <literal>100</literal>, is higher than the first
 	three rules and lower than the <literal>check-state</literal>
 	rule.  Furthermore, because of the behavior of in-kernel
-	<acronym>NAT</acronym> it is advised to place a reassamble
+	<acronym>NAT</acronym> it is advised to place a reassemble
 	rule just before the first <acronym>NAT</acronym> rule and
 	after the rules that allow traffic on trusted interface.
 	Normally, <acronym>IP</acronym> fragmentation should not
 	happen, but when dealing with <acronym>IPSEC/ESP/GRE</acronym>
-	tunneling traffic it might and the reassmabling of fragments
+	tunneling traffic it might and the reassembling of fragments
 	is necessary before handing the complete packet over to the
 	in-kernel <acronym>NAT</acronym> facility.</para>
 
@@ -2275,7 +2275,7 @@ ipfw -q nat 1 config if &dollar;pif same_ports unreg_o
 	<para>The reassemble rule was not needed with userland
 	  &man.natd.8; because the internal workings of the
 	  <application>IPFW</application> <literal>divert</literal>
-	  action already takes care of reassambling packets before
+	  action already takes care of reassembling packets before
 	  delivery to the socket as also stated in &man.ipfw.8;.</para>
 
 	<para>The <acronym>NAT</acronym> instance and rule number used
@@ -2287,7 +2287,7 @@ ipfw -q nat 1 config if &dollar;pif same_ports unreg_o
 
       <programlisting>&dollar;cmd 005 allow all from any to any via xl0  # exclude LAN traffic
 &dollar;cmd 010 allow all from any to any via lo0  # exclude loopback traffic
-&dollar;cmd 099 reass all from any to any in       # reassamble inbound packets
+&dollar;cmd 099 reass all from any to any in       # reassemble inbound packets
 &dollar;cmd 100 nat 1 ip from any to any in via &dollar;pif # NAT any inbound packets
 # Allow the packet through if it has an existing entry in the dynamic rules table
 &dollar;cmd 101 check-state</programlisting>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202004071002.037A2oVL005017>