* variants use for different encapsulation types, we check what
* <pcap.h> defined to determine how to interpret them, so that we
* interpret them the way the libpcap with which we're building
- * Ethereal/Wiretap interprets them (which, if it doesn't support
+ * Wireshark/Wiretap interprets them (which, if it doesn't support
* them at all, means we don't support them either - any capture files
* using them are foreign, and we don't hazard a guess as to which
* platform they came from; we could, I guess, choose the most likely
* These are the values that are almost certainly the same
* in all libpcaps (I've yet to find one where the values
* in question are used for some purpose other than the
- * one below, but...), and that Wiretap and Ethereal
+ * one below, but...), and that Wiretap and Wireshark
* currently support.
*/
{ 0, WTAP_ENCAP_NULL }, /* null encapsulation */
* I also don't see anything immediately obvious that munges
* the address field for sync PPP, either.
*
- * Ethereal currently assumes that if the first octet of a
+ * Wireshark currently assumes that if the first octet of a
* PPP frame is 0xFF, it's the address field and is followed
* by a control field and a 2-byte protocol, otherwise the
* address and control fields are absent and the frame begins
/*
* These are the values that libpcap 0.5 and later use in
* capture file headers, in an attempt to work around the
- * confusion decried above, and that Wiretap and Ethereal
+ * confusion decried above, and that Wiretap and Wireshark
* currently support.
*/
{ 100, WTAP_ENCAP_ATM_RFC1483 },
*
* We put these *after* the entries for the platform-independent
* libpcap type values for those Wiretap encapsulation types, so
- * that Ethereal chooses the platform-independent libpcap type
+ * that Wireshark chooses the platform-independent libpcap type
* value for those encapsulatioin types, not the platform-dependent
* one.
*/
*
* We don't yet handle DLT_C_HDLC, but we can handle DLT_LOOP
* (it's just like DLT_NULL, only with the AF_ value in network
- * rather than host byte order - Ethereal figures out the
+ * rather than host byte order - Wireshark figures out the
* byte order from the data, so we don't care what byte order
* it's in), so if DLT_LOOP is defined as 12, interpret 12
* as WTAP_ENCAP_NULL, otherwise, unless DLT_C_HDLC is defined
* in AIX libpcap rather than PPP in standard libpcap, as
* you're probably more likely to be handing an AIX libpcap
* token-ring capture than an old (pre-libpcap 0.4) PPP capture
- * to Ethereal.
+ * to Wireshark.
*/
aix = FALSE; /* assume it's not AIX */
if (hdr.version_major == 2 && hdr.version_minor == 2) {
* RH 6.1 has a tcpdump that writes out files that can't
* be read by any software that expects non-modified headers
* if the magic number isn't the modified magic number (e.g.,
- * any normal version of tcpdump, and Ethereal if we don't
+ * any normal version of tcpdump, and Wireshark if we don't
* do this gross heuristic).
*
* If this file had the modified magic number, it may be