Custom SNMP Discovery Fails on Yokohama - All Handler/Probe Methods Exhausted

[Preston_83]

I've run into a very stubborn issue trying to discover a specific set of older Axis IP cameras on my Yokohama instance, and I'm hoping someone in the community might have seen this behavior before.

The Goal: Discover ~2,000 Axis IP cameras. A lot of these devices are older and do not have a standard serial number OID. My identification strategy is to get the device's MAC address and use that to derive a unique serial number and name.

The Challenge:

1. SNMP walk works: I have confirmed that running a simple snmpwalk.exe -v2c command from my Windows MID Server successfully retrieves the full MAC address table from the cameras. The data is accessible.
2. Patterns fail: Standard Discovery patterns fail. The SNMP Query operation in the Pattern Designer appears to use a Java SNMP library that has issues with SNMP bulk-gets on these older device firmwares, causing the pattern to fail and not return any data.

Because patterns were inconsistent with a chunk of devices on my network, I moved on to custom probes and sensors, but every attempt has been blocked by what appears to be platform-level configuration issues.

Core Configuration: I have already configured the foundational pieces for this discovery, and the initial steps are working as expected:

• SNMP OID Classification: I have a rule that correctly matches the camera's sysObjectID (1.3.6.1.4.1.368.1.1) and assigns the IP Camera class. The discovery logs confirm this classification is successful.
• IRE/Identifier: We have created a dedicated Identifier for the cmdb_ci_ip_camera class with multiple high-priority entries (Serial Number, Name, and MAC Address) to ensure that if any of this data were present in the final payload, the IRE would successfully create the CI.

Architectures Attempted:

1. Custom Probe w/ MID Server Script Include: I created a custom probe using the JavascriptProbe topic that called a MID Server Script Include. Result: This failed with the error MID Server Script Include output does not exist. I believe that the script file was never synchronized to the mid servers, even after correcting ACLs, scopes, and clearing the cache and restarting the mid servers.
2. Custom Probe w/ Embedded Script: I then embedded the script directly into the probe record itself to bypass the file sync issue. Result: This also failed with the same MID Server Script Include output does not exist error, which seems impossible.
3. Custom Javascript Handler (The Final Approach): I configured the out-of-the-box SNMP - Classify probe to collect the MAC address table and added a custom Javascript Handler (AxisHandler) to its javascript_handlers parameter, which I had to modify a field parameter because the field was limited to 40 characters.
• Result: The ECC Queue logs show the probe runs and collects the MAC address data, but my AxisHandler script is never executed. I confirmed this by placing simple gs.log() statements as the only code in the handler, and no logs are ever generated.
  
  

My Question for the Community:

Has anyone ever encountered a situation on the Yokohama release where the SNMP - Classify sensor seems to ignore the javascript_handlers parameter? Is there a known issue or an alternative architectural pattern for executing a simple command-line tool (like snmpwalk) and parsing its output that I haven't tried?

I have exhausted all configuration paths I know about and now believe the systems out of box snmp discovery probes are just not allowing my probes to run. I assumed that once the OID was classified it would trigger the probe I configured to trigger in the classification setup, but it isn’t triggering my probe. Any insight would be greatly appreciated.

Thank you!

[Fabian Kunzke]

Hey,

That is indeed interesting. The easiest way to enforce this credential is likely by credential-aliases.

With credential aliases you can assign the alias to the credential. Then create a separate discovery schedule for your cameras & assign the alias to the schedule (this will limit the credentials used in the schedule to only the ones assigned to the alias). This is only a "good" solution, if the IP cameras are in distinguishable networks (otherwise you will scan everything in that network with just that one credential, which may cause issues in firewalls).

If you don't have the option to distinguish into different network schedules (e.g. because you cameras are in networks which are not separated from the rest), you will need to add a behavior to these schedules to ignore all devices except for your IP cameras.

Not the issue why this may occur is down to how the IP scanning phase for SNMP uses credentials. For SNMP v1/v2 (and only for these IP port probes) credentials are already applied in the IP scanning phase. If you cameras are reacting positively to the public community string, other credentials might be ignored in later stages of the discovery. This is down to SNMP v1/v2. So to completely solve this issue, your best bet would be to reconfigure all these devices to run SNMP v3 only...

Hope this brings a bit more clarity and also an option on how to address this.

Regards

Fabian