I've been working on adding support for RUT9XX to Netdisco, the open source NMS that we use. Netdisco primarily uses the SNMP protocol. So far it has been pretty straightforward, but I did run into a small issue.
Netdisco prefers to see a value for the SNMPv2-MIB::sysServices.0 object, to give an indication what functionality a device supports (Layer 2, Layer 3, etc.). A sane value for the RUT9XX would be '76', translating to layers 7, 4 and 3. (The device also has some Layer 2 capabilities, eg LAN switching, but doesn't expose that via SNMP - so reporting L2 capabilities is less useful).
By default, the RUT9XX doesn't report sysServices. I did add the configuration key to the uci config, like this:
uci set snmpd.@system[0].sysServices=76
uci commit
ubus call uci commit '{"config":"snmpd"}'
...but then sysServices still isn't returned.
I believe that this is due to a small bug in the /etc/init.d/snmpd script. It looks like this script, in the snmpd_system_add() function, looks for the sysService key and not sysServices, which would be more logical. If I specify sysService as the key, then it is also put as sysService into /var/run/snmpd.conf, which is a directive that snmpd doesn't parse. What snmpd expects is 'sysServices'.
It looks like this issue is also present upstream, for OpenWRT, but I have no experience with bug reporting there.
Found this on RutOS 06.05.3 and still present on 06.06.1 (just upgraded couple of minutes ago). Would you please consider fixing this, so that sysServices is used consistently in the UCI config and in the snmpd.conf when it's generated? And, if possible, to add a default value of 76 for this key? Besides Netdisco I'm sure that other network management systems are also happier if this object is returned by default.
