‎04-20-2025 10:58 AM
Snmpwalk works fine
# snmpwalk -On -v 3 -l authPriv -u ro -a SHA -A '' -x AES -X '' 192.168.99.211 .1.3.6.1.4.1.1916.1.19.1.1.3
.1.3.6.1.4.1.1916.1.19.1.1.3.3.49.58.56.1008 = INTEGER: 1
.1.3.6.1.4.1.1916.1.19.1.1.3.3.49.58.56.2008 = INTEGER: 2
.1.3.6.1.4.1.1916.1.19.1.1.3.4.49.58.50.51.1023 = INTEGER: 2
.1.3.6.1.4.1.1916.1.19.1.1.3.4.49.58.50.51.2023 = INTEGER: 2
.1.3.6.1.4.1.1916.1.19.1.1.3.4.49.58.52.48.1040 = INTEGER: 1
.1.3.6.1.4.1.1916.1.19.1.1.3.4.49.58.52.48.2040 = INTEGER: 1
.1.3.6.1.4.1.1916.1.19.1.1.3.4.49.58.52.49.1041 = INTEGER: 1
.1.3.6.1.4.1.1916.1.19.1.1.3.4.49.58.52.49.2041 = INTEGER: 1
.1.3.6.1.4.1.1916.1.19.1.1.3.4.49.58.52.50.1042 = INTEGER: 1
.1.3.6.1.4.1.1916.1.19.1.1.3.4.49.58.52.50.2042 = INTEGER: 1
.1.3.6.1.4.1.1916.1.19.1.1.3.4.49.58.52.53.1045 = INTEGER: 1
.1.3.6.1.4.1.1916.1.19.1.1.3.4.49.58.52.53.2045 = INTEGER: 1
Snmpget does not (note it's one of the exact same OID from above)
# snmpget -On -v 3 -l authPriv -u ro -a SHA -A '' -x AES -X '' 192.168.99.211 .1.3.6.1.4.1.1916.1.19.1.1.3.4.49.58.52.53.2045
.1.3.6.1.4.1.1916.1.19.1.1.3.4.49.58.52.53.2045 = No Such Instance currently exists at this OID
Why could this be?
(X690 EXOS 31.7.1.4)
‎04-21-2025 09:57 PM
The discrepancy between `snmpwalk` working and `snmpget` failing on the same OID likely stems from `snmpget` requiring the full, explicit instance identifier present in the `snmpwalk` output. Ensure you are using the exact, complete OID from `snmpwalk` in your `snmpget` command. Other less likely causes include typos, transient data, or rare SNMP agent behavior. Try using `snmpgetnext` on a parent OID to investigate further and check the SNMP agent's documentation or logs if available.
‎04-22-2025 01:58 AM
Can you elaborate what exactly you mean? I've posted the output, so we see there is no typo.