forked from osmocom/wireshark
c20bb290c5
as the Ascend routers; those little buggers don't remember time very well. The only timestamp available in the trace is relative to the beginning of the trace. So, right now I'm just using this relative timestamp as the absoulte time. All my times are in 1969 (my timezone is GMT - 6), but all I care about for now is the relative time, which is preserved even if the absolute time is in the wrong decade. svn path=/trunk/; revision=1404 |
||
|---|---|---|
| .. | ||
| .cvsignore | ||
| AUTHORS | ||
| COPYING | ||
| ChangeLog | ||
| INSTALL | ||
| Makefile | ||
| Makefile.am | ||
| Makefile.nmake | ||
| NEWS | ||
| README | ||
| acconfig.h | ||
| acinclude.m4 | ||
| ascend-grammar.y | ||
| ascend-int.h | ||
| ascend-scanner.l | ||
| ascend.c | ||
| ascend.h | ||
| buffer.c | ||
| buffer.h | ||
| config.h.win32 | ||
| configure.in | ||
| file.c | ||
| file.h | ||
| i4b_trace.h | ||
| i4btrace.c | ||
| i4btrace.h | ||
| iptrace.c | ||
| iptrace.h | ||
| lanalyzer.c | ||
| lanalyzer.h | ||
| libpcap.c | ||
| libpcap.h | ||
| netmon.c | ||
| netmon.h | ||
| nettl.c | ||
| nettl.h | ||
| netxray.c | ||
| netxray.h | ||
| ngsniffer.c | ||
| ngsniffer.h | ||
| radcom.c | ||
| radcom.h | ||
| snoop.c | ||
| snoop.h | ||
| toshiba.c | ||
| toshiba.h | ||
| wtap.c | ||
| wtap.h | ||
README
$Id: README,v 1.19 1999/11/26 20:49:28 gram Exp $ Wiretap is a library that is being developed as a future replacement for libpcap, the current standard Unix library for packet capturing. Libpcap is great in that it is very platform independent and has a wonderful BPF optimizing engine. But it has some shortcomings as well. These shortcomings came to a head during the development of Ethereal (http://ethereal.zing.org), a packet analyzer. As such, I began developing wiretap so that: 1. The library can easily be amended with new packet filtering objects. Libpcap is very TCP/IP-oriented. I want to filter on IPX objects, SNA objects, etc. I also want any decent programmer to be able to add new filters to the library. 2. The library can read file formats from many packet-capturing utilities. Libpcap only reads Libpcap files. 3. The library can capture on more than one network interface at a time, and save this trace in one file. 4. Network names can be resolved immediately after a trace and saved in the trace file. That way, I can ship a trace of my firewall-protected network to a colleague, and he'll see the proper hostnames for the IP addresses in the packet capture, even though he doesn't have access to the DNS server behind my LAN's firewall. 5. I want to look into the possibility of compressing packet data when saved to a file, like Sniffer. 6. The packet-filter can be optimized for the host OS. Not all OSes have BPF; SunOS has NIT and Solaris has DLPI, which both use the CMU/Stanford packet-filter pseudomachine. RMON has another type of packet-filter syntax which we could support. Wiretap is very good at reading many file formats, as per #2 above. Wiretap has no filter capability at present; it currently doesn't support packet capture, so it wouldn't be useful there, and filtering when reading a capture file is done by Ethereal, using a more powerful filtering mechanism than that provided by BPF. File Formats ============ Libpcap ------- The "libpcap" file format was determined by reading the "libpcap" code; wiretap reads the "libpcap" file format with its own code, rather than using the "libpcap" library's code to read it. Sniffer (uncompressed) ------- The Sniffer format is documented in the Sniffer manual. Unfortunately, Sniffer manuals tend to document only the format for the Sniffer model they document. Token-Ring and ethernet seems to work well, though. If you have an ATM Sniffer file, both Guy and Gilbert would be *very* interested in receiving a sample. (see 'AUTHORS' file for our e-mail addresses). LANalyzer --------- The LANalyzer format is available from http://www.novell.com. Search their knowledge base for "Trace File Format". Network Monitor --------------- Microsoft's Network Monitor file format is supported, at least under Ethernet and token-ring. If you have capture files of other datalink types, please send them to Guy. "snoop" ------- The Solaris 2.x "snoop" program's format is documented in RFC 1761. "iptrace" --------- This is the capture program that comes with AIX 3.x and 4.x. AIX 3 uses the iptrace 1.0 file format, while AIX4 uses iptrace 2.0. iptrace has an undocumented, yet very simple, file format. The interesting thing about iptrace is that it will record packets coming in from all network interfaces; a single iptrace file can contain multiple datalink types. Sniffer Basic (NetXRay)/Windows Sniffer Pro ------------------------------------------- Network Associates' Sniffer Basic (formerly NetXRay from Cinco Networks) file format is now supported, at least for Ethernet and token-ring. Network Associates' Windows Sniffer Pro appears to use a variant of that format; it's supported to the same extent. RADCOM WAN/LAN Analyzers ------------------------ Olivier Abad has added code to read Ethernet and LAPB captures from RADCOM WAN/LAN Analyzers (see http://www.radcom-inc.com/). Lucent/Ascend access products ----------------------------- Gerald HP-UX nettl ----------- Olivier Toshiba ISDN Router ------------------- An under-documented command that the router supports in a telnet session is "snoop" (not related to the Solaris "snoop" command). If you give it the "dump" option, you'll get a hex dump of all packets across the router (except of your own telnet session -- good thinking Toshiba!). You can select a certain channel to sniff (LAN, B1, B2, D), but the default is all channels. You save this hex dump to disk with 'script' or by 'telnet | tee'. Wiretap will read the ASCII hex dump and convert it to binary data. Gilbert Ramirez <gram@xiexie.org> Guy Harris <guy@alum.mit.edu>