forked from osmocom/wireshark
3db7b1ed04
ERF Dissector: Add dissection for ERF_TYPE_META, Host ID and Flow ID extension headers. Rename ERF extension header defines to ERF_EXT_HDR* and put in erf.h. The Flow ID extension header has an improved 32-bit Flow Hash with a Hash Type field describing what the hash was computed over. The Host ID extension header contains a 48-bit organizationally unique Host Identifier. Both extension headers contain the same 8-bit Source ID used for distinguishing records from multiple sources in the same file and for metadata linking to ERF_TYPE_META records. Host ID is used to identify the capturing host and can also be used to distinguish records from multiple hosts in the same file. ERF_TYPE_META records have a payload consisting of TLV metadata, divided into sections which define the context of the TLV tag. The dissector registers a field for each tag for each section type based on a template. ERF_TYPE_META records generally have a Host ID extension header used to link metadata to packet records with the same Host ID and Source ID. The associated Host ID can either be explicit on all records, or implicit where the Host ID extension header is only present on MetaERF records and other records are associated using only the Source ID in the Flow ID extension header. Includes per-record generated Source summary and frame linking. These have the 'correct' Host ID and Source IDs from either extension header, including applying the Implicit Host ID, and links to the most recent ERF_TYPE_META record. Relies on Wireshark doing more than one pass to associate the correct implicit Host ID tree items for records before the first ERF_TYPE_META record. The metadata is technically not associated at that point anyway. ERF Wiretap: Add per-HostID/per-SourceID wtap interfaces and basic ERF_TYPE_META support. Adds read support for displaying some fields of the 'first' ERF_TYPE_META record in the Capture File Properties screen. Concatenates and merges some summary fields to provide more useful information and attempt to combine ERF sources, streams and interfaces into wtap interfaces. Interface naming gracefully degrades when Host ID and Source ID are not present and is intended to be parseable for use by DAG software. Supports Implicit Host ID, but assumes it does not change. NOTE: Now only ERF interfaces that are present in the file are added. Only works with native ERF files for now. Written such that it is easily adapted for use by pcap dissector. Some support for setting REC_TYPE_FT_SPECIFIC_REPORT on MetaERF records. Disabled for now as this breaks pcapng_dump saving of ERF_TYPE_META and ft_specific_record_phdr clashes with erf_mc_phdr. Only when native ERF file (as uses wth->file_type_subtype). Register packet-erf as a dissector of WTAP_FILE_TYPE_SUBTYPE_ERF. Bug: 12303 Change-Id: I6a697cdc851319595da2852f3a977cef8a42431d Reviewed-on: https://code.wireshark.org/review/14510 Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com> Tested-by: Alexis La Goutte <alexis.lagoutte@gmail.com> Reviewed-by: Michael Mann <mmann78@netscape.net> |
||
---|---|---|
.. | ||
.editorconfig | ||
5views.c | ||
5views.h | ||
CMakeLists.txt | ||
Makefile.am | ||
Makefile.common | ||
Makefile.nmake | ||
README | ||
README.airmagnet | ||
README.developer | ||
aethra.c | ||
aethra.h | ||
ascend-int.h | ||
ascend.y | ||
ascend_scanner.l | ||
ascendtext.c | ||
ascendtext.h | ||
atm.c | ||
atm.h | ||
ber.c | ||
ber.h | ||
btsnoop.c | ||
btsnoop.h | ||
camins.c | ||
camins.h | ||
capsa.c | ||
capsa.h | ||
catapult_dct2000.c | ||
catapult_dct2000.h | ||
commview.c | ||
commview.h | ||
cosine.c | ||
cosine.h | ||
csids.c | ||
csids.h | ||
daintree-sna.c | ||
daintree-sna.h | ||
dbs-etherwatch.c | ||
dbs-etherwatch.h | ||
dct3trace.c | ||
dct3trace.h | ||
erf.c | ||
erf.h | ||
eyesdn.c | ||
eyesdn.h | ||
file_access.c | ||
file_wrappers.c | ||
file_wrappers.h | ||
hcidump.c | ||
hcidump.h | ||
i4b_trace.h | ||
i4btrace.c | ||
i4btrace.h | ||
ipfix.c | ||
ipfix.h | ||
iptrace.c | ||
iptrace.h | ||
iseries.c | ||
iseries.h | ||
json.c | ||
json.h | ||
k12.c | ||
k12.h | ||
k12text.l | ||
lanalyzer.c | ||
lanalyzer.h | ||
libpcap.c | ||
libpcap.h | ||
logcat.c | ||
logcat.h | ||
logcat_text.c | ||
logcat_text.h | ||
merge.c | ||
merge.h | ||
mime_file.c | ||
mime_file.h | ||
mp2t.c | ||
mp2t.h | ||
mpeg.c | ||
mpeg.h | ||
netmon.c | ||
netmon.h | ||
netscaler.c | ||
netscaler.h | ||
netscreen.c | ||
netscreen.h | ||
nettl.c | ||
nettl.h | ||
nettrace_3gpp_32_423.c | ||
nettrace_3gpp_32_423.h | ||
network_instruments.c | ||
network_instruments.h | ||
netxray.c | ||
netxray.h | ||
ngsniffer.c | ||
ngsniffer.h | ||
packetlogger.c | ||
packetlogger.h | ||
pcap-common.c | ||
pcap-common.h | ||
pcap-encap.h | ||
pcapng.c | ||
pcapng.h | ||
pcapng_module.h | ||
peekclassic.c | ||
peekclassic.h | ||
peektagged.c | ||
peektagged.h | ||
pppdump.c | ||
pppdump.h | ||
radcom.c | ||
radcom.h | ||
snoop.c | ||
snoop.h | ||
stanag4607.c | ||
stanag4607.h | ||
tnef.c | ||
tnef.h | ||
toshiba.c | ||
toshiba.h | ||
visual.c | ||
visual.h | ||
vms.c | ||
vms.h | ||
vwr.c | ||
vwr.h | ||
wtap-int.h | ||
wtap.c | ||
wtap.h | ||
wtap_opttypes.c | ||
wtap_opttypes.h |
README
NOTE: this documents the original intent behind libwiretap. Currently, it is being developed solely as a library for reading capture files, rather than packet capture. The list of file formats is also out-of-date. 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 Wireshark (http://www.wireshark.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 Wireshark, 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 (compressed and uncompressed) ------- The uncompressed 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 ----------- nettl is used on HP-UX to trace various streams based subsystems. Wiretap can read nettl files containing IP frames (NS_LS_IP subsystem) and LAPB frames (SX25L2 subsystem). It has been tested with files generated on HP-UX 9.04 and 10.20. Use the following commands to generate a trace : # IP capture. 0x30000000 means PDU in and PDU out : nettl -tn 0x30000000 -e NS_LS_IP -f tracefile # X25 capture. You must specify an interface : nettl -tn 0x30000000 -e SX25l2 -d /dev/x25_0 -f tracefile # stop capture. subsystem is NS_LS_IP or SX25L2 : nettl -tf -e subsystem One may be able to specify "-tn pduin pduout" rather than "-tn 0x30000000"; the nettl man page for HP-UX 10.30 implies that it should work. There is also basic support for nettl files containing NS_LS_DRIVER, NS_LS_TCP, NS_LS_UDP, NS_LS_LOOPBACK, unknown type 0xb9, and NS_LS_ICMP. However, NS_LS_ICMP will not be decoded since WTAP lacks a raw ICMP encapsulation type. 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 (either by letting "snoop" query you for its next argument, or typing "snoop dump" on the command line), 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. ISDN4BSD "i4btrace" utility --------------------------- Bert Driehuis Cisco Secure Intrusion Detection System iplogging facility ----------------------------------------------------------- Mike Hall pppd logs (pppdump-format files) -------------------------------- Gilbert VMS TCPTRACE ------------ Compaq VMS's TCPIPTRACE format is supported. This is the capture program that comes with TCP/IP or UCX as supplied by Compaq or Digital Equipment Corporation. Under UCX 4.x, it is invoked as TCPIPTRACE. Under TCPIP 5.x, it is invoked as TCPTRACE. TCPTRACE produces an ascii text based format, that has changed slightly over time. DBS Etherwatch (text format) ---------------------------- Text output from DBS Etherwatch is supported. DBS Etherwatch is available from: http://www.users.bigpond.com/dbsneddon/software.htm. Catapult DCT2000 (.out files) ----------------------------- DCT2000 test systems produce ascii text-based .out files for ports that have logging enabled. When being read, the data part of the message is prefixed with a short header that provides some context (context+port, direction, original timestamp, etc). You can choose to suppress the reading of non-standard protocols (i.e. messages between layers rather than the well-known link-level protocols usually found on board ports). Gilbert Ramirez <gram@alumni.rice.edu> Guy Harris <guy@alum.mit.edu> STANAG 4607 ----------- Initial support for the STANAG 4607 protocol. Documentation at: http://www.nato.int/structur/AC/224/standard/4607/4607.htm