berny@tndsyd.oz.au (Berny Goodheart) (03/10/91)
I am interested in finding out known ways to make your version of UNIX crash. If you know of a particular application, program bug or programming algorithm that will guarantee to cause your UNIX Operating system to crash I would like to hear about it. Tell me as much info as possible i.e., what the machine is and what version of the OS it is, how does the problem manifest itself, etc. I am particularly interested in generic bugs. .===========================================================================. | ACSnet: berny@tndsyd.oz UUCP: uunet!munnari.oz!tndsyd.oz.au!berny | | INTERNET: berny@tndsyd.oz.au DOMAIN: goodheart_berny@tandem.com | | PSMAIL: smtpgate @comm(berny@tndsyd.oz@munnari.oz.au) | TANDEM Computers Incorporated 76 Berry St, North Sydney, NSW, 2060, Australia
gill@boris.mscs.mu.edu (VAXDEATH (Ender) Gill) (03/11/91)
In article <690@tndsyd.oz.au> berny@tndsyd.oz.au (Berny Goodheart) writes: > >I am interested in finding out known ways to make your version of UNIX >crash. If you know of a particular application, program bug or programming main() { fork (); main (); } This brought the system crashing to a halt, before they set up a quota for process. The system was a SysV 3.0, on 3B5. Also, running two copies of Franz Lisp simultaneously would cause the system to crash. This bug has since been fixed. cheers -dicky gill (Violator) -gill@boris.mscs.mu.edu
mike (03/11/91)
In an article, tndsyd.oz.au!berny (Berny Goodheart) writes: >I am interested in finding out known ways to make your version of UNIX >crash. main() { int fd; long now; time(&now); if ( (fd = open("/dev/kmem",O_RDWR)) == -1 ) return(1); while ( write(fd,&now,sizeof(long)) == sizeof(long) ) ; close(fd); return(0); } -- Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- Remember folks: If you can't flame MS-DOS, then what _can_ you flame?
sow@cad.luth.se (Sven-Ove Westberg) (03/12/91)
In article <690@tndsyd.oz.au> berny@tndsyd.oz.au (Berny Goodheart) writes: | My favorite on SunOS 4.0x is df /dev/*b (the swap partition) It did not crash but the computer hangs forever. Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden.
brendan@cs.widener.edu (Brendan Kehoe) (03/12/91)
In <513@bria>, uunet!bria!mike writes: >In an article, tndsyd.oz.au!berny (Berny Goodheart) writes: >>I am interested in finding out known ways to make your version of UNIX >>crash. > if ( (fd = open("/dev/kmem",O_RDWR)) == -1 ) If your sysadmin (much less the vendor itself) left /dev/kmem world WRITABLE, they're begging for this kind of thing. Readable, possibly; writable, c'mon. -- Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu Widener University in Chester, PA A Bloody Sun-Dec War Zone
scs@iti.org (Steve Simmons) (03/13/91)
In an article, tndsyd.oz.au!berny (Berny Goodheart) writes: >I am interested in finding out known ways to make your version of UNIX >crash. In article <513@bria> Michaoe Stefanik replies: >main() >{ >int fd; >long now; > time(&now); > if ( (fd = open("/dev/kmem",O_RDWR)) == -1 ) > return(1); > while ( write(fd,&now,sizeof(long)) == sizeof(long) ) > ; > close(fd); > return(0); >} Too verbose. On a Sun, try 'b etc/dump' at the '>' prompt. Do I need a smiley? -- "Our informal mission is to improve the love life of operators worldwide." Peter Behrendt, president of Exabyte. Quoted in Digital Review, Feb 4, 1991.
ag@amix.commodore.com (Keith "Cheese Whiz" Gabryelski) (03/13/91)
In article <513@bria> uunet!bria!mike writes: >In an article, tndsyd.oz.au!berny (Berny Goodheart) writes: >>I am interested in finding out known ways to make your version of >>UNIX crash. > >[Code to scribble on /dev/kmem--deleted] Sheeeeiiittt. Just `reading' from /dev/kmem can hose your system if you have write-only registers mapped into kernel address space. Try: ``cat /dev/kmem >/dev/null''. Pax, Keith -- Too many people take too many risks. Too many people I see get dis'd. Keith Gabryelski Advanced Products Group ag@amix.commodore.com ...!cbmvax!amix!ag
ronnie@mindcraft.com (Ronnie Kon) (03/13/91)
May I suggest that posting ways of crashing machines may not be the best of
ideas?
Ronnie
-------------------------------------------------------------------------------
Ronnie B. Kon |
kon@groundfog.stanford.edu | "I like that everyone becomes food."
...!{decwrl,ames}!mindcrf!ronnie | -- Hobbes
-------------------------------------------------------------------------------tar@math.ksu.edu (Tim Ramsey) (03/13/91)
[ diverging a bit, so I added alt.folklore.computers to the Newsgroups: and Followup-To: ] In article <513@bria>: >In an article, tndsyd.oz.au!berny (Berny Goodheart) writes: >>I am interested in finding out known ways to make your version of UNIX >>crash. > time(&now); > if ( (fd = open("/dev/kmem",O_RDWR)) == -1 ) > return(1); > while ( write(fd,&now,sizeof(long)) == sizeof(long) ) > ; A couple of years ago in an extreme fit of boredom, on an unused ATT 3B2/400 running SysV 3.1, I did the following: hack# yes > /dev/kmem (where yes just writes a stream of "y\n" to stdout) Nothing happened. I let it run for a couple of minutes with no apparent effect. Perhaps the writes weren't moving the seek pointer in kmem, so it wasn't writing over anything interesting. I wasn't energetic enough to find out. All in all, it didn't help my boredom. :) -- Tim Ramsey (tar@math.ksu.edu) (913) 532-6750 (voice) (913) 532-7004 (FAX) Department of Mathematics, Kansas State University, Manhattan KS 66506-2602
tar@math.ksu.edu (Tim Ramsey) (03/13/91)
brendan@cs.widener.edu (Brendan Kehoe) writes: [ ... ] > If your sysadmin (much less the vendor itself) left /dev/kmem world > WRITABLE, they're begging for this kind of thing. Readable, possibly; > writable, c'mon. A readable kmem is still a bit no no. Somewhere around here I have small program that lets you peek at what someone is typing by watching tty clists. It will let you crash the system; it just takes a little longer (you have to wait for someone to type in the root password so you can su and cat /bin/emacs to /dev/null :) -- Tim Ramsey (tar@math.ksu.edu) (913) 532-6750 (voice) (913) 532-7004 (FAX) Department of Mathematics, Kansas State University, Manhattan KS 66506-2602
jc@raven.bu.edu (James Cameron) (03/13/91)
>>>>> On 12 Mar 91 23:45:37 GMT, ronnie@mindcraft.com (Ronnie Kon) said:
RK> May I suggest that posting ways of crashing machines may not be the best of
RK> ideas?
RK> Ronnie
I would like to second the suggestion. Why would anyone really want
to know HOW to crash it, unless they WANTED to crash it? Now,
if someone said "the code crashes the system; why?" that would be
fair. (IMHO)
JC
--
James Cameron - jc@raven.bu.edu
Signal Processing and Interpretation Lab, ECS Engineering Dept.
Boston University, Boston MA
Work: 617 353-2879
Information Technology
Boston University, Boston MA
work: 617 353-2780 ext. 338
"But to risk we must, because the greatest hazard in life
is to risk nothing. For the man or woman who risks nothing, has
nothing, does nothing, is nothing."
(A quote from the eulogy for the late Christa McAuliffe.)jmason@gpu.utcs.utoronto.ca (Jamie Mason) (03/13/91)
In article <589@spool.mu.edu> gill@boris.mscs.mu.edu (VAXDEATH (Ender) Gill) writes: > >main() >{ > fork (); > main (); >} > >This brought the system crashing to a halt, before they set up a quota >for process. The system was a SysV 3.0, on 3B5. Isn't C syntax fun? main() { while (1) fork(); } These only destroy the machine if you do not have a per-user process limit. If you do, you just bring YOURSELF to a grinding halt. > Also, running two copies of Franz Lisp simultaneously would cause >the system to crash. This bug has since been fixed. Well we have PCL (Commoin Lisp) at our faciltiy. No bug, but each process apparently allocates itself FIVE MEGABYTES of memory. When the Lisp class has an assignment due... Well guess what it does to the memory swapper?!? It does not CRASH the system, but drives it into the dirt. Might I suggest a nicer way to abuse your Unix? This works even if there is a per-user process limit... #define BIGNUM 128*1024*1024 #define PAGESIZE 4*1024 char eatmem[BIGNUM]; main() { for (i=0 ; i += PAGESIZE ; i < BIGNUM) ++eatmem[i]; } Define BIGNUM to be a REAL large amount of memory that your system will allow you to have in your DATASIZE limit. Alternately, you could MALLOC the memory instead of making it static, subject to your MEMORYUSE limit. Define PAGESIZE to be the size of the memory page the swapper pages in on your system. Now comes the fun part: foo.bar% cc thrash.c foo.bar% a.out This cute little program will allocate a HUGE amount of memory, then read it in a way which makes the swapper do a page-in for *EVERY ACCESS*!! This slows the system down to a *TOTAL* crawl... Almost a crash. Of course you could write a program which simply malloc()s 512k, then another 512k, and another... (Assuming you do not have per-usre limits on 'memoryuse') Until you run out of swap space... PANIC: out of swap space <CRASH!> Kids, *DO NOT TRY THIS AT HOME*!! Seriously, a cute little program can do *REAL* nasty things to your favourite UNIX box... Don't do in on any machine on which you plan on keeping your account :-) Jamie ... "Who was that Masked Interrupt?" Written On Wednesday, March 13, 1991 at 12:23:27am EST
rodney@tyrell.gtc.de (Rodney Volz) (03/15/91)
In article <1991Mar12.132003.27383@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: > >In <513@bria>, uunet!bria!mike writes: >> >> if ( (fd = open("/dev/kmem",O_RDWR)) == -1 ) > > If your sysadmin (much less the vendor itself) left /dev/kmem world > WRITABLE, they're begging for this kind of thing. Readable, possibly; > writable, c'mon. Right. You don't even need C-programs to make the shoebox woe. $ cat /etc/termcap > /dev/kmem :-) -Rod -- Rodney Volz - 7000 Stuttgart 1 - FRG ============> ...uunet!mcsun!unido!gtc!aragon!tyrell!rodney <============= rodney@tyrell.gtc.de * rodney@delos.stgt.sub.org * rodney@mcshh.hanse.de \_____________ May your children and mine live in peace. ______________/
daveh@marob.uucp (Dave Hammond) (03/15/91)
In article <690@tndsyd.oz.au> berny@tndsyd.oz.au (Berny Goodheart) writes: > >I am interested in finding out known ways to make your version of UNIX >crash. System: Altos System V uname -a: unix ces 5.3.1 d 386/2000 (empty) (empty) (empty) 10 $ stty line 1 # the only installed line discipline is 0. -- Dave Hammond daveh@marob.uucp uunet!rutgers!phri!marob!daveh
jc@minya.UUCP (John Chambers) (03/15/91)
In article <JC.91Mar12232818@raven.bu.edu>, jc@raven.bu.edu (James Cameron) writes: > >>>>> On 12 Mar 91 23:45:37 GMT, ronnie@mindcraft.com (Ronnie Kon) said: > > RK> May I suggest that posting ways of crashing machines may not be the best of > RK> ideas? > RK> Ronnie > > I would like to second the suggestion. Why would anyone really want > to know HOW to crash it, unless they WANTED to crash it? Jeez, do we have to go through this "Don't tell them about problems; they'll just try to exploit them" argument yet again? There's a very simple and practical explanation. Some of us are trying to provide robust, secure, etc. releases of systems. If nobody tells us about the problems, how do you expect us to ever fix them? Keeping us ignorant of the problems is NOT the solution. This is a professional Unix administrators' bulletin board; it's hard to imagine a better place to post ways of damaging a Unix system. There's also comp.unix.internals, if you want another good place. (But telling the administrators will likely get faster results. :-) It'd also help if, rather than being insulting, people would followup with ways to correct the problem. One is the following permissions: cr--r----- 1 root kmem 2, 1 Sep 20 1989 /dev/kmem -r-xr-sr-x 2 root kmem 10038 Sep 20 1989 /bin/df -r-xr-sr-x 1 root kmem 21810 Sep 20 1989 /bin/ps and similarly for any other program that needs to read kmem. Many Unix systems come without the kmem group, and often have programs like ps that are setuid-root. This in general isn't the right way to do it. There should be as few setuid-root programs as possible, because of the problems with bugs and undocumented features. It is almost always possible to use setgid instead of setuid, giving much better security. One gotcha in the above: On some systems (Convex is one), ps must be left setuid-root, because it checks its euid, and if it isn't a super-user, it refuses to work. I found this the hard way, trying to do the above, and had to put ps back as I found it. Sigh. -- All opinions Copyright (c) 1991 by John Chambers. Inquire for licensing at: Home: 1-617-484-6393 Work: 1-508-486-5475 Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc
lisbon@vpnet.chi.il.us (Gerry Swetsky) (03/16/91)
In article <668821542.3830@mindcraft.com> ronnie@mindcraft.com (Ronnie Kon) writes: >May I suggest that posting ways of crashing machines may not be the best of >ideas? Nah, that's okay, Ronnie. We're just compiling names of the idea posters here in case any one of them ever applies for a shell account on vpnet. :-) There's an ultra nasty way to bring Unix to a halt with a three line shell script. Dennis Ritchie wrote about in an article on Unix security some years back. How is it done? Let me on your system - I'll demonstrate! Meanwhile, keep your cutsie memory constipating programs on your own systems and off mine. -- ============================================================================ | Help stamp out stupid .signature files! Gerry Swetsky WB9EBO | | vpnet - Public access Unix and Usenet | | Home (708)833-8122 vpnet (708)833-8126 lisbon@vpnet.chi.il.us | ============================================================================
siebeck@infoac.rmi.de (Wolfgang Siebeck ) (03/17/91)
rodney@tyrell.gtc.de (Rodney Volz) writes: >In article <1991Mar12.132003.27383@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: >> >>In <513@bria>, uunet!bria!mike writes: >>> >>> if ( (fd = open("/dev/kmem",O_RDWR)) == -1 ) >> >> If your sysadmin (much less the vendor itself) left /dev/kmem world >> WRITABLE, they're begging for this kind of thing. Readable, possibly; >> writable, c'mon. >Right. You don't even need C-programs to make the shoebox woe. >$ cat /etc/termcap > /dev/kmem > :-) >-Rod what about # rm -f /dev/kmem ??? Wolfgang -- siebeck@infoac.rmi.de (Wolfgang Siebeck)
jik@athena.mit.edu (Jonathan I. Kamens) (03/18/91)
In article <1991Mar16.195916.26282@infoac.rmi.de>, siebeck@infoac.rmi.de (Wolfgang Siebeck ) writes: |> what about |> |> # rm -f /dev/kmem All of the other suggestions which discussed writing to /dev/kmem assume that the device /dev/kmem is world-writeable. Your suggestion assumes that the directory /dev is world-writeable, which is a completely different thing. In any case, I'm not even convinced that removing /dev/kmem will cause a Unix system to crash. The kernel itself doesn't use /dev/kmem; the device is used only by processes that want to get access to kernel memory. Deleting /dev/kmem will simply prevent those processes (e.g. ps, ofiles) from working properly. Not a catastrophic failure by any standard. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
berggren@eecs.cs.pdx.edu (Eric Berggren) (03/18/91)
jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <1991Mar16.195916.26282@infoac.rmi.de>, siebeck@infoac.rmi.de (Wolfgang Siebeck ) writes: >|> what about >|> >|> # rm -f /dev/kmem > All of the other suggestions which discussed writing to /dev/kmem assume >that the device /dev/kmem is world-writeable. > Your suggestion assumes that the directory /dev is world-writeable, which is >a completely different thing. Well, shoot... go for the whole filesystem! rm -f /dev/[Place YOUR disk driver here!] -e.b. ============================================================================== Eric Berggren | "The force of the 'Dark Side' eminates from Computer Science/Eng. | the ominous DeathStar looming overhead." berggren@eecs.cs.pdx.edu | - Down with AT&T! -
jco@crane.cis.ufl.edu (Dumpmaster John) (03/19/91)
Someone talked about a 3 line script to crash a unix box here (but I can't find that message.) Anyway, what the script was: while (1) do mkdir 1; cd 1 end Minus some shell syntax. this is it. However, on newer OS's this won't work. I think it has a minfree on the inodes as well, or some thing like that. later jco -- "BSD the strongest Operating System avaible today without a prescription." John C. Orthoefer Internet: jco@smuggler.cis.ufl.edu University of Florida Floyd Mailing List: eclipse-request@reef.cis.ufl.edu CIS Department >>>>>>New Address<<<<<<-------------^^^^
les@chinet.chi.il.us (Leslie Mikesell) (03/19/91)
AT&T 7300's and 3b1's (the Unix-PC) will crash if you write to the floppy from a shared-memory segment. AT&T 3b2's with the old 23Meg streaming tape will crash if you put the tape into streaming mode and then write a chunk larger than it expects in a single write(). (And since this magic size isn't mentioned in any of the normal documentation, it's pretty easy to miss...) Les Mikesell les@chinet.chi.il.us
dpassage@tornado.Berkeley.EDU (David G. Paschich) (03/19/91)
In article <JCO.91Mar18112624@crane.cis.ufl.edu> jco@crane.cis.ufl.edu (Dumpmaster John) writes: > >Someone talked about a 3 line script to crash a unix box here (but I can't >find that message.) > >Anyway, what the script was: > >while (1) do > mkdir 1; cd 1 >end > >Minus some shell syntax. this is it. However, on newer OS's this won't >work. I think it has a minfree on the inodes as well, or some thing like >that. A while back on the machine run by the CS Undergrad Assn. here at UC Berkeley there was a tongue-in-cheek "Space Warrior" competition to try to get people to clean up their disk space. One guy won by writing a little program which malloc'ed 1 meg of memory until the disk was 99% full. This works on Apollos because the swap is kept in a "first-class file", not in a separate partition. David G. Paschich Open Computing Facility UC Berkeley dpassage@ocf.berkeley.edu "I'm so happy I can't stand myself" -- Adam Glass
akes@mcshh.hanse.de (Andreas Kessemeier) (03/22/91)
les@chinet.chi.il.us (Leslie Mikesell) writes: >AT&T 7300's and 3b1's (the Unix-PC) will crash if you write to the >floppy from a shared-memory segment. This can be done much simpler on some Systems with a poor implementation of shared memory: - create a shared memory segment. - do a shmat() on that segment. - do a write(1,"foo",3) The manual says: "never do systemcalls with attached shared memory", but crashing the machine in such a case is much more poor than this restiction. Greets, Andreas -- Andreas Kessemeier akes@mcshh.hanse.de There is no way to Freedom. Freedom is the way.
lance@motcsd.csd.mot.com (lance.norskog) (03/22/91)
Awhile back, someone found that executing random data made quite a few RISC chips sieze up.
torek@elf.ee.lbl.gov (Chris Torek) (03/22/91)
In article <3442@engadm3.csd.mot.com> lance@motcsd.csd.mot.com (lance.norskog) writes: >Awhile back, someone found that executing random data made quite >a few RISC chips sieze up. False. In fact, the program caused a number of *operating systems* to crash. As I recall, the only chip bug it exposed (one that was already known anyway) was in a ``CISC'' (namely, one of the older 80386 implementations). The ability to crash any particular operating system is not a useful indicator of the reliability of any particular microprocessor. That said, one should note that the more complex something is, the easier it is to make a mistake when implementing it. Bugs are often found in complex-addressing-mode CPUs (until fixed in a later revision) when: - an access-probe instruction crosses a page boundary (example: VAX 11/780) - a read-modify-write instruction crosses a page boundary (example: NS32016) - an exception occurs while recovering from an exception, e.g., a parity error during a register state retract during a page fault. In general, ``RISC'' chips avoid all these bugs by outlawing the situations under which they occur: their instructions never cross page boundaries, they do not provide r/m/w instructions, and so forth. There is, of course, a wide spectrum of actual implementations, with varying degrees of ``RISCness'', and simply not providing an operation does not obviate any existing need for something equivalent. In other words, this sometimes merely moves complexity from point A (the hardware) to point B (the software). Finding the correct balance of simplicity and functionality is what machine architecture is all about. If you think you can do better than ``RISC'' (whatever that is, besides a marketing word---like obscenity, we all know what RISC is when we see it, but no one can define it), by all means, gather some venture capital and start a new company. (There, have I managed to avoid pushing anyone's buttons? :-) ) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
guy@auspex.auspex.com (Guy Harris) (03/26/91)
>Awhile back, someone found that executing random data made quite >a few RISC chips sieze up. No, a while back, someone found that executing random data made some operating systems running on machines with RISC chips crash, and immediately charged ahead and, on the basis of that small bit of partial data and a lot of assumptions about RISC chip design methodology, speculated that this was caused by RISC-chip designers not being as rigorous as CISC-chip designers in testing their chips. Subsequent to this: 1) the same program was found to crash the OS on at least one machine running a *CISC* chip (a 80386 machine, I think); 2) at least in one case, the problem was a bug in the *OS*'s code to deal with, as I remember, illegal instructions in the delay slots of illegal branches, or something like that (this was in the MIPS version). At some point, I may dive in and see what caused SunOS to barf; I suspect it's a bug in the floating-point simulation code (which may get invoked even on SPARCs with an FPU, as the FPU may not implement every single floating-point instruction in the architecture). If one wishes to consider the code that broke on the RISC machines to be low-enough-level support code that it "should" be considered as much a part of the architecture's implementation as would the chip itself, you could, I guess, flame RISC - or, at least, the folks doing the software part of the implementation. Of course, given that, you can probably find plenty of microcode bugs to damn CISC as well, if your goal is to bash some particular architecture style (the posting in which the person revealed the results of his test had a bit of a RISC-bashing flavor to it). (Followups directed to "alt.religion.computers", if you really feel you *MUST* make your 2 small monetary units worth known on the RISC vs. CISC topic.)
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (03/26/91)
In article <11313@dog.ee.lbl.gov>, torek@elf.ee.lbl.gov (Chris Torek) writes: > [...], one should note that the more complex something is, the easier > it is to make a mistake when implementing it. Bugs are often found > in complex-addressing-mode CPUs (until fixed in a later revision) > when: > [...] We came across a most mysterious bug once: our MicroVAX suddenly started coredumping in test(1), but only for this one user. After much disbelief and head-scratching, we eventually determined that the coredump was due to something going wrong when the pushes involved in taking the trap for one of the emulated instructions involved pushing past a page boundary. I think it might have been only when it took a pagefault on the new page. The user in question had just the right size environment to tickle this. I'm still not sure exactly *what* was going wrong when this happened.... About then, we realized that the coredumps had started just about the time the service guys had done some sort of maintenance operation that involved replacing the CPU...we called them back and said "we can't really describe how it's broken; we're not entirely certain we can state it to ourselves. But it's definitely broken; please replace it". They did. (Our sysadmin at the time was good at persuasion.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rdavis@connie.UUCP (Ray Davis) (03/26/91)
In <547@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >One gotcha in the above: On some systems (Convex is one), ps must >be left setuid-root, because it checks its euid, and if it isn't a >super-user, it refuses to work. I found this the hard way, trying >to do the above, and had to put ps back as I found it. Sigh. We added a kmem group in ConvexOS 9.0 and have changed ps and related kmem reading commands: -rwxr-sr-x 1 root kmem 168819 Oct 24 18:04 ps ___ Ray Davis Convex Computer GmbH, Frankfurt, West Germany rdavis@convex.com, unido!connie!rdavis, uunet!convex!rdavis, +49-69-666-8081