On Sun, 12 Apr 2009, Darren Reed wrote:
> I was afraid you were going to ask that. I deleted those core dumps.
> Let's see, it's now 2am on Easter Sunday -- it shouldn't be too
> disruptive
> to cause another crash: add UDP port rules ... swap in firewall rules
> .. resolve apache log file to generate DNS traffic, bingo! core dump.
That sounds too easily repeatable... are you saying that some specific
rules and/or course of action could make it happen?
If you mean if there is a direct cause and effect, probably not.
It took a few minutes of DNS resolving before it crashed, and even then,
it may have crashed without my help. I notice that one of the arguments
to fr_derefrule is an IP address, and for this particular dump, it did
not correspond to the resolving client but some other client.
So other than the observation that I made that adding UDP port filtering
rule will cause a crash eventually, that about as specific as I can be.
These are the rules I swapped in replacing a blanket UDP pass rule.
Group 120 are inbound UDP packets.
# Pass in traffic to my DNS resolving cache / content server
pass in quick from $local_net to to $my_ip1 port = 53 keep state group
120
pass in quick from any to $my_ip2 port = 53 keep state group 120
# Squelch noisy services
block return-icmp-as-dest(port-unr) in quick from $local_net to any port 136
>< 139 group 120
block return-icmp-as-dest(port-unr) in quick from $local_net to any
port = 427 group 120
block return-icmp-as-dest(port-unr) in quick from any to
255.255.255.255/32 port = 67 group 120
# ... falls through to block and log rule
> # adb -k unix.0 vmcore.0
> physmem 3df9f
> adb: warning: dump is from SunOS 5.9 Generic_122300-31; dcmds and
> macros may not match kernel implementation
> 0x118b8a8/i
> bcopy+0x4b8: ld [%i0], %i4
>
> Does that help? (I'm keeping the core files this time in case you ask
> something else).
And stack trace output from $C?
$C
000002a1006a9fc1 bcopy+0x4b8(300035cc4ec, 2a1006aaa5e, 30, 89522465,
ffffffffffffffe8, 30)
000002a1006aa181 ce_wput+0x264(30001e25818, 3000502dd40, 0,
30001015510, 22, 30)
000002a1006aa291 putnext+0x21c(0, 3000502dd40, 2, 30001e1ded8, 14,
2a1006aaae0)
000002a1006aa341 pfilmodwput+0x40(300010d12f0, 30001e1ded8, 20, 0,
7d9e2f2, fffe)
000002a1006aa401 putnext+0x21c(0, 3000502dd40, 0, 8000000, 800,
ba9617670800)
000002a1006aa4b1 ip_wput_frag+0xb30(e, 0, 10000, 300010d1060,
30004c74740, 300038e2a58)
000002a1006aa611 ip_wput_ire+0x16ac(10000, 300000742b0, 3, ffff,
89522441, 300099a9440)
000002a1006aa801 ip_wput_pktoptions+0x56c(30003752910, 0, 89522465,
3000368c4d8, 0, 0)
000002a1006aa8d1 ip_wput+0x78(300032233c0, 300099a9440, 20, 8, 0, 0)
000002a1006aa991 putnext+0x21c(0, 30001199f40, 20, 0, 3, 10)
000002a1006aaa41 udp_wput+0x6bc(30001fae428, ffff, 3b, 3000368c4ec, 0,
10)
000002a1006aab21 putnext+0x21c(0, 30004c74740, 20, 300099a9440, 0, 10)
000002a1006aabd1 strput+0x270(30003221c20, 0, 0, 2a1006ab698, 0, 0)
000002a1006aadc1 kstrputmsg+0x36c(30002ccd740, 30003223650, 0, 0, 0, 0)
000002a1006aaea1 sosend_dgram+0x25c(0, 300039beef8, 10, 2a1006aba00, 8,
1c)
000002a1006aaf91 sosendmsg+0x3f4(0, 300039beef8, 7, 20, 0, 0)
000002a1006ab051 sendit+0x15c(2a1006aba00, 8, 30002ccd740, 8, 0, 0)
000002a1006ab121 sendto+0x78(3, 69ed8, 33, 0, ffbffcb0, 10)
000002a1006ab241 sendto32+0x3c(3, 69ed8, 33, 0, ffbffcb0, 10)
000002a1006ab2f1 syscall_trap32+0xa8(3, 69ed8, 33, 0, ffbffcb0, 10)
Joseph Tam <[email protected]>
