Re: (ASCEND) GRF filter to block Smurf attacks

To: RG <rg1@icanect.net>
Subject: Re: (ASCEND) GRF filter to block Smurf attacks
From: Jason Ackley <jason@viaccess.net>
Date: Sat, 26 Sep 1998 20:21:03 -0400 (AST)
cc: "Neil J. McRae" <neil@DOMINO.ORG>, devin@premier1.net, ascend-users@bungi.com, undrgrid@undergrid.net
In-Reply-To: <Pine.BSI.3.95.980926185235.10077E-100000@foo.icanect.net>
Sender: owner-ascend-users@max.bungi.com

On Sat, 26 Sep 1998, RG wrote:

> I got this binary from the gpeterson@ascend who I was working with....that
> would cause the card to core dump if it was panic'ing and then
> reset....loading the binary...and it never reset again...go figure.....ran

Maybe off topic, maybe not, you decide..

I was at a place one time where we had a SGI Challenge XL doing something
similar, we would run the profiler to collect info to see why it was
reseting one of the interface cards, and it would never happen. When we
would not run the profiling to get the stats, it would hang. 

Turned out to be some kind of a interrupt  driver problem, that the
profiler would reset / cycle when running. To fix the 'hang' all we had to
do is press a key on the console (and generate an interrupt). So all we
did was leave the profiler running (having 16 processors , we didnt notice
much of a CPU drain). 

Just a thought..Maybe some Ascend GRF hacker will want think about it /
investigate.

cheers,

--
Jason Ackley

++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>

References:

Re: (ASCEND) GRF filter to block Smurf attacks

From: RG <rg1@icanect.net>

Prev by Date: Re: (ASCEND) "Ascend-Maximum-Call-Duration" Not working - Re-Post
Next by Date: Re: (ASCEND) Radius Makefile Problem
Prev by thread: Re: (ASCEND) GRF filter to block Smurf attacks
Next by thread: RE: (ASCEND) GRF filter to block Smurf attacks
Index(es):
- Main
- Thread