Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SNMP v3 with incorrect auth password outputs bad data #7512

Closed
ptrdlbrg opened this issue May 14, 2020 · 2 comments
Closed

SNMP v3 with incorrect auth password outputs bad data #7512

ptrdlbrg opened this issue May 14, 2020 · 2 comments
Labels
area/snmp bug unexpected problem or unintended behavior error handling Issues related to error handling

Comments

@ptrdlbrg
Copy link

Relevant telegraf.conf:

[agent]
  omit_hostname = true

[[outputs.file]]
  files = ["stdout"]
  data_format = "influx"

[[inputs.snmp]]
  agents = [ "udp://10.10.10.1:161" ]
  version = 3
  sec_name = "telegraf"
  auth_protocol = "SHA"
  auth_password = "${SNMP_AUTH_PASSWORD}"
  sec_level = "authPriv"
  priv_protocol = "AES"
  priv_password = "${SNMP_PRIV_PASSWORD}"
 
  [[inputs.snmp.field]]
    oid = "RFC1213-MIB::sysName.0"
    name = "source"
    is_tag = true

  [[inputs.snmp.field]]
    oid = "RFC1213-MIB::sysUpTime.0"
    name = "uptime"

System info:

Docker image telegraf:1.14.2-alpine

The SNMP target I'm using is a Ubiquiti EdgeRouter 12. I haven't tested using any other SNMP target.

Docker

I'm using the telegraf:1.14.2-alpine docker image with the /etc/telegraf/telegraf.conf file either copied into the container or bind-mounted. The environment variables SNMP_AUTH_PASSWORD and SNMP_PRIV_PASSWORD are set when running the container, but the same behavior occurs if the password values are specified directly in the config file.

Steps to reproduce:

  1. Have a running SNMP v3 agent with security level authpriv.
  2. In the telegraf.conf specified above, replace the snmp agents, sec_name, and priv_password values so they would be valid when querying the SNMP v3 agent.
  3. Replace the auth_password so it is incorrect for the SNMP agent being queried
  4. Run the telegraf docker container using the telegraf configuration.

Expected behavior:

The telegraf log indicates that the SNMP input plugin can't get any data due to an authentication problem.

Actual behavior:

Telegraf outputs incorrect data for source and uptime (or any other fields requested). Here is an example:

snmp,agent_host=10.10.10.1,source=97112 uptime=97114i 1589490181000000000
snmp,agent_host=10.10.10.1,source=97161 uptime=97163i 1589490190000000000
snmp,agent_host=10.10.10.1,source=97210 uptime=97212i 1589490200000000000
snmp,agent_host=10.10.10.1,source=97259 uptime=97261i 1589490210000000000

Additional info:

When specifying the correct auth_password I see data like this:

snmp,agent_host=10.10.10.1,source=router uptime=206924054i 1589490980000000000
snmp,agent_host=10.10.10.1,source=router uptime=206925046i 1589490990000000000
snmp,agent_host=10.10.10.1,source=router uptime=206926046i 1589491000000000000
snmp,agent_host=10.10.10.1,source=router uptime=206927046i 1589491010000000000

I also noticed that [[inputs.snmp.table]] configurations don't cause any writes to the output when the auth_password is incorrect.

It is difficult to diagnose the problem as being related to authentication since there is no indication from telegraf that the authentication password is wrong. The incorrect data is being written to the output makes this even more confusing since it made me assume there was something wrong in another part of the configuration.

An invalid authentication password should be detectable since the snmpwalk command detects it. When the authentication password is incorrect snmpwalk returns the error:

snmpwalk: Authentication failure (incorrect password, community or key)
@hackery
Copy link
Contributor

hackery commented Jul 23, 2020

Ah! This is what I've just commented about on #7746 - ticket is probably a partial duplicate of this one.

@danielnelson danielnelson added area/snmp bug unexpected problem or unintended behavior labels Jul 23, 2020
@stephanie-engel stephanie-engel added the error handling Issues related to error handling label Oct 16, 2020
@Hipska
Copy link
Contributor

Hipska commented Feb 16, 2021

Sorry I know this ticket is older, but there is more progress on #7929, so I will close this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/snmp bug unexpected problem or unintended behavior error handling Issues related to error handling
Projects
None yet
Development

No branches or pull requests

5 participants