From owner-freebsd-alpha Thu Apr 13 18: 9:19 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from malkavian.org (malkavian.org [206.136.132.23]) by hub.freebsd.org (Postfix) with ESMTP id 7B83837BE11 for ; Thu, 13 Apr 2000 18:08:58 -0700 (PDT) (envelope-from rbw@myplace.org) Received: from localhost (rbw@localhost) by malkavian.org (8.9.3/8.9.3) with ESMTP id SAA14106; Thu, 13 Apr 2000 18:08:55 -0700 (MST) (envelope-from rbw@myplace.org) Date: Thu, 13 Apr 2000 18:08:55 -0700 (MST) From: "brian j. peterson" To: Andrew Gallatin Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: ICMP flood causes panic? In-Reply-To: <14582.26816.657967.136182@grasshopper.cs.duke.edu> Message-ID: X-Prime: (2 ^ 6972593) - 1 X-URL: http://rbw.myplace.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 13 Apr 2000, Andrew Gallatin wrote: # brian j. peterson writes: # > amidst an ICMP flood today, my machine panicked. i have included what i # > think is the relevant syslog info below. (the kernel on this box was # > built from a CVSup to FreeBSD/alpha 4.0-CURRENT on or about March # > 4th... world was rebuilt at the same time.) anyone care to tell me where # > the problem lies? (my box, FreeBSD, both, neither?) if more info is # > required, please ask me for it. # > # <...> # > Apr 13 16:16:21 nikita /kernel: mces = 0x1 # > Apr 13 16:16:21 nikita /kernel: vector = 0x660 # > Apr 13 16:16:21 nikita /kernel: param = 0xfffffc0000006000 # > Apr 13 16:16:21 nikita /kernel: pc = 0xfffffc0000383278 # > Apr 13 16:16:21 nikita /kernel: ra = 0xfffffc00005075d4 # > Apr 13 16:16:21 nikita /kernel: curproc = 0 # > Apr 13 16:16:21 nikita /kernel: # > Apr 13 16:16:21 nikita /kernel: panic: machine check # > Apr 13 16:16:21 nikita /kernel: # > Apr 13 16:16:21 nikita /kernel: syncing disks... ncr0:0: ERROR (20:0) (0-20-0) (8/13) @ (script 918:18000120). # # There's really not a whole lot of information to go on here. It might # help if you were able to map the above pc and ra to functions in the # kernel. If you have a kernel with symbols (kernel.debug from config # -g), try gdb on the kernel, then do # # (gdb) l *0xfffffc0000383278 # (gdb) l *0xfffffc00005075d4 i didn't use config -g when i made the kernel... i guess maybe i should have. does it cause a performance hit to do this? # If you don't have a debug kernel, map the addresses to functions via # nm -n. rbw@nikita:~[26]18:02% nm -n /kernel | grep fffffc00003832 fffffc0000383240 T procrunnable fffffc0000383280 T chooseproc rbw@nikita:~[27]18:03% nm -n /kernel | grep fffffc00005075 fffffc0000507504 T longjmp fffffc000050754c t longjmp_botch fffffc0000507568 T savectx fffffc000050756c t Lsavectx1 fffffc00005075a8 T idle fffffc00005075ac t Lidle1 fffffc00005075cc t Lidle2 fffffc00005075f0 T cpu_switch (i hope that is the output you were looking for.) # BTW, Can you reproduce this? er... i don't really want to reproduce getting flooded by some random jerk from irc. =P seriously though, the answer is "i don't know"... i've been the victim of this sort of attack serveral times and all it has ever dones it lag my connection. (i'm kind of a neophyte, but it looks like a bunch of spoofed ICMP traffic in tcpdump... nothing i can combat without the help of my upstream.) thanks for your time, brian p.s. - i still have the /usr/src/sys/compile/NIKITA2 directory and the /usr/src/sys/alpha/conf/NIKITA2 kernel config file untouched from when i built the kernel... i suppose i could build the kernel with config -g if it would help. -- --===-----=======-----------=============-----------------=================== | rbw aka bjp | god's final message to his creation: | | rbw@myplace.org | we apologize for the inconvenience. | ===================-----------------=============-----------=======-----===-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message