Closed ungrim97 closed 7 months ago
Hi @ungrim97 - are you able to share the entire MIB file? Just that it will help with testing.
@markabrahams Sadly the MIB I am using is proprietary and so I can't share it.
I can create a dummy example I suspect if that would be of help.
Hi @ungrim97 - yes if you're able to create a dummy minimal reproducible example, that would certainly help - thanks!
SMIv1 version
SMIv1-TEST-MIB DEFINITIONS ::= BEGIN
IMPORTS
OBJECT-TYPE, MODULE-IDENTITY
FROM SNMPv2-SMI
TEXTUAL-CONVENTION,
FROM SNMPv2-TC
enterprises
FROM RFC1155-SMI;
test -- 1.3.6.1.4.1.646843
OBJECT IDENTIFIER
::= { enterprises 646843 }
testMib -- 1.3.6.1.4.1.646843.677
MODULE-IDENTITY
LAST-UPDATED "202307211408Z" -- July 21th, 2023 at 14:08 UTC
ORGANIZATION "
Test Org"
CONTACT-INFO ""
DESCRIPTION "
Test MIB module for testing SMIv1 type definitions"
::= { test 677 }
---------------------------------------------------------------------------------------
-- --
-- Type definitions --
-- --
---------------------------------------------------------------------------------------
tsType
::= INTEGER
{
foo(1),
bar(2)
}
---------------------------------------------------------------------------------------
-- Branches --
---------------------------------------------------------------------------------------
tsSystem -- 1.3.6.1.4.1.646843.677.1
OBJECT IDENTIFIER
::= { testMib 1 }
tsHealthStatus -- 1.3.6.1.4.1.646843.677.1.1
OBJECT-TYPE
SYNTAX tsType
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Test Node"
::= { tsSystem 1 }
END
---------------------------------------------------------------------------------------
-- --
-- End of SMIv1-TEST-MIB Definion --
-- --
---------------------------------------------------------------------------------------
SMIv2 version of the same MIB
SMIv2-TEST-MIB DEFINITIONS ::= BEGIN
IMPORTS
OBJECT-TYPE, MODULE-IDENTITY
FROM SNMPv2-SMI
TEXTUAL-CONVENTION,
FROM SNMPv2-TC
enterprises
FROM RFC1155-SMI;
test -- 1.3.6.1.4.1.646843
OBJECT IDENTIFIER
::= { enterprises 646843 }
testMib -- 1.3.6.1.4.1.646843.677
MODULE-IDENTITY
LAST-UPDATED "202307211408Z" -- July 21th, 2023 at 14:08 UTC
ORGANIZATION "
Test Org"
CONTACT-INFO ""
DESCRIPTION "
Test MIB module for testing SMIv1 type definitions"
::= { test 677 }
---------------------------------------------------------------------------------------
-- --
-- Type definitions --
-- --
---------------------------------------------------------------------------------------
tsType
::= TEXTUAL-CONVENTION {
SYNTAX INTEGER
{
foo(1),
bar(2)
}
}
---------------------------------------------------------------------------------------
-- Branches --
---------------------------------------------------------------------------------------
tsSystem -- 1.3.6.1.4.1.646843.677.1
OBJECT IDENTIFIER
::= { testMib 1 }
tsHealthStatus -- 1.3.6.1.4.1.646843.677.1.1
OBJECT-TYPE
SYNTAX tsType
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Test Node"
::= { tsSystem 1 }
END
---------------------------------------------------------------------------------------
-- --
-- End of SMIv2-TEST-MIB Definion --
-- --
---------------------------------------------------------------------------------------
HI @markabrahams have you had any success with this at all?
Hi @ungrim97 - yes between the SMIv1 standard: https://datatracker.ietf.org/doc/html/rfc1155#section-3.2.1.1
and the ASN.1 standard: https://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf
it seems that the ASN.1 syntax for enumerated integers should be supported by SMIv1.
I haven't looked at this yet, but have lofty ambition to do so soon! :-)
@markabrahams Awesome. Do let me know if there is anything I can assist with.
Hi @ungrim97 - I've added support for SMIv1 integer enumerations now and published this in version 3.9.9 of the npm.
I am largely flailing in the dark with regard to formating.
However I am hitting an issue with parsing of Type Definitions using what I believe is SMIv1 type assignment format:
I believe that the above syntax is valid, and if I convert it to use a TEXTUAL-CONVENTION then it is parsed correctly such that any object using this type is recognised as having a type of Integer. i.e
I have been through the mib parser code, but cant figure out where it is best to add a fix for this sadly.
This is parsing an exiting MIB module file so I can't change it perminently so it will require a fix in the parser if possible