Skip to content
DataMiner DoJo

More results...

Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
Search in posts
Search in pages
Search in posts
Search in pages
Log in
Menu
  • Updates & Insights
  • Questions
  • Learning
    • E-learning Courses
    • Empower Replay: Limited Edition
    • Tutorials
    • Open Classroom Training
    • Certification
      • DataMiner Fundamentals
      • DataMiner Configurator
      • DataMiner Automation
      • Scripts & Connectors Developer: HTTP Basics
      • Scripts & Connectors Developer: SNMP Basics
      • Visual Overview – Level 1
      • Verify a certificate
    • Video Library
    • Books We Like
    • >> Go to DataMiner Docs
  • Expert Center
    • Solutions & Use Cases
      • Solutions
      • Use Case Library
    • Markets & Industries
      • Media production
      • Government & defense
      • Content distribution
      • Service providers
      • Partners
      • OSS/BSS
    • Agile
      • Agile Webspace
      • Everything Agile
        • The Agile Manifesto
        • Best Practices
        • Retro Recipes
      • Methodologies
        • The Scrum Framework
        • Kanban
        • Extreme Programming
      • Roles
        • The Product Owner
        • The Agile Coach
        • The Quality & UX Coach (QX)
    • DataMiner DevOps Professional Program
      • About the DevOps Program
      • DataMiner DevOps Support
  • Downloads
  • More
    • DataMiner Releases & Updates
    • Feature Suggestions
    • Climb the leaderboard!
    • Swag Shop
    • Contact
      • General Inquiries
    • Global Feedback Survey
  • PARTNERS
    • All Partners
    • Technology Partners
    • Strategic Partner Program
    • Deal Registration
  • >> Go to dataminer.services

Protocol managing minor OID differences

Solved337 views27th April 2025firmware protocol versioning
0
Sam Stump [DevOps Advocate]616 8th November 2024 1 Comment

This question and documentation suggests the versioning for protocols to support updated vendor firmware.

A question regarding versioning strategy of connectors as recommended by Skyline

https://docs.dataminer.services/develop/devguide/Connector/ProtocolVersionSemantics.html

However for minor OID updates we want our protocols to be able to just adapt automatically and deal with it without having to manage more alarm templates for non-production protocol version and without having any dataminer adminstrator interaction to change element protocol versions when a field engineer updates the firmware of the device at all sorts of hours of the day.   We just want things to keep working automatically.

An example is from DEVA DB8009 firmware 2.x to 3.x they have introduced a new OID and changed 3 others by a minus 1 of three integers.  [ https://www.devabroadcast.com/products/db8009-mpx ]

As the firmware version is available to read in the MIB I’d like to be able to have the OID update automatically to a new OID.

I’ve got some loose ideas how to start this but am very interested if anyone else has made some simple or creative solution to dealing with minor oid changes across vendor firmware to be able to have the protocol manage itself.

The initial idea I had:

Having the polling group containing the firmware parameter with initial=true and delay the parameter group getting the OIDs above.

All the OIDS above are

srcmain: <OID id=“200”>1.3.6.1.4.1.35833.30.2.4.*</OID>

backup1: <OID id=“201”>1.3.6.1.4.1.35833.30.2.4.*</OID>

backup2: <OID id=“202“>1.3.6.1.4.1.35833.30.2.4.*</OID>

backup3: <OID id=“203”>1.3.6.1.4.1.35833.30.2.4.*</OID>

Parameters 200-203 have a default value in line with the most common firmware, and backup3 parameter in a group on it’s own with a condition to not poll at all if the firmware isn’t greater than a certain threshold.

Have a QAction triggered on the firmware parameter to check the firmware version and update parameters 200-203 with the integer that matches the desired OID for that firmware.

Sam Stump [DevOps Advocate] Selected answer as best 27th April 2025
Marieke Goethals [SLC] [DevOps Catalyst] commented 18th April 2025

Hi Sam,
I see that this question has been inactive for some time. Do you still need help with this? If not, could you select the answer (using the ✓ icon) to indicate that no further follow-up is needed?

1 Answer

  • Active
  • Voted
  • Newest
  • Oldest
0
Robin Spruytte [SLC] [DevOps Advocate]647 Posted 13th November 2024 3 Comments

Hi Sam,

The method you are suggesting is a correct workaround. By either using a togglebutton or check the version via polling, you can fill the wildcards with the correct OIDs. We use it in a lot of our drivers as a means to support multiple OID versions, but only in the following cases:

  • All (or big groups of) affected parameters have the same change in OID. An example would be when all OIDs change from A.B.C.X.Y.Z -> D.E.F.X.Y.Z where the A.B.C. changed but the rest of the number stayed the same. In this case the same wildcard (*) can be reused for a lot of parameters.
  • When the amount of impacted parameters is considered low

If the use case does not fit any of these descriptions and there is no particular logic to the OID changes, we are more likely to consider it as a firmware change instead, which leads to a new version according to our versioning strategy

Do note that these rules are not set in stone and the final decision can differ from case to case

Sam Stump [DevOps Advocate] Selected answer as best 27th April 2025
Sam Stump [DevOps Advocate] commented 14th November 2024

Thank you Robin for that reply, I did start working on an update to the protocol and did pretty much what you said

screenshots here: https://internect.net/dma/subOID.png

But I get "Get for srcmain () had error : NO SUCH NAME" in the StreamViewer 🙁

Cannot understand what is wrong. Any ideas?

Robin Spruytte [SLC] [DevOps Advocate] commented 14th November 2024

That error usually means the OID that it tries to poll is not available on the device.
In this case, although I'm not sure if that's the exact issue, I would already suggest to make the wildcard parameter of type string. A type string should be used since we can use the wildcard for more than a single number in the OID.

This means changing the Interprete > Type to 'string' and Interprete > RawType to 'other'. Apart from that, I don't see anything wrong with the code and it should be checked if the correct OID is retrieved and that OID is available on the device.

Sam Stump [DevOps Advocate] commented 9th December 2024

Thanks Robin,

Made that change but still didn't fix it – you were correct with the OID not being available on the device – which I couldn't see at the time.

I had something like this:
srcmain: <OID id="200">1.3.6.1.4.1.35833.30.2.4.*</OID>

backup1: <OID id="201">1.3.6.1.4.1.35833.30.2.4.*</OID>

backup2: <OID id="202">1.3.6.1.4.1.35833.30.2.4.*</OID>

backup3: <OID id="203">1.3.6.1.4.1.35833.30.2.4.*</OID>

BUT, I should have had THIS with Trailing Zeroes

srcmain: <OID id="200">1.3.6.1.4.1.35833.30.2.4.*.0</OID>

backup1: <OID id="201">1.3.6.1.4.1.35833.30.2.4.*.0</OID>

backup2: <OID id="202">1.3.6.1.4.1.35833.30.2.4.*.0</OID>

backup3: <OID id="203">1.3.6.1.4.1.35833.30.2.4.*.0</OID>

Please login to be able to comment or post an answer.

My DevOps rank

DevOps Members get more insights on their profile page.

My user earnings

0 Dojo credits

Spend your credits in our swag shop.

0 Reputation points

Boost your reputation, climb the leaderboard.

Promo banner DataMiner DevOps Professiona Program
DataMiner Integration Studio (DIS)
Empower Katas
Privacy Policy • Terms & Conditions • Contact

© 2025 Skyline Communications. All rights reserved.

DOJO Q&A widget

Can't find what you need?

? Explore the Q&A DataMiner Docs