Broken or missing SNMP MIBS for firmware 10.0.0.31 (GSM7352Sv2)

Here's an update, as Netgear support have kindly provided me with new MIBs for 10.x firmware. To summarise:

* There are different MIBs for 10.x firmware versus 8.x firmware

* The MIBs are incompatible. They re-use the same OIDs but with different semantics :eek:. In the case of environmental sensors, both are called fastpath_boxservices.my and both sit at OID { ng7000managedswitch 43 }

* This means it's impossible to load 8.x and 10.x MIBs at the same time. Netgear assume that your network does not have a mixture of equipment.

However in our case, we have some GSM7224v2, for which there is 8.x firmware but not 10.x; and we have some M4100-50G for which there is 10.x firmware but not 8.x. We also have some GSM7352Sv2 which can run either.

* Since the GSM7352Sv2 returns the same sysObjectID regardless of whether it's running 8.x or 10.x, there is no sensible way to auto-detect which MIB flavour to use.

Example of differences - fan status

(8.x)
    boxServicesFanItemState OBJECT-TYPE
             SYNTAX      INTEGER {
                                  operational(1),
                                  failed(2),
                                  powering(3),
                                  notpowering(4),
                                  notpresent(5)
                                 }

(10.x)
    boxServicesFanItemState OBJECT-TYPE
             SYNTAX      INTEGER {
                                  notpresent(1),
                                  operational(2),
                                  failed(3),
                                  powering(4),
                                  nopower(5),
                                  notpowering(6),
                                  incompatible(7)
                                 }

The data is presented at the same OID, but the values have different meanings. Clearly Netgear could have enhanced the MIB in a backwards-compatible way by adding new values and keeping the old ones unchanged, but instead they shuffled them all around.

boxServicesPowSupplyItemState has the same issue.

Upgrading firmware from 8.x to 10.x without also changing your monitoring scripts will cause spurious errors. e.g. an "operational" fan will change from value 1 to value 2, which is "failed" in the old MIB. :(

Example of differences - temperature

(8.x)
    boxServicesTempSensorsEntry OBJECT-TYPE
         SYNTAX      BoxServicesTempSensorsEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
                     "Box Services Temperature Sensor Entry"
         INDEX { boxServicesTempSensorIndex }
         ::= { boxServicesTempSensorsTable 1 }

(10.x)
    boxServicesTempSensorsEntry OBJECT-TYPE
         SYNTAX      BoxServicesTempSensorsEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
                     "Box Services Temperature Sensor Entry"
         INDEX { boxServicesUnitIndex, boxServicesTempSensorIndex }
         ::= { boxServicesTempSensorsTable 1 }

Notice how the INDEX line has changed. The table now has a compound index (UnitIndex, TempSensorsIndex). UnitIndex is defined in the MIB as being a value between 1 and 8, I guess to do with stacking.

This is why the OIDs are one component longer than they were before.

If the monitoring system is still polling the old OID, it will find no data there at all.

However, once you find the new OID, at least the values returned are the same:

    boxServicesTempSensorState OBJECT-TYPE
             SYNTAX      INTEGER {
                                  normal(1),
                                  warning(2),
                                  critical(3),
                                  shutdown(4),
                                  notpresent(5),
                                  notoperational(6)
                                 }

I hope this helps anyone else who comes across the same issue!

Regards,

Brian.