[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    RE: Solaris 2.5.1 w/ SUNisdn still panics gleefully
From:       "Nathan D. Bowen" <nbowen () 3i ! net>
Date:       1997-11-25 19:22:42
[Download RAW message or body]

On Tue, 25 Nov 1997, Nathan D. Bowen wrote:

> I should note that there are some other peculiarities to the situation as a
> result of using the SUNisdn and ifppp as our external interface. The more I
> examine this problem, I feel that it would not be happening if we were
> simply using two ethernet interfaces that were constantly present.
> 
> However, the isdn interface is not even present much of the time, because
> ISDN rates are a bit prohibitive in this area. The interface gets plumbed in
> the morning and unplumbed at night, and while it is plumbed it
> dials-on-demand. It seems reasonable that these frequent changes in the
> state of the interface would cause some extra stresses on ipfilter. 

I _think_ I've found the problem. When I walked into the office today, I
noticed that when isppp starts up (and thereby creates the ifppp0
interface), I log two messages from ipfilter:

Nov 25 07:24:22 solarflare unix: IP Filter: detaching [ifppp0]
Nov 25 07:24:22 solarflare unix: IP Filter: attach to [ifppp0,0]

...which led me to believe that ipfilter wasn't detaching when isppp was
killed. This turned out to be true, and the script that kills isppp now
unplumbs and downs the interface first, at which point IP Filter detaches
from ifppp0, and _then_ kills isppp (which _does_ unplumb and down the
interface, but apparently does not give ipfilter a chance to detach). Now,
ipfilter detaches when the isdn and ppp services are stopped, and logs only
one message - an attachment - when the isdn and ppp services are started.

Since one of the catalysts that seemed to cause panics in the past was at
the point of starting or stopping isppp, I stress-tested by starting and
stopping ispppd a good 15 times in succession without a single panic. A
similar test last night (before the change to the script) panicked on the
third try, so at least my barbaric tests look better. Now, I'll see if it
lasts all week (knock on wood).

Anyway, I thought this might be helpful if anyone else is experiencing
panics with a demand-dialed interface... Check when IP Filter does its
detaching and attaching..

--
-Nathan "Single-digit Uptime" Bowen                      nbowen@3i.net


[prev in list] [next in list] [prev in thread] [next in thread]