As mentioned in this post, you can create and share custom profiles. However, that is not the extent of profile management. Another great way to utilize these files is to synchronize Wireshark profiles between systems. In this day and age you probably have more than one computer (laptop, VM, home desktop??). Also, if you’re like me you probably have Wireshark installed on anything you can get your hands on! It can be a bit of a pain to keep your favorite Wireshark settings such as protocol options, coloring rules, and saved display filters up to date with each Wireshark installation.

As mentioned in this post, Wireshark is easy to customize and even provides the ability to share custom profiles. Just about everything that can be modified can be shared. I outlined several of those items in the linked post. Wireshark uses files to store the config items located in a couple of key places. The ones I have shared below are all contained in the “Personal configuration” directory. To get sharing right away follow these steps:

One of the great things about Wireshark is the completely customizable interface. Users can change the layout, column settings, protocol decode options, add/remove buttons, change colors, add/remove filters, and more. There is a lot of documentation on how to even write new protocol dissectors. Due to its open source nature and the active development community, one can modify the code and/or participate in its official development. What this means is no two instances of a Wireshark install have to be the same.

One of the most common problems any IT admin faces is a software update. While software updates are generally considered a good thing, because they patch security flaws, fix bugs, try to improve performance, and more, they are also a common source of problems. Every admin knows to be ready for calls after a scheduled maintenance window. This issue was no different.  A ticket came in stating users could not access a web app through the backend system after an upgrade to Java 1.

I’ve helped many users who say Fiddler has “fixed” their issue. Unfortunately, this is a bit deceptive. Fiddler is an excellent debugging tool for web apps, but it does not permanently resolve problems. What it does do is act as a proxy with its own connection settings. This allows it to act as a “man in the middle” and even decrypt the traffic to provide better more insight into application behavior.

Just because you can do something doesn’t always mean you should. One such example of this is using large HTTP headers. While the HTTP specification itself doesn’t set boundaries, most web servers have default limits around 8 KB. Other devices in the path such as firewalls/WAFs, proxies, and load balancers also have similar limits.  Problem The application testers were receiving a reset error. Their application and web server logs did not show any problems.