style="font-size:15px;"> If you have used any modern programming language, the syntax should look familiar. To make a useful expression, you have to match these operators against variables in the packet. This is possible in Wireshark by accessing variables grouped by protocol. For example, ip.addr would contain the destination and the source address. The following statement filters all the traffic coming from or going to the supplied IP address: ip.addr == 1.2.3.4. This works by matching against both the destination and the source address header in the IP packet so that it will return true for packets in both directions.
NOTE
Keep in mind that the expression tests both values of the specified variable if it occurs more than once in the packet. For example, eth.addr will match both the source and destination. This can lead to unexpected behavior if the expressions are grouped incorrectly. This is especially true in expressions featuring negation, such as eth.addr != 00:01:02:03:04:05. This will always return true.
In the previous example on comparison operators, an IP address was compared to the variable ip.addr to only show traffic from and to that IP. If you were to try to compare the same variable to google.com, Wireshark would present an error message because the variable is not an IP address. The variables available to use in expressions are typed. This means that the language expects an object of a certain type to be compared only to a variable of the same type. To see the available variables and their types, you can use the Wireshark Display Filter Reference page at http://www.wireshark.org/docs/dfref/. In practice, you can also see the values Wireshark expects for each element in the packet by inspecting the packet using the Packet Details pane. The variable names can be found on the bottom left of the screen in the status bar or looked up in the reference. The status bar lists the filter field for the selected line in the Packet Details pane.
For an example of this, see Figure 1-4. A packet is captured, and 1 byte is highlighted in the Packet Details pane. The 1-byte portion denotes the IP version. See the lower left of the application, on the status bar: “Version (ip.version), 1 byte.”
Figure 1-4: Field information in the status bar
A good way to filter the available packets is to decide on an expression by inspecting a packet that interests you. It is easier to see the differentiating markers between packets you do want to see by comparing fields in the Packet Details pane. As shown in Figure 1-5, each field in the ARP packet is listed with a readable value (hex in the Packet Details pane) followed by the raw value (on the right side of the Packet Details pane). Both of these values can generally be used in an expression, as Wireshark transforms the readable format to the corresponding raw format for your convenience. For example, if you want to see only ARP requests in the Packet List pane, the filter would be arp.opcode == 1. In this case, typing request would not work, because it is not a named representation of the same data. (The number 1 could mean many things.) With MAC addresses, protocol names, and so on, the named version can be used.
Figure 1-5: ARP packet Opcode
Usually a single expression is not specific enough to narrow down the stream of packets you are looking for when dealing with larger packet captures, as is the case with Figure 1-5. To locate the exact set of packets you want to see, you can combine expressions by logical operators. Table 1-2 shows the available operators. The symbol and English-word operator can be used interchangeably according to personal preference.
Table 1-2: Logical Operators
Source: http://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html
Building Display Filters Interactively
To quickly gain experience at building filters, you can use the graphical interface of Wireshark and the various context menus to build filters interactively. Start by right-clicking on a section of a packet that interests you, and then select Apply as Filter
After filtering for this particular IP address, you might want to add a destination port to the filter to only see traffic from this host to port 80. This can also be done in the GUI without throwing away the current filter by right-clicking the source port in the Packet Details pane and selecting Apply as Filter
Figure 1-6 shows an example of the display filter code after selecting two items: ARP protocol packets and the source MAC address.
Figure 1-6: Filter results of ARP from a source address
After selecting ARP to apply as a filter, only ARP protocol packets from various systems were displayed in the Packet List pane. Subsequently selecting a source MAC (SamsungE_e1:ad:3c) as a filter expression, the display filter was amended to become arp.src.hw_mac == c4:57:6e:e1:ad:3c.
Figure 1-7 shows how complex filter statements can be built using this technique. As you can see in the status bar, Wireshark might suggest adding parentheses or suggest the User Guide. In upcoming chapters we will build and use many filters; this is just to show that filters can certainly grow past one or two functions.
Figure 1-7: Complex display filter example
You can always use the context menus to edit the filter in the Filter bar after you start it. If building them interactively, make sure you are aware of the filters Wireshark applies for you by noting what syntax was inserted in the Filter bar.
Building filters interactively provides a great way to understand the most commonly used filter fields and protocols. This will pay off when dealing with advanced Wireshark use cases in the future.
Summary
Congratulations on finishing the first chapter. It's a fairly light chapter, as we haven't begun actually working with the application yet. Given the belief that new Wireshark users are commonly surprised by the fast-growing number of packets, the book aims to nip overwhelm before it happens. The two big areas to cover before actually using Wireshark are the GUI and filters.
We provided a general overview of the GUI, focusing on its layout and the reasoning behind it. The layout is divided into three panes: Packet List, Packet Details, and Packet Bytes. The panes present packet data at different levels of detail and serve to help the user drill down to
