cole@cc.utah.edu (Allen Cole, UUCC) (05/07/91)
I am trying to get tcpdump to work. I have a ds3100 with Ultrix 4.1. Here is what I did. Got tcpdump from gatekeeper.dec.com made pfilt device (cd /dev; MAKEDEV pfilt) did pfconfig (/usr/etc/pfconfig +promisc) made and installed tcpdump (the makefile is already ultrix'ized) When I run tcpdump as root it says: # tcpdump host 128.110.48.3 ln0: No such device tcpdump: your system may not be properly configured; see "man packetfilter(4)" Also, if I do /usr/etc/pfconfig + promisc ln0 it reports no device ln0. Here is ifconfig ln0 ln0: 128.110.48.6 netmask ffffff00 flags=0x463<DYNPROTO,RUNNING,NOTRAILERS, BROADCAST,UP> Anybody see my mistake? Thanks. Allen Cole University of Utah Computer Center cole@cc.utah.edu 3440 Merrill Engineering Building cole@utahcca.bitnet Salt Lake City, UT 84112 utah-cs!cole (801) 581-8805
frank@croton.nyo.dec.com (Frank Wortner) (05/08/91)
In article <1991May7.141459.11191@fcom.cc.utah.edu>, cole@cc.utah.edu (Allen Cole, UUCC)
writes that he is having trouble getting tcpdump to work.
Did you add the following to you kernel configuration file (/sys/conf/mips/SYSNAME)?
options PACKETFILTER
pseudo-device packetfilter
If not, do so, run doconfig -c SYSNAME, and reboot with the resulting vmunix as
your kernel.
Hope this solves your problem!
Frankmogul@pa.dec.com (Jeffrey Mogul) (05/08/91)
In article <1991May7.141459.11191@fcom.cc.utah.edu> cole@cc.utah.edu writes: >I am trying to get tcpdump to work. I have a ds3100 with Ultrix 4.1. Here >is what I did. [summarized] >made pfilt device (cd /dev; MAKEDEV pfilt) >did pfconfig (/usr/etc/pfconfig +promisc) > >When I run tcpdump as root it says: ># tcpdump host 128.110.48.3 >ln0: No such device >tcpdump: your system may not be properly configured; see "man packetfilter(4)" > >Also, if I do ># /usr/etc/pfconfig + promisc ln0 >it reports no device ln0. > >Anybody see my mistake? Thanks. Almost certainly you have not reconfigured your kernel to include the packet filter. This is NOT included in the default configuration. (Perhaps this default is a mistake, but at the time it seemed likely that "most" Ultrix customers would not be using tcpdump, and would rather have the extra free memory. Here at WRL, all of our kernels are configured to include the packet filter.) As the message says, 'see "man packetfilter"' and 'man config', I guess. -Jeff
tih@barsoom.nhh.no (Tom Ivar Helbekkmo) (05/08/91)
I set up my packet filter to run in promiscuous mode here yesterday, on a 5000/200 with 4.1, and our whole VAXcluster (VMS) started crashing like nobody's business... I've heard that promiscuous mode will break LAT if you've got LAT installed on the Ultrix host running it, which I haven't, but I'm wondering if it still may have been my experimenting that killed the VAXen. We use LAT very extensively, in fact 3 out of every 4 packets on our ethernet are LAT packets. Anybody know anything about it? -tih -- Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205 Postmaster for domain nhh.no. Internet mail: tih@barsoom.nhh.no
bill@pslu1.psl.wisc.edu (Bill Roth) (05/08/91)
In article <tih.673686101@barsoom> tih@barsoom.nhh.no (Tom Ivar Helbekkmo) writes: >I set up my packet filter to run in promiscuous mode here yesterday, on >a 5000/200 with 4.1, and our whole VAXcluster (VMS) started crashing like >nobody's business... I've heard that promiscuous mode will break LAT if >you've got LAT installed on the Ultrix host running it, which I haven't, >but I'm wondering if it still may have been my experimenting that killed >the VAXen. We use LAT very extensively, in fact 3 out of every 4 packets >on our ethernet are LAT packets. Anybody know anything about it? > >-tih >-- >Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205 >Postmaster for domain nhh.no. Internet mail: tih@barsoom.nhh.no We (PSL) saw trhe same thing about 2 months ago. I started up tcpdump and left for the weekend, only to find, on returning monday, that the entire net had been down all weekend. The immediate fix was to pull the cable out of my DECStation. I posted a question about it at the time, and received no answer. Perhaps this time someone will respond. From the Wild Guess Department: I bet that LAT is implemented as a Read Write packetfliter whereas the packetfilter mechanism is read only. Either that or enabling tcpdump stomps all over the pf mechanism used to read and respond to LAT packets. -- ------------------------------------------------------------------------ Bill Roth, University of Wisconsin Physical Sciences Laboratory email: bill@pslu1.psl.wisc.edu bill@wiscpsl.bitnet / (608)-873-6651
mogul@wrl.dec.com (Jeffrey Mogul) (05/09/91)
In article <tih.673686101@barsoom> tih@barsoom.nhh.no (Tom Ivar Helbekkmo) writes: >I set up my packet filter to run in promiscuous mode here yesterday, on >a 5000/200 with 4.1, and our whole VAXcluster (VMS) started crashing like >nobody's business... I've heard that promiscuous mode will break LAT if >you've got LAT installed on the Ultrix host running it, which I haven't, >but I'm wondering if it still may have been my experimenting that killed >the VAXen. We use LAT very extensively, in fact 3 out of every 4 packets >on our ethernet are LAT packets. Anybody know anything about it? [In a separate message, Tom told me he had successfully run tcpdump on his workstation.] If the workstation where you ran tcpdump really and truly does not have LAT installed (i.e., configured into its kernel), and if you didn't run any applications that sent packets via the packet filter, then I can't see any possible way for what you did to crash the VMS machines. Running the packet filter in promiscuous mode should not cause any novel packets to be sent. Perhaps your kernel does contain LAT support, and perhaps the use of promiscuous mode is confusing the LAT code enough that it sends weird packets that then confuse the VMS machines. It has already been made clear by several people on this newsgroup that Ultrix 4.1 has a problem when LAT and promiscuous mode are used together, but if the VMS machines are also crashing, that is news to me. (I believe that the Ultrix problem has been fixed in Ultrix 4.2). Since several people have reported similar problems, I would appreciate getting more precise details, describing the exact sequence of events. For example, I don't believe that simply running "/etc/pfconfig +p -a" can explain this, since all that this command does is to set a flag that, later on, allows the interface to be put into promiscuous mode by programs such as tcpdump. On the other hand, if the crash occurs while tcpdump is running, or right after you stop running tcpdump, that would be helpful to know. It would also be helpful if you would send me a copy of your Ultrix configuration file (e.g., conf/{mips,vax}/CONFIGNAME), so I can see whether LAT is really in your Ultrix kernel or not. (And please provide the usual information on Ultrix version number, processor type, etc.) Please send this to "mogul@decwrl.dec.com", not to comp.unix.ultrix. I can't promise that I will be able to do anything, but I'll try. Thanks -Jeff