From avn@any.ru  Wed May 23 06:25:07 2001
Return-Path: <avn@any.ru>
Received: from ajax2.sovam.com (ajax2.sovam.com [194.67.1.173])
	by hub.freebsd.org (Postfix) with ESMTP id 38C7237B43E
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 23 May 2001 06:25:07 -0700 (PDT)
	(envelope-from avn@any.ru)
Received: from ts9-a253.dial.sovam.com ([195.239.70.253]:1570 "EHLO srv2.any"
	ident: "TIMEDOUT" whoson: "-unregistered-" smtp-auth: <none> TLS-CIPHER:
	"EDH-RSA-DES-CBC3-SHA keybits 192/192 version TLSv1/SSLv3" TLS-PEER:
	<none>) by ajax2.sovam.com with ESMTP id <S1228710AbREWNYt>;
	Wed, 23 May 2001 17:24:49 +0400
Received: (from avn@localhost)
	by srv2.any (8.11.3/8.11.3) id f4NDPZv22014;
	Wed, 23 May 2001 17:25:35 +0400 (MSD)
	(envelope-from avn)
Message-Id: <200105231325.f4NDPZv22014@srv2.any>
Date: Wed, 23 May 2001 17:25:35 +0400 (MSD)
From: avn@any.ru
Reply-To: avn@any.ru
To: FreeBSD-gnats-submit@freebsd.org
Subject: ipfw(8) manpage does not clearly state check-state rule behavior
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         27572
>Category:       docs
>Synopsis:       ipfw(8) manpage does not clearly state check-state rule behavior
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    yar
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          update
>Submitter-Id:   current-users
>Arrival-Date:   Wed May 23 06:30:03 PDT 2001
>Closed-Date:    Wed Jan 2 12:26:20 PST 2002
>Last-Modified:  Wed Jan 02 12:30:04 PST 2002
>Originator:     Alexey V. Neyman
>Release:        FreeBSD 4.3-STABLE i386
>Organization:
http://www.any.ru/
>Environment:
System: FreeBSD srv2.any 4.3-STABLE FreeBSD 4.3-STABLE #2: Thu May 17 19:01:42 MSD 2001 toor@srv2.any:/usr2/obj/usr2/src/sys/SRV2 i386

>Description:
	manpage for ipfw(8) deiscribes behavior of check-state rule as
	'if packet matches, the search terminates'. It should clearly state
	that in case of match the parent rule action will be taken to this
	packet.

>How-To-Repeat:
	it is a doc-update request
>Fix:
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-doc->luigi 
Responsible-Changed-By: ru 
Responsible-Changed-When: Wed May 23 06:34:02 PDT 2001 
Responsible-Changed-Why:  
Let Luigi handle this. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27572 

From: Ruslan Ermilov <ru@FreeBSD.org>
To: "Alexey V. Neyman" <avn@any.ru>
Cc: luigi@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: docs/27572: ipfw(8) manpage does not clearly state check-state rule behavior
Date: Thu, 24 May 2001 10:25:41 +0300

 On Thu, May 24, 2001 at 11:17:06AM +0400, Alexey V. Neyman wrote:
 > Please check the following patch against ipfw.8
 > 
 > Ruslan, as an -mdoc policemeister, could you check if I broke
 > some laws? :)
 > 
 Yes, you introduced what we call "hard sentence breaks".
 Each new sentence should start from the new line.
 
 > Luigi, as far as I remember (correct me if I'm wrong), 'divert' rule does
 > not terminate the search but reinject altered packet from the next rule
 > number - so I updated 'the search terminates' string there.
 > 
 This is totally wrong.  `divert' rule terminates the search, and "diverts"
 the packet to the specified port, with some "glue" supplied to the application
 so that if, and only if, the application writes the (possibly modified) packet
 back to the "divert" socket with the same "glue" data (as specified in the
 divert(4) manpage), it is passed again to the ipfw starting with the rule
 whose number is greater that the "glue" data.  That's the way natd(8) works.
 
 > Also it seems to me that ipfirewall(4) is more than seriously outdated :=\
 > It does not match ip_fw.h in many places. It says that 'tee' is
 > unimplemented. Ruslan, Luigi, I'm not that good in -mdoc, if I try to
 > sync it up in plain text and send it for review - will you do the rest?
 > 
 Yes.
 
 > --- /usr/src/sbin/ipfw/ipfw.8	Thu May  3 15:46:00 2001
 > +++ ipfw.8	Thu May 24 11:13:43 2001
 > @@ -345,9 +345,10 @@
 >  The search continues with the next rule.
 >  .It Cm check-state
 >  Checks the packet against the dynamic ruleset.
 > -If a match is found then the search terminates, otherwise
 > -we move to the next rule.
 > -If no
 > +If a match is found then the search terminates and the action
 > +is inherited from appropriate static
 > +.Cm keep-state
 > +rule, otherwise we move to the next rule. If no
                                            ^^ This is the hard break.
 
 For me, "if the match is found" phrase implies the action is taken
 from the matched (dynamic) rule.
 
 >  .Cm check-state
 >  rule is found, the dynamic ruleset is checked at the first
 >  .Cm keep-state
 > @@ -357,7 +358,8 @@
 >  .Xr divert 4
 >  socket bound to port
 >  .Ar port .
 > -The search terminates.
 > +Diverted packet is reinjected into firewall from the next rule number
 > +(not to the next rule if there are several with the same number).
 > 
 As I said, this is technically wrong.
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Oracle Developer/DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age

From: "Alexey V. Neyman" <avn@any.ru>
To: Ruslan Ermilov <ru@FreeBSD.org>
Cc: <luigi@FreeBSD.org>, <bug-followup@FreeBSD.org>
Subject: Re: docs/27572: ipfw(8) manpage does not clearly state check-state
 rule behavior
Date: Thu, 24 May 2001 12:11:49 +0400 (MSD)

 On Thu, 24 May 2001, Ruslan Ermilov wrote:
 >On Thu, May 24, 2001 at 11:17:06AM +0400, Alexey V. Neyman wrote:
 >> Please check the following patch against ipfw.8
 >>
 >> Ruslan, as an -mdoc policemeister, could you check if I broke
 >> some laws? :)
 >Yes, you introduced what we call "hard sentence breaks".
 >Each new sentence should start from the new line.
 
 Corrected patch below.
 
 >This is totally wrong.  `divert' rule terminates the search, and "diverts"
 >the packet to the specified port, with some "glue" supplied to the application
 >so that if, and only if, the application writes the (possibly modified) packet
 >back to the "divert" socket with the same "glue" data (as specified in the
 >divert(4) manpage), it is passed again to the ipfw starting with the rule
 >whose number is greater that the "glue" data.  That's the way natd(8) works.
 
 Well, let people sink in depths of divert(4) :)
 
 Regards,
 Alexey.
 
 --- /usr/src/sbin/ipfw/ipfw.8	Thu May  3 15:46:00 2001
 +++ ipfw.8	Thu May 24 12:04:43 2001
 @@ -345,8 +345,10 @@
  The search continues with the next rule.
  .It Cm check-state
  Checks the packet against the dynamic ruleset.
 -If a match is found then the search terminates, otherwise
 -we move to the next rule.
 +If a match is found then the search terminates and the action
 +is inherited from appropriate static
 +.Cm keep-state
 +rule, otherwise we move to the next rule.
  If no
  .Cm check-state
  rule is found, the dynamic ruleset is checked at the first
 
State-Changed-From-To: open->closed 
State-Changed-By: yar 
State-Changed-When: Wed Jan 2 12:26:20 PST 2002 
State-Changed-Why:  
The proposed patch doesn't add any clarity. 
Dynamic rules are rather sophisticated, so a user 
should refer to the EXAMPLES section to understand them. 


Responsible-Changed-From-To: luigi->yar 
Responsible-Changed-By: yar 
Responsible-Changed-When: Wed Jan 2 12:26:20 PST 2002 
Responsible-Changed-Why:  
Luigi authorized me to take care of users' suggestions 
to the ipfw(8) page. 
. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27572 
>Unformatted:
