It has help me to
- solve network and transaction issues
- understand protocols and application communication
- check quality
- solve security issues.
Download the Network Troubleshooting Buyer's Guide including reviews and more. Updated: June 2022
It has help me to
I can save the traffic and analysis when I want to. Also, it's especially helpful to follow the stream (TCP, UDP, etc.).
It needs the ability to follow multiple interfaces for specific traffic from different network zones/virtual networks. It would help to understand how any packet is going through the network.
Sometimes, in the previous version, it lost the scroll when I needed to scroll back and forth.
No issues with scalability.
Sometimes I need to use tcpdump when I need to check the packets on CLI.
Very easy. It's also possible to change source code and compile if you want to change something in the code, because it's free.
I believe everyone should use this tool if they need to analyze packets.
Wireshark can be used to troubleshoot network issues, but also to baseline applications. When you know what an app does when there is no issue at hand, you will be better able to spot the problem when there is an issue. Everything that happens on the network can be analysed with Wireshark. However, the tool is as good as the person using it. You need TCP/IP knowledge to be able to use a tool like this. The more you know about packets on the wire, the better you can use this tool.
It gives us the ability to pinpoint problems and to communicate network problems with software and hardware vendors. The packets never lie!
Making different profiles to tune the tool for the problems at hand, the graphing options, to customize the screen layout, etc.
Also, shines for wireless troubleshooting, but most hardware does not give full insight in WiFi communication (beacon frames, etc.).
Big trace files (more than 1,000,000 packets) can be slow, but then you can use "TraceWrangler" (also free) to help with slicing and dicing the data.
This is no complaint, but is not an easy program. You will need to study to use it to its full capabilities (follow a course), but the more you know about it, the more you will use it.
Big trace files need to be chopped for analysis.
My bug reports were in the next release, therefore a great experience.
I have used it more or less since 2001. So no, I did not use a previous solution.
Download, run setup, enter;enter;enter..., it is ready.
It is free to download and install. It runs on multiple platforms, so how can you go wrong?
In those days, there was a tool "Sniffer", but it was too expensive.
If you profile yourself as a network specialist, and don't use it, I would not trust you on my network.
It is even referenced in the book "TCP/IP Illustrated, Vol. 1", the TCP/IP bible!
The people to whom I have introduced this product have found it a great tool to analyze packets. Instead of troubleshooting by trial and error, they have a way to investigate, verify, and then apply a solution. Of course, to derive value from the product, you must know its features.
The drill-down available for packet analysis is great. It gives a network security engineer insight into what is going on at the packet level and enables better troubleshooting.
The Wireshark search function shows green for a correct search and red for an incorrect search. If there were a way to provide a description about what a search - and the similar ones which are available - can do, while a person is typing it, it would make the product easier to use and simultaneously decrease the learning curve.
No stability issues.
No scalability issues.
I have not used technical support.
I used Microsoft's Network Monitor, but with due respect to Microsoft, I prefer Wireshark.
It is utilized for forensic work, with full packet capture.
Packet analysis and filtering. Packet-capture files can be hard to use due to their size. Wireshark has a tool called tshark that can parse the files without opening them so that you can take large captures, say 2-10GB, and return only relevant information.
The UI redesign threw me for a loop but I have learned to overcome it. The product is great but I wish there were more of an emphasis on the command line tools.
No stability issues.
No scalability issues.
Just install the software and the WinPcap software.
It's a standalone tool. If there is a commercial license for it I am unaware of it.
Make sure you are comfortable installing the WinPcap driver for packet collection. This tool could be used maliciously to capture data on your network.
Some valuable features of Wireshark are deep packet inspections based on the capturing process with it's sniffing capabilities.
In order to be more intelligent about all the bits/frames/packets/data traversing your network regardless of how small or large the network is, Wireshark is a network analytic tool which provides such an intelligent information in a network.
Wireshark is that intelligent, not only for production environment alone but also aids study about the packet fields that may exist in any type of packet header of data flowing in your network.To view how all the classes of QoS marking in a packet are and can be used to also sniff packets during reconnaissance phase of a network security attack.
Wireshark provides better understanding on how the bits are set for different fields in a packet header.
It is indeed a very good tool which all network administrators need to be familiar with.
Maximum buffer size of captured data should be unlimited and should allow ability to archive all old captures (not save option) in real time, it should support a destination location where old captures can be directed for long term storage.
Wireshark is hands down one of the best analysis tools on the planet. It is intuitive, simple to use, and gives the depth needed to find problems in today's network and application environments. Sometimes it can be tough to remember some of the filtering commands though, so here is a list of some of my favorites:
1. !(ip.addr==10.0.0.1) [displays everything except IP traffic to or from 10.0.0.1]
2. ip.addr==10.0.0.1 && ip.addr==10.0.0.2 [sets a conversation filter between the two defined IP addresses]
3. http or dns [sets a filter to display all http and dns]
4. tcp.port==4000 [sets a filter for any TCP packet with 4000 as a source or dest port]
5. tcp.flags.reset==1 [displays all TCP resets]
6. http.request [displays all HTTP GET requests]
7. tcp contains traffic [displays all TCP packets that contain the word ‘traffic’. Excellent when searching on a specific string or user ID]
8. !(arp or icmp or dns) [masks out arp, icmp, dns, or whatever other protocols may be background noise. Allowing you to focus on the traffic of interest]
9. udp contains 2069999999 [sets a filter for the number string, great when trying to locate a specific caller ID in a VoIP capture]
10. tcp.analysis.retransmission [displays all retransmissions in the trace. Helps when tracking down slow application performance and packet loss]
I really get excited when I am able to reproduce problems in the lab.
With this specific case, the customer was experiencing errors within their web browsers that looked like either a network or server issue. The specific symptom was that certain images would not display. If you waited a while, and ‘refreshed’ the page, more of it loaded or the entire page loaded properly.
I’m sure you can imagine the chaos this type of intermittent problem causes. The sequence of events unfolds in the following manner; the client reports the webpage issue to the help desk and the help desk tests the webpage with mixed results. In either event, the problem goes to the server group who tests and finds nothing wrong, and then the problem goes to the network group which, in most cases, does not see the problem. Then the political fist fights, finger pointing and witch hunt commence…..
In this case, they even managed to capture some packets during the problem and saw a HTTP “Service Unavailable” message and were having issues interpreting exactly what that would mean. I was there doing some other work when they dumped, uh, I mean asked me if I could help.
They explained that when the problem was occurring, the network management system was not reporting that the server or application was down. I asked how they knew that and they said that they pinged the server, tested for tcp port 80 and lastly retrieved the html page. Wow, I was impressed. I don’t see too many people monitoring from the IP layer up to the Application layer.
I then told them that even though this was an excellent way of monitoring, I wasn’t too surprised that no outages were recorded. If it was an application issue, the pings will still work as well the TCP port check. If all you did was retrieve a single html file, it would not use the same number of connections as actually loading a page and rendering images, etc…
That’s when the lab work came in. I went to my lab and configured IIS to only accept 1 connection, created a simple html file which had a few images on it. After the first try I saw the exact same issue the client experienced as well as the same HTTP message in the analyzer. AWESOME!!!
In the video below you will see how I did it and the results.
The most daunting problem to troubleshoot is when the application spits out a generic error that could mean anything. Here’s the analogy; how helpful is the ‘Check Engine’ light on your car dashboard.
The worst part is when the customer tries to take the cryptic, generic application error message and tries to make sense of it in an attempt to assist the analyst. Don’t get me wrong, any information is helpful while troubleshooting, but you have to be selective in what you pursue.
In this example FTP works one moment and fails the next. Of course the customer immediately called the help desk, who pings the ftp server and comments that is up and no outages have been recorded by the network management system. Then the ticket goes to the server dept who ftp’s without an issue, unfortunately by now so can the customer. The server department says the connection error must be a ‘network thing’.
I captured some packets and have recreated what I found and how the application, Chrome in this example, failed to pass on the FTP server connection limit error. The only way I was able to get real meaningful data is from the wire.
This isn’t a Chrome ‘bash’ session since I have seen many applications not report what was on the wire or reinterpret what was reported by the server.
In summary, the ftp server ran out of connections or had a limit on the number of connections an IP address could have. The administrator was told about this and the FTP server configuration was adjusted to allow more connections.
It always gives me sense of satisfaction when I have a challenge and can leverage some knowledge to figure out.
Today I was in the lab and was powering on two Cisco switches when I noticed that they weren’t labeled with their IP addresses. I’m not sure why I did not label them, but now I have to pay for it.
For those of you who have not been in this situation before I will explain. My switches have a DB9 serial connection and of course good luck finding a computer with a serial port. So now I have to rummage through the box of wires to find the serial to USB adapter. I have had to buy a second one in 2 years since my original does not have a Windows 7 driver, but I digress. After I find the cable, I have to find the installation disk because last week I migrated to a new laptop…. I’m sure you get the picture.
On to plan B. I know the switches have IP addresses since I hard code IP addresses on all of my switches.
Now here’s where a bit of knowledge comes in. I know that when a device powers up and either obtains an IP addresses via DHCP/BOOTP or statically has an IP assigned it will send out a specific ARP called a gratuitous ARP.
Perfect, now all I have to do is make sure the switch port is connected to my subnet, start any protocol analyzer (I chose Wireshark) and power up the switches.
In this video I show you how to find the Gratuitous ARP quickly, create a display filter and lastly, locate the 2 switches’ IP addresses.
A customer called me and wanted some help troubleshooting some wireless problems. Their users have been reporting intermittent wireless performance issues and getting ‘dropped’. To top it all off, their WLAN controller has also been reporting ‘containment’ error messages that weren’t to descriptive or helpful.
I showed up on site and did all the basic RF checks with my AirMagnet Spectrum XT to make sure there wasn’t an RF issue like an interferer or channel planning issues. Like I always say, “Start at Layer 1”.
Then I moved up a layer using my Fluke Networks AirCheck and AirMagnet WiFi Analyzer. Everything looked pretty quiet and nothing jumped up at me, so I saved some trace files to review later.
Then I thought I would take the trace file and open it with Wireshark since I have more experience with packet analysis than I do using the AirMagnet/AirCheck tools.
In this video I show you some of the filters I used, what they mean and what I found.
I always enjoy getting to the packet level since packets don’t lie, but would also like to spend more time with the other tools now that I know what issues are to see how, or what, they report.
In closing there are a few points I want to make sure aren’t lost throughout the video;
1. Just because I used Wireshark to find some clues does not mean that the other tools were less effective, I just have more experience with protocol analysis/Wireshark.
2. If you deploy any kind of wireless intrusion system, make sure you don’t just turn it on without proper network due diligence.
Excellent packet analyzer tool. I have used this a lot and had very good luck with it, it is pretty easy to use and can provide a lot of information and insight when troubleshooting network issues.
NAT Packet Analysis Using Wireshark
One of the most popular questions I get when people get the hang of protocol analysis is the daunting exercise of multitrace analysis. As with anything else the best advice is to start with the basics before tackling anything complicated.
Multitrace analysis is only effective if you truly understand your vendors products, networking and how it relates to the OSI model or packet analysis. I always suggest that you start at layer 1 and work yourself up. The key is to know what fields in the frame or packet changes, or remains the same. Ideally when you figure this out you can use a better capture or display filter
A multitrace capture of a hub, switched, or bridged network is most straight forward since a hub or switch is transparent at layer 1 or 2 and doesn’t change anything in the packet.
When you move up to layer 3 or routing, several things change in the packet such as MAC address, IP TTL and TOS. Of course your mileage will vary, and any device could be configured to muck with more bits in the packet, but I figure I would give you a point of reference.
At layer 4 we get into application gateways, proxy, firewalls and NAT type devices where the following packet fields gets modified; MAC address, IP address, IP TOS, TCP/UDP port numbers, TCP ACK/SEQ values, etc.
Lastly at layer 7, we are dealing with multi-tiered applications and basically everything changes in the packet.
In this video example I do a multitrace analysis of a simple netgear router/NAT/firewall device where I take a trace from the WAN and LAN side to compare. Not to sound like a broken record, but please remember that your devices might behave totally differently and these notes and techniques should only be used as a reference in your environment.
Multitrace analysis can be the most interesting, rewarding and unfortunately, most frustrating exercise an analyst will face.
Before we get to the packet analysis, setting up your tools for simultaneous capturing can be a feat in itself.
The time issue is the most critical when using 2 devices since the time is used to calculate the delay, jitter or latency. Some people are fine with syncing both devices to a common ntp server.
Then there’s the “how the #!!$!@#!!” do I physically capture . This is where you have to be familiar with the problem, the network you are working on and what equipment is available to you. If you are lucky enough to be able to change the speed and duplex to 100 half duplex a good old hub fits the bill. Other than the mirror/span command, a tap is also very helpful. Trust me every one of these suggestions comes with their own caveats. You may have to try different tools for different scenarios.
For example, if I am doing a simple pc bootup/login baseline, I am interested in things like total data transferred, which IP’s I am talking to, protocols used, errors, etc. In this case speed and duplex is not important and I can go with a hub. But if I was troubleshooting why something is taking too long, like a backup or replication, changing the speed and duplex would not be a good idea.
If you are lucky enough and can capture from one device, the time accuracy issue goes away and life does get a bit easier. But now you have 2 different captures in the same trace, Yikes!!!! Not to mention that different network interfaces have different latency or behaviors. I remember trying a usb to 10/100 ethernet adapter to capture packets and quickly realized that this adapter added 30 ms to every packet. Again, if I was troubleshooting latency, this won’t do.
Lastly, if you’re fortunate enough, you might even have an application that takes multiple trace files and calculates all sorts of stuff out for you (hmm.. next article?).
In this example I use Wireshark, my laptops WiFi and Ethernet ports to capture my packet traversing a residential home router. I show some tips and tricks along the way and hope this will help you out.
Documenting a Problem With Wireshark
I remember talking to a group about the ‘superman syndrome’ where the analyst wants to swoop in and save the day. I explained that like most forensic tasks, protocol analysis can be tedius, confusing and downright boring at times. Alright who wants to capture some packets now!?
If you can’t see it, you can’t fix it. That is why I like to use protocol analysis to minimally document the problem that I’m experiencing. Even if the packets don’t show any anomalies, that worth knowing as well, isn’t it? If you do see an anomaly, you might not have the solution but at least you know what it looks like when its broken.
Ideally protocol analysis is most helpful when you have two traces to compare; the good and bad trace. In most realistic scenarios, the client will not have a good trace and just the current bad trace. I’m our classes I review how to make use of what you have.
In this example the customer had a DSL line with an issue and another DSL line what worked fine. The customer mentioned that whenever the DSL circuit ‘acted up’, they simply rebooted the modem. Both DSL circuits went to the same carrier, ordered at the same time, provisioned the same way and even use the same hardware. Perfect, example of something I can compare. I also noticed that these are not just modems, but they route, dhcp, firewall and NAT.
What I found, is that the problem circuit was having issues passing larger frames, while the other had no issues. After the reboot the problem circuit now behaves like the good one. Upon further investigsation I noticed the problem modem had older firmware and suggested they get that firmware updated.
So, even though I couldn’t ‘fix’ the problem, we know exactly what the problem is and what to look for if the problem returns.
I am surprised that this exercise we do in class still proves to be helpful as well as quite popular.
There are many utilities out there to help find rogue servers, but why bother when you already have Wireshark installed. When you get comfortable with this exercise you can save some steps by creating a capture filter for just DHCP packets, or better yet, just DHCP server packets. As always with protocol analysis, there are many ways to do this exercise and this is just my preference since it forces me and the attendees to review the DHCP process as they go through the packets.
Rogue DHCP servers are becoming more common these days since a DHCP server can simply be a part of an application loaded on your computer. The introduction of tablets and smart phones that can provide hotspot support, are also DHCP servers. I even see more applications out there that turns your laptop into a WiFi hotspot so you can tether it to your tablet or smart phone.
Don’t worry, I haven’t forgotten the classic example of an employee who wants wireless access in a nearby conference room and simply connects the LAN port of his wireless router at his desk and starts dishing out IP addresses.
I like the added twist where I ask people to identify the legitimate DHCP based on paying attention to the story, not the packets. I can’t tell you how many times I figure out a problem by going back to the user and having a conversation rather than going over the trace a million times.
I think people forget that Wireshark and protocol analysis is an exercise in forensics and you need a story for context and to make sense of the packets.
I have said many times that many times the answer comes from the story, not the packets.
While troubleshooting a Wifi performance issue on a large BYOD network, I was explaining to the customer a lot of people on a wireless network sending a lot of small packets can cause a performance issue by robbing precious time from other Wifi clients.
They didn’t quite understand how this could happen since many users’ computers and phones are idle and just simply connected to the WiFi network. I illustrated the impact of having common applications installed on a smartphone/tablet as well as browser extensions or add-ons would have on a network by using Wireshark.
The trickiest part of this exercise is actually capturing the Wireless packets. You can use Riverbed’s Airpcap adapter, or any other vendors WiFi packet capturing product. Just keep in mind that in many cases where you have encryption enabled, its easier if you join that network to see the packets.
To this day I am surprised how many network analysts lack WiFi troubleshooting tools and either rely on their wired lan tools or strictly use the vendors monitoring applications as their sole source of information. I remember a few years ago I did a tools presentation for a vendor and asked the group how much confidence they would have in their auto mechanic if he only had one tool on the bench, or if he lacked specialty tools for your specific car’s make and model.
With Wireshark I was able to give them an ‘under the hood’ view of their network. You don’t need to have an extensive protocol analysis background to quickly realize that this is one busy network. As I have many times in the past, “Packets don’t Lie”.
On a wired network this is less of an issue since a wired network is more bandwidth bound. On a wireless network at home this isn’t an issue either since you aren’t sharing the wireless network with as many people.
In this case, the customer had over 200 people on an access point which cumulatively creates an issue.
In this video I use Wireshark to illustrate the traffic generated by these various applications.