Discussion for all types of camera
Posts: 2
Joined: Sat May 28, 2016 10:34 pm


Postby ryan-miller » Sat May 28, 2016 10:36 pm

Trying to set up SNMP traps.
Documentation seems to be virtually non existent for this feature.
I need to know the OID's for all events.

I have the ProHD 1080 Wireless IP Camera.

Any Help?

Posts: 14
Joined: Wed Jan 11, 2017 12:32 am


Postby vegas50000 » Thu Feb 16, 2017 9:44 pm

Not even Amcrest knows. Just do an SNMP walk for common OIDs or use PRTG and have it scan for you:

Posts: 13
Joined: Thu May 03, 2018 12:36 pm
Location: Atlanta, GA


Postby jantman » Sun May 06, 2018 6:00 am

I have two cameras, an IP2M-841B (ProHD 1080P) running 2.520.AC00.18.R 2017-06-29 and an IPM-723W running 2.400.AC02.15.R 2017-07-31. Only the 841B running 18.R supports SNMP.

Based on that camera, there are two sets of camera-related MIBs in these devices. One is the Dahua MIB (Dahua appears to be the OEM of either these cameras or at least the software used in them) rooted at SNMPv2-SMI::enterprises.1004849 (. I was able to find the MIB file for that online in a LibreNMS issue and a IPcamTalk forum post. Unfortunately, it doesn't seem to contain a whole lot of information - just device information, network/port information, and the last event type:

Code: Select all

$ snmpwalk -OUeb -v1 -c public -M $HOME/.snmp/mibs:/usr/share/snmp/mibs:MIB/:$(pwd)/SNMP/MIB/ -mALL .
DAHUA-SNMP-MIB::softwareRevision.0 = STRING: 2.520.AC00.18.R
DAHUA-SNMP-MIB::hardwareRevision.0 = STRING: 1.00
DAHUA-SNMP-MIB::videoChannel.0 = INTEGER: 0
DAHUA-SNMP-MIB::alarmInput.0 = INTEGER: 1
DAHUA-SNMP-MIB::alarmOutput.0 = INTEGER: 1
DAHUA-SNMP-MIB::serialNumber.0 = STRING: AMC00056485D24AAF8
DAHUA-SNMP-MIB::systemVersion.0 = STRING: 2.520.0000.18, Build Date:2017-06-29
DAHUA-SNMP-MIB::deviceType.0 = STRING: IP2M-841B
DAHUA-SNMP-MIB::deviceStatus.0 = INTEGER: 1
DAHUA-SNMP-MIB::machineName.0 = STRING: AMC00056_24AAF8
DAHUA-SNMP-MIB::cpuUsage.0 = INTEGER: 70
DAHUA-SNMP-MIB::lastestEvent.0 = STRING: videoBlindEvent
DAHUA-SNMP-MIB::tcpPort.0 = INTEGER: 37777
DAHUA-SNMP-MIB::udpPort.0 = INTEGER: 37778
DAHUA-SNMP-MIB::httpPort.0 = INTEGER: 80
DAHUA-SNMP-MIB::rtspPort.0 = INTEGER: 554
DAHUA-SNMP-MIB::maxConnectNum.0 = INTEGER: 10
DAHUA-SNMP-MIB::httpsPort.0 = INTEGER: 443
DAHUA-SNMP-MIB::getIpmode.0 = INTEGER: 0
DAHUA-SNMP-MIB::macAddr.0 = STRING: 9c:8e:cd:15:18:31
DAHUA-SNMP-MIB::ipVersion.0 = INTEGER: 0
DAHUA-SNMP-MIB::subnetMast.0 = STRING:
DAHUA-SNMP-MIB::defaultGateway.0 = STRING:
DAHUA-SNMP-MIB::preferredDns.0 = STRING:
DAHUA-SNMP-MIB::alternateDns.0 = STRING:
DAHUA-SNMP-MIB::localAlarmIndex.1 = INTEGER: 1
DAHUA-SNMP-MIB::networkAlarmIndex.1 = INTEGER: 1

Then, it appears that there are also some vendor-specific (Amcrest) MIBs added to the device. Two snippets from an snmpwalk, separated by "...":

Code: Select all

SNMPv2-MIB::sysORID.15 = OID: ccitt.1
SNMPv2-MIB::sysORID.16 = OID: ccitt.1
SNMPv2-MIB::sysORID.17 = OID: ccitt.1
SNMPv2-MIB::sysORID.18 = OID: ccitt.1
SNMPv2-MIB::sysORID.19 = OID: ccitt.1
SNMPv2-MIB::sysORID.20 = OID: ccitt.1
SNMPv2-MIB::sysORID.21 = OID: ccitt.1
SNMPv2-MIB::sysORID.22 = OID: ccitt.1
SNMPv2-MIB::sysORID.23 = OID: ccitt.1
SNMPv2-MIB::sysORID.24 = OID: ccitt.1
SNMPv2-MIB::sysORID.25 = OID: ccitt.1
SNMPv2-MIB::sysORDescr.15 = STRING: RegularStreamInfoTable
SNMPv2-MIB::sysORDescr.16 = STRING: MDStreamInfoTable
SNMPv2-MIB::sysORDescr.17 = STRING: AlarmStreamInfoTable
SNMPv2-MIB::sysORDescr.18 = STRING: Extra1StreamInfoTable
SNMPv2-MIB::sysORDescr.19 = STRING: VideoMotionInfoTable
SNMPv2-MIB::sysORDescr.20 = STRING: VideoLossInfoTable
SNMPv2-MIB::sysORDescr.21 = STRING: VideoBlindInfoTable
SNMPv2-MIB::sysORDescr.22 = STRING: LocalAlarmInfoTable
SNMPv2-MIB::sysORDescr.23 = STRING: NetworkAlarmTable
SNMPv2-MIB::sysORDescr.24 = STRING: RecordMainStreamInfoTable
SNMPv2-MIB::sysORDescr.25 = STRING: PhysicalVolumeInfoTable

Unfortunately, as far as I can tell these additional MIBs are broken. SNMPv2-MIB is reporting them as rooted at "ccitt.1", or ".0.1", which if I recall my time working with SNMP correctly, is an invalid OID and where Net-SNMP and friends put custom MIBs that weren't configured properly. It definitely seems that this information - given the table names - would be very useful, but as far as I can tell it's not actually being served, likely the result of an SNMP misconfiguration in the firmware.

I haven't tried it yet, but for the traps, my plan is to enable both the SNMP traps and SMTP (email) notifications and then attempt to trigger each alarm condition and correlate the email alarms to the SNMP traps.
Lead Software Engineer, Tooling & Automation. Formerly, Wireless & Network Systems Engineer.
Doing all sorts of crazy things to anything with an IP address. /

Posts: 28
Joined: Fri Feb 09, 2018 9:19 am


Postby shaunmurray » Tue May 08, 2018 6:26 am

Tagging along... Working on monitoring as well. Would love it if Amcrest would speak up.

Return to “Technical Discussion”

Who is online

Users browsing this forum: No registered users and 15 guests