vaillan@ireq.hydro.qc.ca (Clement Vaillancourt) (02/14/91)
In article <CHRIS.91Feb13165726@endgame.gsfc.nasa.gov> chris@endgame.gsfc.nasa.gov (Chris Shenton) writes: >I recently saw this clever program from Silicon Graphics which watches >traffic (of a specified protocol, I think) on the ether, and draws lines >connecting machine names -- kind of like a dynamic traffic mapper. They >called it netsnoop or netlook or some such... > >I'd like to try writing something like this but need pointers to the TCP/IP >calls. I assume I'd be interested in the packet level stuff, just reading >the TO and FROM addresses from the ip headers... Any pointers? I have the real NetVisualyzer package (including netsnoop, netlook, analyzer) running on an SGI workstation. It is a great package to watch networks in action. My SGI machine is the only SGI on this research campus watching the traffic of about 300 Suns... I had to buy the SGI workstation to be able to run this great package. I never found something as good for the money running on a Sun. I just don't understand why SGI don't port this package to Sun and sell it with a good profit? Again, a very good package to see and debug networks, no statistics or snmp in version 1.0 but I heard it is comming. Clem. -- Clement Vaillancourt, Analyste, | Institut de Recherche d'Hydro-Quebec Responsable du Reseau Ethernet | 1800 Montee Ste-Julie, Varennes (Analyst, Network Manager) | P. Quebec, Canada, J3X 1S1 vaillan@ireq.hydro.qc.ca |Tel:+1 514 652 8238 Fax:+1 514 652 8309
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/16/91)
In article <5455@s3.ireq.hydro.qc.ca>, vaillan@ireq.hydro.qc.ca (Clement Vaillancourt) writes: > ...[very nice, kind words deleted]... > > I just don't understand why SGI don't port this package to Sun and sell it > with a good profit? The software business is much harder to survive than the hardware business. It is particularly difficult to start doing software only products in a hardware company. It would very difficult to convince the majority of this company to support a port to compeating hardware. Trying to keep up with and properly filter network traffic from an Ethernet or FDDI MAC in promiscuous mode requires substantial support below the application. Such support, if present, is not currently likely to be sufficiently similar on products from hardware vendors. Vernon Schryver, vjs@sgi.com
mogul@wrl.dec.com (Jeffrey Mogul) (02/16/91)
In article <85756@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >Trying to keep up with and properly filter network traffic from an Ethernet >or FDDI MAC in promiscuous mode requires substantial support below the >application. Such support, if present, is not currently likely to be >sufficiently similar on products from hardware vendors. I've ported a number of such programs, and (if the program structure is at all modular) it turns out to be pretty easy to get a program (e.g., tcpdump, nfswatch, statspy) to run on the following systems: Ultrix + Ultrix packet filter SunOs + NIT 4.xBSD + new "Berkeley Packet Filter" (BPF) and possibly the IBM RT using the modified Stanford packet filter done by some folks at Merit. True, all of these facilities have evolved from the same base (even NIT seems to be based on the Stanford packet filter), but that base did not support promiscuous mode, and all those evolved versions do. Admittedly, it becomes a little trickier if your application does fancy filtering, since the filter languages are slightly different (the BPF language is entirely different). However, most statistical network monitors (as opposed to a trace-program such as tcpdump) general want to see all (or almost all) the packets, so filtering isn't an issue. -Jeff
tengi@princeton.edu (Christopher Tengi) (02/23/91)
Jeff, In article <1991Feb16.014841.10155@pa.dec.com>, mogul@wrl.dec.com (Jeffrey Mogul) writes: |> In article <85756@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: |> >Trying to keep up with and properly filter network traffic from an Ethernet |> >or FDDI MAC in promiscuous mode requires substantial support below the |> >application. Such support, if present, is not currently likely to be |> >sufficiently similar on products from hardware vendors. |> |> I've ported a number of such programs, and (if the program structure |> is at all modular) it turns out to be pretty easy to get a program |> (e.g., tcpdump, nfswatch, statspy) to run on the following systems: |> Ultrix + Ultrix packet filter |> SunOs + NIT |> 4.xBSD + new "Berkeley Packet Filter" (BPF) |> and possibly the IBM RT using the modified Stanford packet filter done |> by some folks at Merit. |> I assume, from reading the above, that you did work on tcpdump and statspy to make them work with the Ultrix packet filter. If this is true, have your changes been melded back into the "original" sources for the rest of us to use? If not that, would you be willing to make patches available? /Chris -- ==========----------==========---------+---------==========----------========== UUCP: ...princeton!tengi VOICEnet: 609-258-6799 INTERNET: tengi@princeton.edu FAX: 609-258-3943 BITNET: TENGI@PUCC
mogul@wrl.dec.com (Jeffrey Mogul) (02/23/91)
In article <6507@idunno.Princeton.EDU> tengi@princeton.edu (Christopher Tengi) writes: >Jeff, >I assume, from reading the above, that you did work on tcpdump and >statspy to make them work with the Ultrix packet filter. If this is >true, have your changes been melded back into the "original" sources >for the rest of us to use? If not that, would you be willing to make >patches available? Your inference is correct. Tcpdump version 2.0 includes Ultrix support; you can get it from ftp.ee.lbl.gov:tcpdump-2.0.tar.Z (and see tcpdump-2.0.patch-1) gatekeeper.dec.com:pub/net/tcpdump-2.0.tar.Z I'm pretty sure that the gatekeeper version has the patch installed and has a Makefile which is ready-for-Ultrix. My changes to NNstat (statspy) have been provided to the folks at ISI, and I expect them to appear in the imminent release. -Jeff