Date: Sun, 24 Nov 1996 13:52:10 CST From: Kent Vander Velden <graphix@iastate.edu> To: Tom Samplonius <tom@sdf.com> Cc: hackers@freefall.freebsd.org Subject: Re: ping and freebsd crashes Message-ID: <9611241952.AA18700@spiff.cc.iastate.edu> In-Reply-To: Your message of "Sun, 24 Nov 1996 10:33:07 PST." <Pine.NEB.3.94.961124102437.10660A-100000@misery.sdf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.NEB.3.94.961124102437.10660A-100000@misery.sdf.com>, tom@sdf.c om writes: > >On Sun, 24 Nov 1996, Kent Vander Velden wrote: > >> In message <Pine.NEB.3.94.961124003102.10075A-100000@misery.sdf.com>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9611241952.AA18700>