Details
-
Add New Device / OS
-
Resolution: Fixed
-
Minor
-
None
-
Professional Edition
-
Ubuntu 20.04LTS
Description
Summary
Two Huawei embedded power system controllers that expose EMAP-MIB (hwSiteMonitorMIB, .1.3.6.1.4.1.2011.6.164) are not detected as the Huawei power OS and fall back to linux and generic respectively. Both are caused by the current detection rule in includes/definitions/os/huawei.inc.php (block ending around line 217):
$config['os'][$os]['discovery'][] = [
|
'sysObjectID' => '.1.3.6.1.4.1.8072.3.2.10',
|
'sysDescr' => '/^Linux \w+/',
|
// EMAP-MIB::hwSiteName.0 = STRING: "Huawei eMap"
|
'EMAP-MIB::hwSiteName.0' => '/^Huawei/',
|
];
|
Device A: GSE200M site controller (ETP4890 legacy), detected as linux
sysObjectID: .1.3.6.1.4.1.8072.3.2.10
|
sysDescr: Linux GSE200M 2.6.27-SPEAr310 #5 Fri Mar 9 23:07:56 CST 2012 armv5tejl
|
EMAP-MIB::hwSiteName.0 = "SCLMAS01ETP4890"
|
EMAP-MIB::hwSiteDescription.0 = "HUAWEI SMU"
|
EMAP-MIB::hwMonEquipManufacturer.1 = "HUAWEI"
|
EMAP-MIB::hwMonEquipSoftwareVersion.1 = "V100R002C01B104SP04"
|
sysObjectID and sysDescr match the rule. The third condition fails because hwSiteName is a read-write, user-configurable site label. It was renamed from the factory default "Huawei eMap" to the site name, which is normal operational practice. Detection therefore depends on operators never renaming the site.
The device implements HUAWEI-SITE-MONITOR-MIB V1.01 (March 2011), an older revision of the same tree as the shipped EMAP-MIB (2012). All objects used by the sensor definitions that exist in V1.01 respond with identical OIDs (verified by full walk, attached). Objects added in the 2012 revision (hwRectsLoadUsage, hwRectifierTemperature, hwRectACVoltage, hwTotalRemainingCapacityPercent, hwTemp1/2, door sensor) are absent on this firmware.
Device B: SMU11B controllers (2x ETP48200-B1A1), detected as generic
sysObjectID: .1.3.6.1.4.1.2011.6.164.1.2 (EMAP-MIB::hwSiteMonitors)
|
sysDescr: SMU11B
|
No condition of the current rule matches: the sysObjectID is not the Net-SNMP agent OID and sysDescr does not start with "Linux". The controllers expose the full EMAP-MIB tree (walk attached).
Proposed fix
Match on read-only, vendor-fixed objects instead of the user-configurable hwSiteName, and add a rule for controllers whose sysObjectID points into the EMAP tree itself. Tested locally on all three devices; all are now detected and sensors are discovered.
// Legacy GSE200M site controller (ETP4890): generic Net-SNMP identity,
|
// manufacturer string is read-only and vendor-fixed.
|
$config['os'][$os]['discovery'][] = [
|
'sysObjectID' => '.1.3.6.1.4.1.8072.3.2.10',
|
'sysDescr' => '/^Linux GSE200M/',
|
// EMAP-MIB::hwMonEquipManufacturer.1 = STRING: "HUAWEI"
|
'EMAP-MIB::hwMonEquipManufacturer.1' => '/^HUAWEI/i',
|
];
|
|
|
// SMU11B and similar controllers report a node inside the EMAP-MIB tree as sysObjectID.
|
$config['os'][$os]['discovery'][] = [
|
// sysObjectID = .1.3.6.1.4.1.2011.6.164.1.2 (hwSiteMonitors), sysDescr = "SMU11B"
|
'sysObjectID' => '.1.3.6.1.4.1.2011.6.164.',
|
];
|
Alternatively the existing rule could be relaxed to test EMAP-MIB::hwMonEquipManufacturer.1 instead of hwSiteName.0, which would also cover other Linux-based controllers with a renamed site.
Additional observations from the GSE200M walk (for the sensor/status definitions)
- All OperStatus objects return 255 (other) permanently, including hwRectOperStatus for healthy rectifiers, hwMonitorOperStatus, hwAcInputOperStatus, hwDcOutputOperStatus and hwBattStringOperStatus. This firmware never reports normal(1). If the status definition treats 255 as a warning state, this device will show permanent warnings; treating 255 as ok/ignore for this OS may be appropriate.
- hwBattStringTemprature.1 returns -99999, the documented sentinel for "temperature sensor not configured" (hwBattsTemprature1/2 are not implemented at all). Please confirm the temperature sensor definition skips this sentinel rather than creating a sensor at -9999.9 C.
- Analogue values are scaled 0.1 (V, A, %) as documented in the MIB; matches the shipped definitions.
- Agent quirk: the GSE200M stops responding to GetNext beyond EMAP-MIB::hwBattsTestResultRowStatus.1 (end of hwBattsTestResultTable). A full-tree walk aborts there; walks of the remaining subtrees (.1.4.4, .1.5 to .1.8) work individually. The attached walk was assembled from these parts. Discovery/polling that walks the whole EMAP tree instead of individual tables may hang on this firmware.
Attachments
- sclmas01-etp4890-1.snmpwalk (GSE200M, full walk, -ObentU)
- sclmas01-r04-etp48200-1.snmpwalk (SMU11B, full walk, -ObentU)
- HUAWEI-SITE-MONITOR-MIB.mib (V1.01, for reference only, older revision of the shipped EMAP-MIB)
- huawei.inc.php.diff (local patch as above)