Search     or:     and:
 LINUX 
 Language 
 Kernel 
 Package 
 Book 
 Test 
 OS 
 Forum 
iakovlev.org

Часть 5: Фильтры

When capturing packets from a network interface, Ethereal’s default behavior is to capture all packets that the operating system’s device driver provides. On a lightly loaded home network this is not a problem, but on a busy network at a large enterprise, the deluge of packets would prove too much for the user to handle. Ethereal provides capture filters, which allow you to capture only the packets which you are interested in. By using capture filters, the operating system (OS) sends only selected packets to Ethereal for processing.

Once your packets are loaded into Ethereal, there still may be too many packets for you to easily focus on the problem you’re trying to solve. For this situation Ethereal provides display filters, which allow you to specify which packets are shown in Ethereal’s Graphical User Interface (GUI). As all of the packets are still in memory, they will once again become visible when you reset your display filter.

The reason that there is a distinction between capture filters and display filters is not due to their different uses, but instead to how they are implemented in Ethereal. The Ethereal program does not know how to capture packets from network interfaces by itself. Instead, it relies on a program library to do the packet capturing. On UNIX this library is pcap (also known as libpcap), maintained by the same group that develops tcpdump, the venerable UNIX command-line sniffer available at www.tcpdump.org. On Windows, this library is WinPcap, a device driver and dynamic link library (DLL) that provides a pcap interface for Windows programs. For convenience, we’ll refer to pcap and WinPcap simply as pcap, since for our purposes they are operationally equivalent.

It is the pcap library that provides the capture-filtering mechanism to Ethereal. The pcap library provides a very fast filtering engine, which is important because running a filter on a packet uses processing power from your computer. The packet data has to be analyzed to determine if it passes the filter condition. Inasmuch, if the analysis takes a long time, your operating system might not have time to address the next incoming packet resulting in a dropped packet.

The speed of capture filters is great for live captures, but pcap’s filter language is not powerful or expressive enough for many sniffing or analysis needs. The language itself allows you to test only a few fields from a few protocols. To overcome this deficiency, display filters were introduced to Ethereal. These display filters are a packet filter language completely distinct from pcap’s packet filter language. Almost every protocol and field that Ethereal knows how to retrieve from a packet has a name. Ethereal enables you to use the protocol names and field names to filter packets for display. Display filters rely on a complete dissection of the packet by Ethereal, and thus are much slower than capture filters, which operate differently. Each type of filter has its place; capture filters are good for quickly discarding packets from a live network interface, while display filters are good for fine-tuning which packets you see after the packets have been loaded into Ethereal.

Writing Capture Filters

Ethereal’s capture filters use the pcap library’s filter mechanism. These filters are often called tcpdump filters, as tcpdump is the most famous program that uses the pcap library, and the filter syntax itself is documented in the tcpdump manpage, or manual page. Any program that uses pcap, like tcpdump or Ethereal, can use this filter syntax.

While tcpdump can decode many protocols, its filter language cannot directly address other protocols. The keywords defined in the tcpdump filter language are oriented mostly toward layer 2 and TCP/IP filtering, with few exceptions.

Note 

A manpage, man page, or manual page, is the documentation that comes with a UNIX program. Man pages can be read with the UNIX man command. For example, to read the tcpdump man page, you would type man tcpdump. The Ethereal man page can be read with man ethereal. Many man pages are available as HyperText Markup Language (HTML) on the web. The tcpdump man page is at www.tcpdump.org/tcpdump_man.html and Ethereal man pages can be viewed at www.ethereal.com by clicking on the links under Information | Documentation on the left-hand side of the web page.

Tcpdump Syntax Explained

The tcpdump filter language gives you many ways to look at data inside a packet. The language is designed to give you easy access to the most commonly used fields from the layer 2 and TCP/IP (Transmission Control Protocol/_Internet Protocol) group of protocols by providing keywords that are used to match values of host addresses, hardware addresses, and ports. But, the filter language can handle more than just layer 2 and TCP/IP protocols. It also allows you to look for a number of specific protocols, look at arbitrary bytes in the packet data, and look at meta-data bout the packet.

Host Names and Addresses

Probably the most common use of a tcpdump filter is to capture network traffic originating from or destined for a particular Internet Protocol (IP) address. You can identify an IPv4 (Internet Protocol version 4), IPv6 (Internet Protocol version 6) address, or a hostname by using the host keyword. For example, to captures all IPv4 packets that have a source or destination address of 192.168.1.1, you would use:

host 192.168.1.1

Or, you can use an IPv6 address to capture IPv6 packets:

host 2::8100:2:30a:c392:fc5a

You can also use a hostname or a DNS (Domain Name Service), either which resolves to either an IPv4 or IPv6 address:

host wizard host www.ethereal.com

These three examples will return any IP packet, including Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and any other protocol riding on top of IP, as long as it has an IP source address or IP destination address matching the given IP address or hostname. Furthermore, if the hostname resolves to more than one IP address, as Domain Name System (DNS) entries can, then all of those resolved IP addresses are used in the match.

If you would like to narrow the filter to capture packets that only originate from an IP address, then you use the src (short for source) keyword modifier:

src host 192.168.1.1

Similarly, to match a destination IP address, you use the dst (short for destination) keyword modifier:

dst host 192.168.255.255

You can also use a shorthand notation which takes advantage of the fact that host is understood from src and dst, so that you can check host addresses without using host:

src 192.168.1.1
 dst 192.168.255.255

The host keyword lets you check for an IP address. Similarly, you can use the net keyword to check for an IP network. Use the net keyword in combination with an address formatted in classless interdomain routing (CIDR) notation. CIDR notation is made up of an IPv4 address and a number, separated by a slash. The number after the slash specifies the number of bits, out of the thirty-two bits in the IPv4 address, that make up the network portion of the address. If you want to look at packets coming from any host on the 192.168.100.0 network, which uses 24 bits for the network number (a 255.255.255.0 netmask), then you would use this capture filter:

src net 192.168.100.0/24

Hardware Addresses (MAC Addresses)

If, instead of using IP addresses, you wish to capture packets based on the hardware address of the network card, you use the ether (short for Ethernet) modifier. For example, to find all broadcast packets, which are packets destined for the hardware address ff:ff:ff:ff:ff:ff, use:

ether host ff:ff:ff:ff:ff:ff

There are also fddi (fiber distributed data interface) and tr (token-ring) keywords that match the hardware addresses of NICs (Network Interface Cards). However, since Ethernet, FDDI, and token-ring all contain 6-byte hardware addresses in their protocol headers, the tcpdump filter language treats ether, fddi, and tr as synonyms. It doesn’t matter which of the three topologies your interface card has, you can use any of the three keywords. In practice, ether is most commonly used.

The ether modifier is placed before the dst and src modifiers; to capture packets destined for a particular hardware address, you enter:

ether dst host ff:ff:ff:ff:ff:ff

Again, you can use short hand, because dst implies host, and instead enter:

ether dst ff:ff:ff:ff:ff:ff

To filter packets based on the source hardware address, the src modifier is again used:

ether src host 00:f9:06:aa:01:03
 ether src 00:f9:06:aa:01:03
 

Ports

The port keyword can be used to capture packets that are destined for certain applications, because some applications communicate on well-known TCP and UDP ports. For example, to capture only Hypertext Transfer Protocol (HTTP) packets, which are commonly sent on TCP port 80, you can use:

port 80

However, this checks for packets on both UDP port 80 and TCP port 80. To narrow it to TCP, tcp can be used as a qualifier:

tcp port 80

Or, if you have http defined for a port number in the /etc/services file on UNIX, you can use:

tcp port http

The udp keyword is also available in case you want to capture UDP packets on a certain port. In either instance, the directional qualifiers src and dst can be used. If you are sniffing for UDP requests being sent to a DNS server, you would want to capture UDP packets destined for port 53, as that’s the port for DNS.

udp dst port 53 

If you want the replies, you would look for UDP packets with a source of port 53:

udp src port 53

Logical Operations

The tcpdump filter language allows you to combine several statements with logical operators to create complicated filters. The logic operator not reverses the value of a test, while and and or let you join multiple tests. These three logic keywords have alternate representations, which are used in the C programming language:

  • not is equivalent to !

  • and is equivalent to &&

  • or is equivalent to ||

You can also use parentheses when you need to group multiple statements with logical operations. Parentheses are not always needed, but can be used to make the filter easier to understand.

As an example of negation, to capture everything except DNS lookups, use:

not port 53

Normally, port 53 would capture any TCP or UDP packets with a source or destination port of 53. The logical keyword not reverses the sense of the filter, so that everything is captured except for TCP or UDP packets with a source or destination port of 53.

The logical operator and is used to require that multiple conditions in a test be true. For example, to look at telnet packets to or from the host www.ethereal.com, this filter would be used:

host www.ethereal.com and port telnet

If you wanted either telnet packets or ssh packets, you would use or:

port telnet or port ssh

To combine the port telnet or port ssh test with a test for the www.ethereal.com host, you use and, but you also need to use parentheses:

host www.ethereal.com and ( port telnet or port ssh )

The logical operators and and or have the same precedence, which means that they are analyzed in the order that they are listed in the capture filter. If the parentheses are not used, the capture filter would test for telnet packets to or from the host www.ethereal.com, or ssh packets to or from any IP:

host www.ethereal.com and port telnet or port ssh

Protocols

The tcpdump filter syntax provides some protocol names as keywords, allowing you to test for the existence of these protocols. These protocol keywords are:

  • aarp AppleTalk Address Resolution Protocol

  • ah Authentication Header

  • arp Address Resolution Protocol

  • atalk AppleTalk

  • clnp Connectionless Network Protocol

  • decnet Digital Equipment Corporation Network protocol suite

  • esis (or “es-is”) End System-to-Intermediate System

  • esp Encapsulating Security Payload

  • icmp Internet Control Message Protocol

  • icmp6 Internet Control Message Protocol, for IPv6

  • igmp Internet Group Management Protocol

  • igrp Interior Gateway Routing Protocol

  • ip Internet Protocol

  • ip6 Internet Protocol version 6

  • ipx Internetwork Packet Exchange

  • isis (or “is-is”) Intermediate System-to-Intermediate System

  • iso International Organization for Standardization

  • lat Local Area Transport

  • mopdl Maintenance Operation Protocol

  • moprc Maintenance Operation Protocol

  • netbeui NetBIOS Extended User Interface

  • pim Protocol Independent Multicast

  • rarp Reverse Address Resolution Protocol

  • sca Systems Communication Architecture

  • sctp Stream Control Transmission Protocol

  • stp Spanning Tree Protocol

  • tcp Transmission Control Protocol

  • udp User Datagram Protocol

  • vrrp Virtual Router Redundancy Protocol

For example, to capture all ICMP packets the capture filter is one word:

icmp
 

To capture everything that is not an IPX packet, use negation and the protocol keyword:

not ipx

We’ve talked about ports in TCP and UDP packets, but some protocols use the concept of protocol to indicate what type of payload it is carrying. For example, the IP header contains a protocol field whose numeric value indicates the type of payload it is carrying. Possible values for this protocol field are 1 for ICMP, 6 for TCP, and 17 for UDP. On a UNIX system, you can find a list of IP protocol numbers in the /etc/protocols file.

The tcpdump filter syntax allows you to test the proto field (short for protocol) for the protocols that have it. You can use the proto keyword with the ether, fddi, tr, ppp, ip, ip6, and iso protocol keywords. For example, while you can test for the presence of the TCP protocol via the tcp keyword, you could also check for 6 as the value of the IP protocol field, as “6” designates TCP.

ip proto 6

Protocol Fields

While tcpdump can decode many protocols, the tcpdump filter syntax does not let you easily test for the values of all fields that tcpdump knows how to parse. You’ve seen that many protocol names are provided as keywords, but very few fields within these protocols have names in the tcpdump filter syntax.

Tcpdump filters do allow you to grab and compare values out of the packet, so that if the offset of a field within a protocol is known, its value can be checked. This method is not as elegant as using a field name, but it works.

To retrieve a single byte from a packet, you use square brackets to indicate the offset of that byte from the beginning of a particular protocol. Offsets start at zero, so that tcp[0] would give the first byte in the TCP header, while tcp[1] would give the second byte. Table 5.1 shows the bit layout of the TCP header, as defined by RFC (Request For Comments) 793, available at www.ibiblio.org/_pub/docs/rfc/rfc793.txt.

Table 5.1: TCP Header Layout
Click To expand

Instead of a one-byte integer, you can also retrieve either a two-byte integer or a four-byte integer, using a colon inside the square brackets: tcp[0:2] and tcp[0:4]. Multi-byte integers are always extracted in network order, also known as big-endian order. To compute the value of multi-byte network-order integers, use these formulas:

  • 2-byte value = byte0 * 0x100 + byte1

  • 4-byte value = byte0 * 0x1000000 + byte1 * 0x10000 + byte2 * 0x100 + byte3

The numbers preceded by “0x” in the formulas are hexadecimal numbers.

Unfortunately, only some protocols allow you to retrieve bytes from their data. Interestingly, some protocols whose names could not be used as keywords allow you to retrieve their data by using square brackets. Square brackets can be used to retrieve bytes from these protocols:

  • arp Address Resolution Protocol

  • atalk Appletalk

  • decnet Digital Equipment Corporation Network protocol suite

  • ether Ethernet

  • fddi Fiber Distributed Data Interface

  • icmp Internet Control Message Protocol

  • igmp Internet Group Management Protocol

  • igrp Interior Gateway Routing Protocol

  • ip Internet Protocol

  • lat Local Area Transport

  • link Link layer

  • mopdl Maintenance Operation Protocol

  • moprc Maintenance Operation Protocol

  • pim Protocol Independent Multicast

  • ppp Point-to-Point Protocol

  • rarp Reverse Address Resolution Protocol

  • sca Systems Communication Architecture

  • sctp Stream Control Transmission Protocol

  • tcp Transmission Control Protocol

  • tr Token-Ring

  • udp User Datagram Protocol

  • vrrp Virtual Router Redundancy Protocol

The value that is retrieved from the packet data is an integer, which can be compared with any of the numeric relations shown in Table 5.2.

Table 5.2: Numeric Relations

Numeric Relation

Meaning

>

Greater Than

>=

Greater Than or Equal To

<

Less Than

<=

Less Than or Equal To

= or ==

Equal To

!=

Not Equal To

Additionally, the arithmetic operators +, -, *, and / are provided, as are the bit-wise operators & and |. The bitwise operator & allows you to logically AND the bits of integers, while | allows you to logically OR the bits.

For example, the icmp keyword will let you filter for any ICMP packet. But there are different types of ICMP packets, depending on their function. What if you wanted to look only for ICMP ping packets? The ICMP ping, or echo request/reply, packet layout is shown in Table 5.3. It comes from RFC 792, available at www.ibiblio.org/pub/docs/rfc/rfc792.txt.

Table 5.3: ICMP Echo Request/Reply Header Layout
Click To expand

The ICMP protocol has a field called type, which indicates what type the ICMP packet is. If the type field is 8, then the packet is an ICMP echo (ping) request, while if the type field is 0, then the packet is an ICMP echo (ping) reply. That type field is a one-byte field at the very beginning of the ICMP protocol header. This capture filter tests for packets that are either ICMP ping requests or ICMP ping replies by retrieving that first byte:

icmp[0] == 8 or icmp[0] == 0

As a convenience, the libpcap authors have made available some constant value keywords that are named after ICMP fields. Their values give the offset and the possible values of those fields. The value keywords can be used so that the numbers they stand for need not be remembered. For example, the icmptype is equal to the offset of the ICMP type field (which is 0), the icmp-echo variable is equal to 8, which means that the ICMP packet is an echo request, and icmp-echoreply is equal to 0, which means that the ICMP packet is an echo reply. The test for ICMP ping requests and replies can be written as:

icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply

The keywords that define constant values for field offsets are listed in Table 5.4.

Table 5.4: Constant Value Keywords

Keyword

Value

Used in Protocol

icmptype

0

icmp

icmpcode

1

icmp

tcpflags

13

tcp

Table 5.5 lists the keywords that provide names for the ICMP type values.

Table 5.5: ICMP type Constant Value Keywords

Keyword

Value

icmp-echoreply

0

icmp-unreach

3

icmp-sourcequench

4

icmp-redirect

5

icmp-echo

8

icmp-routeradvert

9

icmp-routersolicit

10

icmp-timxceed

11

icmp-paramprob

12

icmp-tstamp

13

icmp-tstampreply

14

icmp-ireq

15

icmp-ireqreply

16

icmp-maskreq

17

icmp-maskreply

18

Bitwise Operators

The TCP flags field is a bit-field. Bit-fields are integers in which the individual bits are used as separate fields. For example, the TCP flags field is an 8-bit integer field, but the bits in that integer represent independent fields that are either true or false, or 1 or 0. In the tcpdump filter language, the fields for TCP flags have keywords with constant values, as shown in Table 5.6.

Table 5.6: TCP Flags Constant Value Keywords

Keyword

Value

tcp-fin

0x01

tcp-syn

0x02

tcp-rst

0x04

tcp-push

0x08

tcp-ack

0x10

tcp-urg

0x20

The tcpdump filter language defines keywords with constant values for the TCP flags field because it is very common to test for values of this field when looking at TCP problems, especially when related to firewalls or Network Address Translation (NAT). It is important to know how to use bit-field operators properly because complications arise when multiple bits can be set in the bit-field. The TCP flags field can have multiple bits set. Table 5.7 shows the flags field of a TCP packet with its SYN bit (tcp-syn) set.

Table 5.7: TCP SYN Packet Flags Bit-field

URG

ACK

PUSH

RST

SYN

FIN

0

0

0

0

1

0

In this case, only the tcp-syn bit is set, so the value 0x02 can be tested, which is the value of tcp-syn:

tcp[tcpflag] == 0x02

or

tcp[tcpflag] == tcp-syn

However, in the case of the second packet in a TCP handshake, a SYN/ACK packet, both the tcp-syn and tcp-ack bits are set, as shown in Table 5.8.

Table : Table 5.8 TCP SYN/ACK Packet Flags Bit-field

URG

ACK

PUSH

RST

SYN

FIN

0

1

0

0

1

0

When SYN and ACK are both set, the TCP flags field will equal 0x02 + 0x10, or 0x12. Thus the filter tcp[tcpflag] == tcp-syn will fail to show the packets that have SYN plus any other field set; the filter will give you packets that have only SYN set. To write a filter to test for the SYN bit being set, you need to use the bitwise-AND operator to mask out all the bits except for the SYN bit.

tcp[tcpflag] & tcp-syn == 0x02

or:

tcp[tcpflag] & tcp-syn == tcp-syn

The bitwise arithmetic using & (bitwise AND) when comparing a TCP flags field that has SYN and ACK set is shown in Table 5.9.

Table 5.9: TCP SYN/ACK Packet Bitwise AND Against tcp-syn
 

URG

ACK

PUSH

RST

SYN

FIN

Value

Meaning

 

0

1

0

0

1

0

0x12

SYN/ACK

AND

0

0

0

0

1

0

0x02

tcp-syn

 

0

0

0

0

1

0

0x02

tcp-syn

In this case, the bitwise AND produces a result of 0x02, which is equal to tcp-syn, so we have determined that the SYN bit is indeed set. By using the bitwise AND, you can tell if any particular bit in the bit-field is set, even if other bits in the bit-field are set. Table 5.10 shows the bitwise arithmetic when the TCP packet is an ACK packet, and the TCP flags field has only ACK set.

Table 5.10: TCP ACK Packet Bitwise-AND Against tcp-syn
 

URG

ACK

PUSH

RST

SYN

FIN

Value

Meaning

 

0

1

0

0

0

0

0x10

ACK

AND

0

0

0

0

1

0

0x02

tcp-syn

 

0

0

0

0

0

0

0x00

0

The result is 0x00, which does not equal tcp-syn, so a TCP ACK packet does not pass the tcp[tcpflag] & tcp-syn == tcp-syn test.

Packet Size

The tcpdump filter language allows you to test metadata about the packet instead of data from the packet itself. The packet size is available in a variable named len. It can be tested with the standard arithmetic operators. To test for packets smaller than 100 bytes, use this filter:

len < 100

The less and greater operators are built-in shorthand keywords for testing the len variable against a number. less 100 is the same as len <= 100, while greater 1500 is the same as len >= 1500.

$ tcpdump less 100

If your capture filter makes use of punctuation that is normally special to the UNIX shell, you need to enclose your capture filter in single quotes:

$ tcpdump 'len > 1500'

Tcpdump has a –d option, which shows you the Berkeley Packet Filter (BPF) code used to operate the capture filter. BPF is the mechanism that many operating systems provide for packet capture filters. You can read about BPF “The BSD Packet Filter: A New Architecture for User-Level Packet Capture”, by Steven McCanne and Van Jacobson, at www.tcpdump.org/papers/bpf-usenix93.pdf. Here’s an example of BPF code:

$ tcpdump -d  'len > 0xff'
 (000) ld       #pktlen
 (001) jgt      #0xff            jt 2    jf 3
 (002) ret      #96
 (003) ret      #0

Examples

The following list includes a few examples of capture filters.

  • All HTTP packets: tcp port 80

  • Non-HTTP packets: not tcp port 80 or !tcp port 80 or tcp port not 80 or tcp port !80

  • HTTP browsing to www.ethereal.com: tcp port 80 and dst www.ethereal.com

  • HTTP browsing to hosts other than www.ethereal.com: tcp port 80 and not dst www.ethereal.com

  • IPX packets: ipx

  • IPX packets destined for IPX network 00:01:F0:EE: not possible, because you cannot retrieve bytes using the ipx keyword

  • TCP packets: tcp or ip proto 5

  • TCP SYN packets: tcp[tcpflag] & tcp-syn == tcp-syn

  • IP packets with total length > 255: ip[2:2] > 0xff

  • IP or IPX packets: ip or ipx

Using Capture Filters

Tethereal accepts capture filters on the command-line with the –f option, as shown in this example.

# tethereal -i eth1 -f icmp
 Capturing on eth1
   0.000000     10.0.0.5 -> 10.0.0.1     ICMP Echo (ping) request
   0.000062     10.0.0.1 -> 10.0.0.5     ICMP Echo (ping) reply
   1.010753     10.0.0.5 -> 10.0.0.1     ICMP Echo (ping) request
   1.010814     10.0.0.1 -> 10.0.0.5     ICMP Echo (ping) reply

Remember that the argument to –f is a single argument. If your capture filter has spaces in it, you need to surround the capture filter in quotes so that it is passed as the single argument of the –f option:

# tethereal -i eth1 -f 'icmp[0] == 0 or icmp[0] == 8'

Conveniently, Tethereal, like tcpdump, will also accept any leftover arguments on the commandline and use them as a capture filter.

# tethereal -i eth1 icmp[0] == 8

When making use of this facility, you cannot use the –f option.

# tethereal -f icmp -i eth1 icmp[0] == 8
 tethereal: Capture filters were specified both with "-f" and with additional command-line arguments
 

Be aware of characters that are special to the UNIX shell when using capture filters on the command line. This filter should be picking up echo requests and echo replies, but only echo replies are seen.

# tethereal  -i eth1 icmp[0] == 0 || icmp[0] == 8
 Capturing on eth1
   0.000000     10.0.0.1 -> 10.0.0.5     ICMP Echo (ping) reply
   1.009672     10.0.0.1 -> 10.0.0.5     ICMP Echo (ping) reply
   2.016646     10.0.0.1 -> 10.0.0.5     ICMP Echo (ping) reply

The problem is that the two vertical bars (||) are interpreted by the UNIX shell. The two vertical bars and the rest of the command line are never seen by tethereal. To avoid this behavior, use quotes around the capture filter:

# tethereal  -i eth1  'icmp[0] == 0 || icmp[0] == 8'
 Capturing on eth1
   0.000000     10.0.0.5 -> 10.0.0.1     ICMP Echo (ping) request
   0.000057     10.0.0.1 -> 10.0.0.5     ICMP Echo (ping) reply
   1.010248     10.0.0.5 -> 10.0.0.1     ICMP Echo (ping) request
   1.010299     10.0.0.1 -> 10.0.0.5     ICMP Echo (ping) reply

Ethereal, like Tethereal, accepts capture filters with the –f option. If you use Ethereal’s –k option, Ethereal will immediately start capturing packets. You can use the –k option to start a capture and use the –f option to supply a capture filter. Besides –k and –f, Ethereal and Tethereal share many of the same capture-related command line options. However, Ethereal will not accept leftover arguments on the command line and treat them as part of a capture filter.

ethereal [ -vh ] [ -klLnpQS ] [ -a <capture autostop condition> ] ...
         [ -b <number of ringbuffer files>[:<duration>] ]
         [ -B <byte view height> ] [ -c <count> ] [ -f <capture filter> ]
         [ -i <interface> ] [ -m <medium font> ] [ -N <resolving> ]
         [ -o <preference setting> ] ... [ -P <packet list height> ]
         [ -r <infile> ] [ -R <read filter> ] [ -s <snaplen> ]
         [ -t <time stamp format> ] [ -T <tree view height> ]
         [ -w <savefile> ] [ -y <link type> ] [ -z <statistics string> ]
         [ <infile> ]
 tethereal [ -vh ] [ -DlLnpqSVx ] [ -a <capture autostop condition> ] ...
         [ -b <number of ring buffer files>[:<duration>] ] [ -c <count> ]
         [ -d <layer_type>==<selector>,<decode_as_protocol> ] ...
         [ -f <capture filter> ] [ -F <output file type> ] [ -i <interface> ]
         [ -N <resolving> ] [ -o <preference setting> ] ... [ -r <infile> ]
         [ -R <read filter> ] [ -s <snaplen> ] [ -t <time stamp format> ]
         [ -T pdml|ps|text ] [ -w <savefile> ] [ -y <link type> ]
         [ -z <statistics string> ]

Being a graphical application, Ethereal also accepts capture filters in its graphical user interface. Before starting to capture packets, the Capture Options dialog box, as shown in Figure 5.1, provides a Filter text entry box where you can type a capture filter.

Click To expand
Figure 5.1: Capture Options Dialog Box

Writing Display Filters

Ethereal’s display filter mechanism is designed differently than tcpdump’s filters. Tcpdump is a packet analyzer that knows how to decode many protocols, but it relies on libpcap’s filtering engine. Libpcap is a separate library that does not know how to parse many protocols, so libpcap’s filter language is poor in relation to tcpdump’s ability in this respect.

In Ethereal, the protocol-dissection mechanism is intertwined with the display filter mechanism. For almost every item you see in the protocol tree in the middle pane of Ethereal’s GUI, Ethereal has a field name that you can use in a display filter. The Appendix of this book has a list of some commonly used display-filter field names that Ethereal defines, while the CD-ROM that accompanies this book provides HTML pages that show all the display-filter field names for Ethereal version 0.10.0a. These HTML pages are in the /filters directory on the CD-ROM. You can also use the Help | Supported Protocols | Display Filter Fields option in Ethereal to see a similar list. Perhaps the easiest way to find the display-filter name of a field that you’re interested in is to highlight that field in the Ethereal GUI. When highlighted, Ethereal will provide the display-filter field name in the right-hand side of the status bar at the bottom of the GUI. Figure 5.2 shows that ip.len is the name of the IP Total Length field. The ip.len field name is shown in parentheses in the status bar on the bottom right of the Ethereal window.

Click To expand
Figure 5.2: Display Filter Name for IP Total Length

Even the protocol names themselves have display-filter names. Figure 5.3 shows that the ip field name represents the IP protocol.

Click To expand
Figure 5.3: Display Filter Name for IP

Writing Expressions

To test for the existence of a protocol or a field, the display filter is simply the display-filter field name of that protocol or field. To show all IP packets, use:

ip

This shows all packets where the IP protocol is present. You could also show all packets where a field is present:

ip.len

Because IP packets always have a total length (ip.len) field, this is functionally equivalent to testing merely for ip. But some protocols, like TCP, can vary the fields that are present in a protocol header. TCP has optional fields, one of which is MSS option, represented by the tcp.options.mss_val field name. To find all packets that have the tcp.options.mss_val field, just name the field in the display filter:

tcp.options.mss_val

Display-filter fields in Ethereal are typed. This means that depending on its type, a field can hold only certain values. The types in the display filter language are shown in Table 5.11.

Table 5.11: Display Filter Field Types

Display Filter Field Types

Possible Values

Unsigned Integer

Non-negative integers. Can be 8-, 16-, 24-, 32, or 64-bits wide

Signed Integer

Integers. Can be 8-, 16-, 24-, 32-, or 64-bits wide

Boolean

True or False

Frame Number

Like a 32-bit Unsigned Integer, but with special behaviors

Floating Point

Decimal number, i.e., real numbers

Double-precision

Floating point number that can store more Floating Point digits

String

Sequence of characters

Byte String

A sequence of hexadecimal digits

Hardware Address

A six-byte long Byte String with name-lookup capabilities

IPv4 Address

IPv4 address with name-lookup capabilities

IPv6 Address

IPv6 address with name-lookup capabilities

IPX Network

4-byte IPX network number with name-lookup capabilities

Absolute Time

Date/time stamp

Relative Time

Number of seconds between two absolute times

None

A field that holds no value and is used only as a label or placeholder

Protocol

Protocol keywords

The operators that can be used to compare values are shown in Table 5.12.

Table 5.12: Operators Used to Compare Values

Operators

Meanings

> or gt

Greater Than

>= or ge

Greater Than or Equal To

< or lt

Less Than

<= or le

Less Than or Equal To

== or eq

Equal To

!= or ne

Not Equal To

contains

A string or byte string is found within another

matches

A regular expression matches a string

Multiple relations can be combined with the logical operators and and or. You can negate the logical meanings with not. Parenthesis can be used to group logical operations correctly.

Note 

The matches operator only works if your copy of Ethereal was compiled with support for the Perl Compatible Regular Expressions (PCRE) library. Perl is a very popular scripting language which has regular expression built into its syntax, giving programmers a powerful way to search for strings. The PCRE library, available at www.pcre.org, enables other programs, like Ethereal, to use regular expressions that are in the same syntax as those provided by Perl. Furthermore, the matches operator was introduced to Ethereal in version 0.10.0, and only works with string fields. During the development of this book, the matches operator has been extended to work on byte sequences and protocols, just like the contains operator. When Ethereal 0.10.1 is released, the matches operator will work on all the same fields that the contains operator currently supports.

Integers

Integer fields hold numeric values. The numeric values are integers, or whole numbers without fractional parts. Integers can be expressed in decimal, octal, or hexadecimal notation. The octal notation requires an initial “0” (zero), while hexadecimal notation requires an initial “0x” (zero x). Table 5.13 shows examples of how to write the same integer in decimal, octal, and hexadecimal representations.

Table 5.13: Different Representations for the Same Integer

Display Filter

Integer Notation

eth.len > 1500

Decimal

eth.len > 02734

Octal

eth.len > 0x5dc

Hexadecimal

Integer fields are categorized as signed or unsigned, and as 8-bit, 16-bit, 24-bit, 32-bit, or 64-bit in width. These two categories describe how the integers are stored in a computer’s memory. The categories determine the range of values that the integer can be (see Table 5.14).

Table 5.14: Range of Values According to Integer

Bit Width

Signed Range

Unsigned Range

8-bit

-27 to 27-1
-128 to 127

0 to 28-1
0 to 255

16-bit

-215 to 215-1
-32,768 to 32,767

0 to 216-1
0 to 65,535

24-bit

-223 to 223-1
-8,388,608 to 8,388,607

0 to 224-1
0 to 16,777,215

32-bit

-231 to 231-1
-2,147,483,648 to
2,147,483,647

0 to 232-1
to
4,294,967,295

64-bit

-263 to -263-1

0 to 264-1

Some integer fields also have labels representing specific values that the field can be. For example, the Systems Network Architecture (SNA) Transmission Group Segmenting Field, or sna.th.tgsf, can have four distinct values, as shown in Table 5.15.

Table 5.15: SNA Transmission Group Segmenting Field

Integer Field/Value

Label

0

Not Segmented

1

Last segment

2

First segment

3

Middle segment

In these cases, either the integer value or the label can be used when testing for values of sna.th.tgsf. These display filters are equivalent:

sna.th.tgsf == 2
 sna.th.tgsf == "First segment"

This example also shows one instance of how text (or, in programmer jargon, strings) can be represented in a display filter. Note that the label is enclosed by double quotes. More ways of representing strings will be discussed in the section about string fields.

You can use the Filter Expression dialog box, described later in this chapter, to look at the possible values for fields that have label values. You can also use the tables in the Appendix of this book, or the HTML pages in the /filters directory on the accompanying CD-ROM to find the same information.

Some integer fields are of a type called frame number. This is a special integer type within Ethereal that acts like a 32-bit unsigned integer type, but if you right-click on such a field in the GUI, the pop-up menu will have an option called Go to Corresponding Frame which brings you to the frame mentioned by the field. This is used for protocols that make use of request/response packet pairs. For example, the Server Message Block (SMB) and NetWare Core Protocol (NCP) protocols make use of frame-number fields. Figure 5.4 shows an SMB response packet with a field smb.response_to, which gives the frame number of the request packet. Being able to jump to the request packet by clicking on a field in the reply packet can be handy when debugging network problems.

Click To expand
Figure 5.4: SMB Response

Booleans

Boolean fields are fields that have a true or false value. They can be compared against the strings True and False, in lower-case, upper-case, or any combination of case, or against the values 1 and 0, which are Ethereal’s internal representation of True and False, respectively. In some cases, boolean fields, like integer fields, have labels that better describe the 1 or 0 value. For example, the sna.rh.sdi field, the SNA Sense Data Included field, is a boolean field that has the labels Included and Not Included, which describe its values more accurately than True or False. These display filters are equivalent:

sna.rh.sdi == 0
 sna.rh.sdi == "Not Included"
 sna.rh.sdi == false

Floating Point Numbers

Floating point numbers are different from integer numbers in that they contain fractional parts. Even if the number to the right of the decimal point is 0 (or decimal comma, if your locale uses commas instead of periods), it’s still a fractional part of the number. Floating point numbers can be positive or negative. Ethereal provides two types of floating point numbers: regular floating point numbers, and double-precision floating point numbers. The difference between the two is that double-precision floating point numbers can more accurately represent numbers than regular floating point numbers because more digits can be stored. In practice, all of Ethereal’s floating point numbers are of the double-precision type.

Floating point numbers, either regular or double-precision, are not frequently found in protocols, but they do exist. For example, the who protocol, which is the format of the messages sent by the rwhod program on UNIX systems announcing load averages and current logins, has floating point numbers. Some example display filters are:

who.loadav_5 > 3.5
 who.loadav_10 <= 10
 who.loadav_10 <= 10.0

Strings

Some fields hold text values. Sequences of characters are called strings in programming jargon and in Ethereal. If the string you want to represent has no spaces and is not the same as the name of a field, you can use the string directly in your display filter:

sna.rh.csi == ASCII

However, if the string has a space in it, or is the same as the name as a field, the string will have to be enclosed in double quotes:

sna.rh.sdi == "Not included"

If the string you’re providing has a double quote in it, you need to use a backslash followed by a double-quote to embed that double quote in the string. The following display filter looks for a double-quote, followed by Y, E, S, followed by another double-quote.

http contains "\"Yes\""

The backslash also allows you to embed 8-bit unsigned integers, that is, single bytes, inside the string by using either hexadecimal or octal notation:

frame contains "\0777"
 frame contains "\xff"

And if you’re really looking for a backslash, then you use a backslash followed by another backslash. To look for \begin, the display filter would look like:

http contains "\\begin"

Ethereal’s display filter syntax currently only allows you to look for ASCII (American Standard Code for Information Interchange) strings. While the Edit | Find Packet GUI option allows you to search for ASCII and Unicode strings, the display filter language doesn’t allow you to search any other string-encoding, including Unicode or EBCDIC (Extended Binary Coded Decimal Interchange Code) strings. Hopefully, a future version of Ethereal will provide an extension to the display filter language to allow you to denote the character encoding you want when looking for a string. Similarly, be aware that all string comparisons are case-sensitive. In the display filter language, searching for GOOD will not uncover good, as the former is in uppercase, while the latter is in lowercase. Once again, perhaps a future modification to Ethereal will add the ability to perform case-insensitive comparisons.

The matches operator lets you search for text in string fields using a regular expression. The operator is named after the Perl match operator (m//), and in fact, the regular expressions supported by Ethereal are the same regular expressions that Perl uses. Ethereal manages this by using the Perl Compatible Regular Expressions (PCRE) library, which other popular applications also use. This is helpful because you don’t need to learn an Ethereal-specific regular expression syntax if you already happen to know regular expressions from Perl, Python, PHP (a recursive acronym which stands for “PHP: Hypertext Preprocessor”), Apache, Exim, or many other applications.

The best documentation for Perl regular expressions comes from the Perl regular expression manual page, available on-line at www.perldoc.com/perl5.8.0/pod/perlre.html. The Python documentation at www.python.org/doc/current/lib/re-syntax.html also provides a useful summary of regular expression syntax. An entire book could be written on regular expressions, but in short, by using a special syntax, you can search for patterns of strings, instead of just simple strings, in a string field. For example, if you want to look for a directory name with a numeric digit in NetWare Core Protocol’s ncp.directory_name field, you would use:

ncp.directory_name matches "\d"

If you wanted directory names that start with an “f” or an “F”, and have numeric digits, the display filter would be:

ncp.directory_name matches "^[Ff].*\d"

As you can see, regular expression syntax is cryptic if you haven’t practiced it. But once you learn it, regular expressions are powerful tools that can help you find just about anything.

Byte Sequences

Sequences of bytes, including Ethernet addresses, are represented by a sequence of hexadecimal digits, in upper-case or lower-case, separated by colons, periods, or dashes. For example, the broadcast Ethernet address ff:ff:ff:ff:ff:ff can be also be represented as ff.ff.ff.ff.ff.ff or as ff-ff-ff-ff-ff-ff.

Ethernet addresses are byte sequences, but are special because names can be assigned to them via an ethers file that you create. On UNIX, the global file is /etc/ethers, and the personal file is $HOME/.ethereal/ethers. On Windows, the global ethers file would be placed in the Ethereal installation directory, and the personal file would be created as %APPDATA%\Ethereal\ethers, or if %APPDATA% doesn’t exist, then %USERPROFILE%\Application Data\Ethereal\ethers. The ethers file has the format of one hardware address and one name per line, separated by any amount of spaces or tabs:

00:09:f6:01:cc:b3   picard
 01:1a:e3:01:fe:37   worf
 

When a name exists for an Ethernet address, the name can be used in the display filter:

eth.src == 00:09:f6:01:cc:b3
 eth.src == picard

Internally, Ethereal treats protocols as a special field type, but in one aspect, protocols act like byte sequence fields. The contains operator can be used to search through the bytes that belong to each protocol in the packet. The bytes in a packet that are specific to a protocol are treated as belonging to that protocol in the display filter language. The exception is the special frame pseudo-protocol. At the top of every protocol tree, Ethereal places a pseudo-protocol that contains metadata about the packet, including the arrival time and the length of packet. These fields don’t actually appear in the packet data, but are relevant to the packet. Ethereal regards all the bytes in the packet as belonging to the frame pseudo-protocol. Therefore, you can use the contains operator to search for any bytes or ASCII text within the entire packet by checking if the frame protocol contains the bytes or text.

frame contains "POST"
 frame contains 50:4f:53:54

You can, of course, limit your search to a more specific protocol if you know that the text should appear there. For example, to search for GET in the http protocol, use:

http contains "GET"

Addresses

You’ve already seen an example of an address field in the discussion about hardware address fields in the Byte Sequences section. Address fields have the distinction of being represented by either a numeric value or a name. The Ethernet address field is both an address field and a byte-sequence field. The other address fields are the IPv4 address, IPv6 address, and IPX network fields.

IPv4 address fields can be compared against the dotted-quad format of IPv4 addresses, or hostnames and DNS names. The dotted-quad notation is four numbers separated by periods, or dots. In this example, the source IP address field name is ip.src, while the destination IP address field name is ip.dst:

ip.src == 192.168.1.1
 ip.dst == wizard
 ip.dst == www.ethereal.com

If you want to test if either the source IP address or the destination IP address is wizard, you can use the logic or operator to combine two tests:

ip.src == wizard or ip.dst == wizard

But Ethereal provides another field, ip.addr, which stands for either ip.src or ip.dst:

ip.addr == wizard

You will find that most of the fields that have a concept of source and destination will provide a third field that tests for either source or destination, to help you write succinct display filters.

To test if an IPv4 address is within a certain subnet, the == operator and classless interdomain routing (CIDR) notation can be used, which works with dotted-quad notation, hostnames, or DNS names. In CIDR notation, the IPv4 address or hostname is followed by a slash and the number of bits that make up the network portion of the IPv4 address.

ip.addr == 192.168.1.0/24
 ip.addr == wizard/24

IPv6 address fields are similar in name to their IPv4 counterparts: ipv6.src for the source address, ipv6.dst for the destination address, and ipv6.addr to test either source or destination address. For example,

ipv6.dst == 2::8100:2:30a:c392:fc5a or ipv6.dst == 2::8100:2:30a:c392:fc5a
 ipv6.addr == 2::8100:2:30a:c392:fc5a

IPX addresses are comprised of two parts, the network address and the node address. This is comparable to an IPv4 address, where part of the 32-bit IPv4 address is the network portion, and the other part refers to a specific host on that IPv4 network. In IPX, however, the network and node (that is, the host) are separate fields instead of being combined into a single value.

The IPX node fields are hardware-address type fields, but the IPX network fields are unsigned 32-bit integer fields. Ethereal treats IPX network fields differently than normal integer fields in that Ethereal allows you to give names to IPX network numbers. This is useful if you need to analyze IPX packets in an environment where there are many different IPX networks; names are easier to remember than numbers. To define the IPX network names, you create a file called ipxnets. On UNIX, you can create a global ipxnets file in /etc/ipxnets, and a personal file, whose values override the global values, in $HOME/.ethereal/ipxnets. On Windows, the global file is the ipxnets file in the Ethereal installation directory, while the personal file is %APPDATA%\Ethereal\ipxnets, or if %APPDATA% doesn’t exist, then %USERPROFILE%\Application Data\Ethereal\ipxnets. The format of the ipxnets file is the same as the ethers file, except that the hexadecimal bytes representing the IPX network number can be separated by periods, dashes, colons, or nothing. Here is an example from the Ethereal man page:

C0.A8.2C.00              HR
 c0-a8-1c-00              CEO
 00:00:BE:EF              IT_Server1
 110f                     FileServer3

Given this ipxnets file, these two display filters are equivalent:

ipx.src.net == 0xc0a82c00
 ipx.src.net == HR
Note 

Storing hardware addresses in an /etc/ethers file used to be common practice on UNIX systems, but many UNIX systems these days no longer come with an /etc/ethers file. However, the /etc/ipxnets file has no such history. It is a file unique to Ethereal. Don’t expect to find an intalled /etc/ipxnets file on a UNIX system, even if that system comes with an /etc/ethers file.

Time Fields

There are two types of time fields in Ethereal. While they are related to each other, they are represented very differently. An absolute time is a timestamp that combines a date and a time in order to specify a specific moment in time. A relative time is just a floating point number; it’s the number of seconds (including fractional seconds) between two absolute times.

Absolute times are represented as strings of the format

Month Day, Year Hour:Minute:Seconds

They can include fractions of a second, with nanosecond resolution

Month Day, Year Hour:Minute:Seconds.Nsecs

To look at packets that arrived before December 31st, 2003, at 5:03AM, the display filter would be:

frame.time < "Dec 31, 2003 05:03:00"

Ethereal provides the frame.time_delta field to record the difference in arrival times between a packet and its immediate predecessor. Currently, the only way to represent this relative time is with a floating point number that indicates seconds with nanosecond resolution:

frame.time_delta > 0.02

Maybe in the future Ethereal will allow the use of units, such as “1 min 5.3 secs”.

Other Field Types

Some fields have no values associated with them. They don’t have an integer value, string value, or any other value. You can test for the existence of these fields, but they don’t have a value that you can check with ==, <, >, or any other relation. These no-value fields are generally used by the protocol dissector to place text or a branch in a protocol tree.

If you inspect the protocol trees in your packet captures, you’ll eventually discover that some of the items in the protocol tree don’t have any display-filter field associated with them. In some cases, protocol dissectors merely add text to the protocol tree, without labeling the text as belonging to a field. Figure 5.5 shows how the HTTP protocol dissector does this for the HTTP headers. It places the User-Agent field in the protocol tree without giving it a display-filter field name.

Click To expand
Figure 5.5: HTTP Headers as Text

Unfortunately, you cannot create a display filter to search for these types of text labels. However, if the text is found in the packet data, the contains operator can be used to search for the text in a protocol, or even the entire packet by using the frame pseudo-protocol. To find HTTP packets where the User-Agent is “Mozilla”, as in Figure 5.5, use contains:

http contains "User-Agent: Mozilla"

Ranges

The string, byte sequence, and protocol field types have something in common besides being searchable by the contains operator - they are all sequences of bytes. Strings are sequences of characters, but characters are really just bytes. The other field types - integers, floating points, times, etc., - can be thought of as single values rather than sequences of anything. Sometimes it is useful to take a portion of a string, byte sequence, or protocol, that is, slice the data into a smaller section, and compare it against a value. You can slice a sequence by using the ranges functionality of Ethereal’s display filter language. The ranges syntax uses square brackets: [ and ].

To obtain a single byte from a sequence, use the offset of that byte in square brackets. The offset is the position of the byte starting at the beginning of the named field. As typical for computer languages, Ethereal’s display filter language offsets begin at 0. To compare the very first byte in an Ethernet address to the hexadecimal value 0xaa, use:

eth.addr[0] == aa

The hexadecimal byte value aa is not interpreted as the string “aa”, nor can you provide a integer value by typing 0xaa.

Since 0 is the offset of the first byte, 1 is the offset of the second byte. To compare the second byte of the bytes in the telnet portion of the packet to the hexadecimal value 0xff, use:

telnet[1] == ff

A sample of a full hexadecimal table can be found at: www.cookwood.com/_cookwood/html4_examples/4files/colorhex/hexchart.html

Ranges can do more for you than extracting single bytes. You can extract actual ranges of bytes from the fields. Use a colon to separate the offset from the number of bytes in the brackets. To compare the first three bytes of a token-ring address to 00:06:29, type the length of the slice after the colon. The length is 3 because we are comparing three bytes:

tr.addr[0:3] == 00:06:29

If you would rather provide ranges of offsets rather than offset/length pairs, then a hyphen in the brackets can be used. This display filter also compares the first three bytes of a token-ring address to 00:06:29, but by slicing the tr.addr field from offset 0 up to, and including, byte 2.

tr.addr[0-2] == 00:06:29

When using the colon notation to give byte offset and range length, you can choose not to provide either the offset or the length, yet keep the colon.

eth[:2] == ff:ff
 http[10:] contains 00:01:02

When the offset is not provided, as in the eth[:2] case, then the offset is assumed to be zero. When the length is not provided, as in the http[10:] case, then the range includes all the bytes until the end of the field or protocol mentioned.

Within the brackets, you can use commas to concatenate, or combine, multiple ranges of the same field. For example, if you wish to look at the first byte (offset = 0) and third byte (offset = 2) of the token-ring protocol, then you can either create two ranges, combining them with the and logical operator, or simply combine the ranges into one range using a comma inside the square brackets:

tr[0] == ff and tr[2] == ee
 tr[0,2] == ff:ee

The comma operator can combine any number of ranges, so the following monstrosity is entirely legal:

tr[0-2,4:3,7,9] == 01:02:03:04:05:06:07:08

Table 5.16 is a summary of the range syntax options.

Table 5.16: Range Syntax

Range Syntax

Meaning

[ offset ]

Slice a single byte at “offset”

[ offset : length ]

Slice “length” bytes starting at “offset”

[ offset1 – offset2 ]

Slice bytes from “offset1” to “offset2”, inclusive

[ : length ]

Slice “length” bytes starting at offset 0

[ offset : ]

Slice bytes from “offset” to end of field

[ range , range ]

Combine any range syntax with another

Note 

The Ethereal documentation states that you are supposed to be able to use negative numbers as offsets. Negative offsets indicate the offset counting backwards from the end of the field. But, in our testing this doesn’t work as advertised. It is extremely likely that this will be fixed in a future version of Ethereal.

Logical Operations

You’ve already seen many examples of combining multiple relations in the same display filter with the and operator. The and logical operator tests that the two relations it combines are true. To filter for a specific source IP address and a specific destination IP address, use and.

ip.src == 192.168.1.1 and ip.dst == 192.168.2.2

The or logical operator tests if either, or both, of the two relations that it joins is true. If you wanted to test an IP address to see if it was one of two values, you use or.

ip.addr == 192.168.3.3 or ip.addr == 192.168.4.4

The not logical operator reverses the sense of the relation. To find NetWare Core Protocol packets that have an ncp.directory_name field which does not contain the string “System”, you would use this display filter:

not ncp.directory_name contains "System"

Parentheses are used to group relations according to how not, and, and or, should combine them. These two display filters are not the same, due to the presence of parenthesis.

not eth.dst eq ff:ff:ff:ff:ff:ff and ip.len gt 1000
 not (eth.dst eq ff:ff:ff:ff:ff:ff and ip.len gt 1000)

In the first example, not negates the meaning of the eq. In the second example, not negates the meaning of the grouped expression, which is an and expression.

Multiple Occurrences of Fields

Some protocols occur more than once per packet. This can happen when you’re looking at encapsulated or tunneled protocols. For example, Protocol Independent Multicast (PIM) can run on top of IPv6 and at the same time send other IPv6 data. Thus, you can have two instances of IPv6 in a single packet by using PIM. More commonly, the same field can occur more than once in a single protocol. Some protocols have repeated fields, like the ring/bridge pairs in source-routed token-ring packets.

In other cases where the protocol does not normally have multiple occurrences of fields, Ethereal will create multiple occurrences of fields to enhance the filtering. As mentioned in the discussion about address fields, there are many fields that have a source version and a destination version. In those cases, the protocol dissector adds two generic (non-source, non-destination) versions of the field so that a display filter can test both the source and destination fields in one statement. Table 5.17 shows some examples of those fields.

Table 5.17: Generic Versions of Source and Destination Fields

Source Field

Destination Field

Generic Version

eth.src

eth.dst

eth.addr

fddi.src

fddi.dst

fddi.addr

ip.src

ip.dst

ip.addr

ipx.src.net

ipx.dst.net

ipx.net

ipx.src.node

ipx.dst.node

ipx.node

tcp.srcport

tcp.dstport

tcp.port

tr.src

tr.dst

tr.addr

udp.srcport

udp.dstport

udp.port

Care must be given when testing fields that occur more than once in a packet. For example, if you have a packet capture that has a lot of HTTP traffic in it, as does the example in Figure 5.6, and want to use a display filter to hide the HTTP traffic because you’re not interested in it, you might be tempted to use this display filter, where 80 is the TCP port for HTTP:

tcp.port != 80
Click To expand
Figure 5.6: TCP Ports for HTTP Traffic

Unfortunately, this doesn’t work. Why? This display filter is saying “show me all the packets which have a tcp.port that does not equal 80.” Take a look at Figure 5.6; one tcp.port, the destination port, is 80, while the other tcp.port, the source port, is 43,466. This packet does pass the tcp.port != 80 filter, because it has one tcp.port which is not equal to 80.

What you want to say instead is “show me all the packets where none of the tcp.port values are equal to 80.” Or equivalently, “show me the packets which do not have at least one tcp.port equal to 80.” In the correct display filter language, this is:

not tcp.port == 80

It takes some getting used to, but once you understand what the display filter language is doing, you will become more comfortable with it.

Hidden Fields

If you look closely at some protocols in the protocol dissection tree, you might start to notice that some fields that should be present simply are not visible. For example, if you look at the Ethernet portion of a protocol tree in Figure 5.7, you’ll find the Ethernet Source address (eth.src) and the Ethernet Destination address (eth.dst), but you’ll never find a field labeled “Source or Destination Address”, which is the description for the eth.addr field. This is because eth.addr was placed in the protocol tree as a hidden field to aid in writing display filters. You can use the hidden fields in display filters, but you never see them in the protocol tree. Ethereal does this for convenience, and to keep the protocol tree from having duplicate information. Unfortunately, there is no option to make Ethereal display hidden fields. Maybe in the future there will be.

Click To expand
Figure 5.7: Ethernet Source and Destination Address Fields
/* Dumps the contents of the registration database
  * to stdout. An indepedent
  * program can take this output and format it into
  * nice tables or HTML or
  * whatever.
  *
  * There is one record per line. Each is either a
  * protocol or a header
  * field, differentiated by the first field.
  * The fields are tab-delimited.
  *
  * Protocols
  * ---------
  * Field 1 = 'P'
  * Field 2 = protocol name
  * Field 3 = protocol abbreviation
  *
  * Header Fields
  * -------------
  * Field 1 = 'F'
  * Field 2 = field name
  * Field 3 = field abbreviation
  * Field 4 = type ( text representation of the ftenum type )
 * Field 5 = parent protocol abbreviation
  */
 

You can see this glossary by running ethereal –G or tethereal –G. The –G option can also take a parameter. The –G protocols option makes ethereal or tethereal show the glossary only for protocols. The –G fields option shows both protocols and non-protocol fields, just like the –G option with no additional parameter. You can also look at doc/Makefile.am (or doc/Makefile.nmake, for Windows) and doc/dfilter2pod.pl in the Ethereal source distribution to see how the Ethereal build system uses the -G switch to produce the ethereal-filter manual page.

Filter List Dialog Boxes

Ethereal allows you to save both capture filters and display filters, and use them again in the future by selecting from a menu. This is nice when you have complicated filters or many filters that you use often. Ethereal maintains two distinct lists of filters, one for capture filters and another for display filters. The user interfaces for both lists of filters are almost identical, so they will be explained together.

The Capture | Start menu item presents the Capture Options user interface, shown in Figure 5.8. Next to the text entry box where you can type in a capture filter, there is a button labeled Filter:. Clicking this button brings up the Capture Filter user interface. Another way to open the Capture Filter dialog box is to select the Capture | Capture Filters menu item.

Click To expand
Figure 5.8: Capture Options Dialog Box

As shown in Figure 5.9, at the bottom of the main Ethereal window is the text entry box where you can type in a display filter. Next to this box is a button labeled Filter:. Clicking this button brings up the Display Filter user interface. The Display Filter user interface can also be opened from the Analyze | Display Filters menu option.

Click To expand
Figure 5.9: Ethereal Main Window and Filter Button

You’ll notice that the Capture Filter window in Figure 5.10 and the Display Filter window in Figure 5.11 are nearly identical. The only functional differences are the existence of an Add Expression button and an Apply button in the Display Filter window, unless the Display Filter window was opened via Analyzer | Display Filters. The Add Expression button brings up a user interface to create display filters by pointing and clicking. The Apply button applies the display filter to a currently loaded capture file, thereby possibly changing the packets that are displayed in the main Ethereal GUI. The Capture Filter window does not have an Apply button because capture filters do not affect the currently-loaded capture file.

Click To expand
Figure 5.10: Capture Filter Dialog Box
Click To expand
Figure 5.11: Display Filter Dialog Box

To add a new filter to the list, enter a meaningful name in the Filter name text entry box and enter the filter itself in the Filter string text entry box. Then click the New button. This adds the named filter to the list, as shown in Figure 5.12.

Click To expand
Figure 5.12: Display Filter Dialog After Clicking New

To change either the name or the contents of a filter, highlight the name of the filter in the list of filters by clicking on it. The name of the filter you just clicked on and its contents should now appear in the Filter name and Filter string text-entry boxes. Clicking on the text in either or both of these will allow you to modify the filter name and contents. When you are ready to save the modification, click the Change button.

To create a new filter based on a currently saved filter, highlight the name of the filter you wish to copy. The filter’s name and contents should appear in the Filter name and Filter string text entry boxes. Click the Copy button and a new filter will be created and put into the list of filters. The new filter will be named “Copy of ...”, where “...” is the name of the filter you highlighted. The contents will be an exact replica of the contents of the original filter, as shown in Figure 5.13. At this point, you can modify the name or contents of the new filter as you would any other filter. Of course, be sure to click the Change button after changing your new copy, otherwise the changes won’t be saved.

Click To expand
Figure 5.13: Display Filter Dialog After Clicking Copy

To delete a filter from the filter list, highlight the name of the filter, and ensure that its name and contents appear in the Filter name and Filter string text entry boxes. Click the Delete button and it will disappear.

Clicking the OK button in the Display Filter or Capture Filter window will do two things: it will save your filter modifications in memory, but not to disk, and if you have a filter currently highlighted, it will place that filter in the text entry box from which the Display Filter or Capture Filter window was opened. For Capture Filters, the filter is placed in the Capture Options window, the Capture Filter window is closed, and you can continue to modify your options for capturing packets. For Display Filters, the filter is placed in the text entry box at the bottom of the main Ethereal window and is applied to the currently loaded capture file. At this point, if you quit the Ethereal program, your modifications to the display or capture filter list will be lost.

If you want to save your modifications to the filter lists, you must press the Save button in the Display Filter and Capture Filter windows.

The Close button in the Display Filter and Capture Filter windows also saves your modifications in memory only, and closes the filter window, but unlike the OK button, does not apply your filter to the Capture Options window or the main Ethereal window.

Filter Expression Dialog Box

It’s impossible to remember all the field names that are available in Ethereal’s display filter language because there are over 15,000 of them. Ethereal comes with a manual page named ethereal-filter, which lists all the fields. This book comes with a CD-ROM with HTML pages, in the /filters directory, that provide a searchable index of all the fields, and the Appendix has the same tables from some of the more commonly used protocols. The Ethereal program itself, however, provides a user interface which lets you peruse the protocols and fields they contain and construct a display filter.

From the Display Filter window, click the Add Expression button. The Filter Expression window, shown in Figure 5.14, appears.

Click To expand
Figure 5.14: Filter Expression Dialog Box

On the left is a list of all protocols. Each protocol that has fields, which is most of them, can be opened by clicking on the square next to the protocol’s name, thereby presenting a list of the protocol’s fields. When a field name is selected in the list, the relations that apply to that field are shown in the Relation list. The relations are: is present, ==, !=, >, <, >=, <=, and contains. The matches keyword does not appear in this list; this is an oversight that surely will be fixed in a future version of Ethereal. Not all the relations apply to all field types, so only the applicable relations for the selected field are shown.

The default relation is is present, which does not require any other value to compare against. But if you select another relation, one that does require a comparison value, then a Value text entry box appears to the right of the relation list. This is shown in Figure 5.15. If the field can be sliced into ranges, then a Range text entry box appears under the Relation list.

Click To expand
Figure 5.15: Filter Expression Dialog With Operation That Accepts Values

If the selected field has labels that represent its possible values, the list possible values will appear under the Value text entry box. An example is shown in Figure 5.16.

Click To expand
Figure 5.16: Filter Expression With Field That Has Labeled Values

The text you type into the Value and Range text entry boxes are the same that you would type into a normal display filter. If you’re happy with the selections you have made, click the Accept button. Ethereal will put the display filter in the Filter string text entry box of the Display Filter dialog box at the current location of your cursor. In this way, after creating one display filter, you could manually type a logical operator (and or or) into the Filter string text entry box and click Add Expression again. When you accept the second display filter, it is appended to your display filter in the Filter string text entry box, as that’s where your cursor is.

Summary

If you’re trying to pinpoint a network problem, or understand how a particular network operation works, the amount of extraneous traffic on the network can overwhelm you. Filters are the way to manage this huge amount of information. Capture filters allow you to limit the amount of packets that Ethereal receives from the operating system. Display filters allow you to limit the packets that are shown in Ethereal’s main window, giving you the opportunity to concentrate on the problem at hand.

Ethereal’s capture filter syntax is the same as tcpdump’s filter syntax. This is because both Ethereal and tcpdump use a library called libpcap; it is this library that provides the filter engine. The filter engine provided by libpcap, while fast, does not provide many protocol or field names in its language. To find data for fields whose names are not provided in the filter language, the user must extract bytes from the packet by using offsets from the beginning of the protocol fields.

Ethereal’s display filter syntax is unique to Ethereal. It is part of Ethereal’s protocol dissection engine, and provides names for almost all protocols and fields that Ethereal can dissect. Display filters are slower to process packets than capture filters, but the trade-off is ease of use.

You can maintain a collection of capture filters and display filters through Ethereal’s graphical user interface. You can also create display filters through a point-and-click interface. To find the names of all the available fields and protocols in the display filter language, Ethereal provides some information in its GUI and manual pages. Additionally, this book provides that information on the included CD-ROM.

Solutions Fast Track

Writing Capture Filters

  • Capture filters operate quickly and are good for limiting the number of packets captured by Ethereal.

  • The capture filter language has keywords for comparing host names and addresses, hardware addresses, ports, and protocols.

  • Tcpdump can dissect many protocols and fields, but only a handful of those protocols and fields are available in the tcpdump filter (or “capture filter”) language.

  • To test individual fields in a bit-field correctly, you must use the bitwise AND operator: &.

Writing Display Filters

  • Display filters are slower than capture filters, but allow you to test almost any field or protocol that Ethereal knows how to dissect.

  • Display filter fields are typed; each type of field can hold only certain types of values.

  • The contains operator searches for text; the matches operator searches using regular expressions.

  • Take care when testing fields that occur multiple times in a packet; the way you might think to test these fields may be the wrong way.

  • The Capture Filter and Display Filter dialog boxes let you save your filters.

  • The Filter Expression dialog box lets you create display filters by pointing and clicking.

Frequently Asked Questions

The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form. You will also gain access to thousands of other FAQs at ITFAQnet.com.

1. 

My capture filter or display filter that uses multiple ands or ors doesn’t work the way I intended it to work.

The precedence of the operations may not be what you re expecting it to be. This means that the parts of your filter are being run in an order that you didn t expect. Use parentheses to group the parts properly.

2. 

I’m using contains to look for a certain string that I know should be there, but Ethereal can’t find it.

Look closely at the hex-dump when you have the field that you re interested in selected; the encoding of the string may be Unicode or EBCDIC, which won t work with the contains operator. Only ASCII strings are currently compatible with contains .

3. 

I want to find all packets that do not have an IP address of 1.2.3.4. Why does ip.addr != 1.2.3.4 show all packets instead of limiting the packets to what I want?

The ip.addr field occurs more than once in a packet. Your display filter is running correctly; it shows you all packets that have at least one ip.addr that is not equal to 1.2.3.4 . You want not ip.addr == 1.2.3.4 .

4. 

The filters that I enter in the Capture Filter or Display Filter windows aren’t there when I quit Ethereal and start Ethereal again.

Don t forget to click the Save button in those windows. The OK button merely saves the changes to the filters in memory; the Save button saves them to disk.

5. 

My filter can be expressed very easily in both the capture filter and display filter languages. Which should I choose?

If your network has very little traffic on it, then it s easier not to supply a capture filter and use only display filters. But if you have a lot of traffic on the network, especially extraneous traffic, and you re sure that your filter will provide all the packets that you need to look at to solve your problem, then use a capture filter. If you re not sure where to find the clues that will help you solve your problem, capture everything and use a display filter to look for packets that might help you.

6. 

Ethereal comes with a manual for its display filter language. Where’s the manual for the capture filter language?

It s provided by the tcpdump manual page. It s also on-line at www.tcpdump.org/tcpdump_man.html.

Answers

1. 

The precedence of the operations may not be what you’re expecting it to be. This means that the parts of your filter are being run in an order that you didn’t expect. Use parentheses to group the parts properly.

2. 

Look closely at the hex-dump when you have the field that you’re interested in selected; the encoding of the string may be Unicode or EBCDIC, which won’t work with the contains operator. Only ASCII strings are currently compatible with contains.

3. 

The ip.addr field occurs more than once in a packet. Your display filter is running correctly; it shows you all packets that have at least one ip.addr that is not equal to 1.2.3.4. You want not ip.addr == 1.2.3.4.

4. 

Don’t forget to click the Save button in those windows. The OK button merely saves the changes to the filters in memory; the Save button saves them to disk.

5. 

If your network has very little traffic on it, then it’s easier not to supply a capture filter and use only display filters. But if you have a lot of traffic on the network, especially extraneous traffic, and you’re sure that your filter will provide all the packets that you need to look at to solve your problem, then use a capture filter. If you’re not sure where to find the clues that will help you solve your problem, capture everything and use a display filter to look for packets that might help you.

6. 

It’s provided by the tcpdump manual page. It’s also on-line at www.tcpdump.org/tcpdump_man.html.

Часть 6: Другие программы , идущие в пакете с Ethereal

Introduction

Most people who are familiar with Ethereal tend to use the Ethereal Graphical User Interface (GUI). However, when Ethereal is installed it also comes with several other supporting programs: the command line version of Ethereal, called Tethereal, and three other programs to assist you in manipulating capture files; editcap, mergecap, and text2pcap. These supporting programs can be used together to provide very powerful capture file manipulation. For example, files can be captured with Tethereal, edited with editcap, and merged into a single packet capture file with mergecap. They can then be viewed with Tethereal or Ethereal. As you read this chapter you will see the vast capabilities and the granular control these supporting programs give you when manipulating capture files.

Tethereal

Tethereal is the command line version of Ethereal. It can be used to capture, decode, and print to screen live packets from the wire or to read saved capture files. Some of the same features apply to both Tethereal and Ethereal as they use the same capture library, libpcap, and most of the same code. Tethereal can read all of the same packet capture formats as Ethereal, and will automatically determine the type. If Tethereal is compiled with the zlib library, it can automatically uncompress and read files that have been compressed with gzip. The advantage to using Tethereal is that it is highly scriptable.

The following information is the usage output for the Tethereal program, also notice the various types of formats in which Tethereal can save files by using the –F option:

[root@localhost ethereal-0.10.0a]# tethereal -h
 This is GNU tethereal 0.10.0a
 Compiled with GLib 2.2.1, with libpcap 0.7.2, with libz 1.1.4, 
 with libpcre 4.5,with Net-SNMP 5.0.9, with ADNS.
 Running with libpcap (version unknown) on Linux 2.4.20-6
 tethereal [ -vh ] [ -DlLnpqSVx ] [ -a <capture autostop condition> ] ...
         [ -b <number of ring buffer files>[:<duration>] ] [ -c <count> ]
         [ -d <layer_type>==<selector>,<decode_as_protocol> ] ...
 		[ -f <capture filter> ] [ -F <output file type> ] [ -i <interface> ]
         [ -N <resolving> ] [ -o <preference setting> ] ... [ -r <infile> ]
         [ -R <read filter> ] [ -s <snaplen> ] [ -t <time stamp format> ]
         [ -T pdml|ps|text ] [ -w <savefile> ] [ -y <link type> ]
         [ -z <statistics string> ]
 Valid file type arguments to the "-F" flag:
         libpcap - libpcap (tcpdump, Ethereal, etc.)
         rh6_1libpcap - RedHat Linux 6.1 libpcap (tcpdump)
         suse6_3libpcap - SuSE Linux 6.3 libpcap (tcpdump)
         modlibpcap - modified libpcap (tcpdump)
         nokialibpcap - Nokia libpcap (tcpdump)
         lanalyzer - Novell LANalyzer
         ngsniffer - Network Associates Sniffer (DOS-based)
         snoop - Sun snoop
         netmon1 - Microsoft Network Monitor 1.x
         netmon2 - Microsoft Network Monitor 2.x
         ngwsniffer_1_1 - Network Associates Sniffer (Windows-based) 1.1
         ngwsniffer_2_0 - Network Associates Sniffer (Windows-based) 2.00x
         visual - Visual Networks traffic capture
         5views - Accellent 5Views capture
         niobserverv9 - Network Instruments Observer version 9
         default is libpcap

The following command line options are used to control Tethereal’s data capture and output:

  • –a test:value This option is used when capturing to a file. It specifies to Tethereal when to stop writing to the file. The criterion is in the form of test:value, where test is either duration or file size. Duration will stop writing to a file when the specified number of seconds have elapsed, and file size will stop writing to a file after a size of value kilobytes have been reached.

  • –b number of ring buffer files [:duration] This option is used with the –a option, and causes Tethereal to continue capturing data to successive files. This is known as ring buffer mode and it will keep saving files up to the number specified within the option. When the first file reaches the maximum size, as specified with the –a option, Tethereal will begin writing to the next file. When all files are full, it will continue to write new files as it removes the older ones. However, if the number of files is specified as 0, the number of files that Tethereal writes to will be unlimited, and will only be restricted to the size of the partition. An optional duration parameter can also be specified so that Tethereal will switch to the next file when the instructed number of seconds has elapsed. This will happen even if the current file is not yet full. The file names that are created are based on the number of the file and the creation date and time. You can only save files in the libpcap format when this option is used.

  • –c count This option sets the default number of packets to read when capturing data. For example, if you only want to capture 100 packets you would specify –c 100.

  • –d layer type==selector, decode-as protocol This option allows you to specify the way in which traffic is decoded. The parameters denote that if the layer type has a specified value then packets should be decoded as the specified protocol. For example –d tcp.port==8080, http would decode all traffic to and from Transmission Control Protocol (TCP) port 8080 as HyperText Transfer Protocol (HTTP) traffic. This is valuable for applications that allow you to run services on non-standard ports.

  • –D This option instructs Tethereal to print a list of available interfaces on the system. It will print the interface number, name, and description and then return to the command prompt. You can then supply the number or the name to the –i flag to specify an interface on which to capture data. Specifying this option causes Tethereal to actually open and attempt to capture on each interface that it finds. It will only display the interfaces on which this was successful. Also, if you need to be logged in as root to run Tethereal but are not, this option will not display any available interfaces.

  • –f capture filter expression This option allows you to set the filter expression to use when capturing data. For example tethereal -f tcp port 80 will only capture incoming and outgoing HTTP packets.

  • –F type This option is used to set the format of the output of the capture file. For example, if you want to save a file in the Sun snoop format so that snoop can read the capture file, you would use the –F snoop option.

  • –h This option prints the version of Tethereal in use and the help options, then exits.

  • –i interface This option specifies the interface that you want to use to capture data. The –D option can be used to find out the names of your network interfaces. You can use the number or the name as a parameter to the –i option. If you run Tethereal without the –i option it will search the list of interfaces and choose the first non-loopback interface that it finds. If it doesn’t find any non-loopback interfaces, it will use the first loopback interface. If this doesn’t exist ether, Tethereal will exit with an error.

  • l This option flushes the standard output after each packet is printed instead of waiting until it fills up. It is normally used when piping a capture to a script so that the output for each packet is sent as soon as it is read and dissected.

  • L This option lists the data link types that are supported by an interface and then exits. You can specify an interface to use or Tethereal will choose the first one it finds as stated in the –i option information.

  • n This option is used to disable network object name resolution, such as host names and port names.

  • N resolving flags This option is used to enable name resolving for specified address types and port numbers. The m flag enables MAC address resolution, the n flag enables network address resolution, and the t flag enables transport-layer port number resolution. The C flag enables concurrent (asynchronous) Domain Name System (DNS) lookups if Tethereal is compiled with Asynchronous DNS (ADNS). The –N option overrides the –n option.

  • o prefname:value This option allows you to set a preference value that will override any default value or value read from a preference file. The parameter to this option is in the format of prefname:value, where prefname is the name of the preference as it would appear in the preference file and value is the value to which it should be set.

  • p This option tells Tethereal to not put the interface in promiscuous mode. This will cause Tethereal to only read traffic sent to and from the system on which Tethereal is running, broadcast traffic, and multicast traffic.

  • q This option allows you to turn off the packet count when capturing network packets to a file. The count will still be displayed at the end of the capture. On some systems, such as various BSD systems, that support the SIGINFO signal, typing control-T will cause the current count status to be displayed.

  • –r file This option reads and processes a saved capture file.

  • R filter This option causes a read filter to be applied before displaying or writing the packets to a file. Packets that do not match the filter will be discarded.

  • –s snaplen This option allows you to set the default snapshot length to use when capturing data. The parameter snaplen specifies the length, in bytes, of each network packet that will be read or saved to disk.

  • t format This option allows you to set the format of the packet timestamp that is displayed on the summary line. The format parameter will specify the method used to display the data. Relative time is specified by the r parameter and displays the time elapsed between the first packet and the current packet. Absolute time is specified by the a parameter and is the actual time the packet was captured. The absolute date and time is specified by the ad parameter and is the actual time and date the packet was captured. The delta time is specified by the d parameter and displays the time since the previous packet was captured. By default, the time is specified as relative.

  • T pdml|ps|text This option allows you to set the display format to use when viewing packet data. When using the Packet Details Markup Language (PDML) option, the protocol data tree is always displayed.

  • v This option prints the Tethereal version information and then exits.

  • V This option displays the capture in protocol tree form instead of the default summary packet form.

  • –w file This option writes the packets to the file name specified following the option. If the option specified is - then standard output is used.

  • –x This option displays the capture in a hexadecimal and ASCII dump format along with the summary or protocol tree view.

  • –y type This option allows you to set the data link type to use while capturing packets. You can use the –L option to lists the data link types that are supported by an interface.

  • –z statistics This option will enable Tethereal to collect various types of statistics about the data that is being captured. The results will be displayed after reading the capture file.

By default, Tethereal will display packets to the screen in summary line form. These are the same lines that are displayed in the Ethereal summary pane. However, it does not print the frame number field when capturing and displaying real time. The –V option can be used to print detailed information about the packets instead of just a summary. Tethereal can also read saved data capture files, and print the information in either summary (default) or detailed form (–V). This method will display the frame numbers with the saved packets. Finally, the –x command will cause Tethereal to print a hexadecimal and ASCII dump of the packet data with either the summary line or detailed protocol tree. Tethereal has a very strong display filter language and can also use the TCPDump filter syntax as well. These can be used to narrow down the type of traffic that you want to capture.

When using Tethereal to write a capture to a file, the file will be written in libpcap format by default. It will write all of the packets and all of the detail about the packets to the output file, thus the –V and the –x options aren’t necessary. Since Tethereal and Ethereal are compatible with many other sniffers, you can also write the output in several different formats. The –F option can be used to specify a format in which to write the file.

The following is a basic example of using Tethereal to perform a capture and display the output in a protocol tree view along with the associated hexadecimal and ASCII output:

C:\Program Files\Ethereal>tethereal -V -x
 Capturing on \Device\NPF_{A302C81E-256D-4C92-8A72-866F2E1ED55F}
 Frame 1 (114 bytes on wire, 114 bytes captured)
     Arrival Time: Nov 28, 2003 22:14:16.221349000
     Time delta from previous packet: 0.000000000 seconds
     Time since reference or first frame: 0.000000000 seconds
     Frame Number: 1
     Packet Length: 114 bytes
     Capture Length: 114 bytes
 IEEE 802.3 Ethernet
     Destination: ff:ff:ff:ff:ff:ff (Broadcast)
     Source: 00:05:5d:ee:7e:53 (D-Link_ee:7e:53)
     Length: 100
 Logical-Link Control
     DSAP: NetWare (0xe0)
     IG Bit: Individual
     SSAP: NetWare (0xe0)
     CR Bit: Command
     Control field: U, func = UI (0x03)
         000. 00.. = Unnumbered Information
         .... ..11 = Unnumbered frame
 Internetwork Packet eXchange
     Checksum: 0xffff
     Length: 96 bytes
     Transport Control: 0 hops
     Packet Type: PEP (0x04)
     Destination Network: 0x00000000 (00000000)
     Destination Node: ff:ff:ff:ff:ff:ff (Broadcast)
     Destination Socket: SAP (0x0452)
     Source Network: 0x00000000 (00000000)
     Source Node: 00:05:5d:ee:7e:53 (D-Link_ee:7e:53)
     Source Socket: Unknown (0x4008)
 Service Advertisement Protocol
     General Response
     Server Name: TARGET1!!!!!!!!A5569B20ABE511CE9CA400004C762832
         Server Type: Microsoft Internet Information Server (0x064E)
         Network: 00 00 00 00
         Node: 00:05:5d:ee:7e:53
         Socket: Unknown (0x4000)
         Intermediate Networks: 1
 0000  ff ff ff ff ff ff 00 05 5d ee 7e 53 00 64 e0 e0   ........].~S.d..
 0010  03 ff ff 00 60 00 04 00 00 00 00 ff ff ff ff ff   ....`...........
 0020  ff 04 52 00 00 00 00 00 05 5d ee 7e 53 40 08 00   ..R......].~S@..
 0030  02 06 4e 54 41 52 47 45 54 31 21 21 21 21 21 21   ..NTARGET1!!!!!!
 0040  21 21 41 35 35 36 39 42 32 30 41 42 45 35 31 31   !!A5569B20ABE511
 0050  43 45 39 43 41 34 30 30 30 30 34 43 37 36 32 38   CE9CA400004C7628
 0060  33 32 00 00 00 00 00 00 05 5d ee 7e 53 40 00 00   32.......].~S@..
 0070  01 01                                             

The following is an example of using Tethereal to capture traffic on interface 4 and output the data to a file called output. The output files will have a maximum file size of 5 kilobytes each and when they are full a new output file will be created. This will continue up to a maximum of 10 output files. The following example is the command used to perform this capture:

C:\Program Files\Ethereal>
 tethereal -i4 -a filesize:5 -b 10 -w output

The output files generated are appended with the file number, date, and timestamp. You will see the following 10 output files start at number 43 because they have begun to drop the oldest file as they create new files, so that a maximum of 10 files exist at all times:

output_00043_20031128212900
 output_00044_20031128212900
 output_00045_20031128212900
 output_00046_20031128212900
 output_00047_20031128212901
 output_00048_20031128212903
 output_00049_20031128212958
 output_00050_20031128213045
 output_00051_20031128213211
 output_00052_20031128213316

The following is an example of using a Tethereal capture filter to capture all traffic except packets to and from HTTP port 80:

C:\Program Files\Ethereal>tethereal -f "tcp port !80"
 Capturing on \Device\NPF_{A302C81E-256D-4C92-8A72-866F2E1ED55F}
   0.000000 D-Link_ed:3b:c6 -> Broadcast    ARP Who has 192.168.100.40?  Tell 192.168.100.5
   0.000026 D-Link_ee:7e:53 -> D-Link_ed:3b:c6 ARP 192.168.100.40 is at 00:05:5d:ee:7e:53
   0.000066 D-Link_ee:7e:53 -> D-Link_ed:3b:c6 ARP 192.168.100.40 is at 00:05:5d:ee:7e:53
  10.089720 00000000.00055dee7e53 -> 00000000.ffffffffffff IPX SAP General Response
 10.089763 00000000.00055dee7e53 -> 00000000.ffffffffffff IPX SAP General Response

The following is an example of using a Tethereal read filter to output the Telnet data packets from a file called capture:

C:\Program Files\Ethereal>tethereal -r capture -R "telnet"
   7  10.071157 192.168.100.122 -> 192.168.100.132 TELNET Telnet Data ...
   8  10.071464 192.168.100.132 -> 192.168.100.122 TELNET Telnet Data ...
   9  10.071515 192.168.100.132 -> 192.168.100.122 TELNET Telnet Data ...
  11  10.076114 192.168.100.132 -> 192.168.100.122 TELNET Telnet Data ...
  12  10.076155 192.168.100.132 -> 192.168.100.122 TELNET Telnet Data ...
  14  10.089546 192.168.100.122 -> 192.168.100.132 TELNET Telnet Data ...
  15  10.089672 192.168.100.132 -> 192.168.100.122 TELNET Telnet Data ...

The following is an example of using Tethereal to read a libpcap capture file called capture2 and output it to a file called netmon_output in the Microsoft Network Monitor 2.x format; editcap can also be used to perform this function:

C:\Program Files\Ethereal>tethereal -r capture2 -w netmon_output -F netmon2

The following is an example of using the Tethereal statistics function to display a report of all bytes and frames for each protocol detected during the capture, the statistics will display after you end the capture by typing Ctrl + C:

C:\Program Files\Ethereal>tethereal –z io,phs
 <cntrl-c>
 ===================================================================
 Protocol Hierarchy Statistics
 Filter: frame
 frame                                    frames:560 bytes:115233
   eth                                    frames:560 bytes:115233
     ip                                   frames:558 bytes:115005
       udp                                frames:53 bytes:10383
         dns                              frames:21 bytes:3215
         data                             frames:8 bytes:496
         isakmp                           frames:24 bytes:6672
       tcp                                frames:505 bytes:104622
         http                             frames:107 bytes:81798
     llc                                  frames:2 bytes:228
       ipx                                frames:2 bytes:228
         ipxsap                           frames:2 bytes:228
 ===================================================================

The following is an example of using the Tethereal statistics function to display a report of all TCP conversations that take place during the capture, the statistics will display after you end the capture by typing Ctrl + C:

C:\Program Files\Ethereal>tethereal –z conv,tcp
 <cntrl-c>
 ============================================================================
 TCP Conversations
 Filter:<No Filter>
                                                |       <-      | |       ->
  | |     Total     |
                                            | Frames  Bytes | | Frames  Bytes
  | | Frames  Bytes |
 192.168.100.40:2077  <-> 64.12.26.97:http      18      1934      36      368
 4      54      5618
 192.168.100.40:2078  <-> 205.188.1.95:http      4       216       8       48
 0      12       696
 ============================================================================

Tethereal Statistics

Included are some additional examples and supplementary information to the following Tethereal man (short for manual) page statistics information:

COMMAND -z dcerpc,rtt,uuid,major.minor[filter]

DESCRIPTION Collect call and reply Response Time Test (RTT) data for Distributed Computing Environment Remote Procedure Call (DCE RPC) interface uuid, version major.minor. Data collected is the number of calls for each procedure, MinRTT, MaxRTT and AvgRTT. If the optional filterstring is provided, the statistics will only be calculated on those calls

that match that filter. Current supported DCE RPC programs are: ATSVC, BOSSVR, BUTC, CDS_CLERK, CONV, DEC_DFS, DFS, DNSSERVER, DRSUAPI, DTSPROVIDER, DTSSTIME_REQ, EPM, FLDB, FTSERVER, INITSHUTDOWN, KRB5RPC, LSA, LSA_DS, MAPI, MGMT, Messenger, NSPI, OXID, REMACT, REP_PROC, RPC_Browser, RPC_NETLOGON, RS_ACCT, RS_ATTR_RS_BIND, RS_PGO, RS_REPADM, RS_REPLIST, RS_UNIX, SAMR, SECIDMAP, SPOOLSS, SRVSVC, SVCCTL, TAPI, TKN4lnt, UBIKDISK, UBIKVOTE, WINREG, WKSSVC, cds_solicit, cprpc_server, dce_update, roverride, rpriv, re_misc, rsec_login.

EXAMPLE 1 -z dcerpc,rtt,12345778-1234-abcd-ef00-0123456789ac,1.0 will collect data for the Microsoft Security Account Manager (SAMR) interface.

EXAMPLE 2 _-z dcerpc,rtt,12345778-1234-abcd-ef00-0123456789ac,_1.0ip.addr==192.168.100.40 will collect SAMR RTT statistics for the host 192.168.100.40. Notice that there is no comma between the major.minor and filter. The Tethereal man page example shows that a comma is placed between these parameters, however this will cause Tethereal to report an error and exit.

NOTES This option can be used multiple times on the command line.

COMMAND -z io,phs[,filter]

DESCRIPTION Creates protocol hierarchy statistics listing both number of frames and bytes. If no filter is specified the statistics will be calculated for all frames. If a filter is specified, statistics will be only calculated for those packets that match the filter.

EXAMPLE 1 -z io,phs will generate statistics for all traffic.

EXAMPLE 2 -z io,phs,ip.addr==192.168.100.40 will generate statistics for all traffic to and from the host 192.168.100.40.

NOTES This option can be used multiple times on the command line.

COMMAND -z io,stat,interval[,filter][,filter][,filter]...

DESCRIPTION Collects frame and bytes statistics for the capture in intervals of interval seconds. Intervals can be specified either as whole or fractional seconds. Interval can be specified in microsecond (ms) resolution. If no filter is specified the statistics will be calculated for all frames. If one or more filters are specified, statistics will be calculated for all filters and presented with one column of statistics for each filter. io,stat can also calculate COUNT() SUM() MIN() MAX() and AVG() using a slightly different filter syntax: [COUNT|SUM|MIN|MAX|AVG](<field>)<filter>. One important thing to note here is that the field that the calculation is based on must also be part of the filter string or else the calculation will fail. Also, be aware that a field can exist multiple times inside the same packet and will then be counted multiple times in those packets. COUNT(<field>) can be used on any type which has a display filter name. It will count how many times this particular field is encountered in the filtered packet list. SUM(<field>) can only be used on named fields of integer type. This will sum together every occurrence of this field’s value for each interval. MIN/MAX/AVG(<field>) can only be used on named fields that are either integers or relative time fields. This will calculate the maximum, minimum or average that is seen in each interval. If the field is a relative time field the output will be presented in seconds and three digits after the decimal point. The resolution for time calculations is 1ms; anything smaller will be truncated.

EXAMPLE 1 -z io,stat,1,ip.addr==192.168.100.40 will generate 1 second statistics for all traffic to and from host 192.168.100.40.

EXAMPLE 2 -z io,stat,0.001,“http&&ip.addr==192.168.100.40” will generate 1ms statistics for all HTTP frames to and from host 192.168.100.40.

EXAMPLE 3 -z io,stat,0.010,AVG(smb.time)smb.time will calculate the average time for Server Message Block (SMB) frames during each 10ms interval.

EXAMPLE 4 -z io,stat,0.010,COUNT(http.request)http.request will count the total number of HTTP requests seen in each 10ms interval.

EXAMPLE 5 -z io,stat,0.010,SUM(frame.pkt_len)frame.pkt_len will report the total number of bytes seen in all the frames within a 10ms interval.

EXAMPLE 6 -z io,stat,0.010,“smb.time&&ip.addr_==192.168.100.40”,MIN(smb.time) “smb.time&&ip.addr==_192.168.100.40”,MAX(smb.time)“smb.time&&ip.addr==192.168.100.40”,AVG(smb.time)“smb.time&&ip.addr==192.168.100.40” will calculate statistics for all SMB response times we see to and from host 192.168.100.40 in 10ms intervals. The output will be displayed in 4 columns; number of frames/bytes, minimum response time, maximum response time, and average response time.

NOTES This option can be used multiple times on the command line.

COMMAND -z conv,type[,filter]

DESCRIPTION Creates a table that lists all conversations that could be seen in the capture. type specifies which type of conversation we want to generate the statistics for, currently the supported ones are “eth” Ethernet, “fc” Fibre Channel, “fddi” FDDI, “ip” IP addresses, “ipx” IPX addresses, “tcp” TCP/IP socketpairs, “tr” TokenRing, and “udp” UDP/IP socketpairs. Both IPv4 and IPv6 are supported. If the optional filter string is specified, only those packets that match the filter will be used in the calculations. The table is presented with one line for each conversation and displays number of frames/bytes in each direction as well as total number of frames/bytes. The table is sorted according to total number of bytes.

EXAMPLE -z conv,ip,ip.addr==192.168.100.40 will list IP conversations for host 192.168.100.40.

NOTES None.

COMMAND -z proto,colinfo,filter,field

DESCRIPTION Appends all field values for the packet to the COL_INFO information line. This feature can be used to append arbitrary fields to the COL_INFO line in addition to the normal content of the COL_INFO line. field is the display filter name of a field which

value should be placed on the COL_INFO line. filter is a filter string that controls for which packets the field value will be presented on COL_INFO line. field will only be presented on the COL_INFO line for the packets which match filter. In order for Tethereal to be able to extract the field value from the packet, field MUST be part of the filter string. If not, Tethereal will be unable to extract its value.

EXAMPLE 1 -z proto,colinfo,tcp.len,tcp.len will add the TCP segment length, “tcp.len”, field to COL_INFO for all packets containing the “tcp.len” field.

EXAMPLE 2 _-z proto,colinfo,“tcp.len&&ip.src==192.168.100.40”,tcp.len will put “tcp.len” on COL_INFO but only for packets coming from host 192.168.100.40.

NOTES This option can be used multiple times on the command line.

COMMAND -z rpc,rtt,program,version[,filter]

DESCRIPTION Collects call and reply RTT data for program/version. The data collected is the number of calls for each procedure, MinRTT, MaxRTT and AvgRTT. If the optional filter string is provided, the statistics will only be calculated on those calls that match that filter.

EXAMPLE 1 -z rpc,rtt,100003,3 will collect data for Network File System (NFS) v3.

EXAMPLE 2 -z rpc,rtt,100003,3,nfs.fh.hash==0x12345678 will collect NFS v3 RTT statistics for a specific file.

NOTES This option can be used multiple times on the command line.

COMMAND -z rpc,programs

DESCRIPTION Collects call and reply RTT data for all known ONC-RPC programs/versions. Data collected is the number of calls for each protocol/version, MinRTT, MaxRTT and AvgRTT.

EXAMPLE -z rpc,programs will collect data for all known ONC-RPC programs/versions.

NOTES This option can only be used once on the command line.

COMMAND -z smb,rtt[,filter]

DESCRIPTION Collects call and reply RTT data for SMB. The data collected is the number of calls for each SMB command, MinRTT, MaxRTT and AvgRTT. The data will be presented as separate tables for all normal SMB commands, all Transaction2 commands and all NT Transaction commands. Only those commands that are seen in the capture will have its statistics displayed. Only the first command in a “xAndX” command chain will be used in the calculation. So for common “SessionSetupAndX + TreeConnectAndX” chains, only the “SessionSetupAndX” call will be used in the statistics. This is a flaw that might be fixed in the future. If the optional filter string is provided, the stats will only be calculated on those calls that match that filter.

EXAMPLE 1 -z smb,rtt will collect all SMB statistics.

EXAMPLE 2 -z smb,rtt,ip.addr==192.168.100.40 will only collect statistics for SMB packets exchanged by the host at IP address 192.168.100.40.

NOTES This option can be used multiple times on the command line.

COMMAND -z smb,sids

DESCRIPTION When this feature is used Tethereal will print a report with all the discovered Security Identifiers (SIDs) and account name mappings. Only those SIDs where the account name is known will be presented in the table. For this feature to work you will need to either to enable “Edit|Preferences|Protocols|SMB|Snoop SID to name mappings” in the preferences or you can override the preferences by specifying –o smb.sid_name_snooping:TRUE on the Tethereal command line.

EXAMPLE -o smb.sid_name_snooping:TRUE -z smb,sids will enable the mapping preference and report all discovered SMB SIDs.

NOTES The current methods used by Tethereal to find the SID. Name mapping is relatively restricted but is hoped to be expanded in the future.

COMMAND -z mgcp,rtd[,filter]

DESCRIPTION Collects requests and response Response Time Delay (RTD) data for Media Gateway Control Protocol (MGCP). This is similar to -z smb,rtt. The data collected is the number of calls for each known MGCP Type, MinRTD, MaxRTD and AvgRTD. Additionally you get the number of duplicate requests/responses, unresponded requests, responses that don’t match with any request. If the optional filter string is provided, the stats will only be calculated on those calls that match that filter.

EXAMPLE 1 -z mgcp,rtd will collect all statistics for all MGCP traffic.

EXAMPLE 2 -z mgcp,rtd,ip.addr==192.168.100.40 will collect statistics for MGCP packets exchanged by the host at IP address 192.168.100.40.

NOTES This option can be used multiple times on the command line.

COMMAND -z h225,counter[,filter]

DESCRIPTION Count ITU-T H.225 messages and their reasons. The first column provides a list of H.225 messages and H.225 message reasons, which occur in the current capture file. The second column displays the number of occurrences of each message or reason.

EXAMPLE 1 -z h225,counter will collect all H.225 messages and their reasons.

EXAMPLE 2 -z h225,counter,ip.addr==192.168.100.40 will collect statistics for H.225 packets exchanged by the host at IP address 192.168.100.40.

NOTES This option can be used multiple times on the command line.

COMMAND -z h225,srt[,filter]

DESCRIPTION Collect request and response SRT (Service Response Time) data for ITU-T H.225 RAS. The data collected is number of calls of each ITU-T H.225 RAS Message Type, Minimum SRT, Maximum SRT, Average SRT, Minimum in Frame, and Maximum in Frame. Additionally it displays the number of Open Requests (Unresponded Requests), Discarded Responses (responses without matching requests), and Duplicate Messages.

EXAMPLE 1 -z h225,srt will collect all SRT data for all ITU-T H.225 RAS traffic.

EXAMPLE 2 -z h225,srt,ip.addr==192.168.100.40 will collect SRT statistics for ITU-T H.225 RAS packets exchanged by the host at IP address 192.168.100.40.

NOTES This option can be used multiple times on the command line.

 [root@localhost tools]# ./msnchat -h
 msnchat [OPTIONS] CAPTURE_FILE [...]
   -o FILE       name of output file
   -t TETHEREAL  location of tethereal binary
   -u USER       name for unknown user

The following command can be used to read and parse a saved capture file called msn_test1:

[root@localhost tools]# ./msnchat -o outfile msn_test1

When viewed with a web browser, the HTML outfile looks like the following:

---- New Conversation @ Dec 30, 2003 14:21:08 ----
 (14:21:08) Luke: hello
 (14:21:22) Unknown: how are you?
 (14:21:53) Luke: are we meeting at noon?
 (14:22:03) Unknown: yes, at the secret location.
 (14:22:11) Luke: great, see you then
 (14:22:17) Unknown: ok
 (14:22:18) Unknown: bye

You can add a name for the Unknown user by typing the following command:

[root@localhost tools]# ./msnchat -o outfile -u Leia msn_test1

The HTML output would then look like the following:

 ---- New Conversation @ Dec 30, 2003 14:21:08 ----
 (14:21:08) Luke: hello
 (14:21:22) Leia: how are you?
 (14:21:53) Luke: are we meeting at noon?
 (14:22:03) Leia: yes, at the secret location.
 (14:22:11) Luke: great, see you then
 (14:22:17) Leia: ok
 (14:22:18) Leia: bye

The msnchat code will give you a good idea of how to write your own scripts to parse capture files, manipulate the PDML data, and print the output in HTML format.

Editcap

Editcap is a program used to remove or select packets from a file and to translate the format of captured files. It doesn’t capture live traffic; it only reads data from a saved capture file and then saves some or all of the packets to a new capture file. Editcap can read all of the same types of files that Ethereal can, and by default writes to libpcap format. Editcap can also write captures to standard and modified versions of libpcap, Sun snoop, Novell LANalyzer, Networks Associate’s Sniffer, Microsoft Network Monitor, Visual Network traffic capture, Accellent 5Views capture, and Network Instruments Observer version 9 captures. Editcap can determine the file type that it is reading, and is also capable of reading files that are compressed with gzip.

By default editcap writes all of the packets in the capture file to the output file. If you specify a list of packet numbers on the command line, those packets will not be written to the output capture file. If the –r option is specified, it will reverse the default configuration and write only the specified packets to the output capture file. You can also specify a range of packets to include or exclude in the output capture file.

The following information is the usage output for the editcap program:

C:\Program Files\Ethereal>editcap -h
 Usage: editcap [-r] [-h] [-v] [-T <encap type>] [-F <capture type>]
                [-s <snaplen>] [-t <time adjustment
                <infile> <outfile> [ <record#>[-<record#>] ... ]
   where -r specifies that the records specified should be kept, not deleted,
                            default is to delete
         -v specifies verbose operation, default is silent
         -h produces this help listing.
         -T <encap type> specifies the encapsulation type to use:
             ether - Ethernet
             tr - Token Ring
             slip - SLIP
             ppp - PPP
             fddi - FDDI
             fddi-swapped - FDDI with bit-swapped MAC addresses
             rawip - Raw IP
             arcnet - ARCNET
             arcnet_linux - Linux ARCNET
             atm-rfc1483 - RFC 1483 ATM
             linux-atm-clip - Linux ATM CLIP
             lapb - LAPB
             atm-pdus - ATM PDUs
             atm-pdus-untruncated - ATM PDUs - untruncated
             null - NULL
             ascend - Lucent/Ascend access equipment
             isdn - ISDN
             ip-over-fc - RFC 2625 IP-over-Fibre Channel
             ppp-with-direction - PPP with Directional Info
             ieee-802-11 - IEEE 802.11 Wireless LAN
             ieee-802-11-radio - IEEE 802.11 Wireless LAN with radio information
             linux-sll - Linux cooked-mode capture
             frelay - Frame Relay
             frelay-with-direction - Frame Relay with Directional Info
             chdlc - Cisco HDLC
             ios - Cisco IOS internal
             ltalk - Localtalk
             prism - IEEE 802.11 plus Prism II monitor mode header
             pflog-old - OpenBSD PF Firewall logs, pre-3.4
             hhdlc - HiPath HDLC
             docsis - Data Over Cable Service Interface Specification
             cosine - CoSine L2 debug log
             wlan - IEEE 802.11 plus AVS WLAN monitor header
             whdlc - Wellfleet HDLC
             sdlc - SDLC
             tzsp - Tazmen sniffer protocol
             enc - OpenBSD enc(4) encapsulating interface
             pflog - OpenBSD PF Firewall logs
             chdlc-with-direction - Cisco HDLC with Directional Info
             bluetooth-h4 - Bluetooth H4
             mtp2 - SS7 MTP2
             mtp3 - SS7 MTP3
             default is the same as the input file
         -F <capture type> specifies the capture file type to write:
             libpcap - libpcap (tcpdump, Ethereal, etc.)
             rh6_1libpcap - RedHat Linux 6.1 libpcap (tcpdump)
             suse6_3libpcap - SuSE Linux 6.3 libpcap (tcpdump)
             modlibpcap - modified libpcap (tcpdump)
             nokialibpcap - Nokia libpcap (tcpdump)
             lanalyzer - Novell LANalyzer
             ngsniffer - Network Associates Sniffer (DOS-based)
             snoop - Sun snoop
             netmon1 - Microsoft Network Monitor 1.x
             netmon2 - Microsoft Network Monitor 2.x
             ngwsniffer_1_1 - Network Associates Sniffer (Windows-based) 1.1
             ngwsniffer_2_0 - Network Associates Sniffer (Windows-based) 2.00x
             visual - Visual Networks traffic capture
             5views - Accellent 5Views capture
             niobserverv9 - Network Instruments Observer version 9
             default is libpcap
         -s <snaplen> specifies that packets should be truncated to
            <snaplen> bytes of data
         -t <time adjustment> specifies the time adjustment
            to be applied to selected packets
             A range of records can be specified as well

The following command line options are used to control Editcap’s data translation and output:

  • –F type This option is used to set the format of the output capture file. For example, if you want to save a file in the Sun snoop format so that snoop can read the capture file, you would use the –F snoop option.

  • –h This option prints the help options of editcap, then exits.

  • –r This option will cause the packets whose numbers are specified on the command line to be written to the output capture file. This is opposite of the default action, which is to remove the packets that are specified on the command line. Packets can only be specified as a consecutive range in the start-end format, or individually; they cannot be comma delimited.

  • –s snaplen This option will set the snapshot length to use when writing the data to the output capture file. Packets that are larger than the snaplen will be truncated. This option is helpful if you only want to save the packet headers, or if the program you will be importing the capture file into can only read packets of a certain size.

  • –t [-]seconds[.fractional seconds] This option will allow you to specify a time adjustment to apply to selected frames in the output capture file. The time adjustment is specified in seconds and fractions of seconds. An option of –t 3600 will advance the timestamp on the selected frames by one hour, while the option of –t –3600 will reduce the timestamp on the selected frames by one hour. This option is useful when you need to synchronize packet traces with other logs from different devices.

  • –T type This option sets the packet encapsulation type of the output capture file. The default type is the same encapsulation type as the input file. This option forces the encapsulation type of the output capture file to be a specified type, however the packet headers will remain the same encapsulation type as the input capture file. This is because the encapsulation type is stored as meta-data, outside of the packet data. The encapsulation type is a single variable that is changed, thus allowing the packet data and headers of the original packet to remain unchanged.

  • –v This option will cause editcap to print various messages to the screen while it is processing files.

The following is an example of using editcap to translate the first five packets, plus packets 10, 15, and 17 from a tethereal libpcap capture file called capture to a Sun snoop output file called capture_snoop:

C:\Program Files\Ethereal>editcap -r -v -F snoop capture capture_snoop 1-5 10 15 17
 File capture is a libpcap (tcpdump, Ethereal, etc.) capture file.
 Add_Selected: 1-5
 Inclusive ... 1, 5
 Add_Selected: 10
 Not inclusive ... 10
 Add_Selected: 15
 Not inclusive ... 15
 Add_Selected: 17
 Not inclusive ... 17
 Record: 1
 Record: 2
 Record: 3
 Record: 4
 Record: 5
 Record: 10
 Record: 15
 Record: 17

The next example uses editcap to translate all packets, except packets 5 through 120, from a libpcap capture file called capture to a libpcap output file called capture_out:

C:\Program Files\Ethereal>editcap -v capture capture_out 5-120
 File capture is a libpcap (tcpdump, Ethereal, etc.) capture file.
 Add_Selected: 5-120
 Inclusive ... 5, 120
 Record: 1
 Record: 2
 Record: 3
 Record: 4
 Record: 121
 Record: 122

The next example uses editcap to adjust the timestamp forward by five and a half seconds on all packets. It uses an NAI Sniffer Pro capture file called capture.dump as input and saves the output to a Novell LANalyzer file called capture_out:

C:\Program Files\Ethereal>editcap -v -F lanalyzer -t 5.5 capture.dump capture_out
 File capture is a libpcap (tcpdump, Ethereal, etc.) capture file.
 Record: 1
 Record: 2
 Record: 3
 Record: 4
 Record: 5
 Record: 6
 Record: 7
 Record: 8
 Record: 9
 Record: 10 
 output removed
 

The next example uses editcap to save the first 35 bytes of the input capture file called capture to the output capture file called capture_out. This will include the full Ethernet and IP headers in the output file:

C:\Program Files\Ethereal>editcap -v -s 35 capture capture_out
 File capture is a libpcap (tcpdump, Ethereal, etc.) capture file.
 Record: 1
 Record: 2
 Record: 3
 Record: 4
 Record: 5
 Record: 6
 Record: 7
 Record: 8
 Record: 9
 Record: 10
 output removed
 

The next example uses editcap to translate input capture file called capture to the output capture file called capture_out with an encapsulation type of IEEE 802.11 Wireless LAN:

C:\Program Files\Ethereal>editcap -v -T ieee-802-11 capture capture_out
 File capture is a libpcap (tcpdump, Ethereal, etc.) capture file.
 Record: 1
 Record: 2
 Record: 3
 Record: 4
 Record: 5
 Record: 6
 Record: 7
 Record: 8
 Record: 9
 Record: 10
 output removed
 

Mergecap

Mergecap is used to combine multiple saved capture files into a single output file. Mergecap can read all of the same types of files that Ethereal can, and by default writes to libpcap format. Mergecap can also write the output capture file to standard and modified versions of libpcap, Sun snoop, Novel LANalyzer, NAI Sniffer, Microsoft Network Monitor, Visual Network traffic capture, Accellent 5Views capture, and Network Instruments Observer version 9 captures. Mergecap can determine the file type that it is reading, and is also capable of reading files that are compressed with gzip. By default, the packets from the input files are merged in chronological order based on each packet’s timestamp. If the –a option is specified, packets will be copied directly from each input file to the output file regardless of timestamp.

The following information is the usage output for the mergecap program:

C:\Program Files\Ethereal>mergecap -h
 mergecap version 0.10.0
 Usage: mergecap [-hva] [-s <snaplen>] [-T <encap type>]
           [-F <capture type>] -w <outfile> <infile> [...]
   where -h produces this help listing.
         -v verbose operation, default is silent
         -a files should be concatenated, not merged
              Default merges based on frame timestamps
         -s <snaplen>: truncate packets to <snaplen> bytes of data
         -w <outfile>: sets output filename to <outfile>
         -T <encap type> encapsulation type to use:
              ether - Ethernet
              tr - Token Ring
              slip - SLIP
              ppp - PPP
              fddi - FDDI
              fddi-swapped - FDDI with bit-swapped MAC addresses
              rawip - Raw IP
              arcnet - ARCNET
              arcnet_linux - Linux ARCNET
              atm-rfc1483 - RFC 1483 ATM
              linux-atm-clip - Linux ATM CLIP
              lapb - LAPB
              atm-pdus - ATM PDUs
              atm-pdus-untruncated - ATM PDUs - untruncated
              null - NULL
              ascend - Lucent/Ascend access equipment
              isdn - ISDN
              ip-over-fc - RFC 2625 IP-over-Fibre Channel
              ppp-with-direction - PPP with Directional Info
              ieee-802-11 - IEEE 802.11 Wireless LAN
              ieee-802-11-radio - IEEE 802.11 Wireless LAN with radio _          information
              linux-sll - Linux cooked-mode capture
              frelay - Frame Relay
              frelay-with-direction - Frame Relay with Directional Info
              chdlc - Cisco HDLC
              ios - Cisco IOS internal
              ltalk - Localtalk
              prism - IEEE 802.11 plus Prism II monitor mode header
              pflog-old - OpenBSD PF Firewall logs, pre-3.4
              hhdlc - HiPath HDLC
              docsis - Data Over Cable Service Interface Specification
              cosine - CoSine L2 debug log
              wlan - IEEE 802.11 plus AVS WLAN monitor header
              whdlc - Wellfleet HDLC
              sdlc - SDLC
              tzsp - Tazmen sniffer protocol
              enc - OpenBSD enc(4) encapsulating interface
              pflog - OpenBSD PF Firewall logs
              chdlc-with-direction - Cisco HDLC with Directional Info
              bluetooth-h4 - Bluetooth H4
              mtp2 - SS7 MTP2
              mtp3 - SS7 MTP3
              default is the same as the first input file
         -F <capture type> capture file type to write:
              libpcap - libpcap (tcpdump, Ethereal, etc.)
              rh6_1libpcap - RedHat Linux 6.1 libpcap (tcpdump)
              suse6_3libpcap - SuSE Linux 6.3 libpcap (tcpdump)
              modlibpcap - modified libpcap (tcpdump)
              nokialibpcap - Nokia libpcap (tcpdump)
              lanalyzer - Novell LANalyzer
              ngsniffer - Network Associates Sniffer (DOS-based)
              snoop - Sun snoop
              netmon1 - Microsoft Network Monitor 1.x
              netmon2 - Microsoft Network Monitor 2.x
              ngwsniffer_1_1 - Network Associates Sniffer (Windows-based)   1.1
              ngwsniffer_2_0 - Network Associates Sniffer (Windows-based)   2.00x
              visual - Visual Networks traffic capture
              5views - Accellent 5Views capture
              niobserverv9 - Network Instruments Observer version 9
              default is libpcap

The following command line options are used to control Editcap’s data translation and output:

  • –a This option will ignore the timestamps in the input capture files and merge the capture files one after the other. When this option is omitted the packets in the input files are merged in chronological order based on the packet timestamps.

  • –F type This option is used to set the format of the output capture file. For example, if you want to merge capture files and save them in the Sun snoop format so that snoop can read the output file, you would use the –F snoop option.

  • –h This option prints the help options of mergecap, then exits.

  • –s snaplen This option will set the snapshot length to use when writing the data to the output capture file. Packets that are larger than the snaplen will be truncated. This option is helpful if you only want to save the packet headers, or if the program you will be importing the capture file into can only read packets of a certain size.

  • –T type This option sets the packet encapsulation type of the output capture file. The default type is the same encapsulation type as the input files, if they are all the same. If the input files do not all have the same encapsulation type, the encapsulation type of the output file will be set to WTAP_ENCAP_PER_PACKET. However, libpcap and other capture formats do not support this type of encapsulation. The –T option forces the encapsulation type of the output capture file to be a specified type, however the packet headers will remain the same encapsulation type as the input capture file.

  • –v This option will cause mergecap to print various messages to the screen while it is processing files.

  • –w file This option writes the packets to the file name specified following the option. This option is required for mergecap to merge files.

The following is an example of using mergecap to merge the first 35 bytes of each of the four capture files (capture1, capture2, capture3, and capture4) into a single Sun snoop output file called merge_snoop in chronological order by packet timestamp, it will keep reading packets until the end of the last file is reached:

C:\Program Files\Ethereal>mergecap -s 35 -v -F snoop -w merge_snoop capture1 capture2 capture3 capture4
 mergecap: capture1 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture2 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture3 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture4 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: opened 4 of 4 input files
 mergecap: selected frame_type Ethernet (ether)
 Record: 1
 Record: 2
 Record: 3
 Record: 4
 Record: 5
 Record: 6
 Record: 7
 Record: 8
 Record: 9
 Record: 10
 output removed
 

The following is an example of using mergecap to merge four capture files (capture1, capture2, capture3, and capture4) into a single output file called merge_file regardless of packet timestamp, it will write all of the packets of capture1, followed by capture 2, and so on:

C:\Program Files\Ethereal>mergecap -v -a -w merge_file capture1 capture2 capture3 capture4
 mergecap: capture1 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture2 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture3 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture4 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: opened 4 of 4 input files
 mergecap: selected frame_type Ethernet (ether)
 Record: 1
 Record: 2
 Record: 3
 Record: 4
 Record: 5
 Record: 6
 Record: 7
 Record: 8
 Record: 9
 Record: 10
 output removed
 

The following is an example of an attempt to use mergecap to merge three capture files with different encapsulation types (capture1, capture2, and capture3) into a single output file called merge_encap The merge will attempt to set the default encapsulation type and then report an error because libpcap does not understand that type of encapsulation:

C:\Program Files\Ethereal>mergecap -v -w merge_encap capture1 capture2 capture3
 mergecap: capture1 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture2 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture3 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: opened 3 of 3 input files
 mergecap: multiple frame encapsulation types detected
           defaulting to WTAP_ENCAP_PER_PACKET
           capture1 had type (null) ((null))
           capture2 had type Ethernet (ether)
 mergecap: selected frame_type (null) ((null))
 mergecap: Can't open/create merge_encap:
           That file format doesn't support per-packet encapsulations

The following is an example of an attempt to use mergecap to merge three capture files with different encapsulation types (capture1, capture2, and capture3) into a single output file called merge_encap, the –T option is used to force an Ethernet encapsulation type for the output file:

C:\Program Files\Ethereal>mergecap -v -T ether -w merge_encap capture1 capture2 capture3
 mergecap: capture1 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture2 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture3 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: opened 3 of 3 input files
 Record: 1
 Record: 2
 Record: 3
 Record: 4
 Record: 5
 Record: 6
 Record: 7
 Record: 8
 Record: 9
 Record: 10
 output removed
 

Text2pcap

Text2pcap generates capture files by reading ASCII hexadecimal dump captures and writing the data to a libpcap output file. It is capable of reading a hexdump of single or multiple packets, and building capture files from it. Text2pcap can also read hexdumps of application level data only, by creating dummy Ethernet, IP, and User Datagram Protocol (UDP) or TCP headers so Ethereal and other sniffers can read the full data. The user can specify which of these headers to add.

Text2pcap uses the octal dump (od) format of hexadecimal output. Octal dump is a UNIX command that is used to output a file or standard input to a specified form, such as octal, decimal, or hexadecimal format. The format is specified by the parameters given to the –t option. The command od –t x1 will generate output that text2pcap can understand (the x1 describes the format of hexadecimal). The following is an example of the type of hexadecimal dump that text2pcap can read:

0000  00 05 5d ee 7e 53 08 00 20 cf 5b 39 08 00 45 00   ..].~S.. .[9..E.
 0010  00 9a 13 9e 40 00 3c 06 e0 70 c0 a8 64 7a c0 a8   ....@.<..p..dz..
 0020  64 84 00 17 05 49 0e a9 91 43 8e d8 e3 6a 50 18   d....I...C...jP.
 0030  c1 e8 ba 7b 00 00 4c 61 73 74 20 6c 6f 67 69 6e   ...{..Last login
 0040  3a 20 53 75 6e 20 4e 6f 76 20 20 32 20 31 37 3a   : Sun Nov  2 17:
 0050  30 36 3a 35 33 20 66 72 6f 6d 20 31 39 32 2e 31   06:53 from 192.1
 0060  36 38 2e 31 30 30 2e 31 33 32 0d 0a 53 75 6e 20   68.100.132..Sun
 0070  4d 69 63 72 6f 73 79 73 74 65 6d 73 20 49 6e 63   Microsystems Inc
 0080  2e 20 20 20 53 75 6e 4f 53 20 35 2e 39 20 20 20   .   SunOS 5.9
 0090  20 20 20 20 47 65 6e 65 72 69 63 20 4d 61 79 20       Generic May
 00a0  32 30 30 32 0d 0a 23 20                           2002..#

The beginning of each line has an offset of more than two hexadecimal, or octal, digits that is used to track the bytes in the output. If the offset is 0, this indicates the beginning of a new packet. If there are multiple packets in a file they will be output to the packet capture file with one second between each packet. If a line doesn’t have this offset it is ignored. The text output at the end of the line is also ignored. Text files can also contain comments that begin with the # character. Text2pcap has the ability to support commands and options by using the #TEXT2PCAP command at the beginning of the line. Text2pcap currently doesn’t have any commands and options supported, but future development could incorporate methods to control the way the hexadecimal dump is processed.

The following is the usage output for the text2pcap program:

Usage: text2pcap [-h] [-d] [-q] [-o h|o] [-l typenum] [-e l3pid] [-i proto]
          [-m max-packet] [-u srcp,destp] [-T srcp,destp] [-s srcp,destp,tag]
          [-S srcp,destp,tag] [-t timefmt] <input-filename> <output-filename>
 where <input-filename> specifies input filename (use - for standard input)
       <output-filename> specifies output filename (use - for standard
       output)
 [options] are one or more of the following
  -h              : Display this help message
  -d              : Generate detailed debug of parser states
  -o hex|oct      : Parse offsets as (h)ex or (o)ctal. Default is hex
  -l typenum      : Specify link-layer type number. Default is 1 (Ethernet).
                    See net/bpf.h for list of numbers.
  -q              : Generate no output at all (automatically turns off -d)
  -e l3pid        : Prepend dummy Ethernet II header with specified L3PID (in HEX)
                    Example: -e 0x800
  -i proto        : Prepend dummy IP header with specified IP protocol (in
                    DECIMAL).
                    Automatically prepends Ethernet header as well.
                    Example: -i 46
  -m max-packet   : Max packet length in output, default is 64000
  -u srcp,destp   : Prepend dummy UDP header with specified dest and source
                    ports (in DECIMAL).
                    Automatically prepends Ethernet and IP headers as well
                    Example: -u 30,40
  -T srcp,destp   : Prepend dummy TCP header with specified dest and source
                    ports (in DECIMAL).
                    Automatically prepends Ethernet and IP headers as well
                    Example: -T 50,60
  -s srcp,dstp,tag: Prepend dummy SCTP header with specified dest/source
                    ports and verification tag (in DECIMAL).
                    Automatically prepends Ethernet and IP headers as well
                    Example: -s 30,40,34
  -S srcp,dstp,ppi: Prepend dummy SCTP header with specified dest/source
                    ports and verification tag 0. It also prepends a dummy
                    SCTP DATA chunk header with payload protocol identifier
                    ppi.
                    Example: -S 30,40,34
  -t timefmt      : Treats the text before the packet as a date/time code;
                    the specified argument is a format string of the sort
                    supported by strptime.
                    Example: The time "10:15:14.5476" has the format code
                    "%H:%M:%S."
                    NOTE:    The subsecond component delimiter must be
                             specified (.) but no pattern is required; the
                             remaining number is assumed to be fractions of a second.

The following command line options are used to control text2pcap’s data processing and output:

  • –h This option prints the help options of text2pcap, then exits.

  • –d This option displays debugging information during the processing. Like verbose options it can be used several times for more information.

  • –q This option causes text2pcap to be quiet while processing.

  • –o h|o This option specifies either hexadecimal or octal formats for the offset of the output. The default is hexadecimal.

  • –l typenum This option lets you specify the data link layer type of encapsulation for the packet. This option is used when your hexdump is a complete, encapsulated packet. The encapsulation type is specified as a number using the typenum parameter. A complete list of encapsulation types and their associated numbers can be found in the /libpcap-0.7.2/bpf/net/bpf.h file included in the libpcap source distribution. For example Point-to-Point Protocol (PPP) is encapsulation type 9. The default is Ethernet, encapsulation type 1.

  • e l3pid This option allows you to include a dummy Ethernet header for each packet. You would use this option when your dump file has any type of layer 3 header, such as IP, but no layer 2 information.

  • i proto This option allows you to include a dummy IP header for each packet. The proto parameter allows you to specify the IP protocol in decimal format. You would use this option when your dump file has complete layer 4 information, but no layer 3 IP information. This option will also include the necessary Ethernet information. For example, –i 88 will set the set the protocol to Enhanced Interior Gateway Routing Protocol (EIGRP).

  • m max-packet This option will allow you to set the maximum packet length with the max-packet parameter. The default is 64000.

  • u srcport, destport This option allows you to include a dummy UDP header for each packet. The srcport and destport parameters allow you to specify the source and destination UDP ports in decimal format. You would use this option when your dump file has does not contain any UDP layer 4 or below information. This option will also include the necessary IP and Ethernet information.

  • T srcport, destport This option allows you to include a dummy TCP header for each packet. The srcport and destport parameters allow you to specify the source and destination TCP ports in decimal format. You would use this option when your dump file has does not contain any TCP layer 4 or below information. This option will also include the necessary IP and Ethernet information.

  • s srcport, destport, tag This option allows you to include a dummy Stream Control Transmission Protocol (SCTP) header for each packet. The srcport and destport parameters allow you to specify the source and destination SCTP ports in decimal format. The tag parameter allows you to specify a verification tag. You would use this option when your dump file has does not contain any SCTP layer 4 or below information. This option will also include the necessary IP, Ethernet, and CRC32C checksum information.

  • S srcport, destport, ppi This option allows you to include a dummy SCTP header for each packet. The srcport and destport parameters allow you to specify the source and destination SCTP ports in decimal format. The ppi parameter allows you to specify a payload protocol identifier for a dummy SCTP DATA chunk header. The verification tag will automatically be set to 0. You would use this option when your dump file has does not contain any SCTP layer 4 or below information. This option will also include the necessary IP, Ethernet, and CRC32C checksum information.

  • t timefmt This option allows you to specify a time format for the text before the packet. The timefmt parameter follows the format of strptime(3), such as “%H:%M:%S.”, which converts a character string to a time value.

The following is an example of using text2pcap to read a hexadecimal dump, hex_sample.txt, and output it to the libpcap_output file:

C:\Program Files\Ethereal>text2pcap hex_sample.txt libpcap_output
 Input from: hex_sample.txt
 Output to: libpcap_output
 Wrote packet of 168 bytes at 0
 Read 1 potential packets, wrote 1 packets

The next example uses text2pcap to read a file with multiple hexadecimal packets, hex_sample2.txt, and output the format as Telnet/TCP packets to the libpcap_output2 file:

C:\Program Files\Ethereal>text2pcap -T 1297,23 hex_sample2.txt libpcap_output2
 Input from: hex_sample2.txt
 Output to: libpcap_output2
 Generate dummy Ethernet header: Protocol: 0x800
 Generate dummy IP header: Protocol: 6
 Generate dummy TCP header: Source port: 1297. Dest port: 23
 Wrote packet of 62 bytes at 0
 Wrote packet of 62 bytes at 62
 Wrote packet of 60 bytes at 124
 Wrote packet of 69 bytes at 184
 output removed
 Read 76 potential packets, wrote 76 packets

The od command can also be piped into the text2pcap program. Text2pcap will then read the output of the od command as standard input. The next example uses text2pcap to read a data stream as input and output the format as HTTP/TCP packets to the output.pcap file. The –Ax parameter to the od command prints the offsets as hexadecimal. The –m1460 parameter to text2pcap specifies a maximum packet size of 1460 bytes. The maximum Ethernet packet size is 1500 bytes, minus the 20 bytes for each the IP and TCP header, leaves 1460 bytes for the data. By default the –T parameter will create TCP, IP, and Ethernet dummy headers. The following shows the command and associated output:

[root@localhost root]# od -Ax -tx1 input | text2pcap -m1460 -T1234,80 - output.pcap
 Input from: Standard input
 Output to: output.pcap
 Generate dummy Ethernet header: Protocol: 0x800
 Generate dummy IP header: Protocol: 6
 Generate dummy TCP header: Source port: 1234. Dest port: 80
 Wrote packet of 1460 bytes at 0
 Wrote packet of 1460 bytes at 1460
 Wrote packet of 1460 bytes at 2920
 Wrote packet of 788 bytes at 4380
 Read 4 potential packets, wrote 4 packets

Summary

As we have shown in this chapter, Ethereal is more than the GUI; it is a suite of programs that provide command line capturing, formatting, and manipulating capabilities. The programs can be used together to provide even more processing capabilities, while output from one program can be piped as input to another. Since these programs are command line, they also provide powerful scripting capabilities.

Tethereal provides just about all of the same processing capabilities as Ethereal, without the GUI functionality. Editcap, although used primarily for removing packets from a capture file, can also be used to translate capture files into various formats. Mergecap provides the ability to merge various capture files together, even from different network analyzers. This is a great resource when you’re performing audits or incident response and you need to combine captures from various source such as sniffers, IDS, and logs. Text2pcap allows you to translate hexadecimal data streams to sniffer readable packet captures. You can even add dummy Layer 2-4 data when you only have an application output stream.

Solutions Fast Track

Tethereal

  • Tethereal can read packets from the network or from a packet capture file.

  • Tethereal can decode and print the captured packets to screen or save them to a file.

  • One of the best advantages to using Tethereal is that it is highly scriptable.

  • Tethereal can apply both capture filters and display filters to the packet captures.

  • Tethereal can collect various types of statistic about the data that is being captured.

  • Like editcap, Tethereal can be used to translate capture file formats.

Editcap

  • Editcap can be used to remove packets from a capture file or to translate the format of capture files.

  • The –t option in editcap is used to apply a time adjustment to the timestamps of the packets.

  • The snapshot length can be specified with the –s option to decrease the size of each packet.

  • Editcap can specify an encapsulation type for the packets in the output file with the –T option.

Mergecap

  • Mergecap can merge several packet capture files into a single output file.

  • Mergecap can read capture files of various formats and output them to a single format.

  • By default, the packets from the input files are merged in chronological order based on each packets timestamp, however if the –a option is specified, packets will be copied directly from each input file to the output file regardless of timestamp.

  • Mergecap can merge capture files with different encapsulation types into a single output file by using the –T option to force the output encapsulation type.

Text2pcap

  • Text2pcap reads ASCII hexadecimal dump captures and writes the data to a libpcap output file.

  • Text2pcap can insert dummy Ethernet, IP, and UDP or TCP headers.

  • The command od –t x1 will generate output that text2pcap can understand.

  • An offset of 0 indicates the beginning of a new packet.

  • Text2pcap options give you a lot of control over the dummy headers, timestamps, and encapsulation type for each packet.

Frequently Asked Questions

The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form. You will also gain access to thousands of other FAQs at ITFAQnet.com.

1. 

What is the difference between using Tethereal and editcap to translate the format of capture files?

Nothing - they both perform the same function. However, editcap would be a more efficient method of converting files because Tethereal contains a lot of code for protocol dissection, whereas editcap is a smaller program with only a few functions. You can also use the Ethereal GUI to do the same thing by choosing Save As from the File menu.

2. 

Can mergecap combine gzipped files?

Yes, mergecap can automatically uncompress, read, and merge gzip files.

3. 

What types of things can I do to make scripting with Tethereal faster?

One way to make scripting faster with Tethereal is to use the  l option to flushes the standard output after each packet is printed instead of waiting until it fills up. This way each packet is sent as soon as it is read and dissected. You can also use the  n option to disable network object name resolution to make the process faster.

4. 

Can I use filters to specify what packets to remove with editcap?

No, editcap does not have the capability to use filters. You must know the packet numbers that you want to include or exclude from the output capture file. You can use Tethereal to read a capture file, apply filters, and output the results to a new capture file.

Answers

1. 

Nothing - they both perform the same function. However, editcap would be a more efficient method of converting files because Tethereal contains a lot of code for protocol dissection, whereas editcap is a smaller program with only a few functions. You can also use the Ethereal GUI to do the same thing by choosing Save As from the File menu.

2. 

Yes, mergecap can automatically uncompress, read, and merge gzip files.

3. 

One way to make scripting faster with Tethereal is to use the –l option to flushes the standard output after each packet is printed instead of waiting until it fills up. This way each packet is sent as soon as it is read and dissected. You can also use the –n option to disable network object name resolution to make the process faster.

4. 

No, editcap does not have the capability to use filters. You must know the packet numbers that you want to include or exclude from the output capture file. You can use Tethereal to read a capture file, apply filters, and output the results to a new capture file.

Оставьте свой комментарий !

Ваше имя:
Комментарий:
Оба поля являются обязательными

 Автор  Комментарий к данной статье