-- Start of PGP signed section.
> The ipfw(8) man page explicitly states that rule actions:
> 
> * allow | accept | pass | permit
> * deny | drop
> * divert
> * reset | reset6
> * unreach | unreach6
> * abort | abort6
> 
> cause "search terminat[ion]".
> 
> 
> The description for "queue," however, is:
> 
>      queue queue_nr
>              Pass packet to a dummynet ``queue'' (for bandwidth limitation
>              using WF2Q+).
> 
> 
> In particular, there is no statement that "The search terminates" (as
> there is for the above-cited rule actions).
> 
> My (admittedly quick) reading of the code suggests that for the "queue"
> rule action, the search does, in fact, terminate.  This also seems to be
> borne out by empirical evidence (now that I have a "queue" rule in my
> active set of rules on my laptop):
> 
> ...
> 04300  1086    92998 skipto 60000 udp from 192.168.23.119 to any dst-port 53 
> keep-state :default
> 04400     0        0 deny log udp from any to any dst-port 123 iplen 0-75
> 04500   155    11780 skipto 60000 udp from 192.168.23.119 to any dst-port 123 
> keep-state :default
> 04600     0        0 skipto 60000 udp from any 123 to 255.255.255.255 
> dst-port 123 keep-state :default
> 04700     0        0 skipto 60000 udp from 192.168.23.119 to any keep-state 
> :default
> 04800     0        0 deny log ip from any to any
> 60000 35471 18109017 allow ip from any to any in
> 60100 32582  5110013 queue 1 ip from any to any out
> 65535     1      340 deny ip from any to any
> 
> 
> So:
> * Is my reading of the code -- that "queue" (also) casues the search to
>   terminate) correct?
> 
> * If so, is a change to the ipfw(8) page (to state that explicitly)
>   warranted?  (As someone who was recently trying to figure some of this
>   stuff out, I believe that such a statement -- if it is true! -- would
>   have been helpful for me.)

I believe that the behavior of a queue is that of a pipe, and the
"termination" condition is dependent on net.inet.ip.fw.one_pass.

You are correct though the manual page does not document this for
a queue.  At least any place I could find.


-- 
Rod Grimes                                                 rgri...@freebsd.org
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Reply via email to