>I've run Ipfilter 3.x on Solaris 8 and S9 boxes for several years, and >now Ipfilter 4.x on S10 boxes. Systems occasionally panic; most often >in my opinion from bad hardware. However, Sun's first reaction when >they look at the traceback from the crash dump is to blame ipfilter; >ipfilter always shows up near the top of the traceback because it is >loaded into the kernel and active. So they point the finger there. >I've usually been able to convince them that it was bad hardware due >to other evidence, eg parity errors, lom output, etc. If ipfilter really >does cause a panic or hang, it is usually obvious. The system dies right >after ipfilter is loaded and there is discussion about the issue on the >ipfilter list. Sun need not get involved...
If the system dies with ipfilter in the stack trace, it's ipfilter which is to blame; blaming it on bad hardware is ludicrous. If it's in the stack, its code is directly or indirectly involved in the panic. Even if it is "always active", the amount of time spend in ipfilter code is but a small percentage of total system time. Statistically speaking, random panics would then not happen with ipfilter on the stack or they would happen in any of the other scores of kernel threads. >But are you uncomfortable with your Sun hanging out there in the >breeze, waiting to be poked by every hacker on the planet? I sure >am. I need the protection of ipfilter more than I need management's >blessing. I can get away with this attitude due to the local politics >and the fact that IPfilter has been rock solid for many years. If >ipfilter-using machines fell over all the time I would scrap it. Ipfilter has caused its share of panics on my systems but is generaly stable once you have a configuration which works. While I understand that you require the protection of ipfilter, what is it that you need from the bleeding edge version not offered in Solaris 10? Casper
