If you have a number of network interfaces on your machine, you may not be sure which one to select to capture packets, but there's a fairly easy way to figure this out. On the Wireshark start page, click on Interface List (alternatively, click on Interfaces from the Capture menu or click on the first icon on the icon bar).

The Wireshark Capture Interfaces window that opens provides a list and description of all the network interfaces on your machine, the IP address assigned to each one (if an address has been assigned), and a couple of counters, such as the total number of packets seen on the interface since this window opened and a packets/s (packets per second) counter. If an interface has an IPv6 address assigned (which may start with fe80:: and contain a number of colons) and this is being displayed, you can click on the IPv6 address and it will toggle to display the IPv4 address. This is shown in the following screenshot:

The goal is to identify the active interface that will be used to communicate with the Internet when you open a browser and navigate to a website. If you have a wired local area network connection and the interface is enabled, that's probably the active interface, but you might also have a wireless interface that is enabled and you may or may not be the primary interface. The most reliable indicator of the active network interface is that it will have greater number of steadily increasing packets with a corresponding active number of packets/s (which will vary over time). Another possible indicator is if an interface has an IP address assigned and others do not. If you're still unsure, open a browser window and navigate to one of your favorite websites and watch the packets and packets/s counters to identify the interface that shows the greatest increase in activity.

Once you've identified the correct interface, select the checkbox on the left-hand side of that interface and click on the Start button at the bottom of the Capture Interfaces window. Wireshark will start capturing all the packets that can be seen from that interface, including the packets sent to and from your workstation. You'll see a bewildering variety of packets going by in the top section (called the Packet List pane) of the screen; this is normal. If you don't see this, try a different interface.

It's a bit amazing just how much background traffic there is on a typical network, such as broadcast packets from devices advertising their names, addresses, and services to and from other devices asking for addresses of stations they want to communicate with. Also, a fair amount of traffic is generated from your own workstation for applications and services that are running in the background, and you had no idea they were creating this much noise. Your Wireshark's Packet List pane may look similar to the following screenshot; however, we can ignore all this for now:

We're ready to generate some traffic that we'll be interested in analyzing. Open a new Internet browser window, enter www.wireshark.org in the address box, and press Enter.

When the https://www.wireshark.org/ home page finishes loading, stop the Wireshark capture by either selecting Stop from the Capture menu or by clicking on the red square stop icon that's between the View and Go menu headers.

Once you have completed your first capture, you will see the normal Wireshark user interface main screen. So before we go much further, a quick introduction to the primary parts of this user interface will be helpful so you'll know what's being referred to as we continue the analysis process.

There are eight significant sections or elements of the default Wireshark user interface, as shown in the following screenshot:

Let's look at the eight significant sections in detail:

Somewhere in your packet capture, there are packets involved with loading the Wireshark home page—but how do you find and view just those packets out of all the background noise?

The simplest and most reliable method is to determine the IP address of the Wireshark website and filter out all the packets except those flowing between that IP address and the IP address of your workstation by using a display filter. The best approach—and the one that you'll likely use as a first step for most of your post-capture analysis work in future—is to investigate a list of all the conversations by IP address and/or hostnames, sorted by the most active nodes, and identify your target hostname, website name, or IP address from this list.

From the Wireshark menu, select Conversations from the Statistics menu, and in the Conversations window that opens, select the IPv4 tab at the top. You'll see a list of network conversations identified by Address A and Address B, with columns for total Packets, Bytes, Packets A→B, Bytes A→B, Packets A←B, and Bytes A←B.

Scrolling over to the right-hand side of this window, there are Relative Start values. These are the times when each particular conversation was first observed in the capture, relative to the start of the capture in seconds. The next column is Duration, which is how long this conversation persisted in the capture (first to last packet seen).

Finally, there are average data rates in bits per second (bps) in each direction for each conversation, which is the network impact for this conversation. All these are shown in the following screenshot:

We want to sort the list of conversations to get the busiest ones—called the Top Talkers in network jargon—at the top of the list. Click on the Bytes column header and then click on it again. Your list should look something like the preceding screenshot, and if you didn't get a great deal of other background traffic flowing to/from your workstation, the traffic from https://www.wireshark.org/ should have the greatest volume and therefore be at the top of the list.

In this example, the conversation between IP addresses 162.159.241.165 and 192.168.1.116 has the greatest overall volume, and looking at the Bytes A->B column, it's apparent that the majority of the traffic was from the 162.159.241.165 address to the 192.168.1.116 address. However, at this point, how do we know if this is really the conversation that we're after?

We will need to resolve the IP addresses from our list to hostnames or website addresses, and this can be done from within Wireshark by turning on Network Name Resolution and trying to get hostnames and/or website addresses resolved for those IP addresses using reverse DNS queries (using what is known as a pointer (PTR) DNS record type). If you just installed or started Wireshark, the Name Resolution option may not be turned on by default.

This is usually a good thing, as Wireshark can create traffic of its own by transmitting the DNS queries trying to resolve all the IP addresses that it comes across during the capture, and you don't really want that going on during a capture. However, the Name Resolution option can be very helpful to resolve IP addresses to proper hostnames after a capture is complete.

To enable Name Resolution, navigate to View | Name Resolution | Enable for Network Layer (click to turn on the checkmark) and make sure Use External Network Name Resolver is enabled as well. Wireshark will attempt to resolve all the IP addresses in the capture to their hostname or website address, and the resolved names will then appear (replacing the previous IP addresses) in the packet list as well as the Conversations window.

Note that the Name Resolution option at the bottom of the Conversations window must be enabled as well (it usually is by default), and this setting affects whether resolved names or IP addresses appear in the Conversations window (if Name Resolution is enabled in the Wireshark main screen), as shown in the following screenshot:

At this point, you should see the conversation pair between wireshark.org and your workstation at or near the top of the list, as shown in the following screenshot. Of course, your workstation will have a different name or may only appear as an IP address, but identifying the conversation to wireshark.org has been achieved.

Applying a display filter

You now want to see just the conversation between your workstation and wireshark.org, and get rid of all the extraneous conversations so you can focus on the traffic of interest. This is accomplished by creating a filter that only displays the desired traffic.

Right-click on the line containing the wireshark.org entry and navigate to Apply as Filter | Selected | A<->B, as shown in the following screenshot:

Wireshark will create and apply a display filter string that isolates the displayed traffic to just the conversation between the IP addresses of wireshark.org and your workstation, as shown in the following screenshot. Note that if you create or edit a display filter entry manually, you will need to click on Apply to apply the filter to the trace file (or Clear to clear it).

This particular display filter syntax works with IP addresses, not with hostnames, and uses an ip.addr== (IP address equals) syntax for each node along with the && (and) logic operator to build a string that says display any packet that contains this IP address *and* that IP address. This is the type of display filter that you will be using a great deal for packet analysis.

You'll notice as you scroll up and down in the Packet List pane that all the other packets, except those between your workstation and wireshark.org, are gone. They're not gone in the strict sense, they're just hidden—as you can observe by inspecting the Packet No. column, there are gaps in the numbering sequence; those are for the hidden packets.

Now that you've isolated the traffic of interest using a display filter, you can save a new packet trace file that contains just the filtered packets.

This serves two purposes. Firstly, you can close Wireshark, come back to it later, open the filtered trace file, and pick up where you left off in your analysis, as well as have a record of the capture in case you need to reference it later such as in a troubleshooting scenario.

Secondly, it's much easier and quicker to work in the various Wireshark screens and functions with a smaller, more focused trace file that contains just the packets that you want to analyze.

To create a new packet trace file containing just the filtered/displayed packets, select Export Specified Packets from the Wireshark File menu.

You can navigate to and/or create a folder to hold your Wireshark trace files, and then enter a filename for the trace file that you want to save. In this example, the filename is wireshark_website.pcapng. By default, Wireshark will save the trace file in the pcapng format (which is the preferred format). If you don't specify a file extension with the filename, Wireshark will provide the appropriate extension based on the Save as type selection, as shown in the following screenshot:

Also, by default, Wireshark will have the All packets option selected, and if a display filter is applied (as it is in this scenario), the Displayed option will be selected as opposed to the Captured option that saves all the packets regardless of whether a filter was applied. Having entered a filename and confirmed that all the save selections are correct, you can click on Save to save the new packet trace file.

Note that when you have finished this trace file save activity, Wireshark still has all the original packets from the capture in memory, and they can still be viewed by clicking on Clear in the Display Filter Toolbar menu. If you want to work further with the new trace file you just saved, you'll need to open it by clicking on Open in the File menu (or Open Recent in the File menu).

If you have a number of network interfaces on your machine, you may not be sure which one to select to capture packets, but there's a fairly easy way to figure this out. On the Wireshark start page, click on Interface List (alternatively, click on Interfaces from the Capture menu or click on the first icon on the icon bar).

The Wireshark Capture Interfaces window that opens provides a list and description of all the network interfaces on your machine, the IP address assigned to each one (if an address has been assigned), and a couple of counters, such as the total number of packets seen on the interface since this window opened and a packets/s (packets per second) counter. If an interface has an IPv6 address assigned (which may start with fe80:: and contain a number of colons) and this is being displayed, you can click on the IPv6 address and it will toggle to display the IPv4 address. This is shown in the following screenshot:

The goal is to identify the active interface that will be used to communicate with the Internet when you open a browser and navigate to a website. If you have a wired local area network connection and the interface is enabled, that's probably the active interface, but you might also have a wireless interface that is enabled and you may or may not be the primary interface. The most reliable indicator of the active network interface is that it will have greater number of steadily increasing packets with a corresponding active number of packets/s (which will vary over time). Another possible indicator is if an interface has an IP address assigned and others do not. If you're still unsure, open a browser window and navigate to one of your favorite websites and watch the packets and packets/s counters to identify the interface that shows the greatest increase in activity.

Once you've identified the correct interface, select the checkbox on the left-hand side of that interface and click on the Start button at the bottom of the Capture Interfaces window. Wireshark will start capturing all the packets that can be seen from that interface, including the packets sent to and from your workstation. You'll see a bewildering variety of packets going by in the top section (called the Packet List pane) of the screen; this is normal. If you don't see this, try a different interface.

It's a bit amazing just how much background traffic there is on a typical network, such as broadcast packets from devices advertising their names, addresses, and services to and from other devices asking for addresses of stations they want to communicate with. Also, a fair amount of traffic is generated from your own workstation for applications and services that are running in the background, and you had no idea they were creating this much noise. Your Wireshark's Packet List pane may look similar to the following screenshot; however, we can ignore all this for now:

We're ready to generate some traffic that we'll be interested in analyzing. Open a new Internet browser window, enter www.wireshark.org in the address box, and press Enter.

When the https://www.wireshark.org/ home page finishes loading, stop the Wireshark capture by either selecting Stop from the Capture menu or by clicking on the red square stop icon that's between the View and Go menu headers.

Once you have completed your first capture, you will see the normal Wireshark user interface main screen. So before we go much further, a quick introduction to the primary parts of this user interface will be helpful so you'll know what's being referred to as we continue the analysis process.

There are eight significant sections or elements of the default Wireshark user interface, as shown in the following screenshot:

Let's look at the eight significant sections in detail:

Somewhere in your packet capture, there are packets involved with loading the Wireshark home page—but how do you find and view just those packets out of all the background noise?

The simplest and most reliable method is to determine the IP address of the Wireshark website and filter out all the packets except those flowing between that IP address and the IP address of your workstation by using a display filter. The best approach—and the one that you'll likely use as a first step for most of your post-capture analysis work in future—is to investigate a list of all the conversations by IP address and/or hostnames, sorted by the most active nodes, and identify your target hostname, website name, or IP address from this list.

From the Wireshark menu, select Conversations from the Statistics menu, and in the Conversations window that opens, select the IPv4 tab at the top. You'll see a list of network conversations identified by Address A and Address B, with columns for total Packets, Bytes, Packets A→B, Bytes A→B, Packets A←B, and Bytes A←B.

Scrolling over to the right-hand side of this window, there are Relative Start values. These are the times when each particular conversation was first observed in the capture, relative to the start of the capture in seconds. The next column is Duration, which is how long this conversation persisted in the capture (first to last packet seen).

Finally, there are average data rates in bits per second (bps) in each direction for each conversation, which is the network impact for this conversation. All these are shown in the following screenshot:

We want to sort the list of conversations to get the busiest ones—called the Top Talkers in network jargon—at the top of the list. Click on the Bytes column header and then click on it again. Your list should look something like the preceding screenshot, and if you didn't get a great deal of other background traffic flowing to/from your workstation, the traffic from https://www.wireshark.org/ should have the greatest volume and therefore be at the top of the list.

In this example, the conversation between IP addresses 162.159.241.165 and 192.168.1.116 has the greatest overall volume, and looking at the Bytes A->B column, it's apparent that the majority of the traffic was from the 162.159.241.165 address to the 192.168.1.116 address. However, at this point, how do we know if this is really the conversation that we're after?

We will need to resolve the IP addresses from our list to hostnames or website addresses, and this can be done from within Wireshark by turning on Network Name Resolution and trying to get hostnames and/or website addresses resolved for those IP addresses using reverse DNS queries (using what is known as a pointer (PTR) DNS record type). If you just installed or started Wireshark, the Name Resolution option may not be turned on by default.

This is usually a good thing, as Wireshark can create traffic of its own by transmitting the DNS queries trying to resolve all the IP addresses that it comes across during the capture, and you don't really want that going on during a capture. However, the Name Resolution option can be very helpful to resolve IP addresses to proper hostnames after a capture is complete.

To enable Name Resolution, navigate to View | Name Resolution | Enable for Network Layer (click to turn on the checkmark) and make sure Use External Network Name Resolver is enabled as well. Wireshark will attempt to resolve all the IP addresses in the capture to their hostname or website address, and the resolved names will then appear (replacing the previous IP addresses) in the packet list as well as the Conversations window.

Note that the Name Resolution option at the bottom of the Conversations window must be enabled as well (it usually is by default), and this setting affects whether resolved names or IP addresses appear in the Conversations window (if Name Resolution is enabled in the Wireshark main screen), as shown in the following screenshot:

At this point, you should see the conversation pair between wireshark.org and your workstation at or near the top of the list, as shown in the following screenshot. Of course, your workstation will have a different name or may only appear as an IP address, but identifying the conversation to wireshark.org has been achieved.

Applying a display filter

You now want to see just the conversation between your workstation and wireshark.org, and get rid of all the extraneous conversations so you can focus on the traffic of interest. This is accomplished by creating a filter that only displays the desired traffic.

Right-click on the line containing the wireshark.org entry and navigate to Apply as Filter | Selected | A<->B, as shown in the following screenshot:

Wireshark will create and apply a display filter string that isolates the displayed traffic to just the conversation between the IP addresses of wireshark.org and your workstation, as shown in the following screenshot. Note that if you create or edit a display filter entry manually, you will need to click on Apply to apply the filter to the trace file (or Clear to clear it).

This particular display filter syntax works with IP addresses, not with hostnames, and uses an ip.addr== (IP address equals) syntax for each node along with the && (and) logic operator to build a string that says display any packet that contains this IP address *and* that IP address. This is the type of display filter that you will be using a great deal for packet analysis.

You'll notice as you scroll up and down in the Packet List pane that all the other packets, except those between your workstation and wireshark.org, are gone. They're not gone in the strict sense, they're just hidden—as you can observe by inspecting the Packet No. column, there are gaps in the numbering sequence; those are for the hidden packets.

Now that you've isolated the traffic of interest using a display filter, you can save a new packet trace file that contains just the filtered packets.

This serves two purposes. Firstly, you can close Wireshark, come back to it later, open the filtered trace file, and pick up where you left off in your analysis, as well as have a record of the capture in case you need to reference it later such as in a troubleshooting scenario.

Secondly, it's much easier and quicker to work in the various Wireshark screens and functions with a smaller, more focused trace file that contains just the packets that you want to analyze.

To create a new packet trace file containing just the filtered/displayed packets, select Export Specified Packets from the Wireshark File menu.

You can navigate to and/or create a folder to hold your Wireshark trace files, and then enter a filename for the trace file that you want to save. In this example, the filename is wireshark_website.pcapng. By default, Wireshark will save the trace file in the pcapng format (which is the preferred format). If you don't specify a file extension with the filename, Wireshark will provide the appropriate extension based on the Save as type selection, as shown in the following screenshot:

Also, by default, Wireshark will have the All packets option selected, and if a display filter is applied (as it is in this scenario), the Displayed option will be selected as opposed to the Captured option that saves all the packets regardless of whether a filter was applied. Having entered a filename and confirmed that all the save selections are correct, you can click on Save to save the new packet trace file.

Note that when you have finished this trace file save activity, Wireshark still has all the original packets from the capture in memory, and they can still be viewed by clicking on Clear in the Display Filter Toolbar menu. If you want to work further with the new trace file you just saved, you'll need to open it by clicking on Open in the File menu (or Open Recent in the File menu).

Once you've identified the correct interface, select the checkbox on the left-hand side of that interface and click on the Start button at the bottom of the Capture Interfaces window. Wireshark will start capturing all the packets that can be seen from that interface, including the packets sent to and from your workstation. You'll see a bewildering variety of packets going by in the top section (called the Packet List pane) of the screen; this is normal. If you don't see this, try a different interface.

It's a bit amazing just how much background traffic there is on a typical network, such as broadcast packets from devices advertising their names, addresses, and services to and from other devices asking for addresses of stations they want to communicate with. Also, a fair amount of traffic is generated from your own workstation for applications and services that are running in the background, and you had no idea they were creating this much noise. Your Wireshark's Packet List pane may look similar to the following screenshot; however, we can ignore all this for now:

We're ready to generate some traffic that we'll be interested in analyzing. Open a new Internet browser window, enter www.wireshark.org in the address box, and press Enter.

When the https://www.wireshark.org/ home page finishes loading, stop the Wireshark capture by either selecting Stop from the Capture menu or by clicking on the red square stop icon that's between the View and Go menu headers.

Once you have completed your first capture, you will see the normal Wireshark user interface main screen. So before we go much further, a quick introduction to the primary parts of this user interface will be helpful so you'll know what's being referred to as we continue the analysis process.

There are eight significant sections or elements of the default Wireshark user interface, as shown in the following screenshot:

Let's look at the eight significant sections in detail:

Somewhere in your packet capture, there are packets involved with loading the Wireshark home page—but how do you find and view just those packets out of all the background noise?

The simplest and most reliable method is to determine the IP address of the Wireshark website and filter out all the packets except those flowing between that IP address and the IP address of your workstation by using a display filter. The best approach—and the one that you'll likely use as a first step for most of your post-capture analysis work in future—is to investigate a list of all the conversations by IP address and/or hostnames, sorted by the most active nodes, and identify your target hostname, website name, or IP address from this list.

From the Wireshark menu, select Conversations from the Statistics menu, and in the Conversations window that opens, select the IPv4 tab at the top. You'll see a list of network conversations identified by Address A and Address B, with columns for total Packets, Bytes, Packets A→B, Bytes A→B, Packets A←B, and Bytes A←B.

Scrolling over to the right-hand side of this window, there are Relative Start values. These are the times when each particular conversation was first observed in the capture, relative to the start of the capture in seconds. The next column is Duration, which is how long this conversation persisted in the capture (first to last packet seen).

Finally, there are average data rates in bits per second (bps) in each direction for each conversation, which is the network impact for this conversation. All these are shown in the following screenshot:

We want to sort the list of conversations to get the busiest ones—called the Top Talkers in network jargon—at the top of the list. Click on the Bytes column header and then click on it again. Your list should look something like the preceding screenshot, and if you didn't get a great deal of other background traffic flowing to/from your workstation, the traffic from https://www.wireshark.org/ should have the greatest volume and therefore be at the top of the list.

In this example, the conversation between IP addresses 162.159.241.165 and 192.168.1.116 has the greatest overall volume, and looking at the Bytes A->B column, it's apparent that the majority of the traffic was from the 162.159.241.165 address to the 192.168.1.116 address. However, at this point, how do we know if this is really the conversation that we're after?

We will need to resolve the IP addresses from our list to hostnames or website addresses, and this can be done from within Wireshark by turning on Network Name Resolution and trying to get hostnames and/or website addresses resolved for those IP addresses using reverse DNS queries (using what is known as a pointer (PTR) DNS record type). If you just installed or started Wireshark, the Name Resolution option may not be turned on by default.

This is usually a good thing, as Wireshark can create traffic of its own by transmitting the DNS queries trying to resolve all the IP addresses that it comes across during the capture, and you don't really want that going on during a capture. However, the Name Resolution option can be very helpful to resolve IP addresses to proper hostnames after a capture is complete.

To enable Name Resolution, navigate to View | Name Resolution | Enable for Network Layer (click to turn on the checkmark) and make sure Use External Network Name Resolver is enabled as well. Wireshark will attempt to resolve all the IP addresses in the capture to their hostname or website address, and the resolved names will then appear (replacing the previous IP addresses) in the packet list as well as the Conversations window.

Note that the Name Resolution option at the bottom of the Conversations window must be enabled as well (it usually is by default), and this setting affects whether resolved names or IP addresses appear in the Conversations window (if Name Resolution is enabled in the Wireshark main screen), as shown in the following screenshot:

At this point, you should see the conversation pair between wireshark.org and your workstation at or near the top of the list, as shown in the following screenshot. Of course, your workstation will have a different name or may only appear as an IP address, but identifying the conversation to wireshark.org has been achieved.

Applying a display filter

You now want to see just the conversation between your workstation and wireshark.org, and get rid of all the extraneous conversations so you can focus on the traffic of interest. This is accomplished by creating a filter that only displays the desired traffic.

Right-click on the line containing the wireshark.org entry and navigate to Apply as Filter | Selected | A<->B, as shown in the following screenshot:

Wireshark will create and apply a display filter string that isolates the displayed traffic to just the conversation between the IP addresses of wireshark.org and your workstation, as shown in the following screenshot. Note that if you create or edit a display filter entry manually, you will need to click on Apply to apply the filter to the trace file (or Clear to clear it).

This particular display filter syntax works with IP addresses, not with hostnames, and uses an ip.addr== (IP address equals) syntax for each node along with the && (and) logic operator to build a string that says display any packet that contains this IP address *and* that IP address. This is the type of display filter that you will be using a great deal for packet analysis.

You'll notice as you scroll up and down in the Packet List pane that all the other packets, except those between your workstation and wireshark.org, are gone. They're not gone in the strict sense, they're just hidden—as you can observe by inspecting the Packet No. column, there are gaps in the numbering sequence; those are for the hidden packets.

Now that you've isolated the traffic of interest using a display filter, you can save a new packet trace file that contains just the filtered packets.

This serves two purposes. Firstly, you can close Wireshark, come back to it later, open the filtered trace file, and pick up where you left off in your analysis, as well as have a record of the capture in case you need to reference it later such as in a troubleshooting scenario.

Secondly, it's much easier and quicker to work in the various Wireshark screens and functions with a smaller, more focused trace file that contains just the packets that you want to analyze.

To create a new packet trace file containing just the filtered/displayed packets, select Export Specified Packets from the Wireshark File menu.

You can navigate to and/or create a folder to hold your Wireshark trace files, and then enter a filename for the trace file that you want to save. In this example, the filename is wireshark_website.pcapng. By default, Wireshark will save the trace file in the pcapng format (which is the preferred format). If you don't specify a file extension with the filename, Wireshark will provide the appropriate extension based on the Save as type selection, as shown in the following screenshot:

Also, by default, Wireshark will have the All packets option selected, and if a display filter is applied (as it is in this scenario), the Displayed option will be selected as opposed to the Captured option that saves all the packets regardless of whether a filter was applied. Having entered a filename and confirmed that all the save selections are correct, you can click on Save to save the new packet trace file.

Note that when you have finished this trace file save activity, Wireshark still has all the original packets from the capture in memory, and they can still be viewed by clicking on Clear in the Display Filter Toolbar menu. If you want to work further with the new trace file you just saved, you'll need to open it by clicking on Open in the File menu (or Open Recent in the File menu).

Once you have completed your first capture, you will see the normal Wireshark user interface main screen. So before we go much further, a quick introduction to the primary parts of this user interface will be helpful so you'll know what's being referred to as we continue the analysis process.

There are eight significant sections or elements of the default Wireshark user interface, as shown in the following screenshot:

Let's look at the eight significant sections in detail:

Somewhere in your packet capture, there are packets involved with loading the Wireshark home page—but how do you find and view just those packets out of all the background noise?

The simplest and most reliable method is to determine the IP address of the Wireshark website and filter out all the packets except those flowing between that IP address and the IP address of your workstation by using a display filter. The best approach—and the one that you'll likely use as a first step for most of your post-capture analysis work in future—is to investigate a list of all the conversations by IP address and/or hostnames, sorted by the most active nodes, and identify your target hostname, website name, or IP address from this list.

From the Wireshark menu, select Conversations from the Statistics menu, and in the Conversations window that opens, select the IPv4 tab at the top. You'll see a list of network conversations identified by Address A and Address B, with columns for total Packets, Bytes, Packets A→B, Bytes A→B, Packets A←B, and Bytes A←B.

Scrolling over to the right-hand side of this window, there are Relative Start values. These are the times when each particular conversation was first observed in the capture, relative to the start of the capture in seconds. The next column is Duration, which is how long this conversation persisted in the capture (first to last packet seen).

Finally, there are average data rates in bits per second (bps) in each direction for each conversation, which is the network impact for this conversation. All these are shown in the following screenshot:

We want to sort the list of conversations to get the busiest ones—called the Top Talkers in network jargon—at the top of the list. Click on the Bytes column header and then click on it again. Your list should look something like the preceding screenshot, and if you didn't get a great deal of other background traffic flowing to/from your workstation, the traffic from https://www.wireshark.org/ should have the greatest volume and therefore be at the top of the list.

In this example, the conversation between IP addresses 162.159.241.165 and 192.168.1.116 has the greatest overall volume, and looking at the Bytes A->B column, it's apparent that the majority of the traffic was from the 162.159.241.165 address to the 192.168.1.116 address. However, at this point, how do we know if this is really the conversation that we're after?

We will need to resolve the IP addresses from our list to hostnames or website addresses, and this can be done from within Wireshark by turning on Network Name Resolution and trying to get hostnames and/or website addresses resolved for those IP addresses using reverse DNS queries (using what is known as a pointer (PTR) DNS record type). If you just installed or started Wireshark, the Name Resolution option may not be turned on by default.

This is usually a good thing, as Wireshark can create traffic of its own by transmitting the DNS queries trying to resolve all the IP addresses that it comes across during the capture, and you don't really want that going on during a capture. However, the Name Resolution option can be very helpful to resolve IP addresses to proper hostnames after a capture is complete.

To enable Name Resolution, navigate to View | Name Resolution | Enable for Network Layer (click to turn on the checkmark) and make sure Use External Network Name Resolver is enabled as well. Wireshark will attempt to resolve all the IP addresses in the capture to their hostname or website address, and the resolved names will then appear (replacing the previous IP addresses) in the packet list as well as the Conversations window.

Note that the Name Resolution option at the bottom of the Conversations window must be enabled as well (it usually is by default), and this setting affects whether resolved names or IP addresses appear in the Conversations window (if Name Resolution is enabled in the Wireshark main screen), as shown in the following screenshot:

At this point, you should see the conversation pair between wireshark.org and your workstation at or near the top of the list, as shown in the following screenshot. Of course, your workstation will have a different name or may only appear as an IP address, but identifying the conversation to wireshark.org has been achieved.

Applying a display filter

You now want to see just the conversation between your workstation and wireshark.org, and get rid of all the extraneous conversations so you can focus on the traffic of interest. This is accomplished by creating a filter that only displays the desired traffic.

Right-click on the line containing the wireshark.org entry and navigate to Apply as Filter | Selected | A<->B, as shown in the following screenshot:

Wireshark will create and apply a display filter string that isolates the displayed traffic to just the conversation between the IP addresses of wireshark.org and your workstation, as shown in the following screenshot. Note that if you create or edit a display filter entry manually, you will need to click on Apply to apply the filter to the trace file (or Clear to clear it).

This particular display filter syntax works with IP addresses, not with hostnames, and uses an ip.addr== (IP address equals) syntax for each node along with the && (and) logic operator to build a string that says display any packet that contains this IP address *and* that IP address. This is the type of display filter that you will be using a great deal for packet analysis.

You'll notice as you scroll up and down in the Packet List pane that all the other packets, except those between your workstation and wireshark.org, are gone. They're not gone in the strict sense, they're just hidden—as you can observe by inspecting the Packet No. column, there are gaps in the numbering sequence; those are for the hidden packets.

Now that you've isolated the traffic of interest using a display filter, you can save a new packet trace file that contains just the filtered packets.

This serves two purposes. Firstly, you can close Wireshark, come back to it later, open the filtered trace file, and pick up where you left off in your analysis, as well as have a record of the capture in case you need to reference it later such as in a troubleshooting scenario.

Secondly, it's much easier and quicker to work in the various Wireshark screens and functions with a smaller, more focused trace file that contains just the packets that you want to analyze.

To create a new packet trace file containing just the filtered/displayed packets, select Export Specified Packets from the Wireshark File menu.

You can navigate to and/or create a folder to hold your Wireshark trace files, and then enter a filename for the trace file that you want to save. In this example, the filename is wireshark_website.pcapng. By default, Wireshark will save the trace file in the pcapng format (which is the preferred format). If you don't specify a file extension with the filename, Wireshark will provide the appropriate extension based on the Save as type selection, as shown in the following screenshot:

Also, by default, Wireshark will have the All packets option selected, and if a display filter is applied (as it is in this scenario), the Displayed option will be selected as opposed to the Captured option that saves all the packets regardless of whether a filter was applied. Having entered a filename and confirmed that all the save selections are correct, you can click on Save to save the new packet trace file.

Note that when you have finished this trace file save activity, Wireshark still has all the original packets from the capture in memory, and they can still be viewed by clicking on Clear in the Display Filter Toolbar menu. If you want to work further with the new trace file you just saved, you'll need to open it by clicking on Open in the File menu (or Open Recent in the File menu).

Somewhere in your packet capture, there are packets involved with loading the Wireshark home page—but how do you find and view just those packets out of all the background noise?

The simplest and most reliable method is to determine the IP address of the Wireshark website and filter out all the packets except those flowing between that IP address and the IP address of your workstation by using a display filter. The best approach—and the one that you'll likely use as a first step for most of your post-capture analysis work in future—is to investigate a list of all the conversations by IP address and/or hostnames, sorted by the most active nodes, and identify your target hostname, website name, or IP address from this list.

From the Wireshark menu, select Conversations from the Statistics menu, and in the Conversations window that opens, select the IPv4 tab at the top. You'll see a list of network conversations identified by Address A and Address B, with columns for total Packets, Bytes, Packets A→B, Bytes A→B, Packets A←B, and Bytes A←B.

Scrolling over to the right-hand side of this window, there are Relative Start values. These are the times when each particular conversation was first observed in the capture, relative to the start of the capture in seconds. The next column is Duration, which is how long this conversation persisted in the capture (first to last packet seen).

Finally, there are average data rates in bits per second (bps) in each direction for each conversation, which is the network impact for this conversation. All these are shown in the following screenshot:

We want to sort the list of conversations to get the busiest ones—called the Top Talkers in network jargon—at the top of the list. Click on the Bytes column header and then click on it again. Your list should look something like the preceding screenshot, and if you didn't get a great deal of other background traffic flowing to/from your workstation, the traffic from https://www.wireshark.org/ should have the greatest volume and therefore be at the top of the list.

In this example, the conversation between IP addresses 162.159.241.165 and 192.168.1.116 has the greatest overall volume, and looking at the Bytes A->B column, it's apparent that the majority of the traffic was from the 162.159.241.165 address to the 192.168.1.116 address. However, at this point, how do we know if this is really the conversation that we're after?

We will need to resolve the IP addresses from our list to hostnames or website addresses, and this can be done from within Wireshark by turning on Network Name Resolution and trying to get hostnames and/or website addresses resolved for those IP addresses using reverse DNS queries (using what is known as a pointer (PTR) DNS record type). If you just installed or started Wireshark, the Name Resolution option may not be turned on by default.

This is usually a good thing, as Wireshark can create traffic of its own by transmitting the DNS queries trying to resolve all the IP addresses that it comes across during the capture, and you don't really want that going on during a capture. However, the Name Resolution option can be very helpful to resolve IP addresses to proper hostnames after a capture is complete.

To enable Name Resolution, navigate to View | Name Resolution | Enable for Network Layer (click to turn on the checkmark) and make sure Use External Network Name Resolver is enabled as well. Wireshark will attempt to resolve all the IP addresses in the capture to their hostname or website address, and the resolved names will then appear (replacing the previous IP addresses) in the packet list as well as the Conversations window.

Note that the Name Resolution option at the bottom of the Conversations window must be enabled as well (it usually is by default), and this setting affects whether resolved names or IP addresses appear in the Conversations window (if Name Resolution is enabled in the Wireshark main screen), as shown in the following screenshot:

At this point, you should see the conversation pair between wireshark.org and your workstation at or near the top of the list, as shown in the following screenshot. Of course, your workstation will have a different name or may only appear as an IP address, but identifying the conversation to wireshark.org has been achieved.

Applying a display filter

You now want to see just the conversation between your workstation and wireshark.org, and get rid of all the extraneous conversations so you can focus on the traffic of interest. This is accomplished by creating a filter that only displays the desired traffic.

Right-click on the line containing the wireshark.org entry and navigate to Apply as Filter | Selected | A<->B, as shown in the following screenshot:

Wireshark will create and apply a display filter string that isolates the displayed traffic to just the conversation between the IP addresses of wireshark.org and your workstation, as shown in the following screenshot. Note that if you create or edit a display filter entry manually, you will need to click on Apply to apply the filter to the trace file (or Clear to clear it).

This particular display filter syntax works with IP addresses, not with hostnames, and uses an ip.addr== (IP address equals) syntax for each node along with the && (and) logic operator to build a string that says display any packet that contains this IP address *and* that IP address. This is the type of display filter that you will be using a great deal for packet analysis.

You'll notice as you scroll up and down in the Packet List pane that all the other packets, except those between your workstation and wireshark.org, are gone. They're not gone in the strict sense, they're just hidden—as you can observe by inspecting the Packet No. column, there are gaps in the numbering sequence; those are for the hidden packets.

Now that you've isolated the traffic of interest using a display filter, you can save a new packet trace file that contains just the filtered packets.

This serves two purposes. Firstly, you can close Wireshark, come back to it later, open the filtered trace file, and pick up where you left off in your analysis, as well as have a record of the capture in case you need to reference it later such as in a troubleshooting scenario.

Secondly, it's much easier and quicker to work in the various Wireshark screens and functions with a smaller, more focused trace file that contains just the packets that you want to analyze.

To create a new packet trace file containing just the filtered/displayed packets, select Export Specified Packets from the Wireshark File menu.

You can navigate to and/or create a folder to hold your Wireshark trace files, and then enter a filename for the trace file that you want to save. In this example, the filename is wireshark_website.pcapng. By default, Wireshark will save the trace file in the pcapng format (which is the preferred format). If you don't specify a file extension with the filename, Wireshark will provide the appropriate extension based on the Save as type selection, as shown in the following screenshot:

Also, by default, Wireshark will have the All packets option selected, and if a display filter is applied (as it is in this scenario), the Displayed option will be selected as opposed to the Captured option that saves all the packets regardless of whether a filter was applied. Having entered a filename and confirmed that all the save selections are correct, you can click on Save to save the new packet trace file.

Note that when you have finished this trace file save activity, Wireshark still has all the original packets from the capture in memory, and they can still be viewed by clicking on Clear in the Display Filter Toolbar menu. If you want to work further with the new trace file you just saved, you'll need to open it by clicking on Open in the File menu (or Open Recent in the File menu).

Now that you've isolated the traffic of interest using a display filter, you can save a new packet trace file that contains just the filtered packets.

This serves two purposes. Firstly, you can close Wireshark, come back to it later, open the filtered trace file, and pick up where you left off in your analysis, as well as have a record of the capture in case you need to reference it later such as in a troubleshooting scenario.

Secondly, it's much easier and quicker to work in the various Wireshark screens and functions with a smaller, more focused trace file that contains just the packets that you want to analyze.

To create a new packet trace file containing just the filtered/displayed packets, select Export Specified Packets from the Wireshark File menu.

You can navigate to and/or create a folder to hold your Wireshark trace files, and then enter a filename for the trace file that you want to save. In this example, the filename is wireshark_website.pcapng. By default, Wireshark will save the trace file in the pcapng format (which is the preferred format). If you don't specify a file extension with the filename, Wireshark will provide the appropriate extension based on the Save as type selection, as shown in the following screenshot:

Also, by default, Wireshark will have the All packets option selected, and if a display filter is applied (as it is in this scenario), the Displayed option will be selected as opposed to the Captured option that saves all the packets regardless of whether a filter was applied. Having entered a filename and confirmed that all the save selections are correct, you can click on Save to save the new packet trace file.

Note that when you have finished this trace file save activity, Wireshark still has all the original packets from the capture in memory, and they can still be viewed by clicking on Clear in the Display Filter Toolbar menu. If you want to work further with the new trace file you just saved, you'll need to open it by clicking on Open in the File menu (or Open Recent in the File menu).

Now that you've isolated the traffic of interest using a display filter, you can save a new packet trace file that contains just the filtered packets.

This serves two purposes. Firstly, you can close Wireshark, come back to it later, open the filtered trace file, and pick up where you left off in your analysis, as well as have a record of the capture in case you need to reference it later such as in a troubleshooting scenario.

Secondly, it's much easier and quicker to work in the various Wireshark screens and functions with a smaller, more focused trace file that contains just the packets that you want to analyze.

To create a new packet trace file containing just the filtered/displayed packets, select Export Specified Packets from the Wireshark File menu.

You can navigate to and/or create a folder to hold your Wireshark trace files, and then enter a filename for the trace file that you want to save. In this example, the filename is wireshark_website.pcapng. By default, Wireshark will save the trace file in the pcapng format (which is the preferred format). If you don't specify a file extension with the filename, Wireshark will provide the appropriate extension based on the Save as type selection, as shown in the following screenshot:

Also, by default, Wireshark will have the All packets option selected, and if a display filter is applied (as it is in this scenario), the Displayed option will be selected as opposed to the Captured option that saves all the packets regardless of whether a filter was applied. Having entered a filename and confirmed that all the save selections are correct, you can click on Save to save the new packet trace file.

Note that when you have finished this trace file save activity, Wireshark still has all the original packets from the capture in memory, and they can still be viewed by clicking on Clear in the Display Filter Toolbar menu. If you want to work further with the new trace file you just saved, you'll need to open it by clicking on Open in the File menu (or Open Recent in the File menu).

To reiterate what was outlined in the layer 2 (the data-link layer) discussion, Ethernet frames are switched from the entry port to the appropriate destination port based on the destination MAC address. Network switches build tables of which MAC addresses belong to each port, compare a frame's destination MAC address to these tables, and switch the frame to the appropriate egress port if the destination is on the same switch or out a trunk port to another switch or router otherwise.

Note that the first time a switch sees a destination MAC address it doesn't recognize, it sends the packet (which will usually be an ARP packet) out all the ports until a device answers and it can add the new MAC address to its content addressable memory (CAM) table that maps MAC addresses to specific ports.

Frames carrying packets destined for remote networks are sent to the default gateway port MAC address. If you look at a list of MAC addresses in the Ethernet tab of a Conversations table in Wireshark and see an address with a drastically higher volume of traffic than the other stations, this is likely a default gateway (router) port MAC address. This port is the pathway into/out of this LAN from/to other networks.

On any given LAN, you'll see workstations, servers, and routers generating ARP and Domain Name Service (DNS) requests:

In the following diagram, there are two user workstations and a server that are connected together in a LAN residing on the 10.1.1.0/24 IP network. A router is attached to this network, which has a WAN link to another location.

The following two scenarios leverage this drawing to show how MAC addresses are utilized to switch Ethernet frames around local area networks:

When packets need to leave the LAN to get to a remote IP network, routers are required to route the packets based on their destination IP addresses. The following scenario (still referring to the preceding screenshot) illustrates some of the details involved in one possible situation.

Workstation A now wants to use an application on the server Mars, which resides on a different network than in the previous scenarios. And in this case, workstation A doesn't know the IP address of the server; it only needs its name. Workstation A will send a DNS request packet to the DNS server IP address configured in its network settings (the DNS server isn't shown here) with the hostname Mars; the DNS server will return the IP address of Mars 10.1.2.25. Workstation A calculates that this host isn't on its own network from a comparison of its IP address and subnet mask with Mars' IP address, so it sends the session initiation packet to router 1, which was configured as its default gateway in its network settings. We'll assume that Workstation A already knows the MAC address of router 1's port from a previous ARP exchange to find router 1's MAC address from the given IP address.

When the router receives A's frame, which was sent to the router port's MAC address, it inspects the destination IP address inside the IP header and looks up the appropriate port to forward the packet to. This routing process is supported by routing table entries the router builds from route information broadcasted by other routers; each router tells all the others what networks it knows a route to.

In this case, the Ethernet frame surrounding A's packet is stripped off and the remaining payload (packet) is sent across the WAN link to router 2, which also inspects the IP header destination IP address and looks up the correct port to forward the packet to. Router 2 wraps the packet in a new Ethernet frame with its own MAC address X as the source and the Mars server's Y address as the destination MAC (assuming the router already has the server in its MAC table), and transmits the packet out onto the LAN to get switched to the Mars server, as shown in the following diagram:

To reiterate what was outlined in the layer 2 (the data-link layer) discussion, Ethernet frames are switched from the entry port to the appropriate destination port based on the destination MAC address. Network switches build tables of which MAC addresses belong to each port, compare a frame's destination MAC address to these tables, and switch the frame to the appropriate egress port if the destination is on the same switch or out a trunk port to another switch or router otherwise.

Note that the first time a switch sees a destination MAC address it doesn't recognize, it sends the packet (which will usually be an ARP packet) out all the ports until a device answers and it can add the new MAC address to its content addressable memory (CAM) table that maps MAC addresses to specific ports.

Frames carrying packets destined for remote networks are sent to the default gateway port MAC address. If you look at a list of MAC addresses in the Ethernet tab of a Conversations table in Wireshark and see an address with a drastically higher volume of traffic than the other stations, this is likely a default gateway (router) port MAC address. This port is the pathway into/out of this LAN from/to other networks.

On any given LAN, you'll see workstations, servers, and routers generating ARP and Domain Name Service (DNS) requests:

In the following diagram, there are two user workstations and a server that are connected together in a LAN residing on the 10.1.1.0/24 IP network. A router is attached to this network, which has a WAN link to another location.

The following two scenarios leverage this drawing to show how MAC addresses are utilized to switch Ethernet frames around local area networks:

When packets need to leave the LAN to get to a remote IP network, routers are required to route the packets based on their destination IP addresses. The following scenario (still referring to the preceding screenshot) illustrates some of the details involved in one possible situation.

Workstation A now wants to use an application on the server Mars, which resides on a different network than in the previous scenarios. And in this case, workstation A doesn't know the IP address of the server; it only needs its name. Workstation A will send a DNS request packet to the DNS server IP address configured in its network settings (the DNS server isn't shown here) with the hostname Mars; the DNS server will return the IP address of Mars 10.1.2.25. Workstation A calculates that this host isn't on its own network from a comparison of its IP address and subnet mask with Mars' IP address, so it sends the session initiation packet to router 1, which was configured as its default gateway in its network settings. We'll assume that Workstation A already knows the MAC address of router 1's port from a previous ARP exchange to find router 1's MAC address from the given IP address.

When the router receives A's frame, which was sent to the router port's MAC address, it inspects the destination IP address inside the IP header and looks up the appropriate port to forward the packet to. This routing process is supported by routing table entries the router builds from route information broadcasted by other routers; each router tells all the others what networks it knows a route to.

In this case, the Ethernet frame surrounding A's packet is stripped off and the remaining payload (packet) is sent across the WAN link to router 2, which also inspects the IP header destination IP address and looks up the correct port to forward the packet to. Router 2 wraps the packet in a new Ethernet frame with its own MAC address X as the source and the Mars server's Y address as the destination MAC (assuming the router already has the server in its MAC table), and transmits the packet out onto the LAN to get switched to the Mars server, as shown in the following diagram:

When packets need to leave the LAN to get to a remote IP network, routers are required to route the packets based on their destination IP addresses. The following scenario (still referring to the preceding screenshot) illustrates some of the details involved in one possible situation.

Workstation A now wants to use an application on the server Mars, which resides on a different network than in the previous scenarios. And in this case, workstation A doesn't know the IP address of the server; it only needs its name. Workstation A will send a DNS request packet to the DNS server IP address configured in its network settings (the DNS server isn't shown here) with the hostname Mars; the DNS server will return the IP address of Mars 10.1.2.25. Workstation A calculates that this host isn't on its own network from a comparison of its IP address and subnet mask with Mars' IP address, so it sends the session initiation packet to router 1, which was configured as its default gateway in its network settings. We'll assume that Workstation A already knows the MAC address of router 1's port from a previous ARP exchange to find router 1's MAC address from the given IP address.

When the router receives A's frame, which was sent to the router port's MAC address, it inspects the destination IP address inside the IP header and looks up the appropriate port to forward the packet to. This routing process is supported by routing table entries the router builds from route information broadcasted by other routers; each router tells all the others what networks it knows a route to.

In this case, the Ethernet frame surrounding A's packet is stripped off and the remaining payload (packet) is sent across the WAN link to router 2, which also inspects the IP header destination IP address and looks up the correct port to forward the packet to. Router 2 wraps the packet in a new Ethernet frame with its own MAC address X as the source and the Mars server's Y address as the destination MAC (assuming the router already has the server in its MAC table), and transmits the packet out onto the LAN to get switched to the Mars server, as shown in the following diagram:

A Test Access Port (TAP) is a device that copies all the packets flowing through it to one or more monitor ports. A station with Wireshark installed on it can be connected to one of the monitor ports to capture the packets.

You should select an aggregating TAP that supports the link speed of the network ports being analyzed (usually 100 Mbps or 1 Gbps) and that will copy and combine the packets flowing in both directions (transmit data from the user's workstation and receive data from the network); the aggregating TAP funnels the traffic to a single connection (transmit to the Wireshark station) so that you can capture the traffic in both directions with a single network interface on the Wireshark station. Be aware that since you're copying packets from two directions into one pipe to the Wireshark station, it is possible to oversubscribe the monitor port if traffic rates are extremely high. If this happens, the excess packets will be dropped. Oversubscription usually isn't a concern at user workstations, but it could be for switch trunks or other high traffic areas.

The following figure illustrates how a TAP is inserted between a user workstation and that workstation's switch port, and how a Wireshark workstation is attached to capture packets:

Switch port mirroring, also known as a Switched Port Analyzer (SPAN) feature or spanning a port, is the practice of configuring a network switch to perform the same function as a TAP: to make a copy of the packets flowing in and out of a specified port and send them to an otherwise unused monitor port where a Wireshark station is attached to capture the packets.

The advantage of using port mirroring is that no connections need to be broken to insert a TAP. The monitor port can be easily configured by a switch administrator and just as easily disabled.

The potential issues with this option include the fact that not all switches support port mirroring, and there is some evidence to suggest that using this feature can affect the performance of the switch, at least for the port being monitored. The possibility of oversubscribing the monitor port from excessive transmit plus receiving traffic levels also exists for port mirroring, as is the case when using a TAP, and this is likely when monitoring switch trunks to other switches, as these will be carrying traffic for multiple users.

The following diagram is a simple illustration of a port mirroring scenario on a switch. The packets to and from the workstation port are copied to the port where the Wireshark station is connected.

A Test Access Port (TAP) is a device that copies all the packets flowing through it to one or more monitor ports. A station with Wireshark installed on it can be connected to one of the monitor ports to capture the packets.

You should select an aggregating TAP that supports the link speed of the network ports being analyzed (usually 100 Mbps or 1 Gbps) and that will copy and combine the packets flowing in both directions (transmit data from the user's workstation and receive data from the network); the aggregating TAP funnels the traffic to a single connection (transmit to the Wireshark station) so that you can capture the traffic in both directions with a single network interface on the Wireshark station. Be aware that since you're copying packets from two directions into one pipe to the Wireshark station, it is possible to oversubscribe the monitor port if traffic rates are extremely high. If this happens, the excess packets will be dropped. Oversubscription usually isn't a concern at user workstations, but it could be for switch trunks or other high traffic areas.

The following figure illustrates how a TAP is inserted between a user workstation and that workstation's switch port, and how a Wireshark workstation is attached to capture packets:

Switch port mirroring, also known as a Switched Port Analyzer (SPAN) feature or spanning a port, is the practice of configuring a network switch to perform the same function as a TAP: to make a copy of the packets flowing in and out of a specified port and send them to an otherwise unused monitor port where a Wireshark station is attached to capture the packets.

The advantage of using port mirroring is that no connections need to be broken to insert a TAP. The monitor port can be easily configured by a switch administrator and just as easily disabled.

The potential issues with this option include the fact that not all switches support port mirroring, and there is some evidence to suggest that using this feature can affect the performance of the switch, at least for the port being monitored. The possibility of oversubscribing the monitor port from excessive transmit plus receiving traffic levels also exists for port mirroring, as is the case when using a TAP, and this is likely when monitoring switch trunks to other switches, as these will be carrying traffic for multiple users.

The following diagram is a simple illustration of a port mirroring scenario on a switch. The packets to and from the workstation port are copied to the port where the Wireshark station is connected.

Switch port mirroring, also known as a Switched Port Analyzer (SPAN) feature or spanning a port, is the practice of configuring a network switch to perform the same function as a TAP: to make a copy of the packets flowing in and out of a specified port and send them to an otherwise unused monitor port where a Wireshark station is attached to capture the packets.

The advantage of using port mirroring is that no connections need to be broken to insert a TAP. The monitor port can be easily configured by a switch administrator and just as easily disabled.

The potential issues with this option include the fact that not all switches support port mirroring, and there is some evidence to suggest that using this feature can affect the performance of the switch, at least for the port being monitored. The possibility of oversubscribing the monitor port from excessive transmit plus receiving traffic levels also exists for port mirroring, as is the case when using a TAP, and this is likely when monitoring switch trunks to other switches, as these will be carrying traffic for multiple users.

The following diagram is a simple illustration of a port mirroring scenario on a switch. The packets to and from the workstation port are copied to the port where the Wireshark station is connected.

As discussed in Chapter 1, Getting Acquainted with Wireshark, if you have multiple network interfaces on your machine, you need to determine and select the correct interface to capture packets. In Wireshark's Capture menu, click on Interface or click on the first icon on the icon bar.

The Wireshark Capture Interfaces window provides a list and description of the network interfaces on your machine, the IP addresses assigned, and the total packets and packets per second counters for each interface. If an interface has an IPv6 address assigned and this is being displayed, you can click on the address to toggle and display the IPv4 address.

The following screenshot illustrates a typical Capture Interfaces window listing a LAN and wireless interface along with their IP addresses and packet counters:

The Capture Interfaces window provides the following two options:

The following screenshot illustrates a typical Capture Options window with a number of options specified. You can refer to it for examples of the topics on Capture Options.

As seen in the preceding screenshot, the Capture Options window displays the available interfaces and their IP addresses and allows you to select one or more of these interfaces to perform the capture. Wireshark can capture from multiple interfaces simultaneously, as well as from virtual interfaces. The primary advantage of starting with the Capture Interfaces window is the availability of the packet counters to aid in identifying active interfaces, a feature not available in the Capture Options window. Otherwise, if you know which interface you'll want to use, you can skip using the Capture Interfaces window and start here.

Clicking on the Manage Interfaces button in the Capture Options window brings up an Interface Management window. From the Local Interfaces tab, you can select to hide interfaces that you do not wish to see displayed in the Capture Interfaces and Capture Options windows.

There is an option to quickly enable Capture on all interfaces and a Use promiscuous mode on all interfaces option that is enabled by default. In most cases, this option should be left enabled so that the chosen interface(s) can capture and save all the packets seen. Otherwise, only the packets that are being sent to the Wireshark workstation's MAC address, broadcast, and/or multicast packets will be seen and captured, which basically negates its usefulness as a capture device. The Compile selected BPFs button provides a machine language display of the compiled capture filter, but has no other functional purpose.

Capture filters are used to reduce the amount of traffic saved during a packet capture. In practice, capture filters should be used sparingly, if used at all, to help make sure that no packets that are important for an analysis are inadvertently missed because they fall outside the capture filter parameters. Remember that you can always filter out unwanted traffic from a capture, but you can't do anything about missed packets once the capture is finished. If you're unsure about a capture, perform the capture again with a more generous capture filter or none at all.

One scenario where a capture filter is appropriate is when you want to let a capture run for a long period of time. Then, you should filter out as much extraneous traffic as possible to keep capture file sizes under control. However, take care to make sure the capture filter you apply doesn't exclude any traffic that may be useful for the analysis.

It's usually a good idea to do some trial captures when using capture filters to verify that the filter is working as desired before doing the official capture that you want to keep.

Wireshark provides a Capture Filter window that makes it easy to select a preconfigured capture filter, or you can configure your own based on your needs.

Click on the Capture Filter button in the Capture Options window to open the Capture Filters window. From this window, you can select from a number of useful preconfigured capture filters, create a new and unique capture filter for your purposes, or delete unwanted or erroneous filters. Creating a new filter only involves giving the filter a name, entering the capture filter syntax, clicking on New to save the filter, and then finally clicking on OK. Alternatively, you can click on an existing filter and then click on New, which will create a copy of that filter at the bottom of the list that can then be modified for your purposes.

The following screenshot illustrates a typical Capture Filter window. In this case, a capture filter that will only allow traffic to and from a specific Ethernet MAC address has been selected:

Wireshark's capture filters use a syntax that is known as the Berkley Packet Filter (BPF) format, which has legacy roots in the Unix world and is still in use today with packet-level drivers. Note that the syntax used to capture filters in Wireshark differs significantly from the syntax used for display filters.

The default selection of capture filters from the Capture Filter window is helpful in providing examples of capture filter syntax. Some additional examples of capture filter syntax and examples of that syntax are outlined in the following table:

More information and examples of capture filters can be found on the Wireshark wiki at http://wiki.wireshark.org/CaptureFilters and the protocol-specific capture filter syntax is included in the reference information found at http://wiki.wireshark.org/ProtocolReference.

The Wireshark Capture Options window offers a variety of controls to configure captures to suit a particular need.

As discussed in Chapter 1, Getting Acquainted with Wireshark, if you have multiple network interfaces on your machine, you need to determine and select the correct interface to capture packets. In Wireshark's Capture menu, click on Interface or click on the first icon on the icon bar.

The Wireshark Capture Interfaces window provides a list and description of the network interfaces on your machine, the IP addresses assigned, and the total packets and packets per second counters for each interface. If an interface has an IPv6 address assigned and this is being displayed, you can click on the address to toggle and display the IPv4 address.

The following screenshot illustrates a typical Capture Interfaces window listing a LAN and wireless interface along with their IP addresses and packet counters:

The Capture Interfaces window provides the following two options:

The following screenshot illustrates a typical Capture Options window with a number of options specified. You can refer to it for examples of the topics on Capture Options.

As seen in the preceding screenshot, the Capture Options window displays the available interfaces and their IP addresses and allows you to select one or more of these interfaces to perform the capture. Wireshark can capture from multiple interfaces simultaneously, as well as from virtual interfaces. The primary advantage of starting with the Capture Interfaces window is the availability of the packet counters to aid in identifying active interfaces, a feature not available in the Capture Options window. Otherwise, if you know which interface you'll want to use, you can skip using the Capture Interfaces window and start here.

Clicking on the Manage Interfaces button in the Capture Options window brings up an Interface Management window. From the Local Interfaces tab, you can select to hide interfaces that you do not wish to see displayed in the Capture Interfaces and Capture Options windows.

There is an option to quickly enable Capture on all interfaces and a Use promiscuous mode on all interfaces option that is enabled by default. In most cases, this option should be left enabled so that the chosen interface(s) can capture and save all the packets seen. Otherwise, only the packets that are being sent to the Wireshark workstation's MAC address, broadcast, and/or multicast packets will be seen and captured, which basically negates its usefulness as a capture device. The Compile selected BPFs button provides a machine language display of the compiled capture filter, but has no other functional purpose.

Capture filters are used to reduce the amount of traffic saved during a packet capture. In practice, capture filters should be used sparingly, if used at all, to help make sure that no packets that are important for an analysis are inadvertently missed because they fall outside the capture filter parameters. Remember that you can always filter out unwanted traffic from a capture, but you can't do anything about missed packets once the capture is finished. If you're unsure about a capture, perform the capture again with a more generous capture filter or none at all.

One scenario where a capture filter is appropriate is when you want to let a capture run for a long period of time. Then, you should filter out as much extraneous traffic as possible to keep capture file sizes under control. However, take care to make sure the capture filter you apply doesn't exclude any traffic that may be useful for the analysis.

It's usually a good idea to do some trial captures when using capture filters to verify that the filter is working as desired before doing the official capture that you want to keep.

Wireshark provides a Capture Filter window that makes it easy to select a preconfigured capture filter, or you can configure your own based on your needs.

Click on the Capture Filter button in the Capture Options window to open the Capture Filters window. From this window, you can select from a number of useful preconfigured capture filters, create a new and unique capture filter for your purposes, or delete unwanted or erroneous filters. Creating a new filter only involves giving the filter a name, entering the capture filter syntax, clicking on New to save the filter, and then finally clicking on OK. Alternatively, you can click on an existing filter and then click on New, which will create a copy of that filter at the bottom of the list that can then be modified for your purposes.

The following screenshot illustrates a typical Capture Filter window. In this case, a capture filter that will only allow traffic to and from a specific Ethernet MAC address has been selected:

Wireshark's capture filters use a syntax that is known as the Berkley Packet Filter (BPF) format, which has legacy roots in the Unix world and is still in use today with packet-level drivers. Note that the syntax used to capture filters in Wireshark differs significantly from the syntax used for display filters.

The default selection of capture filters from the Capture Filter window is helpful in providing examples of capture filter syntax. Some additional examples of capture filter syntax and examples of that syntax are outlined in the following table:

More information and examples of capture filters can be found on the Wireshark wiki at http://wiki.wireshark.org/CaptureFilters and the protocol-specific capture filter syntax is included in the reference information found at http://wiki.wireshark.org/ProtocolReference.

The Wireshark Capture Options window offers a variety of controls to configure captures to suit a particular need.

Capture filters are used to reduce the amount of traffic saved during a packet capture. In practice, capture filters should be used sparingly, if used at all, to help make sure that no packets that are important for an analysis are inadvertently missed because they fall outside the capture filter parameters. Remember that you can always filter out unwanted traffic from a capture, but you can't do anything about missed packets once the capture is finished. If you're unsure about a capture, perform the capture again with a more generous capture filter or none at all.

One scenario where a capture filter is appropriate is when you want to let a capture run for a long period of time. Then, you should filter out as much extraneous traffic as possible to keep capture file sizes under control. However, take care to make sure the capture filter you apply doesn't exclude any traffic that may be useful for the analysis.

It's usually a good idea to do some trial captures when using capture filters to verify that the filter is working as desired before doing the official capture that you want to keep.

Wireshark provides a Capture Filter window that makes it easy to select a preconfigured capture filter, or you can configure your own based on your needs.

Click on the Capture Filter button in the Capture Options window to open the Capture Filters window. From this window, you can select from a number of useful preconfigured capture filters, create a new and unique capture filter for your purposes, or delete unwanted or erroneous filters. Creating a new filter only involves giving the filter a name, entering the capture filter syntax, clicking on New to save the filter, and then finally clicking on OK. Alternatively, you can click on an existing filter and then click on New, which will create a copy of that filter at the bottom of the list that can then be modified for your purposes.

The following screenshot illustrates a typical Capture Filter window. In this case, a capture filter that will only allow traffic to and from a specific Ethernet MAC address has been selected:

Wireshark's capture filters use a syntax that is known as the Berkley Packet Filter (BPF) format, which has legacy roots in the Unix world and is still in use today with packet-level drivers. Note that the syntax used to capture filters in Wireshark differs significantly from the syntax used for display filters.

The default selection of capture filters from the Capture Filter window is helpful in providing examples of capture filter syntax. Some additional examples of capture filter syntax and examples of that syntax are outlined in the following table:

More information and examples of capture filters can be found on the Wireshark wiki at http://wiki.wireshark.org/CaptureFilters and the protocol-specific capture filter syntax is included in the reference information found at http://wiki.wireshark.org/ProtocolReference.

The Wireshark Capture Options window offers a variety of controls to configure captures to suit a particular need.

Wireshark provides a Capture Filter window that makes it easy to select a preconfigured capture filter, or you can configure your own based on your needs.

Click on the Capture Filter button in the Capture Options window to open the Capture Filters window. From this window, you can select from a number of useful preconfigured capture filters, create a new and unique capture filter for your purposes, or delete unwanted or erroneous filters. Creating a new filter only involves giving the filter a name, entering the capture filter syntax, clicking on New to save the filter, and then finally clicking on OK. Alternatively, you can click on an existing filter and then click on New, which will create a copy of that filter at the bottom of the list that can then be modified for your purposes.

The following screenshot illustrates a typical Capture Filter window. In this case, a capture filter that will only allow traffic to and from a specific Ethernet MAC address has been selected:

Wireshark's capture filters use a syntax that is known as the Berkley Packet Filter (BPF) format, which has legacy roots in the Unix world and is still in use today with packet-level drivers. Note that the syntax used to capture filters in Wireshark differs significantly from the syntax used for display filters.

The default selection of capture filters from the Capture Filter window is helpful in providing examples of capture filter syntax. Some additional examples of capture filter syntax and examples of that syntax are outlined in the following table:

More information and examples of capture filters can be found on the Wireshark wiki at http://wiki.wireshark.org/CaptureFilters and the protocol-specific capture filter syntax is included in the reference information found at http://wiki.wireshark.org/ProtocolReference.

The Wireshark Capture Options window offers a variety of controls to configure captures to suit a particular need.

The Wireshark Capture Options window offers a variety of controls to configure captures to suit a particular need.

The Conversations window exhibits specific behaviors in the Ethernet tab, depending on the available Name Resolution settings. If Enable for Network Layer in the Name Resolution menu, which can be found in the View menu, is enabled and Name Resolution is also enabled in the Conversations window, then the IP address that is associated with a given device's MAC address is displayed as an IP address instead of a MAC address. Toggling the Name Resolution option in this scenario is useful for easily associating a devices' IP address with its MAC address.

If the Enable for Network Layer option is not enabled, then the Name Resolution option in the Conversations window controls whether the MAC addresses are displayed with manufacturer prefixes or as the basic 6-octet MAC address.

The TCP and UDP tabs of the Conversations window list all of the conversations between devices based on IP addresses and ports. Considering that network communications between a pair of devices, each with their associated IP addresses, could include multiple sequential or simultaneous sessions with differing port numbers, the TCP and UDP tabs (depending on the protocol in use) make it much easier to inspect the number and relative size and start/duration of these individual sessions.

As can be done in any of the other tabs in the Conversations window, a display filter can be quickly prepared or applied using the right-click functionality.

A helpful practice when investigating TCP or UDP sessions is to apply a display filter on just the IP addresses initially and then enabling the Limit to display filter option at the bottom of the Conversations window. Upon returning to the TCP or UDP tab, only the port-level sessions between the filtered host pair are displayed, which makes investigating these sessions much easier than picking them out from the entire list.

The following screenshot shows the multiple TCP sessions that were involved in loading the https://www.wireshark.org/ home page after applying a display filter (from the bulk capture file) and enabling the Limit to display filter option in the Conversations window. It can be seen that the (top) conversation between port 54581 on the user workstation and port 80 (HTTP) carried the vast majority of the traffic; the remaining ports carried much smaller amounts of traffic.

Since the Conversations window tabs are ordered alphabetically, the WLAN tab comes at the end. This tab displays the wireless station MAC addresses, as well as the Bytes, Packets, and other columns offered in the other tabs.

The Conversations window exhibits specific behaviors in the Ethernet tab, depending on the available Name Resolution settings. If Enable for Network Layer in the Name Resolution menu, which can be found in the View menu, is enabled and Name Resolution is also enabled in the Conversations window, then the IP address that is associated with a given device's MAC address is displayed as an IP address instead of a MAC address. Toggling the Name Resolution option in this scenario is useful for easily associating a devices' IP address with its MAC address.

If the Enable for Network Layer option is not enabled, then the Name Resolution option in the Conversations window controls whether the MAC addresses are displayed with manufacturer prefixes or as the basic 6-octet MAC address.

The TCP and UDP tabs of the Conversations window list all of the conversations between devices based on IP addresses and ports. Considering that network communications between a pair of devices, each with their associated IP addresses, could include multiple sequential or simultaneous sessions with differing port numbers, the TCP and UDP tabs (depending on the protocol in use) make it much easier to inspect the number and relative size and start/duration of these individual sessions.

As can be done in any of the other tabs in the Conversations window, a display filter can be quickly prepared or applied using the right-click functionality.

A helpful practice when investigating TCP or UDP sessions is to apply a display filter on just the IP addresses initially and then enabling the Limit to display filter option at the bottom of the Conversations window. Upon returning to the TCP or UDP tab, only the port-level sessions between the filtered host pair are displayed, which makes investigating these sessions much easier than picking them out from the entire list.

The following screenshot shows the multiple TCP sessions that were involved in loading the https://www.wireshark.org/ home page after applying a display filter (from the bulk capture file) and enabling the Limit to display filter option in the Conversations window. It can be seen that the (top) conversation between port 54581 on the user workstation and port 80 (HTTP) carried the vast majority of the traffic; the remaining ports carried much smaller amounts of traffic.

Since the Conversations window tabs are ordered alphabetically, the WLAN tab comes at the end. This tab displays the wireless station MAC addresses, as well as the Bytes, Packets, and other columns offered in the other tabs.

The TCP and UDP tabs of the Conversations window list all of the conversations between devices based on IP addresses and ports. Considering that network communications between a pair of devices, each with their associated IP addresses, could include multiple sequential or simultaneous sessions with differing port numbers, the TCP and UDP tabs (depending on the protocol in use) make it much easier to inspect the number and relative size and start/duration of these individual sessions.

As can be done in any of the other tabs in the Conversations window, a display filter can be quickly prepared or applied using the right-click functionality.

A helpful practice when investigating TCP or UDP sessions is to apply a display filter on just the IP addresses initially and then enabling the Limit to display filter option at the bottom of the Conversations window. Upon returning to the TCP or UDP tab, only the port-level sessions between the filtered host pair are displayed, which makes investigating these sessions much easier than picking them out from the entire list.

The following screenshot shows the multiple TCP sessions that were involved in loading the https://www.wireshark.org/ home page after applying a display filter (from the bulk capture file) and enabling the Limit to display filter option in the Conversations window. It can be seen that the (top) conversation between port 54581 on the user workstation and port 80 (HTTP) carried the vast majority of the traffic; the remaining ports carried much smaller amounts of traffic.

Since the Conversations window tabs are ordered alphabetically, the WLAN tab comes at the end. This tab displays the wireless station MAC addresses, as well as the Bytes, Packets, and other columns offered in the other tabs.

Since the Conversations window tabs are ordered alphabetically, the WLAN tab comes at the end. This tab displays the wireless station MAC addresses, as well as the Bytes, Packets, and other columns offered in the other tabs.

You can open the Display Filter window by selecting Display Filters from the Analyze menu, by clicking on the Edit/apply display filter icon on the icon bar, or by just clicking the Filters button next to the display filter textbox on the display filter bar.

The Display Filter window looks and functions in a similar fashion to the capture filters window, as shown in the following screenshot. You can create a new custom display filter to be added to this window by entering a filter name and the appropriate syntax and clicking on New or clicking an existing filter. Click on New and modify/rename as per your requirements.

Display filters listed in this window were saved in a dfilters file in the Wireshark installation directory for the default profile and in the appropriate Personal configuration directory when custom profiles are in use.

When you apply a display filter, the Status Bar at the bottom of the Wireshark user interface screen reflects the total number of packets and the packets displayed, as illustrated in the following screenshot:

The default selection of capture filters from the Display Filter window shown previously provides examples of basic capture filter syntax. Additional examples of display filter syntax are outlined in the following table:

More information and examples of display filters can be found on the Wireshark wiki at http://wiki.wireshark.org/DisplayFilters and protocol-specific display filter syntax is included in the reference information found at http://wiki.wireshark.org/ProtocolReference.

You can type a display filter syntax directly into the Filter textbox in the display filter bar, and then click on Apply to apply the filter or Clear to clear a filter and start over.

A helpful feature of typing the display filter syntax into the textbox is the autocomplete function. Upon typing a protocol and then a period (.), the textbox will display a list of available protocol-related extensions that can be selected and then the appropriate comparison operator and value added before clicking on Apply.

The textbox also has a color-coded background indicating the display filter syntax status. If the syntax is incorrect or incomplete, the background is red and a correct filter results in a green background. A yellow background is a warning that the entered syntax may not work as expected.

Creating a display filter to be applied from a Conversations window has already been covered. The same functionality is available from an Endpoints window, which can be opened by selecting Endpoint List from the Statistics menu and one of the listed protocols.

You can open the Display Filter window by selecting Display Filters from the Analyze menu, by clicking on the Edit/apply display filter icon on the icon bar, or by just clicking the Filters button next to the display filter textbox on the display filter bar.

The Display Filter window looks and functions in a similar fashion to the capture filters window, as shown in the following screenshot. You can create a new custom display filter to be added to this window by entering a filter name and the appropriate syntax and clicking on New or clicking an existing filter. Click on New and modify/rename as per your requirements.

Display filters listed in this window were saved in a dfilters file in the Wireshark installation directory for the default profile and in the appropriate Personal configuration directory when custom profiles are in use.

When you apply a display filter, the Status Bar at the bottom of the Wireshark user interface screen reflects the total number of packets and the packets displayed, as illustrated in the following screenshot:

The default selection of capture filters from the Display Filter window shown previously provides examples of basic capture filter syntax. Additional examples of display filter syntax are outlined in the following table:

More information and examples of display filters can be found on the Wireshark wiki at http://wiki.wireshark.org/DisplayFilters and protocol-specific display filter syntax is included in the reference information found at http://wiki.wireshark.org/ProtocolReference.

You can type a display filter syntax directly into the Filter textbox in the display filter bar, and then click on Apply to apply the filter or Clear to clear a filter and start over.

A helpful feature of typing the display filter syntax into the textbox is the autocomplete function. Upon typing a protocol and then a period (.), the textbox will display a list of available protocol-related extensions that can be selected and then the appropriate comparison operator and value added before clicking on Apply.

The textbox also has a color-coded background indicating the display filter syntax status. If the syntax is incorrect or incomplete, the background is red and a correct filter results in a green background. A yellow background is a warning that the entered syntax may not work as expected.

Creating a display filter to be applied from a Conversations window has already been covered. The same functionality is available from an Endpoints window, which can be opened by selecting Endpoint List from the Statistics menu and one of the listed protocols.

The default selection of capture filters from the Display Filter window shown previously provides examples of basic capture filter syntax. Additional examples of display filter syntax are outlined in the following table:

More information and examples of display filters can be found on the Wireshark wiki at http://wiki.wireshark.org/DisplayFilters and protocol-specific display filter syntax is included in the reference information found at http://wiki.wireshark.org/ProtocolReference.

You can type a display filter syntax directly into the Filter textbox in the display filter bar, and then click on Apply to apply the filter or Clear to clear a filter and start over.

A helpful feature of typing the display filter syntax into the textbox is the autocomplete function. Upon typing a protocol and then a period (.), the textbox will display a list of available protocol-related extensions that can be selected and then the appropriate comparison operator and value added before clicking on Apply.

The textbox also has a color-coded background indicating the display filter syntax status. If the syntax is incorrect or incomplete, the background is red and a correct filter results in a green background. A yellow background is a warning that the entered syntax may not work as expected.

Creating a display filter to be applied from a Conversations window has already been covered. The same functionality is available from an Endpoints window, which can be opened by selecting Endpoint List from the Statistics menu and one of the listed protocols.

You can type a display filter syntax directly into the Filter textbox in the display filter bar, and then click on Apply to apply the filter or Clear to clear a filter and start over.

A helpful feature of typing the display filter syntax into the textbox is the autocomplete function. Upon typing a protocol and then a period (.), the textbox will display a list of available protocol-related extensions that can be selected and then the appropriate comparison operator and value added before clicking on Apply.

The textbox also has a color-coded background indicating the display filter syntax status. If the syntax is incorrect or incomplete, the background is red and a correct filter results in a green background. A yellow background is a warning that the entered syntax may not work as expected.

Creating a display filter to be applied from a Conversations window has already been covered. The same functionality is available from an Endpoints window, which can be opened by selecting Endpoint List from the Statistics menu and one of the listed protocols.

Creating a display filter to be applied from a Conversations window has already been covered. The same functionality is available from an Endpoints window, which can be opened by selecting Endpoint List from the Statistics menu and one of the listed protocols.

To the right-hand side of the textbox on the display filter toolbar is the Expression button. Clicking on this button opens a Filter Expression window that allows you to select a protocol and the extension to that protocol, one of the appropriate relation (comparison) operators, and assign a comparison value. Click on OK to populate the display filter textbox with the resultant display filter syntax and then click on Apply to apply the filter.

If you right-click on a specific field in the Packet List or Packet Details panes, you can select the Apply as Filter or Prepare a Filter option and the required submenu option to create display filter syntax, as illustrated in the following screenshot. This is a very quick way of creating display filter syntax:

If you are selecting a field and using the right-click functionality to create display filter syntax, it is usually better to use the Prepare a Filter option, which will allow you to edit the syntax before clicking on Apply to apply the filter.

To the right-hand side of the textbox on the display filter toolbar is the Expression button. Clicking on this button opens a Filter Expression window that allows you to select a protocol and the extension to that protocol, one of the appropriate relation (comparison) operators, and assign a comparison value. Click on OK to populate the display filter textbox with the resultant display filter syntax and then click on Apply to apply the filter.

If you right-click on a specific field in the Packet List or Packet Details panes, you can select the Apply as Filter or Prepare a Filter option and the required submenu option to create display filter syntax, as illustrated in the following screenshot. This is a very quick way of creating display filter syntax:

If you are selecting a field and using the right-click functionality to create display filter syntax, it is usually better to use the Prepare a Filter option, which will allow you to edit the syntax before clicking on Apply to apply the filter.

If you right-click on a specific field in the Packet List or Packet Details panes, you can select the Apply as Filter or Prepare a Filter option and the required submenu option to create display filter syntax, as illustrated in the following screenshot. This is a very quick way of creating display filter syntax:

If you are selecting a field and using the right-click functionality to create display filter syntax, it is usually better to use the Prepare a Filter option, which will allow you to edit the syntax before clicking on Apply to apply the filter.

You can also temporarily color a series of packets in a conversation by selecting one of the conversation packets, selecting Colorize Conversation from the View menu, and selecting a color from the adjoining menu, or by right-clicking on a packet, selecting Colorize Conversation from the menu, selecting one of the protocol-specific options, and then selecting the desired color. This colorization will disappear when the capture file is reloaded, or you can select Reset Coloring 1-10 from the View menu.

You can also temporarily color a series of packets in a conversation by selecting one of the conversation packets, selecting Colorize Conversation from the View menu, and selecting a color from the adjoining menu, or by right-clicking on a packet, selecting Colorize Conversation from the menu, selecting one of the protocol-specific options, and then selecting the desired color. This colorization will disappear when the capture file is reloaded, or you can select Reset Coloring 1-10 from the View menu.

To create a new Wireshark profile, follow these steps:

You can select one of your custom profiles by selecting Configuration Profiles from the Edit menu, clicking on one of the listed profiles, and clicking on OK. A quicker method is just clicking on the Profile section of Status Bar and selecting a profile from the pop-up menu, as shown in the following screenshot:

To create a new Wireshark profile, follow these steps:

You can select one of your custom profiles by selecting Configuration Profiles from the Edit menu, clicking on one of the listed profiles, and clicking on OK. A quicker method is just clicking on the Profile section of Status Bar and selecting a profile from the pop-up menu, as shown in the following screenshot:

You can select one of your custom profiles by selecting Configuration Profiles from the Edit menu, clicking on one of the listed profiles, and clicking on OK. A quicker method is just clicking on the Profile section of Status Bar and selecting a profile from the pop-up menu, as shown in the following screenshot: