Uploaded image for project: 'Observium'
  1. Observium
  2. OBS-5297

EMAP-MIB OS detection fails on renamed hwSiteName (GSE200M) and on SMU11B controllers reporting sysObjectID inside the EMAP tree

    XMLWordPrintable

Details

    • Add New Device / OS
    • Resolution: Fixed
    • Minor
    • None
    • Professional Edition
    • Discovery
    • 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)

      Attachments

        Activity

          People

            landy Mike Stupalov
            gjeker Gregor Jeker
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: