One of the cooler features added to recent versions of Wireshark is the ability to automatically select a Configuration Profile when you open a capture file.
I covered how to configure this feature in my earlier article, Automatically Switch Configuration Profiles in Wireshark. Since then, I have spent more time thinking about something that turns out to be more important than simply enabling the feature: What display filter should you actually use to trigger each profile? Oh and by the way – you will find all our Wireshark Profiles in our repository if you are new.
At first, this sounds easy.
If you have an OSPF profile, use:
ospf
If you have a DNS profile, use:
dns
If you have a TCP profile, use:
tcp
But as I mentioned in the first post, that last example exposes the problem. Almost every packet capture you work with probably contains TCP. Many captures also contain DNS, TLS, IPv4, IPv6, UDP, ICMP, and several other protocols. So simply creating Auto Switch Filters for every Wireshark profile you own may not produce the results you expect.
In that post I suggested to think of Auto Switch Filters as capture classification. This is the most important concept to understand. An Auto Switch Filter is technically a Wireshark display filter, but its purpose isn’t to determine which packets you want to display.
Instead, you are effectively telling Wireshark: “If you find this characteristic in the capture, assume this is the profile I want to use.”
That means a good Auto Switch Filter should identify the purpose or character of the capture, not simply identify a protocol that happens to be somewhere inside it.
For example: cdp is a very good classification trigger. If I open a capture containing Cisco Discovery Protocol packets, there is a reasonable chance I might want my CDP-focused profile.
Compare that with: tcp Finding TCP tells us almost nothing about the purpose of the packet capture.
There is another catch I also pointed out: First Match Wins! Wireshark checks the configured Auto Switch Filters against the initial packets in the capture. Once it finds a matching Auto Switch Filter, it selects that profile. That creates the possibility of collisions.
Imagine a capture containing:
- Ethernet
- VLAN tags
- IPv4
- UDP
- DNS
- QUIC
You might have profiles with these Auto Switch Filters:
vlan
ip
udp
dns
quic
Every one of those filters could match the same capture.
Which profile did you actually want? Probably the one most closely related to the reason you captured the traffic. This is why I recommend being selective about which Wireshark profiles you configure for automatic switching.
Excellent Auto Switch Filters
Let’s start with protocols that make especially good triggers.
These tend to be protocols that are distinctive enough that their presence strongly suggests a particular type of analysis.
| Profile | Recommended Auto Switch Filter | My Rating |
|---|---|---|
| Cisco Discovery Protocol | cdp | Excellent |
| LLDP | lldp | Excellent |
| Spanning Tree | stp | Excellent |
| VLAN Trunking Protocol | vtp | Excellent |
| OSPF | ospf | Excellent |
| BGP | tcp.port==179 | Excellent |
| VXLAN | vxlan | Excellent |
| MPLS | mpls | Excellent |
| LACP | lacp | Excellent |
| DHCPv6 | dhcpv6 | Excellent |
| 802.1X/EAPOL | eapol | Excellent |
These are the types of profiles where I would have little hesitation enabling automatic profile switching.
For example, if I open a capture containing: ospf there is a strong argument for automatically loading my OSPF analysis profile.
Similarly: cdp, lldp, stp, and: vxlan are reasonably distinctive indicators of the type of packet analysis I may be about to perform.
Wireshark currently recognizes each of these protocol names as display-filter protocol fields; for example, cdp, lldp, stp, ospf, bgp, vlan, vxlan, quic, tls, and sip are all valid protocol-level display filters.
WLAN Captures Are Another Good Candidate
For a Wi-Fi packet analysis profile, I like:
wlan
This is different from triggering on something like UDP or IPv4.
If Wireshark actually has IEEE 802.11 frames available for dissection, that is a pretty good indication that I may want my WLAN troubleshooting profile.
If you maintain different wireless profiles, however, things become more interesting.
For example:
- WLAN Troubleshooting
- WLAN Security
- WLAN Timing
- General WLAN Analysis
All four could potentially use wlan.
Obviously, they can’t all be the automatic choice.
In that situation, I would configure automatic switching only on whichever WLAN profile I consider my normal starting point and manually select the more specialized profiles as my analysis progresses.
DHCP Is Pretty Good — With a Caveat
For DHCPv4:
dhcp
is a reasonable Auto Switch Filter.
For DHCPv6:
dhcpv6
is even more distinctive.
DHCP captures are often specifically created to troubleshoot address assignment, so these protocols lend themselves reasonably well to automatic switching.
There is still a potential collision if you open a larger client-startup capture containing DHCP, DNS, ARP, TCP, TLS, and other traffic.
Again, the question isn’t:
“Does this capture contain DHCP?”
The better question is:
“Does the presence of DHCP mean this is probably a DHCP troubleshooting capture?”
Sometimes yes. Sometimes no.
DNS Is Useful, But More Dangerous
A DNS profile seems like an obvious candidate:
dns
And it certainly works.
The problem is that DNS appears in an enormous percentage of ordinary packet captures.
Open a web browsing capture and you probably have DNS.
Open an application troubleshooting capture and you probably have DNS.
Open a client-startup capture and you probably have DNS.
So I would classify:
dns
as a situational Auto Switch Filter rather than an automatic recommendation.
The same applies to:
mdns
llmnr
and:
nbns
although those protocols can be more distinctive depending on the environment being analyzed.
A dedicated name-resolution profile could even use:
dns || mdns || llmnr || nbns
But be aware that doing so makes that profile increasingly easy to trigger.
VoIP Profiles Present an Interesting Problem
A generalized VoIP profile might use:
sip || rtp || rtcp
That’s a pretty reasonable classification rule.
SIP alone can also work:
sip
The difficulty comes if you maintain separate profiles for:
- SIP
- SDP
- RTP
- RTCP
- General VoIP troubleshooting
If you configure automatic switching on all of them, the profiles will compete.
I would probably use the generalized VoIP profile as the automatic entry point:
sip || rtp || rtcp
Then manually switch to the SIP- or RTP-specific profile once I know which part of the call requires deeper analysis.
This reflects how I normally troubleshoot anyway: begin broad, then narrow the analysis.
QUIC Is a Great Filter — But Not Necessarily a Great Trigger
Technically:
quic
is an excellent filter.
Wireshark has a dedicated IETF QUIC dissector, and quic is the protocol field name.
But modern web browsers and applications generate a lot of QUIC traffic.
That means a capture containing QUIC isn’t necessarily a QUIC troubleshooting capture.
If you do a lot of web, HTTP/3, or application troubleshooting, enabling:
quic
as an automatic profile trigger could cause your QUIC profile to appear more often than you intended.
So I would rate it:
Technically excellent filter. Situational Auto Switch trigger.
That’s an important distinction.
TLS Has the Same Problem — Only Worse
You could certainly configure:
tls
for your TLS profile.
It works.
But TLS is everywhere.
A typical enterprise packet capture may contain dozens or hundreds of TLS conversations.
The presence of TLS therefore tells me very little about why the capture was taken.
Unless your captures are highly specialized, I would probably not automatically trigger my TLS profile using simply:
tls
I would select that profile manually when I decide TLS is where I want to focus my investigation.
VLAN Is Useful, But Think About Your Capture Location
The example I used in my original Auto Switch article was:
vlan
for a VLAN profile.
I still like that example because it clearly demonstrates the feature. But VLAN is another trigger that depends heavily on where you capture.
If you capture from a trunk, SPAN session, network TAP, virtual switch, or certain service-provider environments, VLAN-tagged traffic may be routine.
Your capture could be about TCP performance, VoIP, DNS, OSPF, BGP, or something completely unrelated to VLAN troubleshooting while still containing VLAN headers.
So:
vlan
is useful, but I would rate it as situational rather than universally excellent.
Filters I Usually Would NOT Use for Automatic Switching
Here is where I think the most important recommendation lies.
I maintain several Wireshark profiles that I would not configure for automatic switching.
These include profiles focused on:
- Ethernet
- IPv4
- IPv6
- TCP
- UDP
- TCP sequence analysis
- TCP delta-time analysis
- General TCP troubleshooting
Why?
Because filters such as:
eth
ip
ipv6
tcp
and:
udp
are simply too common.
Consider tcp.
If you configure:
tcp
as the trigger for a TCP troubleshooting profile, almost every capture containing web browsing, email, file transfer, application traffic, TLS, BGP, SSH, or countless other applications can trigger it.
That isn’t classification. That’s simply detecting that TCP exists.
The same problem applies to ip and eth even more strongly.
My “Do Not Automatically Trigger” List
| Profile Type | Possible Filter | Recommendation |
|---|---|---|
| Ethernet | eth | Avoid |
| IPv4 | ip | Avoid |
| IPv6 | ipv6 | Usually avoid |
| TCP | tcp | Avoid |
| UDP | udp | Avoid |
| TCP Delta Time | tcp | Avoid |
| TCP Sequence Analysis | tcp | Avoid |
| General TCP Troubleshooting | tcp | Avoid |
| TLS | tls | Usually avoid |
| DNS | dns | Situational |
| QUIC | quic | Situational |
| VLAN | vlan | Situational |
There’s nothing wrong with these profiles. Quite the opposite—some of them are among the most useful profiles I use.
They simply aren’t necessarily good candidates for automatic selection.
A Better Strategy: Automatically Enter the Analysis, Then Manually Go Deeper
This is probably the model I like best.
Suppose I open a capture containing SIP and RTP. Wireshark automatically selects my generalized VoIP profile using:
sip || rtp || rtcp
Once I begin investigating, I might manually switch to:
- SIP signaling
- RTP quality
- SDP
- UDP timing
Likewise, an OSPF capture could automatically load:
ospf
After examining the adjacency, I might switch to another specialized troubleshooting profile.
Automatic Profile Switching doesn’t have to eliminate manual profile selection. It can simply put you in the best starting environment.
Don’t Forget the Auto Switch Packet Limit
Another important setting is the Auto switch packet limit.
Wireshark does not necessarily search every packet in a massive capture trying to figure out which profile to use. It evaluates the configured filters against a limited number of packets near the beginning of the file. That limit is configurable. If the protocol that should trigger your profile does not occur until much later in the capture, Wireshark may never see it during the automatic profile-selection process.
Setting the packet limit to zero disables automatic profile switching entirely. This creates another reason to choose your trigger carefully.
An OSPF Hello, LLDP advertisement, CDP advertisement, or Spanning Tree BPDU tends to appear periodically, making these protocols particularly useful candidates.
A protocol that appears once, thousands of packets into the capture, may be much less useful.
My Recommended Starting List
If I were setting up automatic switching from scratch, I would probably begin with these:
cdp
lldp
stp
vtp
ospf
bgp
vxlan
mpls
lacp
dhcpv6
eapol
wlan
Then I would cautiously consider:
dhcp
vlan
dns
sip || rtp || rtcp
quic
depending on how I capture traffic and which profile I want Wireshark to select first.
I would generally leave the following profiles as manual selections:
eth
ip
ipv6
tcp
udp
tls
and specialized TCP analysis profiles.
The Best Filter Is the One That Identifies Intent
There really isn’t a universal “best” Auto Switch Filter for every profile.
The important question is whether the filter helps Wireshark distinguish what kind of analysis you probably want to perform.
That’s why: ospf is an excellent trigger.
That’s why: cdp is an excellent trigger.
And that’s why: tcp usually isn’t.
When you build your Auto Switch Filters, don’t ask: “What protocol does this profile analyze?”
Instead ask: “What packet characteristic would make me want Wireshark to start with this profile?”
That small change in thinking makes Automatic Profile Switching much more useful. And remember: you don’t need to automatically switch every profile you have. Sometimes the smartest Auto Switch Filter is no Auto Switch Filter at all.
If you would like to help support the continued development of independent networking, broadband, Wi-Fi, VoIP, and packet analysis content, please consider joining our Patreon community where you will gain access to exclusive technical resources, downloadable labs and PCAPs, bonus course content, troubleshooting guides, and additional member-only material. Comments and technical discussion are always welcomed at our Patreon community or on our Discord server. You can also support our work by simply buying us a coffee — every contribution helps us continue creating practical, real-world network science education for professionals and enthusiasts alike.