Page MenuHomePhabricator

Rewrite service snmp in new style XML interface definition
Closed, ResolvedPublicFEATURE REQUEST

Description

Rewrite service snmp in new style XML interface definition

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
c-po created this task.May 21 2018, 12:14 PM
c-po claimed this task.
c-po moved this task from Need Triage to In Progress on the VyOS 1.2.x board.
c-po changed the status of subtask T654: Support IPv6 configuration for SNMP listen address from Open to In progress.May 22 2018, 4:51 PM
syncer triaged this task as Normal priority.May 27 2018, 9:39 AM
c-po added a comment.Jun 4 2018, 6:15 PM

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 {
         }
     }
 }
c-po added a comment.Jun 4 2018, 6:27 PM

A first implementation is merged

Line2 added a subscriber: Line2.Jun 5 2018, 8:08 AM

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
c-po added a comment.Jun 5 2018, 10:19 AM

@Line2 thanks for the feedback. Could you tell me how you generated that encrypted key so I can retest this evening and bugfix this?

Line2 added a comment.Jun 5 2018, 2:35 PM

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

c-po added a comment.Jun 5 2018, 3:45 PM

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.

c-po added a comment.EditedJun 5 2018, 5:58 PM

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
c-po added a comment.EditedJun 5 2018, 7:50 PM

@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'
Line2 added a comment.Jun 6 2018, 8:40 AM

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?

c-po added a comment.Jun 6 2018, 10:59 AM

Could you check if the snmpd process is running at all? Please execute ps faux | grep snmp in the commandline.

Line2 added a comment.Jun 6 2018, 11:02 AM

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
c-po added a comment.Jun 6 2018, 11:16 AM

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
Line2 added a comment.Jun 6 2018, 11:23 AM

/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
c-po added a comment.Jun 6 2018, 12:00 PM

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?

Line2 added a comment.Jun 6 2018, 12:20 PM

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.

Line2 added a comment.Jun 6 2018, 12:51 PM

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.

c-po added a comment.Jun 6 2018, 5:22 PM

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

c-po added a comment.Jun 6 2018, 6:11 PM

Okay, when rebooting both encrypted keys change, thats a bug in the Python script too ... sorry for the trouble.

c-po added a comment.Jun 6 2018, 6:19 PM

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!

Line2 added a comment.Jun 6 2018, 6:27 PM

ok if you need tests or info, please ask

c-po added a comment.EditedJun 6 2018, 7:49 PM

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

Line2 added a comment.Jun 7 2018, 5:48 AM

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.

c-po added a comment.Jun 7 2018, 8:51 AM

Perfect, thanks!

We can't do anything about the truncated encrypted-key b/c it's actually truncated by SNMP itself.

Line2 added a comment.Jun 7 2018, 8:53 AM

ok thanks for your work and explanations

c-po changed the task status from Open to In progress.
c-po changed the status of subtask T683: Rewrite SNMP op mode commands in new stlye XML/Python from Open to In progress.Jun 10 2018, 4:05 PM
syncer moved this task from VyOS 1.2.0-rc1 to Finished on the VyOS 1.2.x board.
syncer closed this task as Resolved.