forked from osmocom/wireshark
2227 lines
99 KiB
Text
2227 lines
99 KiB
Text
|
|
The Ethereal FAQ
|
|
|
|
Note: This is just an ASCII snapshot of the faq and may not be up to
|
|
date. Please go to http://www.ethereal.com/faq.html for the up
|
|
to date version. The version of this snapshot can be found at
|
|
the end of this document.
|
|
|
|
INDEX
|
|
|
|
|
|
General Questions:
|
|
|
|
1.1 Where can I get help?
|
|
|
|
1.2 What protocols are currently supported?
|
|
|
|
1.3 Are there any plans to support {your favorite protocol}?
|
|
|
|
1.4 Can Ethereal read capture files from {your favorite network
|
|
analyzer}?
|
|
|
|
1.5 What devices can Ethereal use to capture packets?
|
|
|
|
1.6 How do you pronounce Ethereal? Where did the name come from?
|
|
|
|
Downloading Ethereal:
|
|
|
|
2.1 I downloaded the Win32 installer, but when I try to run it, I get
|
|
an error.
|
|
|
|
2.2 When I try to download the WinPcap driver and library, I can't get
|
|
to the WinPcap Web site.
|
|
|
|
Installing Ethereal:
|
|
|
|
3.1 I installed an Ethereal RPM, but Ethereal doesn't seem to be
|
|
installed; only Tethereal is installed.
|
|
|
|
Building Ethereal:
|
|
|
|
4.1 The configure script can't find pcap.h or bpf.h, but I have
|
|
libpcap installed.
|
|
|
|
4.2 Why do I get the error
|
|
|
|
dftest_DEPENDENCIES was already defined in condition TRUE, which
|
|
implies condition HAVE_PLUGINS_TRUE
|
|
|
|
when I try to build Ethereal from SVN or a SVN snapshot?
|
|
|
|
4.3 The link fails with a number of "Output line too long." messages
|
|
followed by linker errors.
|
|
|
|
4.4 The link fails on Solaris because plugin_list is undefined.
|
|
|
|
4.5 The build fails on Windows because of conflicts between winsock.h
|
|
and winsock2.h.
|
|
|
|
Using Ethereal:
|
|
|
|
5.1 When I use Ethereal to capture packets, I see only packets to and
|
|
from my machine, or I'm not seeing all the traffic I'm expecting to
|
|
see from or to the machine I'm trying to monitor.
|
|
|
|
5.2 I can't see any TCP packets other than packets to and from my
|
|
machine, even though another analyzer on the network sees those
|
|
packets.
|
|
|
|
5.3 I'm only seeing ARP packets when I try to capture traffic.
|
|
|
|
5.4 I'm running Ethereal on Windows; why does some network interface
|
|
on my machine not show up in the list of interfaces in the
|
|
"Interface:" field in the dialog box popped up by "Capture->Start",
|
|
and/or why does Ethereal give me an error if I try to capture on that
|
|
interface?
|
|
|
|
5.5 I'm running Ethereal on Windows; why do no network interfaces show
|
|
up in the list of interfaces in the "Interface:" field in the dialog
|
|
box popped up by "Capture->Start"?
|
|
|
|
5.6 I'm running Ethereal on Windows; why doesn't my serial port/ADSL
|
|
modem/ISDN modem/show up in the list of interfaces in the "Interface:"
|
|
field in the dialog box popped up by "Capture->Start"?
|
|
|
|
5.7 I'm running Ethereal on a UNIX-flavored OS; why does some network
|
|
interface on my machine not show up in the list of interfaces in the
|
|
"Interface:" field in the dialog box popped up by "Capture->Start",
|
|
and/or why does Ethereal give me an error if I try to capture on that
|
|
interface?
|
|
|
|
5.8 I'm running Ethereal on a UNIX-flavored OS; why do no network
|
|
interfaces show up in the list of interfaces in the "Interface:" field
|
|
in the dialog box popped up by "Capture->Start"?
|
|
|
|
5.9 Can Ethereal capture on (my T1/E1 line, SS7 links, etc.)?
|
|
|
|
5.10 How do I put an interface into promiscuous mode?
|
|
|
|
5.11 I can set a display filter just fine, but capture filters don't
|
|
work.
|
|
|
|
5.12 I'm entering valid capture filters, but I still get "parse error"
|
|
errors.
|
|
|
|
5.13 I saved a filter and tried to use its name to filter the display,
|
|
but I got an "Unexpected end of filter string" error.
|
|
|
|
5.14 Why am I seeing lots of packets with incorrect TCP checksums?
|
|
|
|
5.15 I've just installed Ethereal, and the traffic on my local LAN is
|
|
boring.
|
|
|
|
5.16 When I run Ethereal on Solaris 8, it dies with a Bus Error when I
|
|
start it.
|
|
|
|
5.17 When I run Ethereal, I get an error
|
|
|
|
Gtk-CRITICAL **: file gtkwindow.c: line 3107 (gtk_window_resize):
|
|
assertion `height > 0' failed.
|
|
|
|
5.18 When I run Tethereal with the "-x" option, it crashes with an
|
|
error
|
|
|
|
"** ERROR **: file print.c: line 691 (print_line): should not be
|
|
reached.
|
|
|
|
5.19 When I run Ethereal on Windows NT, it dies with a Dr. Watson
|
|
error, reporting an "Integer division by zero" exception, when I start
|
|
it.
|
|
|
|
5.20 When I try to run Ethereal, it complains about
|
|
sprint_realloc_objid being undefined.
|
|
|
|
5.21 I'm running Ethereal on Linux; why do my time stamps have only
|
|
100ms resolution, rather than 1us resolution?
|
|
|
|
5.22 I'm capturing packets on {Windows 95, Windows 98, Windows Me};
|
|
why are the time stamps on packets wrong?
|
|
|
|
5.23 When I try to run Ethereal on Windows, it fails to run because it
|
|
can't find packet.dll.
|
|
|
|
5.24 I'm running Ethereal on Windows NT/2000/XP/Server; my machine has
|
|
a PPP (dial-up POTS, ISDN, etc.) interface, and it shows up in the
|
|
"Interface" item in the "Capture Options" dialog box. Why can no
|
|
packets be sent on or received from that network while I'm trying to
|
|
capture traffic on that interface?
|
|
|
|
5.25 I'm running Ethereal on Windows 95/98/Me, on a machine with more
|
|
than one network adapter of the same type; Ethereal shows all of those
|
|
adapters with the same name, but I can't use any of those adapters
|
|
other than the first one.
|
|
|
|
5.26 I'm running Ethereal on Windows, and I'm not seeing any traffic
|
|
being sent by the machine running Ethereal.
|
|
|
|
5.27 I'm trying to capture traffic but I'm not seeing any.
|
|
|
|
5.28 I have an XXX network card on my machine; if I try to capture on
|
|
it, my machine crashes or resets itself.
|
|
|
|
5.29 My machine crashes or resets itself when I select "Start" from
|
|
the "Capture" menu or select "Preferences" from the "Edit" menu.
|
|
|
|
5.30 Does Ethereal work on Windows Me?
|
|
|
|
5.31 Does Ethereal work on Windows XP?
|
|
|
|
5.32 Why doesn't Ethereal correctly identify RTP packets? It shows
|
|
them only as UDP.
|
|
|
|
5.33 Why doesn't Ethereal show Yahoo Messenger packets in captures
|
|
that contain Yahoo Messenger traffic?
|
|
|
|
5.34 Why do I get the error
|
|
|
|
Gdk-ERROR **: Palettized display (256-colour) mode not supported on
|
|
Windows.
|
|
aborting....
|
|
|
|
when I try to run Ethereal on Windows?
|
|
|
|
5.35 When I capture on Windows in promiscuous mode, I can see packets
|
|
other than those sent to or from my machine; however, those packets
|
|
show up with a "Short Frame" indication, unlike packets to or from my
|
|
machine. What should I do to arrange that I see those packets in their
|
|
entirety?
|
|
|
|
5.36 I'm capturing packets on a machine on a VLAN; why don't the
|
|
packets I'm capturing have VLAN tags?
|
|
|
|
5.37 How can I capture raw 802.11 packets, including non-data
|
|
(management, beacon) packets?
|
|
|
|
5.38 How do I capture on an 802.11 device in monitor mode on Linux?
|
|
|
|
5.39 How do I capture on an 802.11 device in monitor mode on FreeBSD?
|
|
|
|
5.40 How do I capture on an 802.11 device in monitor mode on NetBSD?
|
|
|
|
5.41 I'm trying to capture 802.11 traffic on Windows; why am I not
|
|
seeing any packets?
|
|
|
|
5.42 I'm trying to capture 802.11 traffic on Windows; why am I seeing
|
|
packets received by the machine on which I'm capturing traffic, but
|
|
not packets sent by that machine?
|
|
|
|
5.43 How can I capture packets with CRC errors?
|
|
|
|
5.44 How can I capture entire frames, including the FCS?
|
|
|
|
5.45 Ethereal hangs after I stop a capture.
|
|
|
|
5.46 How can I search for, or filter, packets that have a particular
|
|
string anywhere in them?
|
|
|
|
General Questions
|
|
|
|
Q 1.1: Where can I get help?
|
|
|
|
A: Support is available on the ethereal-users mailing list.
|
|
Subscription information and archives for all of Ethereal's mailing
|
|
lists can be found at http://www.ethereal.com/lists
|
|
|
|
Q 1.2: What protocols are currently supported?
|
|
|
|
A: There are currently 518 supported protocols and media, listed
|
|
below. Descriptions can be found in the ethereal(1) man page.
|
|
|
|
3GPP2 A11
|
|
802.1q Virtual LAN
|
|
802.1x Authentication
|
|
AAL type 2 signalling protocol - Capability set 1 (Q.2630.1)
|
|
AFS (4.0) Replication Server call declarations
|
|
AIM Administrative
|
|
AIM Advertisements
|
|
AIM Buddylist Service
|
|
AIM Chat Navigation
|
|
AIM Chat Service
|
|
AIM Directory Search
|
|
AIM Generic Service
|
|
AIM ICQ
|
|
AIM Invitation Service
|
|
AIM Location
|
|
AIM Messaging
|
|
AIM OFT
|
|
AIM Popup
|
|
AIM Privacy Management Service
|
|
AIM Server Side Info
|
|
AIM Signon
|
|
AIM Statistics
|
|
AIM Translate
|
|
AIM User Lookup
|
|
ANSI A-I/F BSMAP
|
|
ANSI A-I/F DTAP
|
|
ANSI IS-637-A (SMS) Teleservice Layer
|
|
ANSI IS-637-A (SMS) Transport Layer
|
|
ANSI IS-683-A (OTA (Mobile))
|
|
ANSI IS-801 (Location Services (PLD))
|
|
ANSI Mobile Application Part
|
|
AOL Instant Messenger
|
|
ARCNET
|
|
ATM
|
|
ATM AAL1
|
|
ATM AAL3/4
|
|
ATM LAN Emulation
|
|
ATM OAM AAL
|
|
AVS WLAN Capture header
|
|
Ad hoc On-demand Distance Vector Routing Protocol
|
|
Address Resolution Protocol
|
|
Aggregate Server Access Protocol
|
|
Alert Standard Forum
|
|
Alteon - Transparent Proxy Cache Protocol
|
|
Andrew File System (AFS)
|
|
Apache JServ Protocol v1.3
|
|
Apple IP-over-IEEE 1394
|
|
AppleTalk Filing Protocol
|
|
AppleTalk Session Protocol
|
|
AppleTalk Transaction Protocol packet
|
|
Appletalk Address Resolution Protocol
|
|
Application Configuration Access Protocol
|
|
Async data over ISDN (V.120)
|
|
Authentication Header
|
|
BACnet Virtual Link Control
|
|
BEA Tuxedo
|
|
BSS GPRS Protocol
|
|
BSSAP/BSAP
|
|
Banyan Vines ARP
|
|
Banyan Vines Echo
|
|
Banyan Vines Fragmentation Protocol
|
|
Banyan Vines ICP
|
|
Banyan Vines IP
|
|
Banyan Vines IPC
|
|
Banyan Vines LLC
|
|
Banyan Vines RTP
|
|
Banyan Vines SPP
|
|
Basic Encoding Rules (ASN.1 X.690)
|
|
Bearer Independent Call Control
|
|
Bi-directional Fault Detection Control Message
|
|
Blocks Extensible Exchange Protocol
|
|
Boardwalk
|
|
Boot Parameters
|
|
Bootstrap Protocol
|
|
Border Gateway Protocol
|
|
Building Automation and Control Network APDU
|
|
Building Automation and Control Network NPDU
|
|
CCSDS
|
|
CDS Clerk Server Calls
|
|
Cast Client Control Protocol
|
|
Check Point High Availability Protocol
|
|
Checkpoint FW-1
|
|
Cisco Auto-RP
|
|
Cisco Discovery Protocol
|
|
Cisco Group Management Protocol
|
|
Cisco HDLC
|
|
Cisco Hot Standby Router Protocol
|
|
Cisco ISL
|
|
Cisco Interior Gateway Routing Protocol
|
|
Cisco NetFlow
|
|
Cisco SLARP
|
|
Clearcase NFS
|
|
CoSine IPNOS L2 debug output
|
|
Common Open Policy Service
|
|
Common Unix Printing System (CUPS) Browsing Protocol
|
|
Compuserve GIF
|
|
Connectionless Lightweight Directory Access Protocol
|
|
Cross Point Frame Injector
|
|
DCE Distributed Time Service Local Server
|
|
DCE Distributed Time Service Provider
|
|
DCE Name Service
|
|
DCE RPC
|
|
DCE Security ID Mapper
|
|
DCE/RPC BOS Server
|
|
DCE/RPC BUDB
|
|
DCE/RPC BUTC
|
|
DCE/RPC CDS Solicitation
|
|
DCE/RPC Conversation Manager
|
|
DCE/RPC Directory Acl Interface
|
|
DCE/RPC Endpoint Mapper
|
|
DCE/RPC Endpoint Mapper4
|
|
DCE/RPC FLDB
|
|
DCE/RPC FLDB UBIK TRANSFER
|
|
DCE/RPC FLDB UBIKVOTE
|
|
DCE/RPC ICL RPC
|
|
DCE/RPC Kerberos V
|
|
DCE/RPC NCS 1.5.1 Local Location Broker
|
|
DCE/RPC Operations between registry server replicas
|
|
DCE/RPC Prop Attr
|
|
DCE/RPC RS_ACCT
|
|
DCE/RPC RS_BIND
|
|
DCE/RPC RS_MISC
|
|
DCE/RPC RS_PROP_ACCT
|
|
DCE/RPC RS_UNIX
|
|
DCE/RPC Registry Password Management
|
|
DCE/RPC Registry Server Attributes Schema
|
|
DCE/RPC Registry server propagation interface - ACLs.
|
|
DCE/RPC Registry server propagation interface - PGO items
|
|
DCE/RPC Registry server propagation interface - properties and poli
|
|
cies
|
|
DCE/RPC Remote Management
|
|
DCE/RPC Repserver Calls
|
|
DCE/RPC TokenServer Calls
|
|
DCE/RPC UpServer
|
|
DCOM OXID Resolver
|
|
DCOM Remote Activation
|
|
DEC Spanning Tree Protocol
|
|
DFS Calls
|
|
DHCPv6
|
|
DICOM
|
|
DNS Control Program Server
|
|
Data
|
|
Data Link SWitching
|
|
Data Stream Interface
|
|
Datagram Delivery Protocol
|
|
Diameter Protocol
|
|
Distance Vector Multicast Routing Protocol
|
|
Distcc Distributed Compiler
|
|
Distributed Checksum Clearinghouse Protocol
|
|
Distributed Network Protocol 3.0
|
|
Domain Name Service
|
|
Dynamic DNS Tools Protocol
|
|
Echo
|
|
Encapsulating Security Payload
|
|
Endpoint Name Resolution Protocol
|
|
Enhanced Interior Gateway Routing Protocol
|
|
EtherNet/IP (Industrial Protocol)
|
|
Ethernet
|
|
Ethernet over IP
|
|
Extensible Authentication Protocol
|
|
FC Extended Link Svc
|
|
FC Fabric Configuration Server
|
|
FCIP
|
|
FTP Data
|
|
FTServer Operations
|
|
Fiber Distributed Data Interface
|
|
Fibre Channel
|
|
Fibre Channel Common Transport
|
|
Fibre Channel Fabric Zone Server
|
|
Fibre Channel Name Server
|
|
Fibre Channel Protocol for SCSI
|
|
Fibre Channel SW_ILS
|
|
Fibre Channel Security Protocol
|
|
Fibre Channel Single Byte Command
|
|
File Transfer Protocol (FTP)
|
|
Financial Information eXchange Protocol
|
|
Frame
|
|
Frame Relay
|
|
GARP Multicast Registration Protocol
|
|
GARP VLAN Registration Protocol
|
|
GPRS Network service
|
|
GPRS Tunneling Protocol
|
|
GSM A-I/F BSSMAP
|
|
GSM A-I/F DTAP
|
|
GSM A-I/F RP
|
|
GSM Mobile Application Part
|
|
GSM SMS TPDU (GSM 03.40)
|
|
GSM Short Message Service User Data
|
|
General Inter-ORB Protocol
|
|
Generic Routing Encapsulation
|
|
Generic Security Service Application Program Interface
|
|
Gnutella Protocol
|
|
H225
|
|
H235-SECURITY-MESSAGES
|
|
H245
|
|
H4501
|
|
HP Extended Local-Link Control
|
|
HP Remote Maintenance Protocol
|
|
Hummingbird NFS Daemon
|
|
HyperSCSI
|
|
Hypertext Transfer Protocol
|
|
ICQ Protocol
|
|
IEEE 802.11 Radiotap Capture header
|
|
IEEE 802.11 wireless LAN
|
|
IEEE 802.11 wireless LAN management frame
|
|
ILMI
|
|
IP Device Control (SS7 over IP)
|
|
IP Over FC
|
|
IP Payload Compression
|
|
IP Virtual Services Sync Daemon
|
|
IPX Message
|
|
IPX Routing Information Protocol
|
|
IPX WAN
|
|
ISDN
|
|
ISDN Q.921-User Adaptation Layer
|
|
ISDN User Part
|
|
ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
|
|
ISO 8073 COTP Connection-Oriented Transport Protocol
|
|
ISO 8327-1 OSI Session Protocol
|
|
ISO 8473 CLNP ConnectionLess Network Protocol
|
|
ISO 8602 CLTP ConnectionLess Transport Protocol
|
|
ISO 8823 OSI Presentation Protocol
|
|
ISO 9542 ESIS Routeing Information Exchange Protocol
|
|
ITU-T E.164 number
|
|
ITU-T Recommendation H.261
|
|
ITU-T Recommendation H.263 RTP Payload header (RFC2190)
|
|
InMon sFlow
|
|
Intel ANS probe
|
|
Intelligent Platform Management Interface
|
|
Inter-Access-Point Protocol
|
|
Inter-Asterisk eXchange v2
|
|
InterSwitch Message Protocol
|
|
Interbase
|
|
Internet Cache Protocol
|
|
Internet Content Adaptation Protocol
|
|
Internet Control Message Protocol
|
|
Internet Control Message Protocol v6
|
|
Internet Group Management Protocol
|
|
Internet Group membership Authentication Protocol
|
|
Internet Message Access Protocol
|
|
Internet Printing Protocol
|
|
Internet Protocol
|
|
Internet Protocol Version 6
|
|
Internet Relay Chat
|
|
Internet Security Association and Key Management Protocol
|
|
Internetwork Packet eXchange
|
|
JPEG File Interchange Format
|
|
Jabber XML Messaging
|
|
Java RMI
|
|
Java Serialization
|
|
Kerberos
|
|
Kerberos Administration
|
|
Kernel Lock Manager
|
|
LWAP Control Message
|
|
LWAPP Encapsulated Packet
|
|
LWAPP Layer 3 Packet
|
|
Label Distribution Protocol
|
|
Laplink
|
|
Layer 2 Tunneling Protocol
|
|
Lightweight Directory Access Protocol
|
|
Line Printer Daemon Protocol
|
|
Line-based text data
|
|
Link Access Procedure Balanced (LAPB)
|
|
Link Access Procedure Balanced Ethernet (LAPBETHER)
|
|
Link Access Procedure, Channel D (LAPD)
|
|
Link Aggregation Control Protocol
|
|
Link Management Protocol (LMP)
|
|
Linux cooked-mode capture
|
|
Local Management Interface
|
|
LocalTalk Link Access Protocol
|
|
Logical Link Control GPRS
|
|
Logical-Link Control
|
|
Lucent/Ascend debug output
|
|
MDS Header
|
|
MIME Multipart Media Encapsulation
|
|
MMS Message Encapsulation
|
|
MS Kpasswd
|
|
MS Proxy Protocol
|
|
MSN Messenger Service
|
|
MSNIP: Multicast Source Notification of Interest Protocol
|
|
MTP 2 Transparent Proxy
|
|
MTP 2 User Adaptation Layer
|
|
MTP 3 User Adaptation Layer
|
|
MTP2 Peer Adaptation Layer
|
|
Media Type
|
|
Media Type: message/http
|
|
Message Transfer Part Level 2
|
|
Message Transfer Part Level 3
|
|
Message Transfer Part Level 3 Management
|
|
Microsoft Directory Replication Service
|
|
Microsoft Distributed File System
|
|
Microsoft Distributed Link Tracking Server Service
|
|
Microsoft Encrypted File System Service
|
|
Microsoft Exchange MAPI
|
|
Microsoft Local Security Architecture
|
|
Microsoft Local Security Architecture (Directory Services)
|
|
Microsoft Messenger Service
|
|
Microsoft Network Logon
|
|
Microsoft Registry
|
|
Microsoft Security Account Manager
|
|
Microsoft Server Service
|
|
Microsoft Service Control
|
|
Microsoft Spool Subsystem
|
|
Microsoft Task Scheduler Service
|
|
Microsoft Telephony API Service
|
|
Microsoft Windows Browser Protocol
|
|
Microsoft Windows Lanman Remote API Protocol
|
|
Microsoft Windows Logon Protocol
|
|
Microsoft Workstation Service
|
|
Mobile IP
|
|
Mobile IPv6
|
|
Modbus/TCP
|
|
Mount Service
|
|
MultiProtocol Label Switching Header
|
|
Multicast Router DISCovery protocol
|
|
Multicast Source Discovery Protocol
|
|
Multiprotocol Label Switching Echo
|
|
MySQL Protocol
|
|
NFSACL
|
|
NFSAUTH
|
|
NIS+
|
|
NIS+ Callback
|
|
NSPI
|
|
NTLM Secure Service Provider
|
|
Name Binding Protocol
|
|
Name Management Protocol over IPX
|
|
NetBIOS
|
|
NetBIOS Datagram Service
|
|
NetBIOS Name Service
|
|
NetBIOS Session Service
|
|
NetBIOS over IPX
|
|
NetWare Core Protocol
|
|
NetWare Link Services Protocol
|
|
NetWare Serialization Protocol
|
|
Network Data Management Protocol
|
|
Network File System
|
|
Network Lock Manager Protocol
|
|
Network News Transfer Protocol
|
|
Network Status Monitor CallBack Protocol
|
|
Network Status Monitor Protocol
|
|
Network Time Protocol
|
|
Nortel SONMP
|
|
Novell Distributed Print System
|
|
Novell Modular Authentication Service
|
|
Null/Loopback
|
|
OSI ISO 8571 FTAM Protocol
|
|
OSI ISO/IEC 10035-1 ACSE Protocol
|
|
Open Shortest Path First
|
|
OpenBSD Encapsulating device
|
|
OpenBSD Packet Filter log file
|
|
OpenBSD Packet Filter log file, pre 3.4
|
|
Optimized Link State Routing Protocol
|
|
PC NFS
|
|
POSTGRESQL
|
|
PPP Bandwidth Allocation Control Protocol
|
|
PPP Bandwidth Allocation Protocol
|
|
PPP CDP Control Protocol
|
|
PPP Callback Control Protocol
|
|
PPP Challenge Handshake Authentication Protocol
|
|
PPP Compressed Datagram
|
|
PPP Compression Control Protocol
|
|
PPP IP Control Protocol
|
|
PPP IPv6 Control Protocol
|
|
PPP Link Control Protocol
|
|
PPP MPLS Control Protocol
|
|
PPP Multilink Protocol
|
|
PPP Multiplexing
|
|
PPP OSI Control Protocol
|
|
PPP Password Authentication Protocol
|
|
PPP VJ Compression
|
|
PPP-over-Ethernet Discovery
|
|
PPP-over-Ethernet Session
|
|
PPPMux Control Protocol
|
|
Packed Encoding Rules (ASN.1 X.691)
|
|
PacketCable
|
|
Point-to-Point Protocol
|
|
Point-to-Point Tunnelling Protocol
|
|
Portmap
|
|
Post Office Protocol
|
|
Pragmatic General Multicast
|
|
Precision Time Protocol (IEEE1588)
|
|
Prism
|
|
Privilege Server operations
|
|
Protocol Independent Multicast
|
|
Q.2931
|
|
Q.931
|
|
Q.933
|
|
Quake II Network Protocol
|
|
Quake III Arena Network Protocol
|
|
Quake Network Protocol
|
|
QuakeWorld Network Protocol
|
|
Qualified Logical Link Control
|
|
RFC 2250 MPEG1
|
|
RFC 2833 RTP Event
|
|
RIPng
|
|
RPC Browser
|
|
RS Interface properties
|
|
RSTAT
|
|
RSYNC File Synchroniser
|
|
RX Protocol
|
|
Radio Access Network Application Part
|
|
Radius Protocol
|
|
Raw packet data
|
|
Real Time Streaming Protocol
|
|
Real-Time Publish-Subscribe Wire Protocol
|
|
Real-Time Transport Protocol
|
|
Real-time Transport Control Protocol
|
|
Registry Server Attributes Manipulation Interface
|
|
Registry server administration operations.
|
|
Remote Management Control Protocol
|
|
Remote Override interface
|
|
Remote Procedure Call
|
|
Remote Program Load
|
|
Remote Quota
|
|
Remote Shell
|
|
Remote Shutdown
|
|
Remote Wall protocol
|
|
Remote sec_login preauth interface.
|
|
Resource ReserVation Protocol (RSVP)
|
|
Rlogin Protocol
|
|
Routing Information Protocol
|
|
Routing Table Maintenance Protocol
|
|
SADMIND
|
|
SCSI
|
|
SEBEK - Kernel Data Capture
|
|
SGI Mount Service
|
|
SMB (Server Message Block Protocol)
|
|
SMB MailSlot Protocol
|
|
SMB Pipe Protocol
|
|
SNA-over-Ethernet
|
|
SNMP Multiplex Protocol
|
|
SPNEGO-KRB5
|
|
SPRAY
|
|
SS7 SCCP-User Adaptation Layer
|
|
SSCOP
|
|
SSH Protocol
|
|
Secure Socket Layer
|
|
Sequenced Packet eXchange
|
|
Service Advertisement Protocol
|
|
Service Location Protocol
|
|
Session Announcement Protocol
|
|
Session Description Protocol
|
|
Session Initiation Protocol
|
|
Session Initiation Protocol (SIP as raw text)
|
|
Short Message Peer to Peer
|
|
Signaling Compression
|
|
Signalling Connection Control Part
|
|
Signalling Connection Control Part Management
|
|
Simple Mail Transfer Protocol
|
|
Simple Network Management Protocol
|
|
Simple Traversal of UDP Through NAT
|
|
Sinec H1 Protocol
|
|
Sipfrag
|
|
Skinny Client Control Protocol
|
|
SliMP3 Communication Protocol
|
|
Socks Protocol
|
|
SoulSeek Protocol
|
|
Spanning Tree Protocol
|
|
Spnego
|
|
Stream Control Transmission Protocol
|
|
Subnetwork Dependent Convergence Protocol
|
|
Symantec Enterprise Firewall
|
|
Synchronous Data Link Control (SDLC)
|
|
Syslog message
|
|
Systems Network Architecture
|
|
Systems Network Architecture XID
|
|
T38
|
|
TACACS
|
|
TACACS+
|
|
TEI Management Procedure, Channel D (LAPD)
|
|
TEREDO Tunneling IPv6 over UDP through NATs
|
|
TPKT
|
|
Tabular Data Stream
|
|
Tazmen Sniffer Protocol
|
|
Telnet
|
|
Time Protocol
|
|
Time Synchronization Protocol
|
|
Token-Ring
|
|
Token-Ring Media Access Control
|
|
Transaction Capabilities Application Part
|
|
Transmission Control Protocol
|
|
Transparent Network Substrate Protocol
|
|
Trivial File Transfer Protocol
|
|
UDP Encapsulation of IPsec Packets
|
|
Universal Computer Protocol
|
|
User Datagram Protocol
|
|
Virtual Router Redundancy Protocol
|
|
Virtual Trunking Protocol
|
|
WAP Binary XML
|
|
WAP Session Initiation Request
|
|
Web Cache Coordination Protocol
|
|
WebSphere MQ
|
|
WebSphere MQ Programmable Command Formats
|
|
Wellfleet Breath of Life
|
|
Wellfleet Compression
|
|
Wellfleet HDLC
|
|
Who
|
|
Windows 2000 DNS
|
|
Wireless Session Protocol
|
|
Wireless Transaction Protocol
|
|
Wireless Transport Layer Security
|
|
X Display Manager Control Protocol
|
|
X.25
|
|
X.25 over TCP
|
|
X.29
|
|
X11
|
|
Xyplex
|
|
Yahoo Messenger Protocol
|
|
Yahoo YMSG Messenger Protocol
|
|
Yellow Pages Bind
|
|
Yellow Pages Passwd
|
|
Yellow Pages Service
|
|
Yellow Pages Transfer
|
|
Zebra Protocol
|
|
Zone Information Protocol
|
|
eDonkey Protocol
|
|
giFT Internet File Transfer
|
|
iSCSI
|
|
iSNS
|
|
|
|
Q 1.3: Are there any plans to support {your favorite protocol}?
|
|
|
|
A: Support for particular protocols is added to Ethereal as a result
|
|
of people contributing that support; no formal plans for adding
|
|
support for particular protocols in particular future releases exist.
|
|
|
|
Q 1.4: Can Ethereal read capture files from {your favorite network
|
|
analyzer}?
|
|
|
|
A: Support for particular protocols is added to Ethereal as a result
|
|
of people contributing that support; no formal plans for adding
|
|
support for particular protocols in particular future releases exist.
|
|
|
|
If a network analyzer writes out files in a format already supported
|
|
by Ethereal (e.g., in libpcap format), Ethereal may already be able to
|
|
read them, unless the analyzer has added its own proprietary
|
|
extensions to that format.
|
|
|
|
If a network analyzer writes out files in its own format, or has added
|
|
proprietary extensions to another format, in order to make Ethereal
|
|
read captures from that network analyzer, we would either have to have
|
|
a specification for the file format, or the extensions, sufficient to
|
|
give us enough information to read the parts of the file relevant to
|
|
Ethereal, or would need at least one capture file in that format AND a
|
|
detailed textual analysis of the packets in that capture file (showing
|
|
packet time stamps, packet lengths, and the top-level packet header)
|
|
in order to reverse-engineer the file format.
|
|
|
|
Note that there is no guarantee that we will be able to
|
|
reverse-engineer a capture file format.
|
|
|
|
Q 1.5: What devices can Ethereal use to capture packets?
|
|
|
|
A: Ethereal can read live data from Ethernet, Token-Ring, FDDI, serial
|
|
(PPP and SLIP) (if the OS on which it's running allows Ethereal to do
|
|
so), 802.11 wireless LAN (if the OS on which it's running allows
|
|
Ethereal to do so), ATM connections (if the OS on which it's running
|
|
allows Ethereal to do so), and the "any" device supported on Linux by
|
|
recent versions of libpcap. See the list of supported capture media on
|
|
various OSes for details (several items in there say "Unknown", which
|
|
doesn't mean "Ethereal can't capture on them", it means "we don't know
|
|
whether it can capture on them"; we expect that it will be able to
|
|
capture on many of them, but we haven't tried it ourselves - if you
|
|
try one of those types and it works, please send an update to
|
|
_EWEB_MAILTO).
|
|
|
|
It can also read a variety of capture file formats, including:
|
|
* libpcap/tcpdump
|
|
* Sun snoop/atmsnoop
|
|
* Shomiti/Finisar Surveyor
|
|
* LanAlyzer
|
|
* DOS-based Sniffer (compressed and uncompressed)
|
|
* MS Network Monitor
|
|
* AIX iptrace
|
|
* NetXray and Windows-based Sniffer
|
|
* EtherPeek/TokenPeek/AiroPeek
|
|
* RADCOM WAN/LAN analyzer
|
|
* Lucent/Ascend debug output
|
|
* Toshiba ISDN router "snoop" output
|
|
* HPUX nettl
|
|
* ISDN4BSD "i4btrace" utility.
|
|
* Cisco Secure IDS
|
|
* pppd log files (pppdump format)
|
|
* VMS TCPIPtrace
|
|
* DBS Etherwatch
|
|
* Visual Networks' Visual UpTime
|
|
* CoSine L2 debug
|
|
|
|
so that it can read traces from various network types, as captured by
|
|
other applications or equipment, even if it cannot itself capture on
|
|
those network types.
|
|
|
|
Q 1.6: How do you pronounce Ethereal? Where did the name come from?
|
|
|
|
A: The English pronunciation can be found in Merriam-Webster's online
|
|
dictionary at
|
|
http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=ethereal.
|
|
|
|
According to the book "Computer Networks" by Andrew Tannenbaum,
|
|
Ethernet was named after the "luminiferous ether" which was once
|
|
thought to carry electromagnetic radiation. Taking that into
|
|
consideration, Ethereal seemed like an appropriate name for something
|
|
that started out as an Ethernet analyzer.
|
|
|
|
Downloading Ethereal
|
|
|
|
Q 2.1: I downloaded the Win32 installer, but when I try to run it, I
|
|
get an error.
|
|
|
|
A: The program you used to download it may have downloaded it
|
|
incorrectly. Web browsers sometimes may do this.
|
|
|
|
Try downloading it with, for example:
|
|
* Wget, for which Windows binaries are available on the SunSITE FTP
|
|
server at sunsite.tk or Heiko Herold's windows wget spot - wGetGUI
|
|
offers a GUI interface that uses wget;
|
|
* WS_FTP from Ipswitch,
|
|
* the ftp command that comes with Windows.
|
|
|
|
If you use the ftp command, make sure you do the transfer in binary
|
|
mode rather than ASCII mode, by using the binary command before
|
|
transferring the file.
|
|
|
|
Q 2.2: When I try to download the WinPcap driver and library, I can't
|
|
get to the WinPcap Web site.
|
|
|
|
A: As is the case with all Web sites, that site won't necessarily
|
|
always be accessible; the server may be down due to a problem or down
|
|
for maintenance, or there may be a networking problem between you and
|
|
the server. You should try again later, or try the local mirror or the
|
|
Wiretapped.net mirror.
|
|
|
|
Installing Ethereal
|
|
|
|
Q 3.1: I installed an Ethereal RPM, but Ethereal doesn't seem to be
|
|
installed; only Tethereal is installed.
|
|
|
|
A: Older versions of the Red Hat RPMs for Ethereal put only the
|
|
non-GUI components into the ethereal RPM, the fact that Ethereal is a
|
|
GUI program nonwithstanding; newer versions make it a bit clearer by
|
|
giving that RPM a name starting with ethereal-base.
|
|
|
|
In those older versions, there's a separate ethereal-gnome RPM that
|
|
includes GUI components such as Ethereal itself, the fact that
|
|
Ethereal doesn't use GNOME nonwithstanding; newer versions make it a
|
|
bit clearer by giving that RPM a name starting with ethereal-gtk+.
|
|
|
|
Find the ethereal-gnome or ethereal-gtk+ RPM, and install that also.
|
|
|
|
Building Ethereal
|
|
|
|
Q 4.1: The configure script can't find pcap.h or bpf.h, but I have
|
|
libpcap installed.
|
|
|
|
A: Are you sure pcap.h and bpf.h are installed? The official
|
|
distribution of libpcap only installs the libpcap.a library file when
|
|
"make install" is run. To install pcap.h and bpf.h, you must run "make
|
|
install-incl". If you're running Debian or Redhat, make sure you have
|
|
the "libpcap-dev" or "libpcap-devel" packages installed.
|
|
|
|
It's also possible that pcap.h and bpf.h have been installed in a
|
|
strange location. If this is the case, you may have to tweak
|
|
aclocal.m4.
|
|
|
|
Q 4.2: Why do I get the error
|
|
|
|
dftest_DEPENDENCIES was already defined in condition TRUE, which
|
|
implies condition HAVE_PLUGINS_TRUE
|
|
|
|
when I try to build Ethereal from SVN or a SVN snapshot?
|
|
|
|
A: You probably have automake 1.5 installed on your machine (the
|
|
command automake --version will report the version of automake on your
|
|
machine). There is a bug in that version of automake that causes this
|
|
problem; upgrade to a later version of automake (1.6 or later).
|
|
|
|
Q 4.3: The link fails with a number of "Output line too long."
|
|
messages followed by linker errors.
|
|
|
|
A: The version of the sed command on your system is incapable of
|
|
handling very long lines. On Solaris, for example, /usr/bin/sed has a
|
|
line length limit too low to allow libtool to work; /usr/xpg4/bin/sed
|
|
can handle it, as can GNU sed if you have it installed.
|
|
|
|
On Solaris, changing your command search path to search /usr/xpg4/bin
|
|
before /usr/bin should make the problem go away; on any platform on
|
|
which you have this problem, installing GNU sed and changing your
|
|
command path to search the directory in which it is installed before
|
|
searching the directory with the version of sed that came with the OS
|
|
should make the problem go away.
|
|
|
|
Q 4.4: The link fails on Solaris because plugin_list is undefined.
|
|
|
|
A: This appears to be due to a problem with some versions of the GTK+
|
|
and GLib packages from www.sunfreeware.org; un-install those packages,
|
|
and try getting the 1.2.10 versions from that site, or the versions
|
|
from The Written Word, or the versions from Sun's GNOME distribution,
|
|
or the versions from the supplemental software CD that comes with the
|
|
Solaris media kit, or build them from source from the GTK Web site.
|
|
Then re-run the configuration script, and try rebuilding Ethereal. (If
|
|
you get the 1.2.10 versions from www.sunfreeware.org, and the problem
|
|
persists, un-install them and try installing one of the other versions
|
|
mentioned.)
|
|
|
|
Q 4.5: The build fails on Windows because of conflicts between
|
|
winsock.h and winsock2.h.
|
|
|
|
A: As of Ethereal 0.9.5, you must install WinPcap 2.3 or later, and
|
|
the corresponding version of the developer's pack, in order to be able
|
|
to compile Ethereal; it will not compile with older versions of the
|
|
developer's pack. The symptoms of this failure are conflicts between
|
|
definitions in winsock.h and in winsock2.h; Ethereal uses winsock2.h,
|
|
but pre-2.3 versions of the WinPcap developer's packet use winsock.h.
|
|
(2.3 uses winsock2.h, so if Ethereal were to use winsock.h, it would
|
|
not be able to build with current versions of the WinPcap developer's
|
|
pack.)
|
|
|
|
Note that the installed version of the developer's pack should be the
|
|
same version as the version of WinPcap you have installed.
|
|
|
|
Using Ethereal
|
|
|
|
Q 5.1: When I use Ethereal to capture packets, I see only packets to
|
|
and from my machine, or I'm not seeing all the traffic I'm expecting
|
|
to see from or to the machine I'm trying to monitor.
|
|
|
|
A: This might be because the interface on which you're capturing is
|
|
plugged into a switch; on a switched network, unicast traffic between
|
|
two ports will not necessarily appear on other ports - only broadcast
|
|
and multicast traffic will be sent to all ports.
|
|
|
|
Note that even if your machine is plugged into a hub, the "hub" may be
|
|
a switched hub, in which case you're still on a switched network.
|
|
|
|
Note also that on the Linksys Web site, they say that their
|
|
auto-sensing hubs "broadcast the 10Mb packets to the port that operate
|
|
at 10Mb only and broadcast the 100Mb packets to the ports that operate
|
|
at 100Mb only", which would indicate that if you sniff on a 10Mb port,
|
|
you will not see traffic coming sent to a 100Mb port, and vice versa.
|
|
This problem has also been reported for Netgear dual-speed hubs, and
|
|
may exist for other "auto-sensing" or "dual-speed" hubs.
|
|
|
|
Some switches have the ability to replicate all traffic on all ports
|
|
to a single port so that you can plug your analyzer into that single
|
|
port to sniff all traffic. You would have to check the documentation
|
|
for the switch to see if this is possible and, if so, to see how to do
|
|
this. See, for example:
|
|
* this documentation from Cisco on the Switched Port Analyzer (SPAN)
|
|
feature on Catalyst switches;
|
|
* documentation from HP on how to set "monitoring"/"mirroring" on
|
|
ports on the console for HP Advancestack Switch 208 and 224;
|
|
* the "Network Monitoring Port Features" section of chapter 6 of
|
|
documentation from HP for HP ProCurve Switches 1600M, 2424M,
|
|
4000M, and 8000M;
|
|
* the "Switch Port-Mirroring" section of chapter 6 of documentation
|
|
from Extreme Networks for their Summit 200 switches;
|
|
* the documentation on "Configuring Port Mirroring and Monitoring"
|
|
in Foundry Networks' documentation for their FastIron Edge
|
|
Switches;
|
|
* the documentation on "Configuring Port Mirroring and Monitoring"
|
|
in Foundry Networks' documentation for their BigIron MG8 Layer 3
|
|
Switches;
|
|
* the "Port Monitor" subsection of the "Status Monitor and
|
|
Statistics" section of the documentation from Foundry Networks for
|
|
their EdgeIron 4802F and 10GC2F switches;
|
|
* the "Configuring Port Mirroring" section of chapter 3 of the
|
|
documentation from Foundry Networks for their EdgeIron 24G,
|
|
2402CF, and 4802CF switches;
|
|
* the documentation on "Configuring Port Mirroring and Monitoring"
|
|
in Foundry Networks' documentation for their other switches and
|
|
metro routers.
|
|
|
|
Note also that many firewall/NAT boxes have a switch built into them;
|
|
this includes many of the "cable/DSL router" boxes. If you have a box
|
|
of that sort, that has a switch with some number of Ethernet ports
|
|
into which you plug machines on your network, and another Ethernet
|
|
port used to connect to a cable or DSL modem, you can, at least, sniff
|
|
traffic between the machines on your network and the Internet by
|
|
plugging the Ethernet port on the router going to the modem, the
|
|
Ethernet port on the modem, and the machine on which you're running
|
|
Ethereal into a hub (make sure it's not a switching hub, and that, if
|
|
it's a dual-speed hub, all three of those ports are running at the
|
|
same speed.
|
|
|
|
If your machine is not plugged into a switched network or a dual-speed
|
|
hub, or it is plugged into a switched network but the port is set up
|
|
to have all traffic replicated to it, the problem might be that the
|
|
network interface on which you're capturing doesn't support
|
|
"promiscuous" mode, or because your OS can't put the interface into
|
|
promiscuous mode. Normally, network interfaces supply to the host
|
|
only:
|
|
* packets sent to one of that host's link-layer addresses;
|
|
* broadcast packets;
|
|
* multicast packets sent to a multicast address that the host has
|
|
configured the interface to accept.
|
|
|
|
Most network interfaces can also be put in "promiscuous" mode, in
|
|
which they supply to the host all network packets they see. Ethereal
|
|
will try to put the interface on which it's capturing into promiscuous
|
|
mode unless the "Capture packets in promiscuous mode" option is turned
|
|
off in the "Capture Options" dialog box, and Tethereal will try to put
|
|
the interface on which it's capturing into promiscuous mode unless the
|
|
-p option was specified. However, some network interfaces don't
|
|
support promiscuous mode, and some OSes might not allow interfaces to
|
|
be put into promiscuous mode.
|
|
|
|
If the interface is not running in promiscuous mode, it won't see any
|
|
traffic that isn't intended to be seen by your machine. It will see
|
|
broadcast packets, and multicast packets sent to a multicast MAC
|
|
address the interface is set up to receive.
|
|
|
|
You should ask the vendor of your network interface whether it
|
|
supports promiscuous mode. If it does, you should ask whoever supplied
|
|
the driver for the interface (the vendor, or the supplier of the OS
|
|
you're running on your machine) whether it supports promiscuous mode
|
|
with that network interface.
|
|
|
|
In the case of token ring interfaces, the drivers for some of them, on
|
|
Windows, may require you to enable promiscuous mode in order to
|
|
capture in promiscuous mode. Ask the vendor of the card how to do
|
|
this, or see, for example, this information on promiscuous mode on
|
|
some Madge token ring adapters (note that those cards can have
|
|
promiscuous mode disabled permanently, in which case you can't enable
|
|
it).
|
|
|
|
In the case of wireless LAN interfaces, it appears that, when those
|
|
interfaces are promiscuously sniffing, they're running in a
|
|
significantly different mode from the mode that they run in when
|
|
they're just acting as network interfaces (to the extent that it would
|
|
be a significant effor for those drivers to support for promiscuously
|
|
sniffing and acting as regular network interfaces at the same time),
|
|
so it may be that Windows drivers for those interfaces don't support
|
|
promiscuous mode.
|
|
|
|
Q 5.2: I can't see any TCP packets other than packets to and from my
|
|
machine, even though another analyzer on the network sees those
|
|
packets.
|
|
|
|
A: You're probably not seeing any packets other than unicast packets
|
|
to or from your machine, and broadcast and multicast packets; a switch
|
|
will normally send to a port only unicast traffic sent to the MAC
|
|
address for the interface on that port, and broadcast and multicast
|
|
traffic - it won't send to that port unicast traffic sent to a MAC
|
|
address for some other interface - and a network interface not in
|
|
promiscuous mode will receive only unicast traffic sent to the MAC
|
|
address for that interface, broadcast traffic, and multicast traffic
|
|
sent to a multicast MAC address the interface is set up to receive.
|
|
|
|
TCP doesn't use broadcast or multicast, so you will only see your own
|
|
TCP traffic, but UDP services may use broadcast or multicast so you'll
|
|
see some UDP traffic - however, this is not a problem with TCP
|
|
traffic, it's a problem with unicast traffic, as you also won't see
|
|
all UDP traffic between other machines.
|
|
|
|
I.e., this is probably the same question as this earlier one; see the
|
|
response to that question.
|
|
|
|
Q 5.3: I'm only seeing ARP packets when I try to capture traffic.
|
|
|
|
A: You're probably on a switched network, and running Ethereal on a
|
|
machine that's not sending traffic to the switch and not being sent
|
|
any traffic from other machines on the switch. ARP packets are often
|
|
broadcast packets, which are sent to all switch ports.
|
|
|
|
I.e., this is probably the same question as this earlier one; see the
|
|
response to that question.
|
|
|
|
Q 5.4: I'm running Ethereal on Windows; why does some network
|
|
interface on my machine not show up in the list of interfaces in the
|
|
"Interface:" field in the dialog box popped up by "Capture->Start",
|
|
and/or why does Ethereal give me an error if I try to capture on that
|
|
interface?
|
|
|
|
A: If you are running Ethereal on Windows NT 4.0, Windows 2000,
|
|
Windows XP, or Windows Server, and this is the first time you have run
|
|
a WinPcap-based program (such as Ethereal, or Tethereal, or WinDump,
|
|
or Analyzer, or...) since the machine was rebooted, you need to run
|
|
that program from an account with administrator privileges; once you
|
|
have run such a program, you will not need administrator privileges to
|
|
run any such programs until you reboot.
|
|
|
|
If you are running on Windows 95/98/Me, or if you are running on
|
|
Windows NT 4.0/2000/XP/Server and have administrator privileges or a
|
|
WinPcap-based program has been run with those privileges since the
|
|
machine rebooted, then note that Ethereal relies on the WinPcap
|
|
library, on the WinPcap device driver, and on the facilities that come
|
|
with the OS on which it's running in order to do captures.
|
|
|
|
Therefore, if the OS, the WinPcap library, or the WinPcap driver don't
|
|
support capturing on a particular network interface device, Ethereal
|
|
won't be able to capture on that device.
|
|
|
|
Note that:
|
|
1. 2.02 and earlier versions of the WinPcap driver and library that
|
|
Ethereal uses for packet capture didn't support Token Ring
|
|
interfaces; versions 2.1 and later support Token Ring, and the
|
|
current version of Ethereal works with (and, in fact, requires)
|
|
WinPcap 2.1 or later.
|
|
If you are having problems capturing on Token Ring interfaces, and
|
|
you have WinPcap 2.02 or an earlier version of WinPcap installed,
|
|
you should uninstall WinPcap, download and install the current
|
|
version of WinPcap, and then install the latest version of
|
|
Ethereal.
|
|
2. On Windows 95, 98, or Me, sometimes more than one interface will
|
|
be given the same name; if that is the case, you will only be able
|
|
to capture on one of those interfaces - it's not clear to which
|
|
one the name, when used in a WinPcap-based application, will
|
|
refer. For example, if you have a PPP serial interface and a VPN
|
|
interface, they might show up with the same name, for example
|
|
"ppp-mac", and if you try to capture on "ppp-mac", it might not
|
|
capture on the interface you're currently using. In that case, you
|
|
might, for example, have to remove the VPN interface from the
|
|
system in order to capture on the PPP serial interface.
|
|
3. WinPcap 3.0 doesn't support PPP WAN interfaces, and WinPcap 2.3
|
|
doesn't support PPP WAN interfaces on Windows NT/2000/XP/Server,
|
|
so Ethereal cannot capture packets on those devices with WinPcap
|
|
3.0, or with WInPcap 2.x when running on Windows
|
|
NT/2000/XP/Server. Regular dial-up lines, ISDN lines, and various
|
|
other lines such as T1/E1 lines are all PPP interfaces. This may
|
|
cause the interface not to show up on the list of interfaces in
|
|
the "Capture Options" dialog.
|
|
4. WinPcap prior to 3.0 does not support multiprocessor machines
|
|
(note that machines with a single multi-threaded processor, such
|
|
as Intel's new multi-threaded x86 processors, are multiprocessor
|
|
machines as far as the OS and WinPcap are concerned), and recent
|
|
2.x versions of WinPcap refuse to operate if they detect that
|
|
they're running on a multiprocessor machine, which means that they
|
|
may not show any network interfaces. You will need to use WinPcap
|
|
3.0 to capture on a multiprocessor machine.
|
|
|
|
If an interface doesn't show up in the list of interfaces in the
|
|
"Interface:" field, and you know the name of the interface, try
|
|
entering that name in the "Interface:" field and capturing on that
|
|
device.
|
|
|
|
If the attempt to capture on it succeeds, the interface is somehow not
|
|
being reported by the mechanism Ethereal uses to get a list of
|
|
interfaces. Try listing the interfaces with WinDump; see the WinDump
|
|
Web site or the local mirror of the WinDump Web site for information
|
|
on using WinDump.
|
|
|
|
You would run WinDump with the -D flag; if it lists the interface,
|
|
please report this to ethereal-dev@ethereal.com giving full details of
|
|
the problem, including
|
|
* the operating system you're using, and the version of that
|
|
operating system;
|
|
* the type of network device you're using;
|
|
* the output of WinDump.
|
|
|
|
If WinDump does not list the interface, this is almost certainly a
|
|
problem with one or more of:
|
|
* the operating system you're using;
|
|
* the device driver for the interface you're using;
|
|
* the WinPcap library and/or the WinPcap device driver;
|
|
|
|
so first check the WinPcap FAQ, the local mirror of that FAQ, or the
|
|
Wiretapped.net mirror of that FAQ, to see if your problem is mentioned
|
|
there. If not, then see the WinPcap support page (or the local mirror
|
|
of that page) - check the "Submitting bugs" section.
|
|
|
|
If you are having trouble capturing on a particular network interface,
|
|
first try capturing on that device with WinDump; see the WinDump Web
|
|
site or the local mirror of the WinDump Web site for information on
|
|
using WinDump.
|
|
|
|
If you can capture on the interface with WinDump, send mail to
|
|
ethereal-users@ethereal.com giving full details of the problem,
|
|
including
|
|
* the operating system you're using, and the version of that
|
|
operating system;
|
|
* the type of network device you're using;
|
|
* the error message you get from Ethereal.
|
|
|
|
If you cannot capture on the interface with WinDump, this is almost
|
|
certainly a problem with one or more of:
|
|
* the operating system you're using;
|
|
* the device driver for the interface you're using;
|
|
* the WinPcap library and/or the WinPcap device driver;
|
|
|
|
so first check the WinPcap FAQ, the local mirror of that FAQ, or the
|
|
Wiretapped.net mirror of that FAQ, to see if your problem is mentioned
|
|
there. If not, then see the WinPcap support page (or the local mirror
|
|
of that page) - check the "Submitting bugs" section.
|
|
|
|
You may also want to ask the ethereal-users@ethereal.com and the
|
|
winpcap-users@winpcap.polito.it mailing lists to see if anybody
|
|
happens to know about the problem and know a workaround or fix for the
|
|
problem. (Note that you will have to subscribe to that list in order
|
|
to be allowed to mail to it; see the WinPcap support page, or the
|
|
local mirror of that page, for information on the mailing list.) In
|
|
your mail, please give full details of the problem, as described
|
|
above, and also indicate that the problem occurs with WinDump, not
|
|
just with Ethereal.
|
|
|
|
Q 5.5: I'm running Ethereal on Windows; why do no network interfaces
|
|
show up in the list of interfaces in the "Interface:" field in the
|
|
dialog box popped up by "Capture->Start"?
|
|
|
|
A: This is really the same question as the previous one; see the
|
|
response to that question.
|
|
|
|
Q 5.6: I'm running Ethereal on Windows; why doesn't my serial
|
|
port/ADSL modem/ISDN modem/show up in the list of interfaces in the
|
|
"Interface:" field in the dialog box popped up by "Capture->Start"?
|
|
|
|
A: All of those devices support Internet access using the
|
|
Point-to-Point (PPP) protocol; WinPcap 3.0 doesn't support PPP
|
|
interfaces, and WinPcap 2.x doesn't support PPP interfaces on Windows
|
|
NT/2000/XP/Server, so Ethereal cannot capture packets on those devices
|
|
with WinPcap 3.0, or with WinPcap 2.x when running on Windows
|
|
NT/2000/XP/Server. This may cause the interface not to show up on the
|
|
list of interfaces in the "Capture Options" dialog.
|
|
|
|
Q 5.7: I'm running Ethereal on a UNIX-flavored OS; why does some
|
|
network interface on my machine not show up in the list of interfaces
|
|
in the "Interface:" field in the dialog box popped up by
|
|
"Capture->Start", and/or why does Ethereal give me an error if I try
|
|
to capture on that interface?
|
|
|
|
A: You may need to run Ethereal from an account with sufficient
|
|
privileges to capture packets, such as the super-user account. Only
|
|
those interfaces that Ethereal can open for capturing show up in that
|
|
list; if you don't have sufficient privileges to capture on any
|
|
interfaces, no interfaces will show up in the list.
|
|
|
|
If you are running Ethereal from an account with sufficient
|
|
privileges, then note that Ethereal relies on the libpcap library, and
|
|
on the facilities that come with the OS on which it's running in order
|
|
to do captures.
|
|
|
|
Therefore, if the OS or the libpcap library don't support capturing on
|
|
a particular network interface device, Ethereal won't be able to
|
|
capture on that device.
|
|
|
|
On Linux, note that you need to have "packet socket" support enabled
|
|
in your kernel; see the "Packet socket" item in the Linux
|
|
"Configure.help" file.
|
|
|
|
On BSD, note that you need to have BPF support enabled in your kernel;
|
|
see the documentation for your system for information on how to enable
|
|
BPF support (if it's not enabled by default on your system).
|
|
|
|
On DEC OSF/1, Digital UNIX, or Tru64 UNIX, note that you need to have
|
|
packet filtering support in your kernel; the doconfig command will
|
|
allow you to configure and build a new kernel with that option.
|
|
|
|
On Solaris, note that libpcap 0.6.2 and earlier didn't support Token
|
|
Ring interfaces; the current version, 0.7.2, does support Token Ring,
|
|
and the current version of Ethereal works with libcap 0.7.2 and later.
|
|
|
|
If an interface doesn't show up in the list of interfaces in the
|
|
"Interface:" field, and you know the name of the interface, try
|
|
entering that name in the "Interface:" field and capturing on that
|
|
device.
|
|
|
|
If the attempt to capture on it succeeds, the interface is somehow not
|
|
being reported by the mechanism Ethereal uses to get a list of
|
|
interfaces; please report this to ethereal-dev@ethereal.com giving
|
|
full details of the problem, including
|
|
* the operating system you're using, and the version of that
|
|
operating system (for Linux, give both the version number of the
|
|
kernel and the name and version number of the distribution you're
|
|
using);
|
|
* the type of network device you're using.
|
|
|
|
If you are having trouble capturing on a particular network interface,
|
|
and you've made sure that (on platforms that require it) you've
|
|
arranged that packet capture support is present, as per the above,
|
|
first try capturing on that device with tcpdump.
|
|
|
|
If you can capture on the interface with tcpdump, send mail to
|
|
ethereal-users@ethereal.com giving full details of the problem,
|
|
including
|
|
* the operating system you're using, and the version of that
|
|
operating system (for Linux, give both the version number of the
|
|
kernel and the name and version number of the distribution you're
|
|
using);
|
|
* the type of network device you're using;
|
|
* the error message you get from Ethereal.
|
|
|
|
If you cannot capture on the interface with tcpdump, this is almost
|
|
certainly a problem with one or more of:
|
|
* the operating system you're using;
|
|
* the device driver for the interface you're using;
|
|
* the libpcap library;
|
|
|
|
so you should report the problem to the company or organization that
|
|
produces the OS (in the case of a Linux distribution, report the
|
|
problem to whoever produces the distribution).
|
|
|
|
You may also want to ask the ethereal-users@ethereal.com and the
|
|
tcpdump-workers@tcpdump.org mailing lists to see if anybody happens to
|
|
know about the problem and know a workaround or fix for the problem.
|
|
In your mail, please give full details of the problem, as described
|
|
above, and also indicate that the problem occurs with tcpdump not just
|
|
with Ethereal.
|
|
|
|
Q 5.8: I'm running Ethereal on a UNIX-flavored OS; why do no network
|
|
interfaces show up in the list of interfaces in the "Interface:" field
|
|
in the dialog box popped up by "Capture->Start"?
|
|
|
|
A: This is really the same question as the previous one; see the
|
|
response to that question.
|
|
|
|
Q 5.9: Can Ethereal capture on (my T1/E1 line, SS7 links, etc.)?
|
|
|
|
A: Ethereal can only capture on devices supported by libpcap/WinPcap.
|
|
On most OSes, only devices that can act as network interfaces of the
|
|
type that support IP are supported as capture devices for
|
|
libpcap/WinPcap, although the device doesn't necessarily have to be
|
|
running as an IP interface in order to support traffic capture.
|
|
|
|
On Linux and FreeBSD, libpcap 0.8 and later support the API for Endace
|
|
Measurement Systems' DAG cards, so that a system with one of those
|
|
cards, and its driver and libraries, installed can capture traffic
|
|
with those cards with libpcap-based applications. You would either
|
|
have to have a version of Ethereal built with that version of libpcap,
|
|
or a dynamically-linked version of Ethereal and a shared libpcap
|
|
library with DAG support, in order to do so with Ethereal. You should
|
|
ask Endace whether that could be used to capture traffic on, for
|
|
example, your T1/E1 link.
|
|
There is currently no hardware to support capturing on SS7 links with
|
|
libpcap. (Note that the fact that Ethereal includes dissectors for
|
|
many SS7 protocols doesn't imply that it can capture traffic from SS7
|
|
links; those protocols can be run over Internet protocols.)
|
|
|
|
Q 5.10: How do I put an interface into promiscuous mode?
|
|
|
|
A: By not disabling promiscuous mode when running Ethereal or
|
|
Tethereal.
|
|
|
|
Note, however, that:
|
|
* the form of promiscuous mode that libpcap (the library that
|
|
programs such as tcpdump, Ethereal, etc. use to do packet capture)
|
|
turns on will not necessarily be shown if you run ifconfig on the
|
|
interface on a UNIX system;
|
|
* some network interfaces might not support promiscuous mode, and
|
|
some drivers might not allow promiscuous mode to be turned on -
|
|
see this earlier question for more information on that;
|
|
* the fact that you're not seeing any traffic, or are only seeing
|
|
broadcast traffic, or aren't seeing any non-broadcast traffic
|
|
other than traffic to or from the machine running Ethereal, does
|
|
not mean that promiscuous mode isn't on - see this earlier
|
|
question for more information on that.
|
|
|
|
I.e., this is probably the same question as this earlier one; see the
|
|
response to that question.
|
|
|
|
Q 5.11: I can set a display filter just fine, but capture filters
|
|
don't work.
|
|
|
|
A: Capture filters currently use a different syntax than display
|
|
filters. Here's the corresponding section from the ethereal(1) man
|
|
page:
|
|
|
|
"Display filters in Ethereal are very powerful; more fields are
|
|
filterable in Ethereal than in other protocol analyzers, and the
|
|
syntax you can use to create your filters is richer. As Ethereal
|
|
progresses, expect more and more protocol fields to be allowed in
|
|
display filters.
|
|
|
|
Packet capturing is performed with the pcap library. The capture
|
|
filter syntax follows the rules of the pcap library. This syntax is
|
|
different from the display filter syntax."
|
|
|
|
The capture filter syntax used by libpcap can be found in the
|
|
tcpdump(8) man page.
|
|
|
|
Q 5.12: I'm entering valid capture filters, but I still get "parse
|
|
error" errors.
|
|
|
|
A: There is a bug in some versions of libpcap/WinPcap that cause it to
|
|
report parse errors even for valid expressions if a previous filter
|
|
expression was invalid and got a parse error.
|
|
|
|
Try exiting and restarting Ethereal; if you are using a version of
|
|
libpcap/WinPcap with this bug, this will "erase" its memory of the
|
|
previous parse error. If the capture filter that got the "parse error"
|
|
now works, the earlier error with that filter was probably due to this
|
|
bug.
|
|
|
|
The bug was fixed in libpcap 0.6; 0.4[.x] and 0.5[.x] versions of
|
|
libpcap have this bug, but 0.6[.x] and later versions don't.
|
|
|
|
Versions of WinPcap prior to 2.3 are based on pre-0.6 versions of
|
|
libpcap, and have this bug; WinPcap 2.3 is based on libpcap 0.6.2, and
|
|
doesn't have this bug.
|
|
|
|
If you are running Ethereal on a UNIX-flavored platform, run "ethereal
|
|
-v", or select "About Ethereal..." from the "Help" menu in Ethereal,
|
|
to see what version of libpcap it's using. If it's not 0.6 or later,
|
|
you will need either to upgrade your OS to get a later version of
|
|
libpcap, or will need to build and install a later version of libpcap
|
|
from the tcpdump.org Web site and then recompile Ethereal from source
|
|
with that later version of libpcap.
|
|
|
|
If you are running Ethereal on Windows with a pre-2.3 version of
|
|
WinPcap, you will need to un-install WinPcap and then download and
|
|
install WinPcap 2.3.
|
|
|
|
Q 5.13: I saved a filter and tried to use its name to filter the
|
|
display, but I got an "Unexpected end of filter string" error.
|
|
|
|
A: You cannot use the name of a saved display filter as a filter. To
|
|
filter the display, you can enter a display filter expression - not
|
|
the name of a saved display filter - in the "Filter:" box at the
|
|
bottom of the display, and type the key or press the "Apply" button
|
|
(that does not require you to have a saved filter), or, if you want to
|
|
use a saved filter, you can press the "Filter:" button, select the
|
|
filter in the dialog box that pops up, and press the "OK" button.
|
|
|
|
Q 5.14: Why am I seeing lots of packets with incorrect TCP checksums?
|
|
|
|
A: If the packets that have incorrect TCP checksums are all being sent
|
|
by the machine on which Ethereal is running, this is probably because
|
|
the network interface on which you're capturing does TCP checksum
|
|
offloading. That means that the TCP checksum is added to the packet by
|
|
the network interface, not by the OS's TCP/IP stack; when capturing on
|
|
an interface, packets being sent by the host on which you're capturing
|
|
are directly handed to the capture interface by the OS, which means
|
|
that they are handed to the capture interface without a TCP checksum
|
|
being added to them.
|
|
|
|
The only way to prevent this from happening would be to disable TCP
|
|
checksum offloading, but
|
|
1. that might not even be possible on some OSes;
|
|
2. that could reduce networking performance significantly.
|
|
|
|
However, you can disable the check that Ethereal does of the TCP
|
|
checksum, so that it won't report any packets as having TCP checksum
|
|
errors, and so that it won't refuse to do TCP reassembly due to a
|
|
packet having an incorrect TCP checksum. That can be set as an
|
|
Ethereal preference by selecting "Preferences" from the "Edit" menu,
|
|
opening up the "Protocols" list in the left-hand pane of the
|
|
"Preferences" dialog box, selecting "TCP", from that list, turning off
|
|
the "Check the validity of the TCP checksum when possible" option,
|
|
clicking "Save" if you want to save that setting in your preference
|
|
file, and clicking "OK".
|
|
|
|
It can also be set on the Ethereal or Tethereal command line with a -o
|
|
tcp.check_checksum:false command-line flag, or manually set in your
|
|
preferences file by adding a tcp.check_checksum:false line.
|
|
|
|
Q 5.15: I've just installed Ethereal, and the traffic on my local LAN
|
|
is boring.
|
|
|
|
A: We have a collection of strange and exotic sample capture files at
|
|
http://www.ethereal.com/sample/
|
|
|
|
Q 5.16: When I run Ethereal on Solaris 8, it dies with a Bus Error
|
|
when I start it.
|
|
|
|
A: Some versions of the GTK+ library from www.sunfreeware.org appear
|
|
to be buggy, causing Ethereal to drop core with a Bus Error.
|
|
Un-install those packages, and try getting the 1.2.10 version from
|
|
that site, or the version from The Written Word, or the version from
|
|
Sun's GNOME distribution, or the version from the supplemental
|
|
software CD that comes with the Solaris media kit, or build it from
|
|
source from the GTK Web site. Update the GLib library to the 1.2.10
|
|
version, from the same source, as well. (If you get the 1.2.10
|
|
versions from www.sunfreeware.org, and the problem persists,
|
|
un-install them and try installing one of the other versions
|
|
mentioned.)
|
|
|
|
Similar problems may exist with older versions of GTK+ for earlier
|
|
versions of Solaris.
|
|
|
|
Q 5.17: When I run Ethereal, I get an error
|
|
|
|
Gtk-CRITICAL **: file gtkwindow.c: line 3107 (gtk_window_resize):
|
|
assertion `height > 0' failed.
|
|
|
|
A: This is a bug in Ethereal 0.10.5, which will be fixed in the next
|
|
release of Ethereal. To work around this bug:
|
|
1. On Windows, this message will appear in a console window; do NOT,
|
|
under any circumstances, close that window!
|
|
2. Make sure the "Save window size" prefrence is set the "User
|
|
Interface" prefrences in the preferences window opened by
|
|
"Preferences" under the "Edit" menu.
|
|
3. Quit Ethereal.
|
|
4. On Windows, a "Press any key to exit" message might appear in the
|
|
command window; if that message appears in the window, click on
|
|
that window and press any key (such as Enter).
|
|
|
|
The next time Ethereal starts, it should not produce that error
|
|
message.
|
|
|
|
Q 5.18: When I run Tethereal with the "-x" option, it crashes with an
|
|
error
|
|
|
|
"** ERROR **: file print.c: line 691 (print_line): should not be
|
|
reached.
|
|
|
|
A: This is a bug in Ethereal 0.10.0a, which is fixed in 0.10.1 and
|
|
later releases. To work around the bug, don't use "-x" unless you're
|
|
also using "-V"; note that "-V" produces a full dissection of each
|
|
packet, so you might not want to use it.
|
|
|
|
To get a fixed version, either build the current SVN version from
|
|
anonymous SVN or a nightly SVN snapshot, or apply to tethereal.c in
|
|
the 0.10.0a source tarball the changes between the broken and the
|
|
fixed versions, which you can download with the URL
|
|
http://www.ethereal.com/cgi-bin/viewcvs.cgi/ethereal/tethereal.c.diff?
|
|
r2=1.211&r1=1.210&diff_format=u and (re-)build from source. It might
|
|
be easier to get the SVN version than to get the patch and apply it to
|
|
the 0.10.0a source tarball, but it's probably easier to build from the
|
|
source tarball than from the SVN version, as you'll need to have more
|
|
tools and make more steps to generate from the SVN version some files
|
|
that are bundled with the source tarball.
|
|
|
|
Note that to build from the 0.10.0a source tarball on Windows with
|
|
Microsoft Visual C++, you will need to get a file that was missing
|
|
from the 0.10.0a source tarball; see the FAQ for that problem.
|
|
|
|
Q 5.19: When I run Ethereal on Windows NT, it dies with a Dr. Watson
|
|
error, reporting an "Integer division by zero" exception, when I start
|
|
it.
|
|
|
|
A: In at least some case, this appears to be due to using the default
|
|
VGA driver; if that's not the correct driver for your video card, try
|
|
running the correct driver for your video card.
|
|
|
|
Q 5.20: When I try to run Ethereal, it complains about
|
|
sprint_realloc_objid being undefined.
|
|
|
|
A: Ethereal can only be linked with version 4.2.2 or later of UCD
|
|
SNMP. Your version of Ethereal was dynamically linked with such a
|
|
version of UCD SNMP; however, you have an older version of UCD SNMP
|
|
installed, which means that when Ethereal is run, it tries to link to
|
|
the older version, and fails. You will have to replace that version of
|
|
UCD SNMP with version 4.2.2 or a later version.
|
|
|
|
Q 5.21: I'm running Ethereal on Linux; why do my time stamps have only
|
|
100ms resolution, rather than 1us resolution?
|
|
|
|
A: Ethereal gets time stamps from libpcap/WinPcap, and libpcap/WinPcap
|
|
get them from the OS kernel, so Ethereal - and any other program using
|
|
libpcap, such as tcpdump - is at the mercy of the time stamping code
|
|
in the OS for time stamps.
|
|
|
|
At least on x86-based machines, Linux can get high-resolution time
|
|
stamps on newer processors with the Time Stamp Counter (TSC) register;
|
|
for example, Intel x86 processors, starting with the Pentium Pro, and
|
|
including all x86 processors since then, have had a TSC, and other
|
|
vendors probably added the TSC at some point to their families of x86
|
|
processors.
|
|
|
|
The Linux kernel must be configured with the CONFIG_X86_TSC option
|
|
enabled in order to use the TSC. Make sure this option is enabled in
|
|
your kernel.
|
|
|
|
In addition, some Linux distributions may have bugs in their versions
|
|
of the kernel that cause packets not to be given high-resolution time
|
|
stamps even if the TSC is enabled. See, for example, bug 61111 for Red
|
|
Hat Linux 7.2. If your distribution has a bug such as this, you may
|
|
have to run a standard kernel from kernel.org in order to get
|
|
high-resolution time stamps.
|
|
|
|
Q 5.22: I'm capturing packets on {Windows 95, Windows 98, Windows Me};
|
|
why are the time stamps on packets wrong?
|
|
|
|
A: This is due to a bug in WinPcap. The bug should be fixed in WinPcap
|
|
3.0.
|
|
|
|
Q 5.23: When I try to run Ethereal on Windows, it fails to run because
|
|
it can't find packet.dll.
|
|
|
|
A: In older versions of Ethereal, there were two binary distributions
|
|
available for Windows, one that supported capturing packets, and one
|
|
that didn't. The version that supported capturing packets required
|
|
that you install the WinPcap driver; if you didn't install it, it
|
|
would fail to run because it couldn't find packet.dll.
|
|
|
|
The current version of Ethereal has only one binary distribution for
|
|
Windows; that version will check whether WinPcap is installed and, if
|
|
it's not, will disable support for packet capture.
|
|
|
|
The WinPcap driver and libraries can be downloaded from the WinPcap
|
|
Web site, the local mirror of the WinPcap Web site, or the
|
|
Wiretapped.net mirror of the WinPcap site.
|
|
|
|
Q 5.24: I'm running Ethereal on Windows NT/2000/XP/Server; my machine
|
|
has a PPP (dial-up POTS, ISDN, etc.) interface, and it shows up in the
|
|
"Interface" item in the "Capture Options" dialog box. Why can no
|
|
packets be sent on or received from that network while I'm trying to
|
|
capture traffic on that interface?
|
|
|
|
A: WinPcap doesn't support PPP WAN interfaces on Windows
|
|
NT/2000/XP/Server; one symptom that may be seen is that attempts to
|
|
capture in promiscuous mode on the interface cause the interface to be
|
|
incapable of sending or receiving packets. You can disable promiscuous
|
|
mode using the -p command-line flag or the item in the "Capture
|
|
Preferences" dialog box, but this may mean that outgoing packets, or
|
|
incoming packets, won't be seen in the capture.
|
|
|
|
Q 5.25: I'm running Ethereal on Windows 95/98/Me, on a machine with
|
|
more than one network adapter of the same type; Ethereal shows all of
|
|
those adapters with the same name, but I can't use any of those
|
|
adapters other than the first one.
|
|
|
|
A: Unfortunately, Windows 95/98/Me gives the same name to multiple
|
|
instances of the type of same network adapter. Therefore, WinPcap
|
|
cannot distinguish between them, so a WinPcap-based application can
|
|
capture only on the first such interface; Ethereal is a
|
|
libpcap/WinPcap-based application.
|
|
|
|
Q 5.26: I'm running Ethereal on Windows, and I'm not seeing any
|
|
traffic being sent by the machine running Ethereal.
|
|
|
|
A: If you are running some form of VPN client software, it might be
|
|
causing this problem; people have seen this problem when they have
|
|
Check Point's VPN software installed on their machine. If that's the
|
|
cause of the problem, you will have to remove the VPN software in
|
|
order to have Ethereal (or any other application using WinPcap) see
|
|
outgoing packets; unfortunately, neither we nor the WinPcap developers
|
|
know any way to make WinPcap and the VPN software work well together.
|
|
|
|
Also, some drivers for Windows (especially some wireless network
|
|
interface drivers) apparently do not, when running in promiscuous
|
|
mode, arrange that outgoing packets are delivered to the software that
|
|
requested that the interface run promiscuously; try turning
|
|
promiscuous mode off.
|
|
|
|
Q 5.27: I'm trying to capture traffic but I'm not seeing any.
|
|
|
|
A: Is the machine running Ethereal sending out any traffic on the
|
|
network interface on which you're capturing, or receiving any traffic
|
|
on that network, or is there any broadcast traffic on the network or
|
|
multicast traffic to a multicast group to which the machine running
|
|
Ethereal belongs?
|
|
|
|
If not, this may just be a problem with promiscuous sniffing, either
|
|
due to running on a switched network or a dual-speed hub, or due to
|
|
problems with the interface not supporting promiscuous mode; see the
|
|
response to this earlier question.
|
|
|
|
Otherwise, on Windows, see the response to this question and, on a
|
|
UNIX-flavored OS, see the response to this question.
|
|
|
|
Q 5.28: I have an XXX network card on my machine; if I try to capture
|
|
on it, my machine crashes or resets itself.
|
|
|
|
A: This is almost certainly a problem with one or more of:
|
|
* the operating system you're using;
|
|
* the device driver for the interface you're using;
|
|
* the libpcap/WinPcap library and, if this is Windows, the WinPcap
|
|
device driver;
|
|
|
|
so:
|
|
* if you are using Windows, see the WinPcap support page (or the
|
|
local mirror of that page) - check the "Submitting bugs" section;
|
|
* if you are using some Linux distribution, some version of BSD, or
|
|
some other UNIX-flavored OS, you should report the problem to the
|
|
company or organization that produces the OS (in the case of a
|
|
Linux distribution, report the problem to whoever produces the
|
|
distribution).
|
|
|
|
Q 5.29: My machine crashes or resets itself when I select "Start" from
|
|
the "Capture" menu or select "Preferences" from the "Edit" menu.
|
|
|
|
A: Both of those operations cause Ethereal to try to build a list of
|
|
the interfaces that it can open; it does so by getting a list of
|
|
interfaces and trying to open them. There is probably an OS, driver,
|
|
or, for Windows, WinPcap bug that causes the system to crash when this
|
|
happens; see the previous question.
|
|
|
|
Q 5.30: Does Ethereal work on Windows Me?
|
|
|
|
A: Yes, but if you want to capture packets, you will need to install
|
|
the latest version of WinPcap, as 2.02 and earlier versions of WinPcap
|
|
didn't support Windows Me. You should also install the latest version
|
|
of Ethereal as well.
|
|
|
|
Q 5.31: Does Ethereal work on Windows XP?
|
|
|
|
A: Yes, but if you want to capture packets, you will need to install
|
|
the latest version of WinPcap, as 2.2 and earlier versions of WinPcap
|
|
didn't support Windows XP.
|
|
|
|
Q 5.32: Why doesn't Ethereal correctly identify RTP packets? It shows
|
|
them only as UDP.
|
|
|
|
A: Ethereal can identify a UDP datagram as containing a packet of a
|
|
particular protocol running atop UDP only if
|
|
1. The protocol in question has a particular standard port number,
|
|
and the UDP source or destination port number is that port
|
|
2. Packets of that protocol can be identified by looking for a
|
|
"signature" of some type in the packet - i.e., some data that, if
|
|
Ethereal finds it in some particular part of a packet, means that
|
|
the packet is almost certainly a packet of that type.
|
|
3. Some other traffic earlier in the capture indicated that, for
|
|
example, UDP traffic between two particular addresses and ports
|
|
will be RTP traffic.
|
|
|
|
RTP doesn't have a standard port number, so 1) doesn't work; it
|
|
doesn't, as far as I know, have any "signature", so 2) doesn't work.
|
|
|
|
That leaves 3). If there's RTSP traffic that sets up an RTP session,
|
|
then, at least in some cases, the RTSP dissector will set things up so
|
|
that subsequent RTP traffic will be identified. Currently, that's the
|
|
only place we do that; there may be other places.
|
|
|
|
However, there will always be places where Ethereal is simply
|
|
incapable of deducing that a given UDP flow is RTP; a mechanism would
|
|
be needed to allow the user to specify that a given conversation
|
|
should be treated as RTP. As of Ethereal 0.8.16, such a mechanism
|
|
exists; if you select a UDP or TCP packet, the right mouse button menu
|
|
will have a "Decode As..." menu item, which will pop up a dialog box
|
|
letting you specify that the source port, the destination port, or
|
|
both the source and destination ports of the packet should be
|
|
dissected as some particular protocol.
|
|
|
|
Q 5.33: Why doesn't Ethereal show Yahoo Messenger packets in captures
|
|
that contain Yahoo Messenger traffic?
|
|
|
|
A: Ethereal only recognizes as Yahoo Messenger traffic packets to or
|
|
from TCP port 3050 that begin with "YPNS", "YHOO", or "YMSG". TCP
|
|
segments that start with the middle of a Yahoo Messenger packet that
|
|
takes more than one TCP segment will not be recognized as Yahoo
|
|
Messenger packets (even if the TCP segment also contains the beginning
|
|
of another Yahoo Messenger packet).
|
|
|
|
Q 5.34: Why do I get the error
|
|
|
|
Gdk-ERROR **: Palettized display (256-colour) mode not supported on
|
|
Windows.
|
|
aborting....
|
|
|
|
when I try to run Ethereal on Windows?
|
|
|
|
A: Ethereal is built using the GTK+ toolkit, which supports most
|
|
UNIX-flavored OSes, and also supports Windows.
|
|
|
|
Windows versions of Ethereal before 0.9.14 were built with an older
|
|
version of that toolkit, which didn't support 256-color mode on
|
|
Windows - it required HiColor (16-bit colors) or more.
|
|
|
|
Windows versions of Ethereal 0.9.14 and later are built with a version
|
|
of that toolkit that supports 256-color mode; upgrade to the current
|
|
version of Ethereal if you want to run on a display in 256-color mode.
|
|
|
|
Q 5.35: When I capture on Windows in promiscuous mode, I can see
|
|
packets other than those sent to or from my machine; however, those
|
|
packets show up with a "Short Frame" indication, unlike packets to or
|
|
from my machine. What should I do to arrange that I see those packets
|
|
in their entirety?
|
|
|
|
A: In at least some cases, this appears to be the result of PGPnet
|
|
running on the network interface on which you're capturing; turn it
|
|
off on that interface.
|
|
|
|
Q 5.36: I'm capturing packets on a machine on a VLAN; why don't the
|
|
packets I'm capturing have VLAN tags?
|
|
|
|
A: You might be capturing on what might be called a "VLAN interface" -
|
|
the way a particular OS makes VLANs plug into the networking stack
|
|
might, for example, be to have a network device object for the
|
|
physical interface, which takes VLAN packets, strips off the VLAN
|
|
header and constructs an Ethernet header, and passes that packet to an
|
|
internal network device object for the VLAN, which then passes the
|
|
packets onto various higher-level protocol implementations.
|
|
|
|
In order to see the raw Ethernet packets, rather than "de-VLANized"
|
|
packets, you would have to capture not on the virtual interface for
|
|
the VLAN, but on the interface corresponding to the physical network
|
|
device, if possible.
|
|
|
|
Q 5.37: How can I capture raw 802.11 packets, including non-data
|
|
(management, beacon) packets?
|
|
|
|
A: That depends on the operating system on which you're running, and
|
|
on the 802.11 interface on which you're capturing.
|
|
|
|
This would probably require that you capture in promiscuous mode or in
|
|
the mode called "monitor mode" or "RFMON mode". On some platforms, or
|
|
with some cards, this might require that you capture in monitor mode -
|
|
promiscuous mode might not be sufficient. If you want to capture
|
|
traffic on networks other than the one with which you're associated,
|
|
you will have to capture in monitor mode.
|
|
|
|
Not all operating systems support capturing non-data packets and, even
|
|
on operating systems that do support it, not all drivers, and thus not
|
|
all interfaces, support it. Even on those that do, monitor mode might
|
|
not be supported by the operating system or by the drivers for all
|
|
interfaces.
|
|
|
|
NOTE: an interface running in monitor mode will, on most if not all
|
|
platforms, not be able to act as a regular network interface; putting
|
|
it into monitor mode will, in effect, take your machine off of
|
|
whatever network it's on as long as the interface is in monitor mode,
|
|
allowing it only to passively capture packets.
|
|
|
|
This means that you should disable name resolution when capturing in
|
|
monitor mode; otherwise, when Ethereal (or Tethereal, or tcpdump)
|
|
tries to display IP addresses as host names, it will probably block
|
|
for a long time trying to resolve the name because it will not be able
|
|
to communicate with any DNS or NIS servers.
|
|
|
|
There are FAQ items below with information on capturing in monitor
|
|
mode on Linux, FreeBSD, and NetBSD.
|
|
|
|
On Windows, you will not be able to capture in monitor mode on any
|
|
interfaces, and you might not be able to capture in promiscuous mode,
|
|
either. You might have some success in promiscuous mode with Centrino
|
|
interfaces, although you will need the not-yet-released Ethereal
|
|
0.10.6 in order to have the non-data packets recognized and properly
|
|
dissected.
|
|
|
|
You will not be able to capture in monitor mode on any other platforms
|
|
(including Mac OS X). You might be able to capture in promiscuous
|
|
mode, but this won't capture non-data packets.
|
|
|
|
Q 5.38: How do I capture on an 802.11 device in monitor mode on Linux?
|
|
|
|
A: Whether you will be able to capture in monitor mode depends on the
|
|
card and driver you're using. See this page of Linux 802.11b
|
|
information for details on 802.11b wireless cards, including
|
|
information on the chips they use, and see this page of Linux
|
|
802.11b+/a/g information for details on 802.11b+, 802.11a, and 802.11g
|
|
wireless cards, including information on the chips they use.
|
|
|
|
Cisco Aironet cards:
|
|
|
|
On Linux with the driver in the 2.4.6 through 2.4.19 kernel:
|
|
1. Put the card into monitor mode with the command echo "Mode: rfmon"
|
|
>/proc/driver/aironet/interface/Config. If you want to capture
|
|
traffic for any BSS rather than just the BSS with which the card
|
|
is associated, use "Mode: y" rather than "Mode: rfmon".
|
|
2. When the capture completes, turn off monitor mode with the command
|
|
echo "Mode: ess" >/proc/driver/aironet/interface/Config.
|
|
|
|
On Linux with the driver in the 2.4.20 or later kernel, or with the
|
|
CVS drivers from the airo-linux SourceForge site, you will have to
|
|
capture on the wifiN interface if your Aironet card is ethN, after
|
|
running the commands listed above.
|
|
|
|
In all of those cases, Ethereal would have to be linked with libpcap
|
|
0.7.1 or later; this means that most Ethereal binary packages won't
|
|
work unless they're statically linked with libpcap 0.7.1 or later, or
|
|
they're dynamically linked with libpcap and your system has a libpcap
|
|
0.7.1 or later shared library installed (note that libpcap source
|
|
package from tcpdump.org does not build shared libraries). Some binary
|
|
packaging mechanisms might make it difficult to install Ethereal
|
|
binary packages built to depend on older libpcap binary packages if
|
|
you have a newer libpcap binary package installed; the installer
|
|
programs for those packaging mechanisms might support disabling
|
|
dependency checking so that they will install Ethereal even though a
|
|
newer version of libpcap is installed.
|
|
|
|
Cards using the Prism II chip set:
|
|
|
|
You can capture raw 802.11 packets with Prism II cards on Linux
|
|
systems with the 0.1.14-pre6 or later version of the linux-wlan-ng
|
|
drivers (see the linux-wlan page, and the linux-wlan-ng tarball
|
|
directory), or with the hostap driver for Prism II/2.5/3.
|
|
|
|
Those require either Solomon Peachy's patch to libpcap 0.7.1 (see his
|
|
libpcap-0.7.1-prism.diff file, or his RPMs of that version of
|
|
libpcap), or the current CVS version of libpcap, which includes his
|
|
patch (download it from the "Current Tar files" section of the
|
|
tcpdump.org Web site). If you apply his patches to libpcap 0.7.1 and
|
|
rebuild and install libpcap, or if you build and install the current
|
|
CVS version of libpcap, you would have to rebuild Ethereal from
|
|
source, linking it with that new version of libpcap; an Ethereal
|
|
binary package would not work. Ethereal binary packages might work if
|
|
you install the libpcap-0.7.1-1prism.i386.rpm RPM, as it might install
|
|
a libpcap shared library in place of the one on your system.
|
|
|
|
With the linux-wlan-ng driver, you should:
|
|
1. Put the card into monitor mode with the command wlanctl-ng
|
|
interface lnxreq_wlansniffer enable=true. You should request
|
|
802.11 headers by adding to that command the option
|
|
prismheader=true or, if supported, wlanheader=true; the latter
|
|
might require libpcap 0.8.1 or later. You can also set the channel
|
|
to monitor by adding the argument channel=channel_number to that
|
|
command.
|
|
2. When the capture completes, turn off monitor mode with the command
|
|
wlanctl-ng interface enable=false. You might also have to turn
|
|
802.11 headers off with prismheader=false or wlanheader=false.
|
|
|
|
See the wlan-ng FAQ for additional information, although note that it
|
|
does not appear to be up-to-date.
|
|
|
|
With the hostap driver, you should:
|
|
1. Put the card into monitor mode with the command iwpriv interface
|
|
monitor mode, where mode is 2 or 3 (mode 3 would require libpcap
|
|
0.8.1 or later).
|
|
2. When the capture completes, turn off monitor mode with the command
|
|
iwpriv interface monitor 0.
|
|
|
|
Orinoco Silver and Gold cards:
|
|
|
|
On Linux systems, the current version of the SourceForge orinoco_cs
|
|
driver should support monitor mode. There also exist patches to
|
|
earlier versions of the Orinoco driver, on the Orinoco Monitor Mode
|
|
Patch Page, to add support for monitor mode. You will have to
|
|
determine which version of the driver you have, and select the
|
|
appropriate patch, if one is necessary.
|
|
|
|
Note that the page indicates that not all versions of the Orinoco
|
|
firmware support this patch. It says, for some versions of the patch,
|
|
"This patch should allow monitor mode with v8.10 firmware (untested w/
|
|
8.42);" if you have version 8.10 or later firmware on your Orinoco
|
|
cards, you might have to use those patches, with the corresponding
|
|
versions of the Orinoco driver, in order to run in monitor mode.
|
|
|
|
That patch is written for the drivers included with the pcmcia-cs
|
|
drivers, but works equally well for the Orinoco drivers provided with
|
|
Linux kernels up to 2.4.20. To apply a patch to your kernel drivers,
|
|
simply copy the orinoco-09b-patch.diff file to the
|
|
/usr/src/linux/drivers/net directory and patch according to the
|
|
directions on the Orinoco Monitor Mode Patch Page. You can double-
|
|
check the version of the Orinoco drivers that shipped with your kernel
|
|
by examining the first few lines of the orinoco.c file.
|
|
|
|
The Orinoco patches and SourceForge driver require either Solomon
|
|
Peachy's patch to libpcap 0.7.1 (see his libpcap-0.7.1-prism.diff
|
|
file, or his RPMs of that version of libpcap), or the current CVS
|
|
version of libpcap, which includes his patch (download it from the
|
|
"Current Tar files" section of the tcpdump.org Web site). If you apply
|
|
his patches to libpcap 0.7.1 and rebuild and install libpcap, or if
|
|
you build and install the current CVS version of libpcap, you would
|
|
have to rebuild Ethereal from source, linking it with that new version
|
|
of libpcap; an Ethereal binary package would not work. Ethereal binary
|
|
packages might work if you install the libpcap-0.7.1-1prism.i386.rpm
|
|
RPM, as it might install a libpcap shared library in place of the one
|
|
on your system.
|
|
|
|
With a driver that supports monitor mode, you should:
|
|
1. Put the card into monitor mode with the command iwpriv interface
|
|
monitor mode channel_number, where mode is 1 or 2, and
|
|
channel_number is the number of the channel to monitor.
|
|
2. When the capture completes, turn off monitor mode with the command
|
|
iwpriv interface monitor 0.
|
|
|
|
Cards with the Texas Instruments ACX100 chipset:
|
|
|
|
You can capture raw 802.11 packets with ACX100 cards on Linux systems
|
|
with the ACX100 OSS drivers available from the ACX100 wireless network
|
|
driver project SourceForge site.
|
|
|
|
With that driver:
|
|
|
|
1. Put the card into monitor mode with the command iwpriv interface
|
|
monitor 2 channel_number, where channel_number is the number of
|
|
the channel to monitor.
|
|
2. When the capture completes, turn off monitor mode with the command
|
|
iwpriv interface monitor 0.
|
|
|
|
Cards with Atheros Communications chipsets:
|
|
|
|
You can capture raw 802.11 packets with AR5K cards on Linux systems
|
|
with the v5_ar5k drivers. You will need the Linux wireless-tools
|
|
version 25 or higher to put the card into monitor mode. It might also
|
|
be possible to do so with the madwifi driver. If you have information
|
|
on how to do this, please supply it to us, so that we can incorporate
|
|
that information into the FAQ in the future.
|
|
|
|
Other cards:
|
|
|
|
It might be possible to capture in monitor mode on other cards. If so,
|
|
please supply us with information on how to do so, so that we can
|
|
incorporate that information into this FAQ in the future.
|
|
|
|
Q 5.39: How do I capture on an 802.11 device in monitor mode on
|
|
FreeBSD?
|
|
|
|
A: On FreeBSD 5.2 and later, you should be able to capture in monitor
|
|
mode on 802.11 interfaces supported by the wi and acx drivers, if
|
|
Ethereal is linked with libpcap 0.8.1 or later, and on 802.11
|
|
interfaces supported by the an driver, if Ethereal is linked with
|
|
libpcap 0.7.1 or later.
|
|
|
|
For cards supported by the wi and acx drivers, you should:
|
|
1. Put the card into monitor mode with the command ifconfig interface
|
|
monitor. You can also set the channel to monitor by adding the
|
|
argument channel channel_number to that command.
|
|
2. When you start the capture, in Ethereal select "802.11" as the
|
|
"Link-layer header type", and in Tethereal add the command-line
|
|
argument -y 802.11.
|
|
3. When the capture completes, turn off monitor mode with the command
|
|
ifconfig interface -monitor.
|
|
|
|
For cards supported by the an driver, you should:
|
|
1. Put the card into monitor mode with the command ancontrol -i
|
|
interface -M flag, where flag should be the sum of:
|
|
+ 1, to turn monitor mode on;
|
|
+ 2, if you want to capture traffic from any BSS rather than
|
|
just the BSS with which the card is associated;
|
|
+ 4, if you want to see beacon packets (capturing beacon
|
|
packets increases the CPU requirements of capturing).
|
|
2. When the capture completes, turn off monitor mode with the command
|
|
ancontrol -i interface -M 0.
|
|
|
|
Don't add 8 in to flag; Ethereal currently doesn't support the full
|
|
Aironet header.
|
|
|
|
On FreeBSD 4.6 through 5.1, you should be able to capture in monitor
|
|
mode on 802.11 interfaces supported by the an driver, but not on any
|
|
other interfaces; see the instructions for FreeBSD 5.2 or later for
|
|
those cards.
|
|
|
|
In FreeBSD 4.5 and earlier, you will not be able to capture in monitor
|
|
mode on 802.11 interfaces (no drivers supported it prior to 4.5, and
|
|
in 4.5 the an driver had bugs that caused packets not to be captured
|
|
correctly).
|
|
|
|
Q 5.40: How do I capture on an 802.11 device in monitor mode on
|
|
NetBSD?
|
|
|
|
A: On NetBSD 2.0-beta and later, you should be able to capture in
|
|
monitor mode on 802.11 interfaces supported by the wi and acx drivers,
|
|
if Ethereal is linked with libpcap 0.8.1 or later. The instructions
|
|
are the same as for FreeBSD 5.2 and later.
|
|
|
|
Q 5.41: I'm trying to capture 802.11 traffic on Windows; why am I not
|
|
seeing any packets?
|
|
|
|
A: At least some 802.11 card drivers on Windows appear not to see any
|
|
packets if they're running in promiscuous mode. Try turning
|
|
promiscuous mode off; you'll only be able to see packets sent by and
|
|
received by your machine, not third-party traffic, and it'll look like
|
|
Ethernet traffic and won't include any management or control frames,
|
|
but that's a limitation of the card drivers.
|
|
|
|
Q 5.42: I'm trying to capture 802.11 traffic on Windows; why am I
|
|
seeing packets received by the machine on which I'm capturing traffic,
|
|
but not packets sent by that machine?
|
|
|
|
A: This appears to be another problem with promiscuous mode; try
|
|
turning it off.
|
|
|
|
Q 5.43: How can I capture packets with CRC errors?
|
|
|
|
A: Ethereal can capture only the packets that the packet capture
|
|
library - libpcap on UNIX-flavored OSes, and the WinPcap port to
|
|
Windows of libpcap on Windows - can capture, and libpcap/WinPcap can
|
|
capture only the packets that the OS's raw packet capture mechanism
|
|
(or the WinPcap driver, and the underlying OS networking code and
|
|
network interface drivers, on Windows) will allow it to capture.
|
|
|
|
Unless the OS always supplies packets with errors such as invalid CRCs
|
|
to the raw packet capture mechanism, or can be configured to do so,
|
|
invalid CRCs to the raw packet capture mechanism, Ethereal - and other
|
|
programs that capture raw packets, such as tcpdump - cannot capture
|
|
those packets. You will have to determine whether your OS needs to be
|
|
so configured and, if so, can be so configured, configure it if
|
|
necessary and possible, and make whatever changes to libpcap and the
|
|
packet capture program you're using are necessary, if any, to support
|
|
capturing those packets.
|
|
|
|
Most OSes probably do not support capturing packets with invalid CRCs
|
|
on Ethernet, and probably do not support it on most other link-layer
|
|
types. Some drivers on some OSes do support it, such as some Ethernet
|
|
drivers on FreeBSD; in those OSes, you might always get those packets,
|
|
or you might only get them if you capture in promiscuous mode (you'd
|
|
have to determine which is the case).
|
|
|
|
Note that libpcap does not currently supply to programs that use it an
|
|
indication of whether the packet's CRC was invalid (because the
|
|
drivers themselves do not supply that information to the raw packet
|
|
capture mechanism); therefore, Ethereal will not indicate which
|
|
packets had CRC errors unless the FCS was captured (see the next
|
|
question) and you're using Ethereal 0.9.15 and later, in which case
|
|
Ethereal will check the CRC and indicate whether it's correct or not.
|
|
|
|
Q 5.44: How can I capture entire frames, including the FCS?
|
|
|
|
A: Ethereal can only capture data that the packet capture library -
|
|
libpcap on UNIX-flavored OSes, and the WinPcap port to Windows of
|
|
libpcap on Windows - can capture, and libpcap/WinPcap can capture only
|
|
the data that the OS's raw packet capture mechanism (or the WinPcap
|
|
driver, and the underlying OS networking code and network interface
|
|
drivers, on Windows) will allow it to capture.
|
|
|
|
For any particular link-layer network type, unless the OS supplies the
|
|
FCS of a frame as part of the frame, or can be configured to do so,
|
|
Ethereal - and other programs that capture raw packets, such as
|
|
tcpdump - cannot capture the FCS of a frame. You will have to
|
|
determine whether your OS needs to be so configured and, if so, can be
|
|
so configured, configure it if necessary and possible, and make
|
|
whatever changes to libpcap and the packet capture program you're
|
|
using are necessary, if any, to support capturing the FCS of a frame.
|
|
|
|
Most OSes do not support capturing the FCS of a frame on Ethernet, and
|
|
probably do not support it on most other link-layer types. Some
|
|
drivres on some OSes do support it, such as some (all?) Ethernet
|
|
drivers on NetBSD and possibly the driver for Apple's gigabit Ethernet
|
|
interface in Mac OS X; in those OSes, you might always get the FCS, or
|
|
you might only get the FCS if you capture in promiscuous mode (you'd
|
|
have to determine which is the case).
|
|
|
|
Versions of Ethereal prior to 0.9.15 will not treat an Ethernet FCS in
|
|
a captured packet as an FCS. 0.9.15 and later will attempt to
|
|
determine whether there's an FCS at the end of the frame and, if it
|
|
thinks there is, will display it as such, and will check whether it's
|
|
the correct CRC-32 value or not.
|
|
|
|
Q 5.45: Ethereal hangs after I stop a capture.
|
|
|
|
A: The most likely reason for this is that Ethereal is trying to look
|
|
up an IP address in the capture to convert it to a name (so that, for
|
|
example, it can display the name in the source address or destination
|
|
address columns), and that lookup process is taking a very long time.
|
|
|
|
Ethereal calls a routine in the OS of the machine on which it's
|
|
running to convert of IP addresses to the corresponding names. That
|
|
routine probably does one or more of:
|
|
* a search of a system file listing IP addresses and names;
|
|
* a lookup using DNS;
|
|
* on UNIX systems, a lookup using NIS;
|
|
* on Windows systems, a NetBIOS-over-TCP query.
|
|
|
|
If a DNS server that's used in an address lookup is not responding,
|
|
the lookup will fail, but will only fail after a timeout while the
|
|
system routine waits for a reply.
|
|
|
|
In addition, on Windows systems, if the DNS lookup of the address
|
|
fails, either because the server isn't responding or because there are
|
|
no records in the DNS that could be used to map the address to a name,
|
|
a NetBIOS-over-TCP query will be made. That query involves sending a
|
|
message to the NetBIOS-over-TCP name service on that machine, asking
|
|
for the name and other information about the machine. If the machine
|
|
isn't running software that responds to those queries - for example,
|
|
many non-Windows machines wouldn't be running that software - the
|
|
lookup will only fail after a timeout. Those timeouts can cause the
|
|
lookup to take a long time.
|
|
|
|
If you disable network address-to-name translation - for example, by
|
|
turning off the "Enable network name resolution" option in the "Name
|
|
resolution" options in the dialog box you get by selecting
|
|
"Preferences" from the "Edit" menu - the lookups of the address won't
|
|
be done, which may speed up the process of reading the capture file
|
|
after the capture is stopped. You can make that setting the default by
|
|
using the "Save" button in that dialog box; note that this will save
|
|
all your current preference settings.
|
|
|
|
If Ethereal hangs when reading a capture even with network name
|
|
resolution turned off, there might, for example, be a bug in one of
|
|
Ethereal's dissectors for a protocol causing it to loop infinitely.
|
|
The bug should be reported to the Ethereal developers' mailing list at
|
|
ethereal-dev@ethereal.com.
|
|
|
|
On UNIX-flavored OSes, please try to force Ethereal to dump core, by
|
|
sending it a SIGABRT signal (usually signal 6) with the kill command,
|
|
and then get a stack trace if you have a debugger installed. A stack
|
|
trace can be obtained by using your debugger (gdb in this example),
|
|
the Ethereal binary, and the resulting core file. Here's an example of
|
|
how to use the gdb command backtrace to do so.
|
|
$ gdb ethereal core
|
|
(gdb) backtrace
|
|
..... prints the stack trace
|
|
(gdb) quit
|
|
$
|
|
|
|
The core dump file may be named "ethereal.core" rather than "core" on
|
|
some platforms (e.g., BSD systems)
|
|
|
|
Also, if at all possible, please send a copy of the capture file that
|
|
caused the problem; when capturing packets, Ethereal normally writes
|
|
captured packets to a temporary file, which will probably be in /tmp
|
|
or /var/tmp on UNIX-flavored OSes and \TEMP on Windows, so the capture
|
|
file will probably be there. It will have a name beginning with ether,
|
|
with some mixture of letters and numbers after that. Please don't send
|
|
a trace file greater than 1 MB when compressed. If the trace file
|
|
contains sensitive information (e.g., passwords), then please do not
|
|
send it.
|
|
|
|
Q 5.46: How can I search for, or filter, packets that have a
|
|
particular string anywhere in them?
|
|
|
|
A: If you want to do this when capturing, you can't. That's a feature
|
|
that would be hard to implement in capture filters without changes to
|
|
the capture filter code, which, on many platforms, is in the OS kernel
|
|
and, on other platforms, is in the libpcap library.
|
|
|
|
In releases prior to 0.9.14, you also can't search for, or filter,
|
|
packets containing a particular string even after you've captured
|
|
them.
|
|
|
|
In 0.9.14, you can search for, but not filter, packets that have a
|
|
particular string; this has been added to the "Find Frame" dialog
|
|
("Find Frame" under the "Edit" menu, or control-F).
|
|
|
|
In 0.9.15 and later, you can search for those packets using either the
|
|
mechanism introduced in 0.9.14 or using the new "contains" operator in
|
|
filter expressions, which lets you search the entire packet or text
|
|
string or byte string fields in the packet; the "contains" operator
|
|
can also be used in expressions used to filter the display.
|
|
|
|
Please send support questions about Ethereal to the
|
|
ethereal-users[AT]ethereal.com mailing list.
|
|
For corrections/additions/suggestions for this web page (and not
|
|
Ethereal support questions), please send email to
|
|
ethereal-web[AT]ethereal.com .
|
|
Last modified: Sun, August 08 2004.
|