Analysis and processing of network traffic are critical aspects for maintaining and optimizing the performance of local networks. In this context, tools such as Wireshark and tcpdump become indispensable assistants for network engineers and administrators. They enable you to capture, analyze and understand the flow of data on the network, helping to solve real-world problems and ensure network security. Wireshark, known for its powerful and intuitive interface, provides users with the ability to intercept data packets, analyze their headers and contents, identify potential security threats, and identify network speed issues. Meanwhile, tcpdump is a command-line tool that allows for more in-depth packet analysis.
In this article, we will take a detailed look at how Wireshark and tcpdump can be used to analyze local networks and process captured network packets. You’ll learn about their capabilities, key benefits, and how they work together to help uncover potential network problems and keep your network running efficiently. Network traffic analysis is an important part of the IT infrastructure field, and knowledge of these tools can be extremely useful for engineers, administrators, and anyone responsible for network reliability and security. Understanding and effectively using tools such as Wireshark and tcpdump are key aspects of ensuring the reliability and security of local networks. Unlike ordinary users who can only interact with the network at a superficial level, network engineers and administrators must have the means to deeply analyze network traffic. After familiarizing yourself with Wireshark, you can start collecting and analyzing packets. In this section, you will learn how to handle capture files, packets, and time display formats. Additional capabilities for packet sniffing and ways to use filters are also discussed.
Over time, you’ll find that a large proportion of packet sniffing occurs in the post-capture stage. As a rule, several interceptions are made at different points in time. At the same time, they are stored and then analyzed. Thus, Wireshark allows you to save capture files for later analysis. Additionally, multiple capture files can be merged together.
Save and export capture files
To save the packet capture result, select File4 Save As from the main menu. As a result, the Save file as dialog box shown in Fig. 4.1, in which you will be asked to specify the location of the received packet interception, as well as to choose the appropriate file format for it. If you do not specify a file format, Wireshark will automatically select the default file format with the .rsarpd extension.
Most often, it is necessary to save only a part of the captured packets. To do this, select “Specified packages” in the main menu. As a result, the dialog box shown in fig. 4.2. This is a handy way to reduce the size of excessively bloated capture files. In particular, you can choose to save packets only in a certain range of numbers, labeled packets or those packets that appear on the screen after applying a display filter (specified packets and filters are matrixed later in this section).
Some types of analysis require the ability to combine multiple capture files together. And this is a common practice when you have to compare two data streams or combine streams related to the same network traffic, but intercepted separately.
To merge capture files, open one of them and select File4Merge from the main menu. As a result, the Merge with capture file dialog will open, shown in Fig. 4.3. First select the new file with which you want to merge the already open file, and then how to merge them. For example, you can add a selected file to the beginning or end of an open file, or you can combine files chronologically based on their creation or modification timestamps.
This will eventually lead to you having to process a lot of packets. As the number of packages grows into the thousands or even millions, you will need to navigate these packages efficiently. And for this, Wireshark provides search and marking of packets that meet certain criteria. To make it easier to refer to the packages for quick reference, you can print them.
To find packets that meet certain criteria, open the Find Packet panel, shown in a condensed form in Fig. 4.4 by pressing the <Ctrl+F> key combination. This panel appears between the Filter panel and the Package List window.
This panel provides three options for finding packages as described below.
Filter display. This option allows you to create a filter to search for only those packages that match the expression specified in it. It is this option that is used to search for packages to obtain the results shown in Fig. 4.4.
Nex Value: Use this option to search for packets based on the specified hex value. String: Use this option to search for packages based on a specified string of characters. For example, you can specify an object name to search for packages or be case-sensitive in the search string.
The types of search for parcels are summarized in the table. 4.1.
After you have selected the package search type, enter your search criteria in the text box and click the Find button to find the first package that matches the specified criteria. To find the next package, click the Find button again, or press <Ctrl+N>, or press <Ctrl+B> to find a previous package that met the specified criteria.
So, after finding the packages that meet the given criteria, you can mark those that interest you first of all. Marking of packages, in particular, allows you to store only these packages. In addition, these packages can be quickly identified by their white text on a black background, as shown in Fig. 4.5.
To mark a package, right-click it in the Package List panel and select (()mark package) from the context menu, or press <Ctrl+M> in the Package List panel. You can mark as many captured packages as you need. And to move forward or backward between the specified packages, press the key combination <Shift+Ctrl+N> or <Shift+Ctrl+B>, respectively.
Despite the fact that most of the analysis is carried out on the computer monitor screen, the intercepted data sometimes needs to be printed. From time to time I print out the intercepted packets and tape the resulting printouts to my desktop so that I can quickly refer to their contents for help as I progress through the analysis. It is also convenient to print packages in PDF format, especially when preparing reports.
To print captured packets, open the Print dialog by selecting File4Print from the main menu (Figure 4.6).
As with the Export Specified Packets dialog box, this box allows you to specify which packets are printed only within certain ranges or which packets are displayed after applying a filter. You can also specify the level of detail to print for each package. After you have selected all the print options, click on the Print button.
Timing is very important, especially for packet analysis. Everything that happens on the network is sensitive to time, and therefore it is often necessary to study trends and network delays in the interception of files. The Wireshark application provides several customizable time-related settings. This section discusses time display formats and binding to it.
Time display formats
Each packet captured by Wireshark is time-stamped at the operating system level. The Wireshark application is capable of displaying an absolute timestamp indicating the exact moment a packet was intercepted, the time relative to the last intercepted packet, and the start and end of the intercept.
Options related to time display are located under the View heading in the main menu. The Time Display Format item under this heading of the main menu allows you to configure the time display format, as well as the accuracy of its display, as shown in Fig. 4.7.
Time display format settings allow you to choose different time display options. These include the display of the date and time of the sug in the standard format or in the format of Universal Coordinated Time (UTC), the number of seconds that have passed since the moment of the last interception, and so on.
And the precision settings allow you to set the precision of the time display automatically, that is, in the format taken from the capture file, or manually, for example, in seconds, milliseconds, microseconds, etc.
Time binding to packets allows you to configure a specific packet so that subsequent timing calculations are performed for that packet. This feature is particularly useful when examining a series of sequential events that occur at a different time than when the capture file begins to form.
To set a time reference for a package, right-click your preference as a reference package in the Package List panel and select SetnJnset Time Reference from the context menu. And in order to reset the temporary binding, repeat the same operation again. Alternatively, you can set and reset a temporary binding to a package by selecting the link package in the Package List pane and pressing <Ctrl+T>.
If packet time binding is enabled, the *REF* label will appear in the (Time) column displayed in the Packet List panel (Figure 4.8).
It is convenient to set the binding to the packet time only if the capture time display format is configured to show the time relative to the start of the capture. And in any other case, setting a temporary link to the package will not do anything useful and will actually lead to the display of moments in time, which will be very difficult to understand.
Sometimes there are packets from different sources that are not synchronized with the same source. This is especially true when examining capture files taken from two locations that contain the same data stream. Most network administrators want to ensure that all devices on their network are synchronized. But there are often cases when there is a shift in time between certain types of devices. The Wireshark application provides the ability to shift the timestamp in packets to eliminate this complexity during analysis.
To shift the time stamp in one or more batches, select Edit c>Time Shift from the main menu or press <Ctrl+Shift+T>. In the Time Offset dialog box, you can specify an offset time limit for the entire capture file as a whole or set the time for individual packets. In the example shown in fig. 4.9, is chosen to offset the timestamp in each packet from the capture file by two minutes and five seconds.
In the previous section, we looked at the basic process of capturing packets using the settings in the Capture Interfaces dialog box. But Wireshark provides quite a few other options for configuring interception options that we haven’t covered yet. To access these options, select Capture40options from the main menu.
The Capture Interfaces dialog box provides many customizable options to make the process of capturing packets more convenient. It is divided into three tabs: lnput (Input), 0utput (Output) and 0ptions (Options). Let’s consider them one by one.
The input tab
The main purpose of the lnput tab (Figure 4.10) is to display all network interfaces available for packet sniffing, as well as some basic information about each of these interfaces. This information includes the understandable name of the network interface, which is provided at the operating system level, a graph of network traffic that clearly shows the bandwidth of the interface, and additional configuration settings, including the mixed mode state of the network interface and the size of the buffer. On the right edge of the tab considered here, not shown in fig. 4.10, there is also a graph to display the filter applied during interception. This will be discussed in more detail in the “Interception Filters” section.
On the 0utput tab (Figure 4.11), you can automatically save intercepted packets to a file instead of first intercepting them and then saving them to a file. After all, it is much easier to manipulate stored parcels. In particular, captured packets can be stored in a single file, in multiple files, and even in a ring buffer, as explained below, to manipulate a series of generated files. To enable this capture mode, enter the full name and file name in the File text box. And in order to select a directory and specify a file name, click the Browse… button.
If you have to intercept a large amount of network traffic or perform interception in the long term, then file sets are especially convenient for this purpose – collections of several files allocated to separate groups under a special condition. To specify a set of files, check the Automatically create a new flash drive… (Automatically create a new file after…).
Wireshark uses special triggers to save captured packets in file sets of a specified size or time interval. To activate one of these triggers, select the radio button below the flag mentioned above, then specify the desired threshold value and the trigger unit. For example, you can set a trigger to start the process and create a new file every time 1 MB of network traffic is intercepted, as shown in Figure 1.4.12, or every minute when network traffic is intercepted.
The Use a ring buffer with” checkbox allows you to specify a certain number of files that should be accumulated in the set by Wireshark tools before overwriting them. And although the term ring buffer has different meanings, in this case it essentially refers to a set of files where the first file can be overwritten as soon as the last written file is entered into the set in order to preserve the newly received data. In other words, this flag sets the file writing mode to first-in-first-out (FIFO). By setting this check box, you can specify the maximum number of files to store in the circular shift ring buffer. Suppose a set of six files is selected to store intercepted network traffic, and a new file is created every hour. Thus, a ring buffer of 6 files is created. Once the sixth file is created file, the ring buffer will be circularly shifted when overwriting the first file, instead of creating a seventh file to store the next array of intercepted data. This ensures that no more than six data files will be stored on the hard disk for 6 hours with the possibility of writing new data.
And finally, on the Output tab, you can also specify a specific data file format. Yes, you can choose the traditional Psar format if you need to interact with saved packages in a tool that is not capable of processing files with the .pcapng extension.
The 0options tab contains a number of other options for choosing how to save intercepted packets, including settings for display, name translation, and interrupt interception, as shown in Fig. 4.13.
Display settings options
The Display 0options section contains elements that control the order in which packets are displayed when they are captured. The purpose of the Update package list in real-time check box is self-explanatory. It can be set together with the Auto-scroll during live capture check box. When both of these flags are checked, all intercepted packets are displayed on the screen, and the most recent ones are displayed immediately.
You can use the Show More Capture Details dialog box to enable or disable the display of a small window that shows the percentage of captured packets sorted by network protocol. Personally, I prefer to display this information window, as I usually prevent active scrolling of the packet display window while intercepting them.
Options for configuring name resolution
In the Name Resolution section, you can set the MAC address translation mode (second level), as well as the network and transport name resolution mode (third and fourth levels, respectively). General name resolution issues will be covered in more detail in Chapter 5, Wireshark Advanced Features.
Interception stop options
In the section Stop automatic capture… (Stop capture automatically after…) you can specify certain conditions under which the capture will be stopped. As with creating a set of files, you can stop capture at a specified file size or time period. But it can also be done for the specified number of packages. It is convenient to combine the settings in this section with the settings available on the 0utput tab.
Application of filters
Filters can be used to specify the packages that are required for analysis. Simply put, a filter is an expression that specifies criteria to include or exclude packets from analysis. For example, if you have packages you don’t want to view, you can create a filter to get rid of them. And if you want to see only certain packages, you can create a filter to show only them.
Interception filters. Used when you want to capture only those packets that are specified to be included or excluded in the specified expression.
Displaying filters. Apply to an existing package series to hide unwanted packages or show desired packages based on a given expression.
Filters of this type are used in packet sniffing to initially limit the number of packets submitted for analysis. One of the main reasons for using intercept filters is performance. If you know in advance that you don’t need to analyze a certain form of network traffic, you can filter it out with a capture filter, saving the CPU time that would normally be needed to capture the relevant packets.
The ability to create special capture filters will be handy if you have to deal with large amounts of data. Their analysis can be accelerated by filtering only those packets that are needed to solve the current analysis task.
Let’s say you are troubleshooting a service running on port 262, but the server being analyzed has a number of services running on different ports. Interception and analysis of network traffic through only one port is not an easy task. And this is where an interception filter can come in handy.
To do this, simply use the Capture Interfaces dialog as follows.
Choose Capture c> Options from the main menu to open the Capture lnterfaces dialog box.
Select the network interface on which you want to capture packets, then scroll to the rightmost Capture Filter column.
To apply an intercept filter, click this column and enter a filter expression. In this case, you only need to filter incoming and outgoing network traffic on port 262, so enter port 262 as shown in Figure 262. 4.14. (Filter expressions are discussed in more detail in the next section.) The cell color in this column should change to green, indicating that a valid expression has been entered. If it is unreliable, the cell will be highlighted in red.
After setting up the filler, press the Star1 button to start interception.
As a result, you should only see the network traffic that goes through port 262. So, this will give you the ability to analyze the data of that particular traffic more effectively.
The capture filters used by the libpcap/WinPcap drivers are described using the Berkeley Packet Filter (BPE) syntax. This syntax is common to many packet sniffers, mainly because they rely on the libpcap/WinPcap libraries, which use the BPE syntax to describe filters. For in-depth network analysis at the packet level, knowledge of BPF syntax is critical.
A filter created using BPF syntax is called an expression, and each expression consists of one or more primitives. In turn, primitives consist of one or more classifiers listed in the table. 4.2, as well as the name or identifier number, as shown in fig. 4.15.
Given the constituent expressions, the DST classifier and the identifier 192 .168 .0.10 together form a primitive. Such a primitive is itself an expression that defines the interception of network traffic only by the recipient’s IR address 192 .168. 0 .10. You can use logical operations to combine primitives to create more complex expressions.
And for this there are the following logical operations.
A logical union operation relative to AND
Logical disjunction operation using OR ().
Logical operation of negation through NOT (! ).
For example, the following expression captures only network traffic originating from a source located at 1P 192 .168. 0 .10 and passing through the sender or receiver port 80:
src host 192.168.0.10 && port 80
Most filters are created to analyze a specific network device or group of similar devices. Depending on the circumstances, filtering can be based on the device’s MAC address, IPv4 or IPv6 addresses, and DNS hostname.
Suppose you want to analyze the network traffic of a particular host that is communicating with a server on the network. To capture all network traffic associated with a specific host’s IPv4 address, you can create the following filter on the server using the host classifier:
If you are analyzing an IPv6 network, the filter should be created based on the IPv6 address using the host classifier:
You can also create a filter based on the hostname of a network device using the host classifier as described below.
And if you want to account for a possible change in the host’s 1P address, you can create a filter based on its MAC address by adding an ethernet protocol classifier as shown below.
ether host 00-la-a0-52-e2-a0
It is not uncommon for data direction classifiers to be used in conjunction with filters (such as in the examples above) to intercept network traffic based on whether the traffic is inbound or outbound from a host. For example, to capture only network traffic originating from a specific host, you would need to complete the filter with the src qualifier as follows:
src host 172.16.16.149
And in order to intercept only those data that are intended for the host at 172.16.16.149, the above filter should be supplemented with the dst classifier:
dst host 172.16.16.149
If the filter does not use a type classifier (host, net, or port) with the primitive, then the host classifier is assumed. Therefore, the following expression, which does not have such a classifier, is equivalent to the expression from the previous example.
In addition to filtering hosts, the filter you create can be based on the ports used in each packet. Port filtering can be performed to filter services and applications that use ports of known services. For example, the following example shows a simple filter that is only designed to intercept network traffic coming in or out of port 8080:
The following filter is suitable for intercepting all network traffic, except for port 8080:
Port filters can be combined with data direction filters. For example, if you want to capture only network traffic that is sent to a web server to be received via the standard NTGR network protocol port 80, you can use the DST classifier in the filter as follows:
dst port 8080
Filters of this type allow you to filter packets using specific network protocols. They are used to represent network protocols that are not related to the application layer and cannot be identified only on a specific port. For example, if you want to view only ICMP network traffic, you can use the following filter:
And for viewing all network traffic, except for the IPv6 protocol, the following filter is suitable:
One of the greatest strengths of the BPF syntax is the ability to inspect each byte in the protocol header to create custom filters based on protocol-specific information. The special filters discussed in this section allow you to extract a specific number of bytes from a packet starting at a specific location.
Let’s say you want to filter network traffic by the type field in the ICMP header. The type field is located at the very beginning of the packet, that is, it has a zero offset. To specify the location of the investigated field in the packet, it is sufficient to specify the offset in bytes after the protocol classifier (in this example – icmp [О]) in square brackets. As a result, a single-byte value will be returned that can be compared to something. For example, if you want to receive only Internet Control Message Protocol (ICMP) packets that represent Type 3 Recipient Unreachable messages, you should use the equality operation in the filter expression as shown below.
cmp[O] == 3
And in order to consider only packets transmitted via the ICMP network protocol and representing an echo request (type 8) or an echo response (type 0), two primitives and a logical OR operation can be used in the filter expression as follows:
cmp[O] == 8 OR icmp[O] == О
Despite the fact that special filters do their job, they are based on only one-byte information from the packet header. However, in the filter expression, you can also specify the length of the returned data in bytes after the numeric offset value in square brackets separated by a colon.
For example, suppose you want to create a filter to intercept all ICMP packets sent by the network protocol for an unreachable recipient, host, and identified by type 3 and code 1. The one-byte fields with this data are located one by one in the packet header, starting at offset zero. To do this, you can create a filter that checks the two leading zero-offset bytes in the packet header, which compares it to the hexadecimal value 0301 (ie type 3 and code 1) as follows:
icmp[0:2] == ОхОЗОl
Often you only need to capture packets that are transmitted over the TCP network protocol with the RST flag set. The TCP protocol will be discussed in more detail in Chapter 8 “Transport Layer Protocols”, but for now it is enough to say that the flags are located in the field of the TCP packet with an offset of 13. This field is interesting because its length is one byte, where each bit represents a separate flag. As explained in Appendix B, “Packet Interpretation”, each bit with a flag set in it is represented in such a byte by a base-2 number. So, the first bit is represented by the number 1, the second bit by the number 2, the third by the number 4, and so on. Therefore, one value of tcp [ 13) is not enough for their effective filtering, since several values may correspond to the specified RST bit.
Instead, you must specify the location of the flag to be checked in bytes by enclosing the filter expression with an ampersand (‘) and a number representing the bit in which the flag is stored. Specifically, the RST flag is stored in the bit represented by the number 4 in this byte, which indicates that the RST flag is set. Thus, the filter for the purposes discussed here will look like this:
tcp[lЗ] & 4 == 4
And in order to view all packets with a set of PSH flags, which is stored in the bit represented by the number 8 in the field of the TCP packet with an offset of 13, it is enough to use the following filter:
tcp[lЗ] & 8 == 8
Often the success or failure of packet sniffing depends on the ability to create filters appropriate for a particular situation. In the table Table 4.3 shows some example expressions for intercept filters that are often used in packet analysis.
This type includes filters that, when applied to the capture file, means that Wireshark should only display packets that match that filter. You can create a display filter in the Filter text box above the Package List panel.
Display filters are more commonly used than capture filters because they allow you to filter out unwanted data without physically removing it from the capture file. For example, if you want to change the original intercept condition, you can simply clear the filter expression. In addition, display filters are much more efficient thanks to support for the large library of packet decryptors available in Wireshark.
For example, in some cases, a display filter can be used to filter out inappropriate broadcast traffic from a capture file. At the same time, the “Packet List” panel filters out those broadcast ARP packets that have nothing to do with the current problem being analyzed in the network. But since these ARP broadcast packets will prove to be useful in the future, it is better to weed them out temporarily rather than removing them completely.
To filter all ARP packets in the capture window, place the cursor in the Filter text box above the Packet List panel and type !arp. As a result, all ARP packets were removed from the list (Fig. 4.16). To remove an entered display filter, press the X button, or to save the filter for later use, press the plus (+) button.
Display filters can be applied in two ways. One is to use the syntax directly, as shown in the previous example, and the other is to use the Filter Expression dialog box to create a filter in dialog mode. This is an easier way for those who are just starting to use filters. Let’s look at both ways of applying display filters, starting with the simpler one.
Features of the Display Filter Expression dialog box are shown in Fig. 4.17 makes it much easier for novice Wireshark users to create capture and display filters. To access this window, select the Filter4Expression command from the main menu.
In the left part of this window, all available fields of the network protocol are listed, where all possible filtering criteria are indicated.
To create a filter, follow these steps:
Click the arrow next to the network protocol name to view its associated condition fields. Once you’ve found the criteria you want to use as a basis for creating a filter, click on it to select.
Choose the order in which the selected field is compared to the value from the conditions. Such a comparison is indicated by the operation greater than, less than, equal to, and so on.
Create a filter expression by specifying values from the criteria against which the selected field should be compared. This value can be specified manually or selected from a list of predefined values in Wireshark.
The resulting filter will appear at the bottom of the screen. When finished, click OK to enter it into the filter panel.
The Display Filter Expression dialog box is very handy for first-time Wireshark users, but once you’ve gained some experience building filters, you’ll find that entering filter expressions manually is much more efficient. The syntactic structure of creating display filters is very simple, although it is quite effective.
The more you use Wireshark, the more you will have to use display filters directly in the main program window to save time. However, the syntax for creating display filters is simple and follows a standard structure. Most often, this structure focuses on network protocols and follows the format of the protocol. means. subordinate instrument. This is not difficult to verify by looking at the Display Filter Expression dialog box. Now let’s look at a series of examples that demonstrate how to build display filters.
Most often, interception or display filters are used to view packets on a separate network protocol. Let’s say you want to diagnose a problem that occurred at the TCP network protocol level, and to do this, you want to intercept only the network traffic using this protocol. A simple tcp filter is quite suitable for this.
Now let’s look at this problem from a different angle. Suppose that when diagnosing a problem at the level of the TCP network protocol, the Ping utility was used quite intensively, which led to the formation of a large amount of network traffic using the ICMP protocol. To filter this traffic out of the capture file, simply apply the expression ! IFKS.
Comparison operations allow you to compare individual values. For example, when diagnosing TCP/IP networks, it is often necessary to look at all packets with links to a specific 1P address. Using the equality comparison operation (—), the following filter can be created to display all packets with the address 192 .168. 0 .1:
Now suppose you want to view only those packets that are less than 128 bytes in length. To do this, you can use the comparison operation less than or equal to equality (<=) in the following filter:
In the table Figure 4.4 shows all the comparison operations used in the filter expressions generated by Wireshark.
Logical operations allow you to combine multiple filter expressions in a single statement. And thanks to this, the efficiency of the used filters is noticeably increased.
Let’s say you want to display packets to only two 1P addresses. To create a single expression to filter packets that contain both IP addresses, you can use the or boolean operation as follows:
ip.addr==192.168.0.1 or ip.addr==192.168.0.2
In the table Figure 4.5 shows all the logical operations used in the filter expressions compiled in Wireshark.
Despite the fact that the principles of filtering expressions are quite simple, in the process of creating new filters, a number of special keywords and operations have to be used to solve various tasks. In the table 4.6 provides some example expressions for the most common display filters, and a complete list can be found in the Display Filters Reference Manual available at http : / /www.wireshark.org/docs/dfref/.
Once you start creating a significant number of capture and display filters, you may find that some of them are used quite often. At the same time, it is not necessary to enter them every time they are needed, as Wireshark provides the ability to save filters for later use.
So, to save a custom capture filter, follow these steps:
Click Capture4Capture Filters to open the Capture Filter dialog box.
To create a new filter, click the plus (+) button in the lower left corner of the dialog box.
Enter a name for the new filter in the Filter Name field.
Enter a filter expression in the Filter string field.
Click OK to save the filter expression.
To save a custom display filter, follow these steps:
Enter a filter in the Filter panel above the Packet List panel in the main Wireshark window, then click the green ribbon button on the left side of the panel.
Select “Save this filter” from the pop-up menu. A separate dialog box will provide a list.
If you have filters that you use frequently, the easiest way to interact with them is to place their labels in the filter panel mentioned above.
To do this, do the following:
Enter your filter in the Filter panel above the Packet List panel in the main Wireshark window, then click the plus (+) button on the right side of the panel.
A new panel will appear under the “Filter” panel, where you can specify the name of your filter in the “Label” field (Fig. 4.19). The specified label will be used to represent the filter on the toolbar. After entering a label in this field, click OK to create a label for quick access to the filter in the Filter panel.
As shown in Fig.. 4.20, this (:luc managed to create a filter shortcut to quickly display any TCP packets with the RST flag set. The filters placed on the toolbar store (‘.i in the configuration file mentioned in section H , “Introduction to Wireshark.” This greatly expands your ability to detect packet-level network problems in a variety of situations.
Wireshark comes with a number of built-in filters that serve as personal examples for creating your own filters. Use them in conjunction with Wireshark’s help pages when creating your own filters. We will use filters a lot in the examples shown later in this book.
We used materials from the book “PRACTICAL RACKET ANALYSIS” written by Chris Sanders.