Anyone faced issue with snmptd. It is dumping message in Hex.
This behavior was changed in version 3.13. Now the probe converts each variable to hex if it finds any non-alphanumeric characters. Prior versions also converted variables to hex but not nearly as frequently. You can disable the conversion behavior completely by changing this in the config:
VariablesToHex = no
The setting should appear in the config file by default but set to "yes".
That worked, no documented mentioned same.
But still probe still behaves erratically in resolving OID. I rearely resolve same. I was able to make it working after many restart but fails after sometime... mostly it generate trap with OID like iso.220.127.116.11.1.6818.104.22.168.0.12 instead of G3-AVAYA-TRAP::alarmRestart . As snmpget/SNMPwalk able to resolve same , i am not able to figureout why its's not working with SNMPTD
I have not seen an issue like that, but I do not think most of our alarms from traps include the OID. If you are able to reproduce the issue manually, I would recommend cranking up the loglevel in the probe and trying to gather logs that show it working and show it not working for the same OID. You might find something interesting, but that would be excellent information to put into a support case.
This is interesting; is there a support case? Could you send me a case number?
What versions are
Retrieving data ...