exporter crash upon using module

[PrestonTaylor]

Host operating system: output of uname -a

Linux someserver 3.10.0-1062.el7.x86_64 #1 SMP Wed Aug 7 18:08:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

snmp_exporter version: output of snmp_exporter -version

I'm using #624

What device/snmpwalk OID are you using?

1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.200
with

      - source_indexes: [tmnxWlanGwUeQryId] #(1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.1)
        lookup: tmnxWlanGwUeQryWhereState #(1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.3)

however a lookup of tmnxWlanGwUeQryName (1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.27) works fine

If this is a new device, please link to the MIB(s).

Not sure where to find publicly, it's quite rare I can share via this https://drive.google.com/file/d/1MkizXzWaEokQTLpQSGFKQsBJMv-6UbY_/view?usp=share_link

What did you do that produced an error?

error ocurrs only when I include the lookup

What did you expect to see?

minimum: no crash, ideally: no error and valid data returned. using snmpwalk and manageengine MIBBrowser I can walk this table without issue

What did you see instead?

Mar 20 18:56:04 myexporterserver snmp_exporter: ts=2023-03-20T22:56:04.339Z caller=main.go:98 level=debug module=mymodule target=someserver msg="Starting scrape"
Mar 20 18:56:04 myexporterserver snmp_exporter: ts=2023-03-20T22:56:04.358Z caller=collector.go:243 level=debug module=mymodule target=someserver msg="Walking subtree" oid=1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.200
Mar 20 18:56:05 myexporterserver snmp_exporter: ts=2023-03-20T22:56:05.413Z caller=collector.go:256 level=debug module=mymodule target=someserver msg="Walk of subtree completed" oid=1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.200 duration_seconds=1.055329302s
Mar 20 18:56:05 myexporterserver snmp_exporter: ts=2023-03-20T22:56:05.413Z caller=collector.go:243 level=debug module=mymodule target=someserver msg="Walking subtree" oid=1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.27
Mar 20 18:56:06 myexporterserver snmp_exporter: ts=2023-03-20T22:56:06.253Z caller=collector.go:256 level=debug module=mymodule target=someserver msg="Walk of subtree completed" oid=1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.27 duration_seconds=839.801075ms
Mar 20 18:56:06 myexporterserver snmp_exporter: ts=2023-03-20T22:56:06.253Z caller=collector.go:243 level=debug module=mymodule target=someserver msg="Walking subtree" oid=1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.3
Mar 20 18:56:07 myexporterserver snmp_exporter: ts=2023-03-20T22:56:07.093Z caller=collector.go:256 level=debug module=mymodule target=someserver msg="Walk of subtree completed" oid=1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.3 duration_seconds=839.986217ms
Mar 20 18:56:07 myexporterserver snmp_exporter: panic: Unknown index type Bits
Mar 20 18:56:07 myexporterserver snmp_exporter: goroutine 32 [running]:
Mar 20 18:56:07 myexporterserver snmp_exporter: github.com/prometheus/snmp_exporter/collector.indexOidsAsString({0xc0002b2870, 0x2, 0x2}, {0xc00025b2d8, 0xe5ce00}, 0x0, 0x0, 0xc000147478)
Mar 20 18:56:07 myexporterserver snmp_exporter: /home/centos/snmp_exporter/collector/collector.go:845 +0xd39
Mar 20 18:56:07 myexporterserver snmp_exporter: github.com/prometheus/snmp_exporter/collector.pduValueAsString(0xc0001475b8, {0xc00025b2d8, 0xc0000b0000})
Mar 20 18:56:07 myexporterserver snmp_exporter: /home/centos/snmp_exporter/collector/collector.go:734 +0x477
Mar 20 18:56:07 myexporterserver snmp_exporter: github.com/prometheus/snmp_exporter/collector.indexesToLabels({0xc000258380, 0x1, 0x10}, 0xc000263d80, 0x0)
Mar 20 18:56:07 myexporterserver snmp_exporter: /home/centos/snmp_exporter/collector/collector.go:876 +0x505
Mar 20 18:56:07 myexporterserver snmp_exporter: github.com/prometheus/snmp_exporter/collector.pduToSamples({0xc000258380, 0x1, 0x10}, 0xc000147be8, 0xc000263d80, 0x0, {0xa8c120, 0xc000080550})
Mar 20 18:56:07 myexporterserver snmp_exporter: /home/centos/snmp_exporter/collector/collector.go:501 +0x74
Mar 20 18:56:07 myexporterserver snmp_exporter: github.com/prometheus/snmp_exporter/collector.collector.Collect({{0xa9ab10, 0xc0000a2240}, {0xc0000aa086, 0x2a}, 0xc000115c20, {0xa8c120, 0xc000080550}}, 0xc000082840)
Mar 20 18:56:07 myexporterserver snmp_exporter: /home/centos/snmp_exporter/collector/collector.go:419 +0x817
Mar 20 18:56:07 myexporterserver snmp_exporter: github.com/prometheus/client_golang/prometheus.(*Registry).Gather.func1()
Mar 20 18:56:07 myexporterserver snmp_exporter: /home/centos/go/pkg/mod/github.com/prometheus/client_golang@v1.12.2/prometheus/registry.go:446 +0x102
Mar 20 18:56:07 myexporterserver snmp_exporter: created by github.com/prometheus/client_golang/prometheus.(*Registry).Gather
Mar 20 18:56:07 myexporterserver snmp_exporter: /home/centos/go/pkg/mod/github.com/prometheus/client_golang@v1.12.2/prometheus/registry.go:457 +0x4e8
Mar 20 18:56:07 myexporterserver systemd: snmp_exporter.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Mar 20 18:56:07 myexporterserver systemd: Unit snmp_exporter.service entered failed state.
Mar 20 18:56:07 myexporterserver systemd: snmp_exporter.service failed.

[sebastien-coavoux]

Hey

I believe the error is the data type as mentioned in the logs : Mar 20 18:56:07 myexporterserver snmp_exporter: panic: Unknown index type Bits
Looking at the provided MIB :

TmnxWlanGwUeQryEntry             ::= SEQUENCE
{       
    tmnxWlanGwUeQryId                Unsigned32,
    tmnxWlanGwUeQryRowStatus         RowStatus,
    tmnxWlanGwUeQryWhereState        BITS,
    tmnxWlanGwUeQryWhereMacAddress   MacAddress,
    tmnxWlanGwUeQryWhereAddrType     InetAddressType,
    [...] 
    tmnxWlanGwUeQryName              TNamedItem,
    tmnxWlanGwUeQryWhereSoftQuotaExh TruthValue,
    tmnxWlanGwUeQryNumResults        Gauge32
}

[...]

tmnxWlanGwUeQryWhereState        OBJECT-TYPE
    SYNTAX      BITS {
        bDataTriggered        (0),
        bDhcpTriggered        (1),
        bIpAssigned           (2),
        bAuthorizedOnly       (3),
        bIpAssignedAuthorized (4),
        bAlreadySignedIn      (5),
        bPortal               (6),
        bDistributedSubMgmt   (7),
        bEsmUser              (8),
        bL2User               (9),
        bGtpAuthorized        (10),
        bDeletePending        (11),
        bXcon                 (12)
    }
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The value of tmnxWlanGwUeQryWhereState specifies the set of UE state
         values.

         When the value of tmnxWlanGwUeQryWhereState is not all zeroes, the
         tmnxWlanGwUeResTable will contain only rows with this query ID where
         the value of the object tmnxWlanGwUeResState is equal to one of the
         states corresponding to the bits set in tmnxWlanGwUeQryWhereState.

         Setting the value of tmnxWlanGwUeQryWhereState to all zeroes is
         equivalent of setting it to all ones, and specifies that the
         tmnxWlanGwUeResTable may contain rows with this query ID having any
         value of the object tmnxWlanGwUeResState."
    DEFVAL      { {} }
    ::= { tmnxWlanGwUeQryEntry 3 }

From https://www.rfc-editor.org/rfc/rfc3416

The SMIv2 [[RFC2578](https://www.rfc-editor.org/rfc/rfc2578)] defines 11 base types (INTEGER, OCTET STRING,
   OBJECT IDENTIFIER, Integer32, IpAddress, Counter32, Gauge32,
   Unsigned32, TimeTicks, Opaque, Counter64) and the BITS construct.
 
 
   The SMIv2 BITS construct is mapped to the string-value selection type
   of the SimpleSyntax choice.  A BITS value is encoded as an OCTET
   STRING, in which all the named bits in (the definition of) the
   bitstring, commencing with the first bit and proceeding to the last
   bit, are placed in bits 8 (high order bit) to 1 (low order bit) of
   the first octet, followed by bits 8 to 1 of each subsequent octet in
   turn, followed by as many bits as are needed of the final subsequent
   octet, commencing with bit 8.  Remaining bits, if any, of the final
   octet are set to zero on generation and ignored on receipt.

My take would be, this type cannot be looked up to do mapping ?
tmnxWlanGwUeQryName (1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.27) is TNamedItem so not the same type as far as I can tell.
@SuperQ Is mapping on Bit supposed to work ?

@PrestonTaylor Do you have any error when generating the snmp file btw ?

On my side when using the snipped provided I have the following warning : ts=2023-03-28T14:43:05.768Z caller=main.go:119 level=warn msg="NetSNMP reported parse error(s)" errors=2105 but I think it is missing a more complete example.

So far I have:

modules:
 timetra:
   version: 2
   max_repetitions: 25
   timeout: 20s
   walk:
   - 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.1
   lookups:
     - source_indexes: [tmnxWlanGwUeQryId] #(1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.1)
       lookup: tmnxWlanGwUeQryWhereState #(1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.3)

NB: I had to download https://www.circitor.fr/Mibs/Html/T/TIMETRA-GLOBAL-MIB.php to be able to generate the snmp.yaml with this

Other option would be to provide the snmp.yaml snippet used.

Last thing, do you have a snmprec file to feed my snmpsim locally so I'll be able to test further ?

[PrestonTaylor]

Thanks for taking the time on this one.

generator log , I get the same warning but the number of "errors" remains the same if I include the lookup or not.

"ts=2023-03-29T19:21:35.255Z caller=net_snmp.go:161 level=info msg=\"Loading MIBs\" from=/home/user/prometheus/snmp_exporter_generator/mibs
ts=2023-03-29T19:21:36.503Z caller=main.go:120 level=warn msg=\"NetSNMP reported parse error(s)\" errors=78
ts=2023-03-29T19:21:36.871Z caller=main.go:52 level=info msg=\"Generating config for module\" module=arista
ts=2023-03-29T19:21:36.992Z caller=main.go:67 level=info msg=\"Generated metrics\" module=arista metrics=7
ts=2023-03-29T19:21:36.992Z caller=main.go:52 level=info msg=\"Generating config for module\" module=f5
ts=2023-03-29T19:21:37.079Z caller=main.go:67 level=info msg=\"Generated metrics\" module=f5 metrics=20
ts=2023-03-29T19:21:37.079Z caller=main.go:52 level=info msg=\"Generating config for module\" module=nokia_low_res
ts=2023-03-29T19:21:37.213Z caller=main.go:67 level=info msg=\"Generated metrics\" module=nokia_low_res metrics=12
ts=2023-03-29T19:21:37.213Z caller=main.go:52 level=info msg=\"Generating config for module\" module=nokia_high_res
ts=2023-03-29T19:21:37.289Z caller=main.go:67 level=info msg=\"Generated metrics\" module=nokia_high_res metrics=6
ts=2023-03-29T19:21:37.289Z caller=main.go:52 level=info msg=\"Generating config for module\" module=nokia_aaa
ts=2023-03-29T19:21:37.411Z caller=main.go:67 level=info msg=\"Generated metrics\" module=nokia_aaa metrics=1
ts=2023-03-29T19:21:37.411Z caller=main.go:52 level=info msg=\"Generating config for module\" module=nokia_extra
ts=2023-03-29T19:21:37.487Z caller=main.go:67 level=info msg=\"Generated metrics\" module=nokia_extra metrics=13
ts=2023-03-29T19:21:37.487Z caller=main.go:52 level=info msg=\"Generating config for module\" module=nokia_uequery
ts=2023-03-29T19:21:37.598Z caller=main.go:67 level=info msg=\"Generated metrics\" module=nokia_uequery metrics=1
ts=2023-03-29T19:21:37.604Z caller=main.go:92 level=info msg=\"Config written\" file=/home/user/prometheus/snmp_exporter/snmp_exporter_config.yml

Example of generator output (sorry, you can ignore the extra lookups, they make no difference if they are there or not)

nokia_uequery:
  walk:
  - 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.13
  - 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.14
  - 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.15
  - 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.200
  - 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.26
  - 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.27
  - 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.3
  metrics:
  - name: tmnxWlanGwUeQryNumResults
    oid: 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.200
    type: gauge
    help: The value of tmnxWlanGwUeQryNumResults indicates the current number of User
      Equipment matching this query - 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.200
    indexes:
    - labelname: tmnxWlanGwUeQryId
      type: gauge
    lookups:
    - labels:
      - tmnxWlanGwUeQryId
      labelname: tmnxWlanGwUeQryName
      oid: 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.27
      type: DisplayString
    - labels:
      - tmnxWlanGwUeQryId
      labelname: tmnxWlanGwUeQryWhereState
      oid: 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.3
      type: Bits
    - labels:
      - tmnxWlanGwUeQryId
      labelname: tmnxWlanGwUeQryWhereTuLocAddrTyp
      oid: 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.13
      type: gauge
    - labels:
      - tmnxWlanGwUeQryId
      labelname: tmnxWlanGwUeQryWhereTuLocAddr
      oid: 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.14
      type: InetAddress
    - labels:
      - tmnxWlanGwUeQryId
      labelname: tmnxWlanGwUeQryWhereEncap
      oid: 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.15
      type: gauge
    - labels:
      - tmnxWlanGwUeQryId
      labelname: tmnxWlanGwUeQryWhereAddrFamily
      oid: 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.26
      type: gauge
  version: 3
  retries: 2
  timeout: 30s
  auth:

snmprec:
edit: ..snip..

All Nokia/ALU/Timetra MIBs for this hardware:
edit: ..snip..

[sebastien-coavoux]

Hi there,

I gave a try and yes I can reproduce on the main branch, which was expected.

I would like to confirm first what is your intent here, you would like to have extra label in the prometheus output ?
Something like the following is what you are trying to achieve ?

# TYPE tmnxWlanGwUeQryNumResults gauge
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="100",tmnxWlanGwUeQryName="stagingho-p_v4_dsm",tmnxWlanGwUeQryWhereState="<FORMAT TO DEFINE>"} 2
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="101",tmnxWlanGwUeQryName="stagingho-p_v6_dsm",tmnxWlanGwUeQryWhereState="<FORMAT TO DEFINE>"} 0
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1017",tmnxWlanGwUeQryName="ivyland_dualstack",tmnxWlanGwUeQryWhereState="<FORMAT TO DEFINE>"} 3
[...]

If so then the issue we have is how to format it. A smpwalk (from the snmprec given) return something like Hex-STRING: 00 00. However this is just the default formatting there is the -O option to treat as ascii for instance..
Currently we don't handle the Bits case of the Lookup when receiving bits that is why it fails.

We can see in the code link that if typ is an empty string then it is assumed to be OctetString. I think it could be a good candidate for type Bits. Doing that get the following Prometheus output (format "0x")

# TYPE tmnxWlanGwUeQryNumResults gauge
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="100",tmnxWlanGwUeQryName="stagingho-p_v4_dsm",tmnxWlanGwUeQryWhereState="0x0100"} 2
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="101",tmnxWlanGwUeQryName="stagingho-p_v6_dsm",tmnxWlanGwUeQryWhereState="0x0100"} 0
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1017",tmnxWlanGwUeQryName="ivyland_dualstack",tmnxWlanGwUeQryWhereState="0x0000"} 3

We could set EnumAsInfofor instance, this change the format to integer-ish . Not sure if that makes sense

# TYPE tmnxWlanGwUeQryNumResults gauge
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="100",tmnxWlanGwUeQryName="stagingho-p_v4_dsm",tmnxWlanGwUeQryWhereState="1"} 2
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="101",tmnxWlanGwUeQryName="stagingho-p_v6_dsm",tmnxWlanGwUeQryWhereState="1"} 0
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1017",tmnxWlanGwUeQryName="ivyland_dualstack",tmnxWlanGwUeQryWhereState="0"} 3

@SuperQ @beorn7 Any advice on the last part on how to convert this ? I could make a PR out of that, it's a relative simple fix

[SuperQ]

Hmmm, doing a lookup on Bits is interesting. Yea, I'm not sure what the intended use case is here.

Handling Bits as a 0x string would probably make the most sense from a "Don't crash" perspective.

[PrestonTaylor]

tmnxWlanGwUeQryWhereState Is just another column in the same table, it actually maps to a value in the MIB like this

tmnxWlanGwUeQryWhereState        OBJECT-TYPE
    SYNTAX      BITS {
        bDataTriggered        (0),
        bDhcpTriggered        (1),
        bIpAssigned           (2),
        bAuthorizedOnly       (3),
        bIpAssignedAuthorized (4),
        bAlreadySignedIn      (5),
        bPortal               (6),
        bDistributedSubMgmt   (7),
        bEsmUser              (8),
        bL2User               (9),
        bGtpAuthorized        (10),
        bDeletePending        (11),
        bXcon                 (12)
    }

Whether it returns as
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="100",tmnxWlanGwUeQryName="stagingho-p_v4_dsm",tmnxWlanGwUeQryWhereState="1"} 2
or
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="100",tmnxWlanGwUeQryName="stagingho-p_v4_dsm",tmnxWlanGwUeQryWhereState="bDhcpTriggered"} 2

Either way isn't a huge deal to me, obviously the string makes for simpler transition to the presentation layer if the functionality already exists (I believe this is already in NetSNMP?), otherwise probably not worth the effort and simple output as hex is perfectly fine.

I recognize I'm using some pretty exotic OIDs and this isn't a an absolute must have for me to use the exporter as I can modify the names of tmnxWlanGwUeQryName to be descriptive enough cover the need so if this is a big lift it may not be worth the effort for you guys or may be more productive to just fix the service crashing. Let me know your thoughts.

[beorn7]

I don't have enough context about SNMP to make a call about the best way. But definitely we don't want the exporter to crash under these circumstances. :)

[sebastien-coavoux]

I did some test and EnumAsInfo could maps the values, as long as you feed it with enum_values.

I changed :

• In the code, pduValueAsString signature to have EnumValue map parameter so that indexOidsAsString call would have the map and not nil
• In the code, pduValueAsString call in lookup to get the map from the Metric
• In the snmp.yaml, put the enum_values snippet in the Metric but that should probably belong in Lookup (it already exists in Metric and Indexes)

snmp.yaml is the following (replace Bits by EnumAsInfo and added enum_values )

timetra:
  walk:
  - 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.200
  - 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.3
  metrics:
  - name: tmnxWlanGwUeQryNumResults
    oid: 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.200
    type: gauge
    help: The value of tmnxWlanGwUeQryNumResults indicates the current number of User
      Equipment matching this query - 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.200
    indexes:
    - labelname: tmnxWlanGwUeQryId
      type: gauge
    lookups:
    - labels:
      - tmnxWlanGwUeQryId
      labelname: tmnxWlanGwUeQryWhereState
      oid: 1.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.3
      type: EnumAsInfo
    enum_values:
      0: bDataTriggered
      1: bDhcpTriggered
      2: bIpAssigned
      3: bAuthorizedOnly
      4: bIpAssignedAuthorized
      5: bAlreadySignedIn
      6: bPortal
      7: bDistributedSubMgmt
      8: bEsmUser
      9: bL2User
      10: bGtpAuthorized
      11: bDeletePending
      12: bXcon
  version: 2
  max_repetitions: 25
  timeout: 20s

Without the enum_values (or without changing the code, ie map is nil)

tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="100",tmnxWlanGwUeQryWhereState="1"} 2
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="101",tmnxWlanGwUeQryWhereState="1"} 0
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1017",tmnxWlanGwUeQryWhereState="0"} 3
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1018",tmnxWlanGwUeQryWhereState="0"} 3
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1019",tmnxWlanGwUeQryWhereState="0"} 1
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="102",tmnxWlanGwUeQryWhereState="2"} 1
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1020",tmnxWlanGwUeQryWhereState="0"} 5
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1021",tmnxWlanGwUeQryWhereState="0"} 2
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1022",tmnxWlanGwUeQryWhereState="64"} 0
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1023",tmnxWlanGwUeQryWhereState="128"} 0
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="103",tmnxWlanGwUeQryWhereState="2"} 0
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="11",tmnxWlanGwUeQryWhereState="0"} 7

with the enum_values

tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="100",tmnxWlanGwUeQryWhereState="bDhcpTriggered"} 2
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="101",tmnxWlanGwUeQryWhereState="bDhcpTriggered"} 0
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1017",tmnxWlanGwUeQryWhereState="bDataTriggered"} 3
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1018",tmnxWlanGwUeQryWhereState="bDataTriggered"} 3
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1019",tmnxWlanGwUeQryWhereState="bDataTriggered"} 1
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="102",tmnxWlanGwUeQryWhereState="bIpAssigned"} 1
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1020",tmnxWlanGwUeQryWhereState="bDataTriggered"} 5
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1021",tmnxWlanGwUeQryWhereState="bDataTriggered"} 2
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1022",tmnxWlanGwUeQryWhereState="64"} 0
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="1023",tmnxWlanGwUeQryWhereState="128"} 0
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="103",tmnxWlanGwUeQryWhereState="bIpAssigned"} 0
tmnxWlanGwUeQryNumResults{tmnxWlanGwUeQryId="11",tmnxWlanGwUeQryWhereState="bDataTriggered"} 7

As you can see, based on the snmprec you gave me, not all values are mapped. So I am not sure if it is normal / expected.

If this is what we expect then there is a fix to do in the generator to add enum in lookup and to treat Bits as EnumAsInfo .

If that's not we can still stick to the OctetString quick fix to avoid crash

[PrestonTaylor]

Wow I just noticed that, that's bizarre. An plain old snmpwalk gets this,

iso.3.6.1.4.1.6527.3.1.2.81.1.11.3.1.3.1023 = Hex-STRING: 80 00

However if I reference the mib explicitly and ask it to perform lookups (snmpwalk -m TIMETRA-WLAN-GW-MIB) I get this

TIMETRA-WLAN-GW-MIB::tmnxWlanGwUeQryWhereState.1023 = BITS: 80 00 bDataTriggered(0)
TIMETRA-WLAN-GW-MIB::tmnxWlanGwUeQryWhereState.1022 = BITS: 40 00 bDhcpTriggered(1)

somehow netsnmp is figuring that out from the MIB, but as to how 128==0 and 64==1.... no idea.

[PrestonTaylor]

I just figured it out, it's a list of items and it matches on the n bit specified by the MIB

for example
TIMETRA-WLAN-GW-MIB::tmnxWlanGwUeQryWhereState.1024 = BITS: C2 00 bDataTriggered(0) bDhcpTriggered(1) bPortal(6)

C2=11000010
0th 1st and 6th bits

This complicates things even from my side, I didn't plan to use it like this and even if I did I don't know how it should look. This does appear to be a standard but I totally understand any hesitance to implement it. LMK what you guys think. I will probably opt to not put this in a lookup.

[sebastien-coavoux]

The implementation is pretty strange, because the way you interpret the value depend on the value size, and the maximum size is 12 bits. The value is a stack to "unpack", I would have expect a fixed size value and do bit masking.
How snmpwalk binary interpret 00 00 ? Nothing ?

This also mean that the bDataTriggered flag is always true when the value is not 0. Since we start reading at the first non null bit. Unless we only consider the last flag in the value ?

If that's not clear, here is a golang playground illustrating it.

Coming back to the fix, I agree it might be better to consider OctetString for now as I am not sure this transformation is accurate. Always better return a "raw" but correct value (what's on the wire) than something incorrectly transformed.

[SuperQ]

I think this is fixed now.