---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 156
Steve,
Little correction, "captrans" is a NetApp tool, please follow recommendation from Guy Harris earlier today.
Thank you.
Regards, Jagan Bearelly
From guy@netapp.com Fri Mar 10 11:37:27 2000
From: Guy Harris guy@netapp.com Subject: Re: FW: filer-side packet tracing. To: "Uren, Jim" jim.uren@netapp.com Date: Fri, 10 Mar 2000 11:24:37 -0800 (PST) CC: armijo@cs.unm.edu, toasters@mathworks.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit
On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote:
Yes. pktt will do this. It creates a file in tcpdump format, which is convertable into snoop with the right utilities.
would you folks(NetApp) be willing to share these utilities?
As the author of captrans (the utility in question) and the changes to libpcap required to make it read other capture file formats, I don't have any problem making that stuff available.
*However*, there's a better program than captrans - editcap.
It's part of the Ethereal packet capture/analysis program package:
and uses the same library that Ethereal (and the text-mode - snoop/tcpdump-like - utility Tethereal that also comes with Ethereal) uses to read and write capture files. That library can read more capture file formats than can the patched libpcap I have here, and can also write more formats than can captrans.
I don't plan to add any new capture file formats to the patched libpcap, but there are many people who have added new formats to the Wiretap library in Ethereal, and we will probably continue to add new formats as they come up (and as we can figure them out - a lot of the formats were figured out by reverse-engineering, as no documentation was available).
Ethereal requires GLib 1.2[.x] and GTK+ 1.2[.x], so you'd have to have them installed on your system in order to build editcap (unless you tweak the Makefile by hand so as to build only the Wiretap library and editcap, in which case you need only GLib 1.2[.x], but once you've installed GLib, you might as well install GTK+ while you're at it), but, once you've done that, you not only have a program to convert capture files, you have a pretty nice GUI packet capture and analysis program, and a pretty nice text-mode packet capture and analysis program as well.
(It also runs on Win32 operating systems such as Windows 9x and Windows NT - you have to get versions of GLib, GTK+, and libpcap that have been ported to Win32, but those all exist, and Ethereal can even capture packets on Win32 OSes with that version of libpcap.)
There's also, on the "Download" page of the Ethereal Web site, a list of links to binary packages that have been made of Ethereal - or, at least, links to archive sites for binary packages for various OSes - although there's no guarantee that the latest version of Ethereal has been so packaged, in which case the package might not include editcap or Tethereal.
From jagan@netapp.com Fri Mar 10 15:48:25 2000 Date: Fri, 10 Mar 2000 15:48:17 -0800 (PST) From: Jagan Bearelly jagan@netapp.com To: jonas.jonsson@proact.se, armijo@cs.unm.edu, jagan@netapp.com Subject: Re: filer-side packet tracing. Cc: Adam.Fox@netapp.com, toasters@mathworks.com
Steve,
Here is a documentation on "pktt" too. Please see the attachment. Thank you.
Regards, Jagan Bearelly
From jagan@netapp.com Fri Mar 10 15:43:26 2000 Date: Fri, 10 Mar 2000 15:23:56 -0800 (PST) From: Jagan Bearelly jagan@netapp.com To: jonas.jonsson@proact.se, armijo@cs.unm.edu Subject: Re: filer-side packet tracing. Cc: Adam.Fox@netapp.com, toasters@mathworks.com
Steve,
The solaris command "captrans" can be used for conversion and Solaris has man pages for this command. For example, to convert pktt trace file called "e0.trc" into a snoop format, the following command works on Solaris:
captrans -f snoop e0.trc > e0.trc.snoop
Please let me know if you need man pages for "captrans". I hope that helps.
Regards, Jagan
From armijo@cs.unm.edu Fri Mar 10 15:07:59 2000 Date: Fri, 10 Mar 2000 15:59:35 -0700 From: Steve Armijo armijo@cs.unm.edu To: Jonas Jonsson jonas.jonsson@proact.se Cc: "'Steve Armijo'" armijo@cs.unm.edu, "Fox, Adam" Adam.Fox@netapp.com, toasters@mathworks.com Subject: Re: filer-side packet tracing. Mime-Version: 1.0
On Fri, Mar 10, 2000 at 11:59:30AM +0100, Jonas Jonsson wrote:
Well,
In netcache v4.1 there is a presentation of this so it is somewhat documented.
I can't say that I know the documentation of the filer side as well ;)
-----Original Message----- From: Steve Armijo [mailto:armijo@cs.unm.edu] Sent: den 10 mars 2000 10:34 To: Fox, Adam Cc: 'Ronan Mullally'; toasters@mathworks.com Subject: Re: filer-side packet tracing.
On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote:
Yes. pktt will do this. It creates a file in tcpdump format, which is convertable into snoop with the right utilities.
would you folks(NetApp) be willing to share these utilities?
ok, i guess i should have been more specific. would you be willing to share the conversion utilities?
-s
-- Cue the music, fade to black, no such thing as no payback. -PWEI
[ armijo@cs.unm.edu ]
---------- X-Sun-Data-Type: default X-Sun-Data-Name: pktt_doc X-Sun-Charset: us-ascii X-Sun-Content-Lines: 225
Packet trace facility
With the increased use of fast, switched networks it is becoming harder to get network traces from customers. Yet frequently that is the only way to debug certain problems. For that reason we have added a primitive facility for capturing network traffic on the filer, since it is the one place which has access to all network data.
There are two main uses. If a customer site is experiencing crashing bugs it is often useful to have a trace of recent network activity, because the crash is frequently caused by an incoming request. It is possible to log packet traces to memory, where they can then be extracted from the core file.
Since the filer is a storage device, it is also possible to save the packet traces on disk. This can be used to diagnose connectivity problems or unexpected requests, particularly for CIFS where the application/redirector/network combination may make it difficult or impossible to recreate the customer situation.
Command usage
The new command is "pktt" and it is invoked as follows:
pktt start <if>|all [-d dir] [-s size] [-m pklen] [-b bsize] [-i ipaddr ...] [-v] pktt pause <if>|all pktt dump <if>|all [-d dir] pktt stop <if>|all pktt status [<if>|all] [-v]
Each of the subcommands must be followed by an interface name or the word "all." A small exception to this is that "pktt status -v" is equivalent to "pktt status all -v". The available interface names can be found via "ifconfig -a" or "pktt status."
pktt start
The "start" subcommand is used to start tracing, (or restart if it has been paused). The packet trace data is stored in "tcpdump" format in a circular buffer in memory. The flags that can optionally be supplied are as follows:
-d dir
This specifies the path to an existing directory in which the trace data file will be written. The file will always have the name "<if>.trc" where "<if>" is the interface name (e.g. e4, fa3, etc.). If this option is missing the trace data will only be collected in memory, and after the buffer fills, new packets will replace existing packets. However, it is always possible to dump the contents of the buffer at any time using the "pktt dump" command. One thing to be aware of when writing trace data to disk is that if the filesystem cannot keep up with the network traffic you may not log all packets. This will show up in the "dropped" counts when looking at status. Along with this, you should remember that logging all traffic may generate a heavy write load on the filer which may bog it down. If possible, use the IP filter to reduce the amount of data to log. Note that the default value of the -b flag is too small when logging to disk if there is much traffic. You should set -b 128k or larger. (But not too large! See below.)
-s size
This allows you to set a maximum size of the trace file. If you don't specify this the file can grow to 32GB, so you should be careful to set it to a reasonable value if you think there is a chance you might forget you have left the trace going. This parameter is only useful in conjunction with the "-d" option. After the maximum size has been reached, packets continue to be logged to the buffer, but not to disk.
-m pklen
This sets the length at which packets will be truncated. The default is 1500 bytes, which results in full packets for ethernet. Note that in 5.3 the default of 1500 is incorrect for ethernet. You must override with "-m 1514" to get the full packets. It is sometimes useful to limit the data stored when every byte of the packet is not critical. However, for many debugging tasks it is useful to have the entire packet. In the case where the packet size can be larger than 1500 you may want to specify a larger maximum. However, many of the decoders refuse to deal with packets larger than 1500 bytes so you should only specify a larger value if that seems critical to finding the problem.
-b bsize
This sets the buffer size, which may be specified as a number with an optional trailing 'k' or 'm' multiplier. The default is 32K, which is fairly small but may be OK for finding "packet of death" bugs and the like. You should use a value of at least 128K when using the -d option. The value may range from 8K to 128M, but only in the most exceptional cases would it be necessary to increase the size beyond 1-2M. In cases where the network is very busy and it is not practical to log all the traffic to disk you may need to use a larger buffer. Warning! Do not specify a value larger than 3MB, even on a 1GB 760 filer! You may hang the system console or cause WAFL to run out of memory. This will be enforced in later versions, but in 5.3 you have to be careful not to specify too large a buffer size.
-i ipaddr [-i ipaddr] ...
This allows a kind of primitive filtering capability. Up to four IP address may be specified, which causes only traffic to or from any of those IP addresses to be logged. This will, of course, prevent logging of any non-IP (e.g. arp/rarp) traffic.
-v
This causes "pktt status -v" information to be displayed as tracing starts.
Examples of "pktt start"
pktt start e0
This will start capturing network traffic from the "e0" interface. All traffic will be logged to a 32K circular buffer. Or, if tracing had been suspended previously it would be restarted.
pktt start fa3 -d / -s 100m -b 128k
This starts capturing traffic on the "fa3" interface, writing to a file called "/fa3.trc" which will be allowed to grow to a maximum size of 100MB, with a 128K buffer.
pktt start el10 -d /home -m 10k -b 1m -i ehost1 -i ehost2
This starts capturing traffic to and from the hosts "ehost1" and "ehost2", storing the traces into the file "/home/el10.trc". Up to 10K of each packets will be stored, in a 1MB buffer.
pktt start all -b 128k -i 172.20.4.1
All interfaces will start capturing traffic to and from the specified IP address. This is a quick way to look at traffic if you're not sure which interface to use but you want to see the packets from one or more IP addresses.
pktt pause
The "pause" subcommand is used to temporarily stop capturing traffic from one or all interfaces. If any unwritten data is in the trace buffer it will be flushed to disk. Use "pktt start" without any options to restart a paused interface.
pktt dump
The "dump" subcommand causes the contents of the packet trace buffer to be written to a file. If the "-d <dir>" option is used the file will be written to that directory, otherwise it will be written to the root directory of the root volume. The name of the file is always <if>.trc, and the contents are in "tcpdump" format. If a file by that name already exists it will be overwritten.
pktt stop
This causes all tracing to stop on the named interface, or all interfaces. If any unwritten data is in the trace buffer it will be flushed to disk. If you have not dumped the trace data and you were not tracing to a disk file, the trace data will be lost. This action is not confirmed, so be careful when using this command.
pktt status
This can be used to display the buffer and file status of an existing trace. Using "pktt status -v" will give you full tracing status for all interfaces.
Using pktt with "captrans" and "tcpslice"
Guy Harris' "captrans" program is your friend. It allows you to convert between "tcpdump" format and "snoop," "netmon," or "sniffer" formats so that you can use your favorite packet parser to look at the traffic. For example,
tooting> captrans -f snoop /n/filer/root/e4.trc > ~/mycap.snoop
tooting> snoop -i ~/mycap.snoop | more
See the captrans man page for more details on how to use it.
Another useful program is "tcpslice," which can be used to extract time slices from trace files. Unfortunately it won't merge trace files from multiple interfaces. Someday we should enhance it to do that, since it frequently happens that traffic for one client appears on multiple interfaces.