From owner-freebsd-hackers Sun Nov 24 11:53:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA08430 for hackers-outgoing; Sun, 24 Nov 1996 11:53:44 -0800 (PST) Received: from spiff.cc.iastate.edu (spiff.cc.iastate.edu [129.186.142.89]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA08417 for ; Sun, 24 Nov 1996 11:53:25 -0800 (PST) Received: by spiff.cc.iastate.edu with sendmail-5.65 id ; Sun, 24 Nov 1996 13:52:11 -0600 Message-Id: <9611241952.AA18700@spiff.cc.iastate.edu> To: Tom Samplonius Cc: hackers@freefall.freebsd.org Subject: Re: ping and freebsd crashes In-Reply-To: Your message of "Sun, 24 Nov 1996 10:33:07 PST." Date: Sun, 24 Nov 1996 13:52:10 CST From: Kent Vander Velden Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message , tom@sdf.c om writes: > >On Sun, 24 Nov 1996, Kent Vander Velden wrote: > >> In message , tom@sd >f.c >> om writes: >> > >> >On Sat, 23 Nov 1996, Kent Vander Velden wrote: >> > >> >> After reading the url that was mentioned earlier about ping I tried to >> >> crash an Irix 5.2 machine. I used OSF/1 v3.2 'ping -q -f -l 200 -s >> >> 5000'. The network appeared to take quite a beating. Sort of related >> >> to wanting to try this was that I have been working on a network packet >> >> analyzer and wanted to see how much of a load this pinging would cause. >> >> The network analyzer runs on a freebsd machine and uses libpcap. The >> >> interesting part of all this is the freebsd machine crashed and in fact >> >> crashed really hard. In the worst case a user's home directory and 50% >> >> of /bin and misc. was removed. I must point out that the freebsd >> >> machine was not being pinged nor was it doing the pinging it was simply >> >> a machine on the network with it's interface running in promiscuous mode. >> >> I also tried tcpdump to make sure that it was not my program that was >> >> causing problems with the same result. >> > >> >> > How much memory does the test machine have in it? >> >> 20M and used for very little. There is not really a load on it. > > Are you using a non-GENERIC kernel? If so, do you have BOUNCE_BUFFERS >compiled in? If so, this is your problem. Apparently the lance ethernet >cards use DMA, and if you have more than 16MB and no bounce buffers, the >card could be overwriting all kinds of thing in main memory, including >file buffers (which would explain disk corruption). > Is a non-generic kernel it is one that has been customized then, yes I am using a non-generic kernel. It does have BOUNCE_BUFFERS enabled which I did to use the 20M and the 1542 in the machine. I am confused by your statement above. You seem to say that if BOUNCE_BUFFERS are enabled then this is a problem but describe a problem that happens when they are not enabled. Should I get a different ethernet card, remove memory or does someone have another suggestion? >... >> > Not really. It involves putting the ethernet device in promiscous mode. >> >This is rare and involves root access. It has always been risky, because >> >some hardware doesn't like it. I've seen some NE2000s get stuck in >> >promiscous mode and do all kinds of strange things. >> > >> >> If the interface is not in promiscuous mode the system does not crash >> but instead reports the mentioned errors over and over. Unfort. some of >> my systems have to be in promiscuous mode all the time since they have >> rarpd (or is it rbootd that does it) running on them. Seemed nasty >> that I could remotely crash a system in this way :) > > I believe that both of these tools only look for ethernet broadcasts. >Putting a ethernet into promiscous mode is something you want to avoid >because of the amount of load it generates on the system. In promiscous >mode, the CPU has to store and process *everything* on the wire, rather >than just traffic with its ethernet address and the ethernet broadcast >address. My mistake, it is rbootd that was concerning me. These are the messages that get generated when it starts so I assume that this "bug" might give the machines that are running rbootd a problem " Oct 20 14:56:41 pseudo rbootd[175]: restarted (ed0) Oct 20 14:56:41 pseudo rbootd[175]: bpf: can't add mcast addr (Invalid argument), setting promiscuous mode Oct 20 14:56:41 pseudo /kernel: ed0: promiscuous mode enabled " (This is a different system so that is why this is ed0 and the other was lnc0). Thanks. --- Kent Vander Velden graphix@iastate.edu