Wireshark comes with powerful and flexible columns features. We can add any number of columns, sort them and so on. I’m pretty sure any analyst has his own set of profiles with different columns.
The easiest way to add a column is the next: select a packet of interest, find the field you wanna build column of, right click -> “Apply as column”
And we’ll get needed column:
Nice and handy feature!
Now let’s proceed to the hint.
After upgrading Wireshark to version 2.4.0rc1 today I suddenly realized that PCAP files began to open very slowly. No, not just very slowly, but waaaay too sloooow:
12 MB file was opened in 45 seconds! 143 MB file was opened in 5 minutes and Wireshark took more than 2,5 Gigs of RAM.
“Hmmm, what could be the problem”, I thought…
Read more…
One of our customers was trying to add 3rd party IP-camera into our video management software (VMS). There is indeed such possibility, but not all camera manufacturers/models are supported. In other words, it’s always better to try and see if it works.
The process of adding 3rd party camera looks like the next:
Here I want to start new article series called “5-minute troubleshooting”. In these articles I’m going to describe short simple cases which we solved very quickly using protocol analysis and which could take much more time if we use another approach. So, let’s go.
One day we received an IP camera from our customer with the next complaint: “No image, no ping, the camera just disappeared from a network”.
First, we checked whether the camera was receiving PoE (yes it was), and booted up normally (according to camera LEDs no problems were here also).
Next step? Let’s try to ping it using IP-address our customer provided to us. No reply (and no surprise actually).
At this point it would be nice to check port statistics and status to eliminate L1 failure:
WARNING!
This blog post contains answers to the questions I’ve asked in my “PMTUD or not? Troubleshooting case” article. If you want to work through them yourself, do not read the following.
Ok, let’s start. First I want to say that these answers are just my thoughts, and if you don’t agree – welcome to have a discussion. Maybe I’ll learn a lot of new things, and this is always great.
So,
Standalone question 1. Why the first thing I did was the server side capture?
My answer consists of two parts. Read more…
One day when I had a couple of free minutes I decided to perform some baselining in our office network.
This time my eye caught an interesting pattern in our NAS device traffic. Look at the screenshot below:
You see it? Maybe a couple of retransmissions? They may seem interesting. Delay of 6 seconds – it’s quite large to pay attention to it. But honestly there was some NFS-related stuff happening on the background that I’ve filtered out from the trace. So that’s not what I want to show you.
Now I’m talking about all those packets starting from number 67. All of them are 590 bytes in size. Of course, there are many packets, that are even less in size we can see before packet 67, BUT “TCP segment of a reassembled PDU” sign and the same size of 590 bytes tell us clearly that after packet 67 there must be fully-loaded packets. Fully-loaded packets of only 590 bytes size? Why is that? Read more…
|
I’m Vladimir, and I’m into Protocol analysis and troubleshooting for 5 years. I’m WCNA and CCNA.
Here I would like to share my experience – cases, tricks and other stuff I find interesting. If you have any questions – feel free to contact me on Linkedin or by mail on vlad [at] packettrain.net or just leave a comment. |