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

False positive on OS detection with newer firmware on switch

Details

    • Add New Device / OS
    • Resolution: Fixed
    • Minor
    • None
    • CE-22.5
    • Discovery
    •  Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-40-generic x86_64)

    Description

      I just recently deployed an Observium server to monitor the network.  So far it has been great and no issues adding devices.    I have a few Ruggedcom switches some with up to date FW and one that needs a FW update.    On the older FW v5.5 the device are discovered and added as a generic device.  With v5.7 Observium gives a false positive of a Wowza Streaming engine after what appears to be a re-detect.

       

      o Re-Detect OS matched (wowza-engine: Wowza Streaming Engine):

       

      I'm pretty new at this so hopefully someone can point me in the right direction on how to resolve the issue.   Attached are both 5.5 and 5.7 discovery debugs.

      Attachments

        Activity

          [OBS-4892] False positive on OS detection with newer firmware on switch
          Andrew MacLeod Andrew Neil macleod added a comment -

          Thanks so much for your help.

          Andrew MacLeod Andrew Neil macleod added a comment - Thanks so much for your help.
          landy Mike Stupalov added a comment -

          This is new OS.

          Added support in r13651.

          landy Mike Stupalov added a comment - This is new OS. Added support in r13651.
          landy Mike Stupalov added a comment - - edited

          Seems this device is shit...

          Oid three 1.3.6.1.4.1 required for vendor private entities.
          Try more vendor specific Oids (but exacly with all options):

          snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1.3.6.1.4.1.15004 > myagent-ent.snmpwalk

          if this still get timeout, try same with bulk option:

          snmpbulkwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1.3.6.1.4.1.15004 > myagent-bulk.snmpwalk

          landy Mike Stupalov added a comment - - edited Seems this device is shit... Oid three 1.3.6.1.4.1 required for vendor private entities. Try more vendor specific Oids (but exacly with all options): snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1.3.6.1.4.1.15004 > myagent-ent.snmpwalk if this still get timeout, try same with bulk option: snmpbulkwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1.3.6.1.4.1.15004 > myagent-bulk.snmpwalk
          Andrew MacLeod Andrew Neil macleod added a comment - - edited

          The first command worked and is attached.  Second timed out.   A regular walk on that OID "snmpwalk -v2c -c <community> <host> .1.3.6.1.4.1" starts walking but eventually times out.  Attached the output.

           

           

          Andrew MacLeod Andrew Neil macleod added a comment - - edited The first command worked and is attached.  Second timed out.   A regular walk on that OID "snmpwalk -v2c -c <community> <host> .1.3.6.1.4.1" starts walking but eventually times out.  Attached the output.    
          landy Mike Stupalov added a comment -

          Based on your response, make snmpdump as this oids:

          snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1.3.6.1.2.1 > myagent.snmpwalk
          		 
          snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1.3.6.1.4.1 >> myagent.snmpwalk

          This is a new (unsupported) hardware, for improve detect and discovery need snmpdump.
          Or you can provide snmp access to test device, for this write me in Discord channel @landy

          landy Mike Stupalov added a comment - Based on your response, make snmpdump as this oids: snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1.3.6.1.2.1 > myagent.snmpwalk snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1.3.6.1.4.1 >> myagent.snmpwalk This is a new (unsupported) hardware, for improve detect and discovery need snmpdump. Or you can provide snmp access to test device, for this write me in Discord channel @landy
          Andrew MacLeod Andrew Neil macleod added a comment -

          Started dump '/tmp/<host>.snmpwalk' for device <host> from Oid: .
          WARNING. THIS MAY TAKE A WHILE, PLEASE BE PATIENT WHILE IT RUNNING...
          Check snmpdump running by cmd: wc -l /tmp/<host>.snmpwalk
          Timeout: No Response from udp:<host>:161
          Snmpdump not completed or exit by timeout.
          <user>@observium:/opt/observium$

           

          This works....  snmpwalk -v2c -c <community> <host> .1.3.6.1.2.1

           

          Andrew MacLeod Andrew Neil macleod added a comment - Started dump '/tmp/<host>.snmpwalk' for device <host> from Oid: . WARNING. THIS MAY TAKE A WHILE, PLEASE BE PATIENT WHILE IT RUNNING... Check snmpdump running by cmd: wc -l /tmp/<host>.snmpwalk Timeout: No Response from udp:<host>:161 Snmpdump not completed or exit by timeout. <user>@observium:/opt/observium$   This works....  snmpwalk -v2c -c <community> <host> .1.3.6.1.2.1  
          landy Mike Stupalov added a comment -

          you can make snmpdump by new script:

          ./scripts/snmpdump.php -h <device>

          where <device> is device_id or hostname of device as stored in observium db.

          landy Mike Stupalov added a comment - you can make snmpdump by new script: ./scripts/snmpdump.php -h <device> where <device> is device_id or hostname of device as stored in observium db.

          People

            landy Mike Stupalov
            Andrew MacLeod Andrew Neil macleod
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: