distnoted -- distributed notification server…
Tcp Dump
Tcp Dump
This command line tool is included with all versions of Mac OS X, and is also available on many other Unix platforms. To get started, try the following command.
sudo tcpdump -i en0 -s 0 -w DumpFile.dmp
Each element of the command line is explained below.
The sudo command causes tcpdump to run with privileges, which is necessary to access promiscuous mode.
The -i en0 option tells tcpdump to capture packets on the first Ethernet interface. You need to select an interface; there is no default. For a list of interfaces, type ifconfig -a. Mac OS X 10.1 and later provide packet capture support on PPP, so you can also specify a PPP interface here (for example, -i ppp0).
Note: If you need to capture PPP packets on traditional Mac OS, try using Interarchy or Sample Code Project ‘OTStreamDumper’.
The -s 0 option requests the full packet rather than just the first 68 bytes.
The -w DumpFile.dmp parameter tells tcpdump to dump the packets to a file called DumpFile.dmp.
In response to this command, tcpdump will begin to capture packets and put them in the DumpFile.dmp file. When you want to stop capturing, interrupt tcpdump by typing ^C. You can then display the contents of the packets as text using the following command.
tcpdump -s 0 -n -e -x -vvv -r DumpFile.dmp
New elements of the command line are explained below.
The -n option means that addresses are not converted to domain names, which speeds things up considerably.
The -e option causes tcpdump to display the link-level header for each packet.
The -x option causes the contents of the packet to also be displayed in hex.
The -vvv option makes tcpdump’s output as verbose as possible.
By specifying -r DumpFile.dmp option you tell tcpdump to read packets from the file DumpFile.dmp rather than from a network interface. Note that you don’t need privileges to do this, so running tcpdump using sudo is not required.
You can also combine these steps, as shown below, but if you do this you don’t get a high-fidelity record of the packets that you captured.
sudo tcpdump -i en0 -s 0 -n -e -x -vvv
You can learn about tcpdump from the online manual and from the book TCP/IP Illustrated, Volume 1, The Protocols, W Richard Stevens, Addison-Wesley, 1994, ISBN 0-201-63346-9. That book is also an excellent introduction to TCP/IP protocols in general.
Note: Mention of third party sites and third party products is for informational purposes only and constitutes neither an endorsement nor a recommendation. Apple assumes no responsibility with regard to the selection, performance, or use of these vendors or products.
Miscellaneous Notes
Some of these tools have problems with packets being transferred to or from the trace machine (the machine running the tool). In general I recommend that your trace machine be separate from the machines whose network traffic you’re tracing. If you don’t follow this advice, please note the following anomalies.
EtherPeek on traditional Mac OS is unable to see packets being sent by the trace machine.
On Mac OS X, both EtherPeek and tcpdump will display bad IP checksums for packets being sent by the trace machine.
You should consult the documentation that comes with your tool for accurate and up-to-date information about its limitations.
If you use a separate trace machine, make sure that you connect all of the machines via a passive hub rather than a switch. Virtually all 10/100 hubs are actually switches, so you’ll probably have to dig through your boxes of old stuff for a 10 Mbit/s-only passive hub (or specifically look for a 10/100 hub that only switches between the different speed segments, for example the SMC-EZ58xxDS range).
If you send a packet trace to DTS, please include the following:
The name and version of the tool you used to capture the packet trace.
The system type and OS version of the trace machine.
If you’ve used either EtherPeek or tcpdump to capture your packet trace, you can send us the packet trace file in its native format. Otherwise, please include a copy of the packet trace in both its native format and, if that native format isn’t text, a text export of the trace as well. That way we’re guaranteed to be able to read your packet trace.
For each relevant machine shown in the trace, please describe the following:
The machine’s role in the network conversation.
The system type and OS version.
The machine’s IP address.
The machine’s hardware address (also known as the Ethernet address or MAC address).
EOF