mogul@wrl.dec.com (Jeffrey Mogul) (02/13/91)
In article <28528.27b72f38@kuhub.cc.ukans.edu> jian@kuhub.cc.ukans.edu writes: >I want to config one of ethernet interfaces on the DEC 3100 running Ultrix >4.1 to be in a promiscous mode. Does anyone have experience with this matter? > >I got some hints from the menu that I need to create a psudo packet filter >device driver first. The command for creating the packet filter device is: > > #MAKEDEV pfilt > >I followed what the menu says. But I could not open the packet filter device >after I created it. I saw there are some pfiltnnn files in the /dev/pf/ >directory. Am I missing something. I would appreciate any helps. You should first of all make sure that your kernel has been built with the proper options: see "man packetfilter(4)". I believe that the default configuration does not include the packetfilter. I'm not quite sure how you intend to use the promiscuous mode support of the packet filter, but quite often people neglect to run /etc/pfconfig +p <interface-name> which is necessary before using a promiscuous-mode application. I put this in my /etc/rc.local; it has absolutely no effect unless a promiscuous-mode application is running. See the manual page. If you want an example of how to write an application, you can obtain the sources for tcpdump or nfswatch from gatekeeper.dec.com via anonymous FTP: pub/net/tcpdump-2.0.tar.Z pub/net/nfs/nfswatch3.0.tar.Z -Jeff
schemers@vela.acs.oakland.edu (Roland Schemers III) (02/13/91)
In article <1991Feb13.020117.27922@pa.dec.com> mogul@wrl.dec.com (Jeffrey Mogul) writes: > >I'm not quite sure how you intend to use the promiscuous mode support >of the packet filter, but quite often people neglect to run > /etc/pfconfig +p <interface-name> > ... > pub/net/nfs/nfswatch3.0.tar.Z I finally took the plunge and got nfswatch, had the kernel compiled with the packet filter, etc. Then I ran nfswatch. Works pretty nice, shows a lot of interesting things. Then I said ok, thats neat, and did a /etc/pfconfig -p ln0 To turn of promiscuous mode. To my suprise I started getting a TON of complaints that no one could connect to any system via LAT! The only system they could connect to was mine! Strange? I finally though maybe I did something by using nfswatch. The second I rebooted my machine everyone could use LAT again! I tried this a couple of times, and everytime I took ln0 out of promscuous mode no one could use LAT! Has anyone seen this before?? Are you supposed to keep the interface in promiscuous mode once you have used it that way? Roland -- Roland J. Schemers III Systems/Network Manager schemers@vela.acs.oakland.edu (Ultrix) Oakland University schemers@argo.acs.oakland.edu (VMS) Rochester, MI 48309-4401 You can tune a piano, but you can't tuna VMS! (313)-370-4323
mogul@wrl.dec.com (Jeffrey Mogul) (02/14/91)
In article <5132@vela.acs.oakland.edu> schemers@vela.acs.oakland.edu (Roland Schemers III) writes: >I finally took the plunge and got nfswatch, had the kernel compiled with >the packet filter, etc. Then I ran nfswatch. Works pretty nice, shows >a lot of interesting things. Then I said ok, thats neat, and did a > >/etc/pfconfig -p ln0 > >To turn of promiscuous mode. To my suprise I started getting a TON of complaints >that no one could connect to any system via LAT! The only system they could >connect to was mine! Strange? I finally though maybe I did something by >using nfswatch. The second I rebooted my machine everyone could use LAT >again! I tried this a couple of times, and everytime I took ln0 out of >promscuous mode no one could use LAT! > >Has anyone seen this before?? Are you supposed to keep the interface in >promiscuous mode once you have used it that way? I suspect you are running Ultrix 4.1 ... I've heard that this bug appeared in 4.1, but that it wasn't in 4.0. (I don't know if this is so.) Anyway, it's certainly not intentional! This will be fixed in the next release, as far as I know. Scant solace, I realize. Basically, for now one should not run promiscuous-mode applications on a LAT-accessed system. Since running nfswatch or tcpdump on a busy network can eat up most of the CPU, it's probably best to run them on an otherwise unused workstation. Yes, I know that nfswatch has nifty features that make sense only if you run it on an NFS server, but most of the time you can do just as well by spying on the server from afar. In fact, there are other reasons why running nfswatch on the NFS server won't work quite right; these, too, should be fixed in the next release. -Jeff