5-minute troubleshooting – “Remote IP-camera”

Posted on by Vladimir Gerasimov

Several weeks ago we were given a camera from one of our clients who said – “could you please check if it works correctly, something is not right”.

When we asked them about camera’s IP address, we got “I don’t know”. Well, it’s not the first time we hear that.

Fortunately, manufacturer has implemented MDNS-based camera discovery feature in own VMS (video management system). It worked and after performing discovery process we found IP address of the camera is 10.22.107.41 (By the way this was factory IP address for the cam, so it wasn’t changed by client).

So far so good, we tried to access the camera, but suddenly got “wrong password” response. For sure that meant the customer had changed default password. So we asked him for the actual one but got – you guessed it – “I don’t know, some other engineers have set it”.

Continue reading “5-minute troubleshooting – “Remote IP-camera”” →

Wireshark Hints: Multi-column

Posted on by Vladimir Gerasimov

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.

Read more…

Wireshark Hints: be aware of your current config!

Posted on by Vladimir Gerasimov

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…

5-minute troubleshooting. “No image!”

Posted on by Vladimir Gerasimov

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:

  • Add camera in corresponding menu:

  • Define an URL to access MJPEG-stream.

Read more…

5-minute troubleshooting. Can you hear me?

Posted on by Vladimir Gerasimov

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:

1_switch

Read more…

PMTUD or not? Part 2. My answers.

Posted on by Vladimir Gerasimov

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…

PMTUD or not? Troubleshooting case

Posted on by Vladimir Gerasimov

One day when I had a couple of free minutes I decided to perform some baselining in our office network.

The Problem

This time my eye caught an interesting pattern in our NAS device traffic. Look at the screenshot below:

1

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…