Re: bridge
> This looks very weird, almost as if the snapshots were not properly > built. Can you fetch the -current source for sys/net/pfvar.h and > usr.sbin/tcpdump, then I just tried this (snap is mid-january). There did appear to be a problem (incorrect tcpdump?) dropping a freshly compiled (-stable) tcpdump on the box fixed the problem. -kj
Re: bridge
> ok, it was a real bug. the snapshots are fine ;-) > > and here's the fix... Man. I need some coffee, or something.. I just verified that my previously posted workaround fixed on a -stable machine (which already worked). Grr. Three days of digging into ipsec has me seeing double. Your diff is correct, henning. -kj
Re: bridge
On Tue, Jan 28, 2003 at 04:46:35PM -0500, jolan wrote:
> On Tue, Jan 28, 2003 at 10:37:30PM +0100, Henning Brauer wrote:
> > thx for the verification, I'll have a look.
>
> fwiw, i'm seeing this too.. now that i'm looking for it :)
ok, it was a real bug. the snapshots are fine ;-)
and here's the fix...
Index: print-pflog.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-pflog.c,v
retrieving revision 1.11
diff -u -r1.11 print-pflog.c
--- print-pflog.c 1 Jan 2003 16:55:16 - 1.11
+++ print-pflog.c 28 Jan 2003 22:41:37 -
@@ -91,7 +91,7 @@
printf("rule %d/%s: ",
(short)ntohs(hdr->rnr), reason);
- switch (hdr->action) {
+ switch (ntohs(hdr->action)) {
case PF_SCRUB:
printf("scrub");
break;
Re: bridge
On Tue, Jan 28, 2003 at 04:46:35PM -0500, jolan wrote: > On Tue, Jan 28, 2003 at 10:37:30PM +0100, Henning Brauer wrote: > > thx for the verification, I'll have a look. > > fwiw, i'm seeing this too.. now that i'm looking for it :) This looks very weird, almost as if the snapshots were not properly built. Can you fetch the -current source for sys/net/pfvar.h and usr.sbin/tcpdump, then cp /usr/src/sys/net/pfvar.h /usr/include/net/ cd /usr/src/usr.sbin/tcpdump/ rm -rf obj/* rm -rf obj make obj make make install And then try to repeat the behavior? If all sources are completely updated to -current, and the entire system is rebuilt, there's no way tcpdump could still be built from an outdated pfvar.h. Yet that's what would explain the messages you quoted. You're not running old pcap files through a new tcpdump, right? The binary format for pflog entries has slightly changed... Daniel
Re: bridge
On Tue, Jan 28, 2003 at 10:37:30PM +0100, Henning Brauer wrote: > thx for the verification, I'll have a look. fwiw, i'm seeing this too.. now that i'm looking for it :) - jolan
Re: bridge
On Tue, Jan 28, 2003 at 04:23:39PM -0500, Jason Houx wrote: > I just installed the latest snapshot and see the same in tcpdump on > pflog0. To recap it says pass on the rules when they get passed but it > doesn't say block. This is really trivial but i figured i would post it > to see if i am just the only one seeing this. thx for the verification, I'll have a look. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie) msg01090/pgp0.pgp Description: PGP signature
Re: bridge
I just installed the latest snapshot and see the same in tcpdump on pflog0. To recap it says pass on the rules when they get passed but it doesn't say block. This is really trivial but i figured i would post it to see if i am just the only one seeing this. This is a pf bridge: OpenBSD 3.2-current (GENERIC) #98: Tue Jan 28 11:36:44 MST 2003 21:02:16.393370 rule 89/0(match): pass out on de0: 10.0.1.250.26970 > 209.143.0.10.53: [udp sum ok] 44372+ PTR? 36.50.255.216.in-addr.arpa. (44) (ttl 64, id 58306) 21:02:21.400190 rule 89/0(match): pass out on de0: 10.0.1.250.30296 > 209.143.0.10.53: [udp sum ok] 44372+ PTR? 36.50.255.216.in-addr.arpa. (44) (ttl 64, id 65479) 21:02:22.168831 rule 89/0(match): pass out on de0: 10.0.1.250.37613 > 209.143.0.10.53: [udp sum ok] 47066+ A? lithium-gw.bright.net. (39) (ttl 64, id 47248) 21:03:31.051637 rule 6/0(match): in on de0: 216.255.50.35 > 10.0.1.250: icmp: echo request (id:16186 seq:1) (DF) (ttl 64, id 0) 21:04:44.288719 rule 1/0(match): in on dc0: 216.255.50.35 > 216.201.43.114: icmp: echo request (id:16224 seq:1) (DF) (ttl 63, id 0, bad cksum 0!) 21:04:45.288688 rule 1/0(match): in on dc0: 216.255.50.35 > 216.201.43.114: icmp: echo request (id:16224 seq:2) (DF) (ttl 63, id 0, bad cksum 0!) 21:04:46.293043 rule 1/0(match): in on dc0: 216.255.50.35 > 216.201.43.114: icmp: echo request (id:16224 seq:3) (DF) (ttl 63, id 0, bad cksum 0!) 21:04:50.823618 rule 1/0(match): in on dc0: 216.255.50.35 > 216.201.43.114: icmp: echo request (id:16226 seq:1) (DF) (ttl 63, id 0, bad cksum 0!) @1 block drop in log on dc0 all label "block in on ext-Bridge0:default deny" @6 block drop in log on de0 all label "block all traffic to man_if: default deny" @89 pass out on de0 inet proto tcp all modulate state label "permit the man_if to make tcp connections out" thanks, Jason
Re: [Q} firewall machine nmbclusters,nkmempages
On Tue, Jan 28, 2003 at 07:51:55AM -0500, Jung wrote: > $ netstat -m > 35581 mbufs in use: > 577 mbufs allocated to data > 35002 mbufs allocated to packet headers > 2 mbufs allocated to socket names and addresses > 576/1222 mapped pages in use > 11348 Kbytes allocated to network (88% in use) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines that looks very wrong... 35k mbufs for packet headers??? can you monitor that? e. g., running "( date; netstat -m; echo ) >> /var/log/netstat" every 10 minutes from cron, and send me & daniel this file when it crashed again? -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
[Q} firewall machine nmbclusters,nkmempages
today my firewall kernel panic /bsd: panic: malloc: out of space in kmem_map anyone know about number of optimize NMBCLUSTERS,NKMEMPAGES for my firewall ? machine have a physical 512MB memory. and kernel config below option NMBCLUSTERS=16384 option NKMEMPAGES=32768 maxusers64 # estimated number of users i tested a real traffic pf states in my network over 30,000 (very busy firewall normal times) now not network busy time. (defail information. vmstat, netstat after kernel panic 10 hours) $ vmstat -m Memory statistics by bucket size Size In Use Free Requests HighWater Couldfree 1635398186 1939931280 0 32 255 1409 12639 640345 64 906310 23931 320 0 128 226734 43084 160 3216 256 345231 12344 80 86 512 722 6809 40 0 1024 178 10 501891 20 0 2048 15 11 75 10 9 4096 34 4451 5 0 81928 44407 5364 163845 0 8 5 0 327683 0 13 5 0 Memory usage type by bucket size Size Type(s) 16 devbuf, pcb, routetbl, ifaddr, sysctl, namecache, UFS mount, proc, in_multi, exec, xform_data, VM swap, UVM amap, UVM aobj, USB, packet tags, temp 32 devbuf, pcb, routetbl, ifaddr, vnodes, undefined, LFS segment, ether_multi, xform_data, VM swap, UVM amap, USB, temp 64 devbuf, pcb, routetbl, ifaddr, namecache, UFS mount, shm, undefined, lockf, LFS segment, in_multi, exec, pfkey data, UVM amap, USB, NDP 128 devbuf, routetbl, ifaddr, vnodes, UFS mount, shm, ttys, inodedep, UVM amap, USB, USB device, NDP 256 devbuf, pcb, routetbl, ifaddr, sysctl, ioctlops, vnodes, UFS mount, VM map, proc, NFS srvsock, NFS daemon, ttys, newblk, UVM amap, USB 512 devbuf, pcb, ifaddr, ioctlops, mount, UFS mount, UVM amap, USB device 1024 devbuf, sysctl, namei, ioctlops, UFS mount, proc, ttys, exec, pagedep, UVM amap, UVM aobj, crypto data 2048 devbuf, UFS mount, VM swap, UVM amap 4096 devbuf, UFS mount, MSDOSFS mount, UVM amap, temp 8192 devbuf, NFS node, namecache, UFS quota, UFS mount, ISOFS mount, inodedep, indirdep, UVM amap 16384 devbuf, namecache, UFS mount, UVM amap 32768 devbuf Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) devbuf 1628 649K713K 78644K 16960 0 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768 pcb20 4K 5K 78644K 5780 0 16,32,64,256,512 routetbl 21326K100K 78644K251600 0 16,32,64,128,256 ifaddr 13224K 24K 78644K 1360 0 16,32,64,128,256,512 sysctl 3 2K 2K 78644K30 0 16,256,1024 namei 0 0K 5K 78644K 5013310 0 1024 ioctlops 0 0K 1K 78644K 3060 0 256,512,1024 mount 7 4K 4K 78644K90 0 512 NFS node 1 8K 8K 78644K10 0 8192 vnodes60 8K 44K 78644K 12470 0 32,128,256 namecache 525K 25K 78644K50 0 16,64,8192,16384 UFS quota 1 8K 8K 78644K10 0 8192 UFS mount2978K 78K 78644K 290 0 16,64,128,256,512,1024,2048,4096,8192,16384 shm 2 1K 1K 78644K20 0 64,128 VM map 4 1K 1K 78644K40 0 256 undefined 2 1K 1K 78644K20 0 32,64 lockf 1 1K 1K 78644K 410 0 64 proc 5 3K 3K 78644K 340 0 16,256,1024 LFS segment 0 0K 2K 78644K 53390 0 32,64 NFS srvsock 2 1K 1K 78644K20 0 256 NFS daemon 1 1K 1K 78644K10 0 256 in_multi36 2K 2K 78644K 360 0 16,64 ether_multi10 1K 1K 78644K 100 0 32 ISOFS mount 1 8K 8K 78644K10 0 8192 MSDOSFS mount 1 4K 4K 78644K10 0 4096 ttys 324 189K189K 78644K 3240 0 128,256,1024 exec 0 0K 2K 78644K 9570 0 16,64,1024 pfkey data 1 1K 1K 78644K20 0 64 xform_data 0 0K 1K 78644K 140 0
