Re: interpreting pfctl -s info
On Tue, Dec 24, 2002 at 04:21:05PM -0500, Michael Lucas wrote: > I'm not certain how to interpret the output of some pfctl -s entries. > > State Table Total Rate > current entries5 > searches 6300427.7/s > inserts 17250.0/s > removals17200.0/s > > "Current entries" is obvious, but what are "searches", "inserts," and > "removals"? They refer to state table entries. "searches" is incremented whenever a state table lookup is done, which happens whenever a packet passes an interface (twice for each forwarded packet). "inserts" and "removals" are incremented when a state table entry is created and destroyed, respectively. The difference between the two totals should equal the number of current state table entries (unless you reset them while leaving state entries intact, etc.), and the two rates tend to get equal over time, and approximate the number of newly established connection per second. > Counters > match 25040.0/s > bad-offset 00.0/s > fragment 00.0/s > short 00.0/s > normalize 00.0/s > memory 00.0/s > > The counters bad-offset, fragment, and short appear to be that sort of > packet. I would guess that "normalize" is the number of packets > normalized by scrub. It's the number of packets dropped by normalization. The packets that were passed after normalization are not counted there. > That leaves me wondering what "match" and "memory" mean. "match" is incremented whenever a packet causes a ruleset evaluation and a last matching rule is found. It's mainly useful in comparison with the evaluation counters of individual rules (pfctl -vsr), or when comparing the match rate vs. the state searches rate. "memory" counts the number of packets dropped due to memory allocation failures. If the memory pool limits set with 'set limit states/frags' are reached, further packets/fragments that would require memory allocation will be dropped. With high enough limits, this counter shouldn't get very high. If it does, the limits should probably be increased. Daniel
interpreting pfctl -s info
Hello, I've dug through the man pages and Google, but some of these things don't seem to be documented. After spending some quality time with cscope and google, I'm giving up and just groveling for help here. I'm not certain how to interpret the output of some pfctl -s entries. State Table Total Rate current entries5 searches 6300427.7/s inserts 17250.0/s removals17200.0/s "Current entries" is obvious, but what are "searches", "inserts," and "removals"? Counters match 25040.0/s bad-offset 00.0/s fragment 00.0/s short 00.0/s normalize 00.0/s memory 00.0/s The counters bad-offset, fragment, and short appear to be that sort of packet. I would guess that "normalize" is the number of packets normalized by scrub. That leaves me wondering what "match" and "memory" mean. Any help would be appreciated. Merry Christmas, all! ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.AbsoluteBSD.com/
Re: panics when using reply-to
On Tuesday, December 24, 2002, at 11:27 AM, Daniel Hartmeier wrote:
On Tue, Dec 24, 2002 at 10:02:50AM -0600, Joe Nall wrote:
I took the reply-to out of pf.conf and disabled the cable modem and
the
box is fine.
Can you post the significant reply-to to rule here? If it's using
address pools (round-robin), I hope Ryan can take a look...
No address pools. Criticism welcome.
dhcp_if="dc0" # roadrunner cable modem dhcp
static_if="rl0" # dsl 16 static IPs
internal_if="rl1"
ext_if="{ dc0, rl0 }"
internal_net="192.168.20.1/24"
tcp_svcs="{ ssh, http, https, smtp, auth }"
udp_svcs="{ domain }"
bad_ip="{
127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
0.0.0.0/8,
169.254.0.0/16, 192.0.2.0/24, 204.152.64.0/23, 224.0.0.0/3,
255.255.255.255/32
}"
set block-policy return
set optimization conservative
scrub in all fragment reassemble
scrub out all no-df max-mss 1452
nat on $dhcp_if from $internal_net to any -> $dhcp_if
nat on $static_if from $internal_net to any -> $static_if
block quick inet6 all label "block inet6"
block in log quick on $ext_if inet from $bad_ip to any label "bad IPs"
block in quick on $ext_if proto igmp all label "drop igmp"
block in log all label "default block"
pass in on $dhcp_if reply-to $dhcp_if inet proto tcp from any to
($dhcp_if) port 22 keep state
pass out on $dhcp_if proto { tcp, udp } all keep state
pass in on $static_if reply-to $static_if inet proto tcp from any to
$static_if port $tcp_svcs keep state
pass in on $static_if reply-to $static_if inet proto udp from any to
$static_if port $udp_svcs keep state
pass out on $static_if proto { tcp, udp } all keep state
pass in on $internal_if all
pass out on $internal_if all
pass in on $static_if reply-to $static_if inet proto icmp all
icmp-type echoreq keep state
pass out inet proto icmp all icmp-type echoreq keep state
antispoof for rl0 inet
antispoof for rl1 inet
antispoof for dc0 inet
Re: pfctl: DIOCADDRULE: Device busy
On Tue, Dec 24, 2002 at 09:13:20AM -0500, Michael Lucas wrote: > I can reload the whole rules file, just not the rules section alone. > > Any suggestions? It's obviously a bug, probably related to ticket (lock) handling, I'll try to find it. Thanks for the report. Daniel
Re: panics when using reply-to
On Tue, Dec 24, 2002 at 10:02:50AM -0600, Joe Nall wrote: > I took the reply-to out of pf.conf and disabled the cable modem and the > box is fine. Can you post the significant reply-to to rule here? If it's using address pools (round-robin), I hope Ryan can take a look... Daniel
panics when using reply-to
I built a new machine on 12/22/02 from a -current snapshot and updated
it
from source checked out on 12/22 and then 12/23. The goal was to use
the new
reply-to functionality to simultaneously connect to a cable modem
(default route)
and dsl (static IP with mail/web) with packets going out the correct
interface.
Here are two tracebacks and a dmesg. Kernel is GENERIC + makeoptions
DEBUG=-ggdb
I'm confused that the pf_test arguments in the traceback don't match my
memory
of the ddb screen - which had for the last argument (m0) of
the second
call to pf_test in all cases.
I took the reply-to out of pf.conf and disabled the cable modem and the
box is fine.
(gdb) where
#0 0x1000 in ?? ()
#1 0xd02f899c in boot (howto=2308) at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../arch/i386/i386/
machdep.c:1665
#2 0xd019c673 in db_boot_crash_cmd (addr=-803680277, haddr=0,
count=-1, modif=0xe28c627c "")
at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../ddb/db_command.c:600
#3 0xd019c1b4 in db_command (last_cmdp=0xd04eb558,
cmd_table=0xd04eb398)
at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../ddb/db_command.c:257
#4 0xd019c4b3 in db_command_loop () at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../ddb/db_command.c:503
#5 0xd019f6ae in db_trap (type=6, code=0) at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../ddb/db_trap.c:85
#6 0xd02f37cd in kdb_trap (type=6, code=0, regs=0xe28c640c)
at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../arch/i386/i386/
db_interface.c:117
#7 0xd0301988 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi =
2586064, tf_esi = 2, tf_ebp = -494115700,
tf_ebx = -504936432, tf_edx = -494115716, tf_ecx = -793169776,
tf_eax = 48, tf_trapno = 6, tf_err = 0,
tf_eip = -803680277, tf_cs = 80, tf_eflags = 65606, tf_esp =
-504936432, tf_ss = 2, tf_vm86_es = -494114988,
tf_vm86_ds = -803664357, tf_vm86_fs = -494265536, tf_vm86_gs =
20})
at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../arch/i386/i386/
trap.c:257
#8 0xd0100dc5 in alltraps ()
#9 0xd018dbca in pf_test (dir=2, ifp=0x2775d0, m0=0xe28c6754)
at /usr/src/sys/arch/i386/compile/GENERIC/../../../../net/pf.c:4236
#10 0xd018cfaa in pf_route (m=0xe28c6a70, r=0xe28ba96c, dir=2,
oifp=0xd0a65440, s=0xd0b93090)
at /usr/src/sys/arch/i386/compile/GENERIC/../../../../net/pf.c:3854
#11 0xd018dbca in pf_test (dir=2, ifp=0xd0a65440, m0=0xe28c6a70)
at /usr/src/sys/arch/i386/compile/GENERIC/../../../../net/pf.c:4236
#12 0xd023cb77 in ip_output (m0=0xd0b6c000)
at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../netinet/
ip_output.c:673
#13 0xd02439ed in tcp_output (tp=0xd0b9a15c)
at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../netinet/
tcp_output.c:1110
#14 0xd0241713 in tcp_input (m=0xd0b6c000)
at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../netinet/
tcp_input.c:2264
#15 0xd023a823 in ipv4_input (m=0xd0b6c000)
at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../netinet/
ip_input.c:685
#16 0xd023a125 in ipintr () at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../netinet/
ip_input.c:284
#17 0xd0101de8 in Xsoftnet ()
(gdb)
(gdb) where
#0 0x1000 in ?? ()
#1 0xd02f89d8 in boot (howto=2308) at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../arch/i386/i386/
machdep.c:1665
#2 0xd019c6af in db_boot_crash_cmd (addr=-803680277, haddr=0,
count=-1, modif=0xe28b42e0 "")
at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../ddb/db_command.c:600
#3 0xd019c1f0 in db_command (last_cmdp=0xd04eb558,
cmd_table=0xd04eb398)
at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../ddb/db_command.c:257
#4 0xd019c4ef in db_command_loop () at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../ddb/db_command.c:503
#5 0xd019f6ea in db_trap (type=6, code=0) at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../ddb/db_trap.c:85
#6 0xd02f3809 in kdb_trap (type=6, code=0, regs=0xe28b4470)
at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../arch/i386/i386/
db_interface.c:117
#7 0xd03019c4 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 4,
tf_esi = 2, tf_ebp = -494189328,
tf_ebx = -793366460, tf_edx = -494124548, tf_ecx = -793313280,
tf_eax = 84, tf_trapno = 6, tf_err = 0,
tf_eip = -803680277, tf_cs = 8, tf_eflags = 65606, tf_esp =
-793366460, tf_ss = 2, tf_vm86_es = -494188616,
tf_vm86_ds = 0, tf_vm86_fs = 0, tf_vm86_gs = 20})
at
/usr/src/sys/arch/i386/compile/GENERIC/../../../../arch/i386/i386/
trap.c:257
#8 0xd0100dc5 in alltraps ()
#9 0xd018dbca in pf_test (dir=2, ifp=0x4, m0=0xe28b47b8)
at /usr/src/sys/arch/i386/compile/GENERIC/../../../../net/pf.c:4236
#10 0xd018cfaa in pf_route (m=0xe28b4ad4, r=0xe28c41fc, dir=2,
oifp=0xd0a6c034, s=0xd0b7)
at /usr/src/sys/arch/i386/compile/GENERIC/../../../../net/pf.c:3854
#11 0xd018dbca in pf_test (dir=2, ifp=0xd0a6c034, m0=0xe28b4ad4)
at /usr/src/sys/arch/i
pfctl: DIOCADDRULE: Device busy
Hello, Updated once in the morning yesterday, and once in the afternoon after getting this error. # pfctl -R -f pf.conf pfctl: DIOCADDRULE: Device busy # I can reload the whole rules file, just not the rules section alone. Any suggestions? ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.AbsoluteBSD.com/
