Re: My Inheritance: Solaris 9, ipfilter 3.4.29 x 3 systems, crashes

[Sergio Rabellino]

I had some trouble like yours, filtering out ICMP solved temporarily the kernel crash, but upgrading to the latest ipf, it's the best choice for a long term solution. Now i'm running ipf on many (>10) hosts without any problem, but i've the 4.x version. Also sunscreen is not an alternative to ipf, as the philosophy is very different between these two products. Ipf can be used as a "local firewall system" much like "ZoneAlarm", sunscreen is designed to be run on a separate system, doing firewall job. The rules on ipf are more hard to understand if compared to the simplicity of sunscreen, but sunscreen - as i know - is not supported anymore; yes, it's stable, it's the only bridge-level firewall for free, but the java applet interface is very old. Hope this help. Rugen, Len ha scritto: I inherited a group of Solaris systems.  They have been having some problems since before I was assimilated that I think I’ve tracked down to ipfilter.    The problem first described was the Veritas Vxsvc process would become unresponsive and unkillable until reboot.  I finally discovered that this didn’t happen until ipf rules were changed.  The prior technique was ipfboot stop and ipfboot start.  I changed this to ipfboot reload and it is much better.  Before it died every time, if not immediately, after a few days, now it has just failed once after many changes.   However, earlier this week I used reload to change a filter list on another system and it crashed.  (Messages at the end).  I sent this to Sun and of course they said “ipf, go away”.    My DBA’s will not upgrade to Solaris 10.  (Systems run Oracle & PeopleSoft).  I’ve tried SunScreen on a test and a development system.  It’s “supported”, but seems to be unstable on a low use system, I think it would be as bad or worse on the overloaded systems.    It looks like ipf was downloaded and installed as a precompiled package.  Any suggestions / opinions on upgrading ipfilter on these systems?  I’m currently reviewing the rules and to me, they are UGLY.  Could cleaner rules help?  They have very few KEEP STATE, maybe 500 entries and no grouping.  From ipfstat, particularly for the pass out rules, few if any have count other than 0.    Thanks for any suggestions or job offers….    Len Rugen     unix: [ID 836849 kern.notice] ^Mpanic[cpu15]/thread=3012e8703a0: unix: [ID 799565 kern.notice] BAD TRAP: type=34 rp=2a104def1b0 addr=2004000000001 mmu_fsr=0 unix: [ID 100000 kern.notice] unix: [ID 839527 kern.notice] ipf: unix: [ID 123557 kern.notice] alignment error: unix: [ID 381800 kern.notice] addr=0x2004000000001 unix: [ID 101969 kern.notice] pid=1332, pc=0x78a6c144, sp=0x2a104deea51, tstate=0x80001604, context=0x10ce unix: [ID 743441 kern.notice] g1-g7: 14b9c00, 15fcdb1, 0, 0, ffffffffc0047241, 0, 3012e8703a0 unix: [ID 100000 kern.notice] genunix: [ID 723222 kern.notice] 000002a104deeed0 unix:die+a4 (34, 2a104def1b0, 2004000000001, 0, 61, 53) genunix: [ID 179002 kern.notice]   %l0-3: 0000000000000000 ffffffffc0047241 0000000000000003 0000000000000000   %l4-7: 0000000000000034 0000000000000000 0000000000000000 0000000000000000 genunix: [ID 723222 kern.notice] 000002a104deefb0 unix:trap+5dc (2a104def1b0, 0, 10000, 10200, 20040, 53) genunix: [ID 179002 kern.notice]   %l0-3: 0000000001007374 000000000080000b 0000033eda78d490 0000000000000034   %l4-7: 000003013f0ee3c8 0000000000000053 0000000000000000 0000000000000000 genunix: [ID 723222 kern.notice] 000002a104def100 unix:ktl0+48 (0, 0, 0, 0, 2a104def310, ffffffff7f731e88) genunix: [ID 179002 kern.notice]   %l0-3: 0000000000000005 0000000000001400 0000000080001604 000000000102edf4   %l4-7: ffffffff7ecbc524 ffffffff7ecbc020 0000000000000000 000002a104def1b0 genunix: [ID 723222 kern.notice] 000002a104def250 ipf:fr_delgroup+24 (0, 0, 2a104def5b0, 3002bc40430, 707574, 707269) genunix: [ID 179002 kern.notice]   %l0-3: 0002004000000001 000003000006e1d8 000003000006e198 000000007f6f7473   %l4-7: 0000000070757400 0000000000000000 000000007efefeff 0000000081010100 genunix: [ID 723222 kern.notice] 000002a104def330 ipf:frflushlist+64 (0, 0, 2a104def5b0, 3006681c598, ffffffff7f60efe4, 0) genunix: [ID 179002 kern.notice]   %l0-3: 000003002bc40428 000003006681c598 000003012d462428 000003000006e1b0   %l4-7: 000003000006e1d8 00000401cb219400 ffffffff7ffff8bc ffffffff7eb022fc genunix: [ID 723222 kern.notice] 000002a104def410 ipf:frflushlist+64 (0, 0, 2a104def5b0, 78a8c670, f0, 0) genunix: [ID 179002 kern.notice]   %l0-3: 000003006681c590 0000000078a8c670 0000000000000000 000002a104def5b0   %l4-7: ffffffff7f730948 ffffffff7ffff8bc 0000000000000000 0000000000000000 genunix: [ID 723222 kern.notice] 000002a104def4f0 ipf:frflush+f4 (0, 200c, 4, 0, c, 0) genunix: [ID 179002 kern.notice]   %l0-3: 0000000078a8c670 0000000000000000 000002a104def5b0 000003012e8703a0   %l4-7: 0000000080100280 0000000001000000 0000000000000000 0000000000000000 genunix: [ID 723222 kern.notice] 000002a104def5c0 ipf:iplioctl+490 (ea00000000, ffffffffc0047241, ffffffff7ffffb24, 202003, 3664837cca0, 2a104defaec) genunix: [ID 179002 kern.notice]   %l0-3: 0000000000000000 ffffffffc0047241 0000000000000003 ffffffffc0047241   %l4-7: 0000033eda78d490 0000000000000078 ffffffff7f500698 00000000800035ac genunix: [ID 723222 kern.notice] 000002a104def9a0 genunix:ioctl+1f8 (3, ffffffffc0047241, ffffffff7ffffb24, 61, 61, 53) genunix: [ID 179002 kern.notice]   %l0-3: 000000000118e5c8 ffffffffc0047241 0000000000000003 0000000000000000   %l4-7: 0000030123b68850 0000000000000000 0000000000000000 0000000000000000 unix: [ID 100000 kern.notice] -- Ing. Sergio Rabellino Università degli Studi di Torino Dipartimento di Informatica ICT Services Director C.so Svizzera 185, 10149 - Torino