Subscriber Discussion

Iqinvision Iqd41s Cameras Reboot When Avigilon Looks For Cameras

UI
Undisclosed Integrator #1
Oct 13, 2016

I have two systems in a network. An avigilon system, and a zoneminder system, because licences are expensive. Everything worked great, until I decided to put everything on a single subnet. Then my three iqd41s cameras, that was being recorded with the zoneminder system, started to behave badly. After some testing I found out that the cameras were rebooting every minute. It was not the poe switch, and not the cameras on their own, as this did not happen when I isolated a camera from the network. I then suspected the avigilon system, which was the big new thing on that subnet. When I turned off the avigilon server software with the admin tool, the problems went away. When I turned it on again, the problems returned.

I suspect that it is some broadcast that is coming from the server, because setting up mac acl on the switch, with the destination address of the cameras and the server, did not stop it. Any packets from the cameras directly to the server, or the other way, would have been stopped by the acl. My best guess was that an initial broadcast message from the server was confusing the cameras. I then set protected mode on the camera ports and the server port in the cisco poe switch. This fixed the problems. The protected mode prevents broadcasts and multicasts between protected ports. I will do some more investigating tomorrow.

The iqeye cameras are running firmware version v3.3/1, and the avigilonserver is version 5.8.2.8.

But my question for you guys is: Does anyone know how to turn off the connect/disconnect function in avigilon? I think it is the discovery function that is doing this, and I don't think I need it to be running, because I know that avigilon can communicate with cameras on another subnet. It does not need arp broadcasts for camera communication. I would really like not to set up an extra router just for the server.

KL
Keefe Lovgren
Oct 13, 2016
IPVMU Certified

might be worth downloading the most recent version of acc and see if the issue persists...

U
Undisclosed #2
Oct 13, 2016
IPVMU Certified

Even if it is ACC causing it, it still an IQeye problem. A camera should not be rebooting because of any discovery arp.

Can you look at the errorlog of the cameras to see what it says caused the panic or reboot?

(1)
MT
Matt Transue
Oct 13, 2016

I agree with U2, this sounds like a camera problem.

To view the logs from the IQeye cameras, you need to telnet to it over port 2300. 2300 is the port used to view the debugging logs.

You can use something like Putty to achieve this.

**Important, the log data is only available for that session. Meaning, when the camera reboots, it clears the log data and starts over.**

Here is a technical tip on how to view debug information.

If you haven't already, you can try to factory reset the camera. I know that sounds strange and unrelated to what the problem is, but I can assure you that I've seen a factory reset fix stranger things. A factory reset probably has a low probability of resolving the issue and will require you to set the IP address and all other settings back to the way they were. Just keep that in mind.

I hope this helps.

(1)
UI
Undisclosed Integrator #1
Oct 17, 2016

I agree absolutely that Avigilon is not at fault here. The reason for me asking for the off-switch on the avigilonserver camera discovery function, was simply because I don't use it, and it would be an easier and better fix, then blocking off multicast etc. It would be nice if the problem did not return when some electrician replaces the switch, for instance.

Even if Avigilon were to send packets that were not up to standards, the cameras should not be so shocked by the rudeness that they faint. But they do, or rather they did. Because now I can't reproduce the behaviour. I installed a managed switch between the avigilonserver and the camera switch, and mirrored the avigilonport to a server for running tcpdump. I also telnetted to the logging port as Matt suggested. I then removed the measures I had put in place to prevent the rebooting. And then I was sort of hoping for some failure, but no. The darn thing will not behave badly. Everything is running like a Swiss watch.

I will have to leave this stuff running to see if the error returns. It took some time for the problem to arise the first time, so maybe there is some memory leak in the onvif server on the camera or something. Time will show.

Thank you all for your attention. I will update if the problem resurfaces.

UI
Undisclosed Integrator #1
Jun 22, 2017

An update

I put some equipment between the cameras and the Avigilon server to see what was going on. The equipment made the problem go away, and I got other stuff to do, so I left the equipment there until the problem came back. Time passed by, but today I removed the listening equipment, and the reboots came back.

I used wireshark, and found out, by configuring the Avigilon server firewall, that the problem went away if I block udp messages to port 3702 to ip 239.255.255.250. From what I can gather, this is multicast probing for onvif NetworkVideoTransmitter devices. The packets are xml documents with urls for www.onvif.org. The cameras are answering the server, with some information about the camera. Other cameras from other manufacturers answer too.

The Avigilon server keep up with sending these messages, several a second, for couple of seconds. Then it takes a break. But the IQInVision cameras seem to give up after 3 or 4 messages. I suspect some buffer overrun or something in the camera software. I believe these cameras were retrofitted with onvif, so maybe they had to "hack" a bit to make it work.

The cameras are working now, connected to a milestoneserver. The Avigilon server is hindered from doing onvif searches, but I see no need for it one this particular network anyway. And the plan is to replace the IQ cameras with avigilon ones soon.

But I put my findings here, in case someone run into some strange behaviour on their IQ cameras in the future.

(3)
New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions