Spell Wireshark in a few places.

It has been nearly twenty years since Wireshark forked from Ethereal,
so use the current name to identify the software.  Continue to call the
pre-fork mailing list "ethereal-users" because I do not see the old
archives incorporated into the new.

Author: infrastation

doc/README.hpux

@@ -245,7 +245,7 @@ case $1 in
 # Syn-Flood-Protection an
 # ip_forwarding aus
 # Source-Routing aus
-# Ausgehende Packets an ethereal/tcpdump etc.
+# Ausgehende Packets an Wireshark/tcpdump etc.
 
 /usr/contrib/bin/nettune -s tcp_random_seq 2 || exit $ERROR
 /usr/contrib/bin/nettune -s hp_syn_protect 1 || exit $ERROR

pcap-common.c

@@ -277,7 +277,7 @@
  * Do *NOT* use these in capture files that you expect anybody not using
  * your private versions of capture-file-reading tools to read; in
  * particular, do *NOT* use them in products, otherwise you may find that
- * people won't be able to use tcpdump, or snort, or Ethereal, or... to
+ * people won't be able to use tcpdump, or snort, or Wireshark, or... to
  * read capture files from your firewall/intrusion detection/traffic
  * monitoring/etc. appliance, or whatever product uses that LINKTYPE_ value,
  * and you may also find that the developers of those applications will

pcap-linux.c

@@ -2211,9 +2211,9 @@ static int map_arphrd_to_dlt(pcap_t *handle, int arptype,
 		 * header whatsoever to PF_PACKET sockets; other PPP
 		 * code supplies PPP link-layer headers ("syncppp.c");
 		 * some PPP code might supply random link-layer
-		 * headers (PPP over ISDN - there's code in Ethereal,
+		 * headers (PPP over ISDN - there's code in Wireshark,
 		 * for example, to cope with PPP-over-ISDN captures
-		 * with which the Ethereal developers have had to cope,
+		 * with which the Wireshark developers have had to cope,
 		 * heuristically trying to determine which of the
 		 * oddball link-layer headers particular packets have).
 		 *

pcap/dlt.h

@@ -595,7 +595,7 @@
  * Do *NOT* use these in capture files that you expect anybody not using
  * your private versions of capture-file-reading tools to read; in
  * particular, do *NOT* use them in products, otherwise you may find that
- * people won't be able to use tcpdump, or snort, or Ethereal, or... to
+ * people won't be able to use tcpdump, or snort, or Wireshark, or... to
  * read capture files from your firewall/intrusion detection/traffic
  * monitoring/etc. appliance, or whatever product uses that DLT_ value,
  * and you may also find that the developers of those applications will

sf-pcap.c

@@ -415,7 +415,7 @@ pcap_check_header(const uint8_t *magic, FILE *fp, u_int precision, char *errbuf,
 		 * we'd have to use some hacks^H^H^H^H^Hheuristics to
 		 * detect those variants.
 		 *
-		 * Ethereal does that, but it does so by trying to read
+		 * Wireshark does that, but it does so by trying to read
 		 * the first two packets of the file with each of the
 		 * record header formats.  That currently means it seeks
 		 * backwards and retries the reads, which doesn't work