SNMP

[ryan-miller]

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?

[vegas50000]

Not even Amcrest knows. Just do an SNMP walk for common OIDs or use PRTG and have it scan for you: https://www.paessler.com/prtg

[jantman]

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 (.1.3.6.1.4.1.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 192.168.0.61 .1.3.6.1.4.1.1004849

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::deviceClass.0 = STRING: IPC

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::encodeNo.0 = INTEGER: 0

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: 255.255.255.0

DAHUA-SNMP-MIB::defaultGateway.0 = STRING: 192.168.0.1

DAHUA-SNMP-MIB::preferredDns.0 = STRING: 192.168.0.1

DAHUA-SNMP-MIB::alternateDns.0 = STRING: 1.0.0.1

DAHUA-SNMP-MIB::ipAddr.0 = STRING: 192.168.0.60

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.

[shaunmurray]

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