Rewrite service snmp in new style XML interface definition
Description
Description
Details
Details
- Difficulty level
- Unknown (require assessment)
- Version
- -
- Why the issue appeared?
- Will be filled on close
Event Timeline
There are a very large number of changes, so older changes are hidden. Show Older Changes
Comment Actions
Tested using:
# show service snmp
community foobar {
network 172.16.100.0/24
}
description FOO
listen-address 172.16.254.35 {
}
location bar
v3 {
engineid 0x80001f9980f286be17f8313c5800000000
group nmsreadonly {
mode ro
seclevel priv
view all
}
trap-target 172.16.100.1 {
auth {
plaintext-key testtest
type sha
}
engineid 0x80001f9980f286be17f8313c5800000000
port 163
privacy {
plaintext-key testtest
type aes
}
protocol tcp
type trap
user nms
}
user nms {
auth {
plaintext-key testtest
type sha
}
engineid 0x80001f9980f286be17f8313c5800000000
group nmsreadonly
mode ro
privacy {
plaintext-key testtest
type aes
}
}
view all {
oid 1 {
}
}
}Comment Actions
Hi
I just tested vyos-1.2.0-rolling+201806050337 with this config (same as in the past worked):
vyos@vyos-test# sh service snmp
contact "xy"
description xy
location "xy"
v3 {
engineid 0x90001faaa0f286be17c8314c5800000000
group nmsreadonly {
mode ro
seclevel priv
view all
}
user nms {
auth {
encrypted-key 0xc456c679c79c95cf7f420fa46b95e4cdda18d96a
type sha
}
engineid 0x90001faaa0f286be17c8314c5800000000
group nmsreadonly
mode ro
privacy {
encrypted-key 0xc456c679c79c95cf7f420fa46b95e4cd
type aes
}
}
view all {
oid 1 {
}
}
}But no SNMP connectivity by the monitoring system anymore. Strange is, both keys are the same but in the config the auth encrypted-key is truncated after 34digits. It showed like this in older VyOS version too, but it worked there. It's only an observation.
In log:
Jun 5 10:03:33 vyos-test snmpd[3271]: Turning on AgentX master support. Jun 5 10:03:33 vyos-test snmpd[3267]: Starting SNMP services:: snmpd Jun 5 10:03:33 vyos-test snmpd[3273]: NET-SNMP version 5.7.2.1 Jun 5 10:03:37 vyos-test snmpd[3273]: [smux_accept] accepted fd 15 from 127.0.0.1:40146 Jun 5 10:03:37 vyos-test snmpd[3273]: accepted smux peer: oid SNMPv2-SMI::enterprises.3317.1.2.3, descr Quagga-0.99.20.1 Jun 5 10:03:37 vyos-test snmpd[3273]: [smux_accept] accepted fd 16 from 127.0.0.1:40150 Jun 5 10:03:37 vyos-test snmpd[3273]: accepted smux peer: oid SNMPv2-SMI::enterprises.3317.1.2.5, descr Quagga-0.99.20.1 Jun 5 10:03:37 vyos-test snmpd[3273]: [smux_accept] accepted fd 17 from 127.0.0.1:40154 Jun 5 10:03:37 vyos-test snmpd[3273]: accepted smux peer: oid SNMPv2-SMI::enterprises.3317.1.2.2, descr Quagga-0.99.20.1
Comment Actions
@Line2 thanks for the feedback. Could you tell me how you generated that encrypted key so I can retest this evening and bugfix this?
Comment Actions
I think I set it in an older VyOS version by "set service snmp v3 user nms auth plaintext-key blabla" and VyOS encrypted the key.
I changed now to plaintext-key as in your config in newest build with the same negative result.
Then I rolled back to VyOS-1.2.0-rolling+201806040337, deleted the complete SNMP config and rebuild the SNMP config with this commands:
set service snmp contact "xy" set service snmp description "xy" set service snmp location "xy" set service snmp trap-target 172.16.1.1 set service snmp v3 view all oid 1 set service snmp v3 group nmsreadonly mode ro set service snmp v3 group nmsreadonly seclevel priv set service snmp v3 group nmsreadonly view all set service snmp v3 user nms group nmsreadonly set service snmp v3 user nms auth type sha set service snmp v3 user nms auth plaintext-key [key here] set service snmp v3 user nms privacy type aes set service snmp v3 user nms privacy plaintext-key [key here]
Then commit and VyOS encrypted the keys and the config works. I hope this helps. Please ask again when I can help
Comment Actions
Ah, yes. In the past the Perl scripts re-read the newly generated configuration and altered the running configuration using /opt/vyatta/sbin/my_set or /opt/vyatta/sbin/my_delete. That's indeed missing. Thanks for the commands and I'll fix it this evening.
Comment Actions
Okay, the encrypted passwords are re-read from /var/lib/snmp/snmpd.conf and set on the CLI. The truncation originats from that file.
$ sudo cat /var/lib/snmp/snmpd.conf | grep usmUser usmUser 1 3 0x80001f8880de85fa380aac165b00000000 "nms" "nms" NULL .1.3.6.1.6.3.10.1.1.3 0x0836f853d74df74c4ae2236292aa6690d543f893 .1.3.6.1.6.3.10.1.2.4 0x0836f853d74df74c4ae2236292aa6690 0x usmUser 1 3 0x80001f8880de85fa380aac165b00000000 "vyattac364cc1b126c0ceb" "vyattac364cc1b126c0ceb" NULL .1.3.6.1.6.3.10.1.1.2 0x3757ee2957f9ec849ddc65b3dabed161 .1.3.6.1.6.3.10.1.2.2 0x3757ee2957f9ec849ddc65b3dabed161 0x
Comment Actions
@Line2 new ISO building right now which converts plaintext-keys to encrypted keys again.
Tested using
set service snmp v3 engineid '0x80001f8880de85fa380aac165b00000000' set service snmp v3 group nmsreadonly mode 'ro' set service snmp v3 group nmsreadonly seclevel 'priv' set service snmp v3 group nmsreadonly view 'all' set service snmp v3 user nms auth plaintext-key testtest set service snmp v3 user nms auth type 'sha' set service snmp v3 user nms engineid '0x80001f8880de85fa380aac165b00000000' set service snmp v3 user nms group 'nmsreadonly' set service snmp v3 user nms privacy plaintext-key testtest set service snmp v3 user nms privacy type 'aes' set service snmp v3 view all oid '1'
Comment Actions
I have updated from VyOS-1.2.0-rolling+201806040337 to VyOS-1.2.0-rolling+201806060337 with the same config (the one I sent you before). But now I cannot get SNMP info from this VyOS installation anymore (timeout).
What can I test next?
Comment Actions
Could you check if the snmpd process is running at all? Please execute ps faux | grep snmp in the commandline.
Comment Actions
Yes is running:
vyos@vyos-test# ps faux | grep snmp vyos 3905 0.0 0.4 12732 2240 pts/0 S+ 13:01 0:00 \_ grep snmp snmp 3323 0.0 1.6 55172 8188 ? S 10:31 0:03 /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -g snmp -p /run/snmpd.pid
Comment Actions
Could you please paste the content of the following files:
- /etc/snmp/snmp.conf
- /etc/snmp/snmpd.conf
- /usr/share/snmp/snmpd.conf
- /var/lib/snmp/snmpd.conf
Comment Actions
/etc/snmp/snmp.conf:
### Autogenerated by snmp.py ###
/etc/snmp/snmpd.conf:
### Autogenerated by snmp.py ### # non configurable defaults sysObjectID 1.3.6.1.4.1.44641 sysServices 14 master agentx agentXPerms 0755 0755 pass .1.3.6.1.2.1.31.1.1.1.18 /opt/vyatta/sbin/if-mib-alias smuxpeer .1.3.6.1.2.1.83 smuxpeer .1.3.6.1.2.1.157 smuxpeer .1.3.6.1.4.1.3317.1.2.2 smuxpeer .1.3.6.1.4.1.3317.1.2.3 smuxpeer .1.3.6.1.4.1.3317.1.2.5 smuxpeer .1.3.6.1.4.1.3317.1.2.8 smuxpeer .1.3.6.1.4.1.3317.1.2.9 smuxsocket localhost # linkUp/Down configure the Event MIB tables to monitor # the ifTable for network interfaces being taken up or down # for making internal queries to retrieve any necessary information iquerySecName vyatta0b989de4d2d95b5f # Modified from the default linkUpDownNotification # to include more OIDs and poll more frequently notificationEvent linkUpTrap linkUp ifIndex ifDescr ifType ifAdminStatus ifOperStatus notificationEvent linkDownTrap linkDown ifIndex ifDescr ifType ifAdminStatus ifOperStatus monitor -r 10 -e linkUpTrap "Generate linkUp" ifOperStatus != 2 monitor -r 10 -e linkDownTrap "Generate linkDown" ifOperStatus == 2 ######################## # configurable section # ######################## # Default system description is VyOS version sysDescr VyOS 1.2.0-rolling+201806060337 # Description SysDescr xy # Listen agentaddress unix:/run/snmpd.socket # SNMP communities # system contact information SysContact xy # system location information SysLocation xy # if there is a problem - tell someone! trap2sink 172.16.1.1 # # SNMPv3 stuff goes here # # views view all included .1 # access # context sec.model sec.level match read write notif access nmsreadonly "" usm priv exact all none none access nmsreadonly "" tsm priv exact all none none # trap-target # group group nmsreadonly usm nms group nmsreadonly tsm nms
/usr/share/snmp/snmpd.conf:
### Autogenerated by snmp.py ### rouser nms rwuser vyatta0b989de4d2d95b5f
/var/lib/snmp/snmpd.conf:
# # net-snmp (or ucd-snmp) persistent data file. # ############################################################################ # STOP STOP STOP STOP STOP STOP STOP STOP STOP # # **** DO NOT EDIT THIS FILE **** # # STOP STOP STOP STOP STOP STOP STOP STOP STOP ############################################################################ # # DO NOT STORE CONFIGURATION ENTRIES HERE. # Please save normal configuration tokens for snmpd in SNMPCONFPATH/snmpd.conf. # Only "createUser" tokens should be placed here by snmpd administrators. # (Did I mention: do not edit this file?) # usmUser 1 3 0x80001f88805dcd8c6af69b175b00000000 "nms" "nms" NULL .1.3.6.1.6.3.10.1.1.3 0x9c730ab9043c074afc737285cca7c389dc53cadc .1.3.6.1.6.3.10.1.2.4 0xdc81c9465cd4f7bf5c0c95448aba3c08 "" usmUser 1 3 0x80001f88805dcd8c6af69b175b00000000 "vyatta0b989de4d2d95b5f" "vyatta0b989de4d2d95b5f" NULL .1.3.6.1.6.3.10.1.1.2 0x11dcc2e4b52ddadb4021732226516825 .1.3.6.1.6.3.10.1.2.2 0x11dcc2e4b52ddadb4021732226516825 "" setserialno 165627204 ############################################################## # # snmpNotifyFilterTable persistent data # ############################################################## ############################################################## # # ifXTable persistent data # ifXTable .1 14:0 18:0x $ ifXTable .2 14:0 18:0x $ ifXTable .3 14:0 18:0x $ ############################################################## engineBoots 1 oldEngineID 0x80001f88805dcd8c6af69b175b00000000
Comment Actions
Looks like there is no listen address agentaddress unix:/run/snmpd.socket configured and if there is none inside the configuration, we won't listen on all addresses. This is likely the cause. Could you please add for validation a set service snmp listen-address <ipv4> and check if you can now reach the server again?
Comment Actions
i set this, got the following messages:
vyos@vyos-test# commit [ service snmp ] Nothing to delete (the specified node does not exist) Nothing to delete (the specified node does not exist)
retested with snmpwalk, no timeout but 'authentication failure (incorrect password, community or key'.
config looks like this:
vyos@vyos-test# show service snmp
contact "xy"
description xy
listen-address 172.16.100.10 {
}
location "xy"
trap-target 172.16.1.1 {
}
v3 {
engineid 0x80001f8880e251911b8c9e165b00000000
group nmsreadonly {
mode ro
seclevel priv
view all
}
user nms {
auth {
encrypted-key 0x57049c9511e046c85e63a15c501d2a10943b093a
type sha
}
engineid 0x80001f8880b354e16b78d0175b00000000
group nmsreadonly
mode ro
privacy {
encrypted-key 0x7624d39dac1bc4cab5691924ad35cf92
type aes
}
}
view all {
oid 1 {
}
}
}the two keys should be the same. So maybe something wrong in key handling.
Comment Actions
then I deleted the encrypted-keys, set plaintext keys, commit, show config shows encrypted-keys (the privacy key again truncated), and snmpwalk works now. So it is a migration problem if someone just updates his router to rolling version from today.
Comment Actions
Okay, there was definately a problem with the listen address which is fixed now. Waiting for a new ISO and then I try upgrading from old version, too
Comment Actions
Okay, when rebooting both encrypted keys change, thats a bug in the Python script too ... sorry for the trouble.
Comment Actions
Okay, when not executing the marked part (https://github.com/vyos/vyos-1x/blob/743b16de1aac4c6b579767f28d57bc2156d3acdf/src/conf_mode/snmp.py#L704-L729) reboots work but then we loose transformation from plaintext o encrypted passwords. So the bug is definately here. Will check!
Comment Actions
Issue should be fixed starting with vyos-1.2.0-rolling+201806062125-amd64.iso at least it was tested positively when updating from 1.2.0-rolling+201806040337 to 1.2.0-rolling+201806062125
Comment Actions
I tested update from vyos-1.2.0-rolling+201806060337 to vyos-1.2.0-rolling+201806070337, went fine.
Then I tested update from vyos-1.2.0-rolling+201806040337 to vyos-1.2.0-rolling+201806070337, went fine too , even without 'listen-address'.
Looks good. Only the truncated encrypted-key in privacy is still there.
Comment Actions
Perfect, thanks!
We can't do anything about the truncated encrypted-key b/c it's actually truncated by SNMP itself.