I believe so. I believe OpenWrt uses the standard snmpd, that has had SNMPv3 capabilities for about a decade.

It may have the capability, but it can't leverage snmpv3 just because snmpd is installed. First off it doesn't have SSL compiled with it, and that's just for starters. One could install openssl, but I haven't found any documentation on how to leverage it.

davidc502 wrote:

It may have the capability, but it can't leverage snmpv3 just because snmpd is installed. First off it doesn't have SSL compiled with it, and that's just for starters. One could install openssl, but I haven't found any documentation on how to leverage it.

OK then. You know more about it than I do :-) I wonder if there's some place to ask for updating the snmp package to compile in the encryption, plus address one other bug I know about.

[The bug is that if you request counters "too frequently", the second and subsequent responses will frequently return a the same value. This plays hob with traffic stats and other counter-based measurements. Everything is fine if you have a monitoring system that requests data every 30 seconds, but I use a package that allows you to re-query at any time (for example, to test, "Is it up yet? How 'bout now?") and the traffic statistics go crazy. (That is, traffic goes to zero, then when the counter is updated, go to an extremely high value as it "catches up".)

I filed a bug on this ages ago, and was told in no uncertain terms that this was not an OpenWrt problem, but an snmpd problem (https://dev.openwrt.org/ticket/19569). That's clearly not the case - I've built SNMP from source for the last couple decades. I imagine that there's some compilation option for the OpenWrt snmp package which, if set, could handle the screwy counters, and possibly include the SNMPv3 encryption, etc. Thanks for listening! ]

richbhanover wrote:

davidc502 wrote:

It may have the capability, but it can't leverage snmpv3 just because snmpd is installed. First off it doesn't have SSL compiled with it, and that's just for starters. One could install openssl, but I haven't found any documentation on how to leverage it.

OK then. You know more about it than I do :-) I wonder if there's some place to ask for updating the snmp package to compile in the encryption, plus address one other bug I know about.

[The bug is that if you request counters "too frequently", the second and subsequent responses will frequently return a the same value. This plays hob with traffic stats and other counter-based measurements. Everything is fine if you have a monitoring system that requests data every 30 seconds, but I use a package that allows you to re-query at any time (for example, to test, "Is it up yet? How 'bout now?") and the traffic statistics go crazy. (That is, traffic goes to zero, then when the counter is updated, go to an extremely high value as it "catches up".)

I filed a bug on this ages ago, and was told in no uncertain terms that this was not an OpenWrt problem, but an snmpd problem (https://dev.openwrt.org/ticket/19569). That's clearly not the case - I've built SNMP from source for the last couple decades. I imagine that there's some compilation option for the OpenWrt snmp package which, if set, could handle the screwy counters, and possibly include the SNMPv3 encryption, etc. Thanks for listening! ]

If you compiled from source, then snmpv3 encryption/hashing would be fully integrated. Really, the only hurdle to getting snmpv3 working is the "user" that's required to authenticate snmpv3.

Can you share that source? Would need compiled for kernel 4.4.6

For your problem --- Updating counters... As someone who's worked with MIBS for over 10 years, this is a common problem... I've worked with pieces of equipement ranging in the "millions" of dollars who's network counters only update every 15 seconds (MAX). I've yet to find equipment update any faster that say 8-10 seconds.

However, unless debugging, it's rare to need bandwidth reported on a frequency of less than 60 seconds. After all, we are taking the delta of the two measurements which is really just a 1 second average over 60 seconds. 

These are the 3 hurdles that must be addressed when setting up v3

User Name  << A user on the router that's already set up. Root would probably work but not recommended
Context Name << usually set to "."  << Meaning user is allowed to walk the entire MIB tree.
Authentication protocol << HMAC-SHA-1 OR HMAC-MD5-96 << It's the hashing protocol to confirm password is correct.
Privacy Protocol << Usually AES-128 << Encryption Level
Privacy Passphrase << The passphrase is confirmed before setting up the tunnel.

So, we can see there are several levels that must be configured before snmpv3 can be deployed.

@james04

At the time I talked with the maintainer of the snmp package, and didn't really get anywhere. Seems it has to be configured in conjunction with openssl, but after a few days of fooling around with it moved on.

I remember the configuration showing a line indicating the possibility of snmpv3, but none of the actual configurations that would make it happen.

davidc502 wrote:

@james04

At the time I talked with the maintainer of the snmp package, and didn't really get anywhere. Seems it has to be configured in conjunction with openssl, but after a few days of fooling around with it moved on.

I remember the configuration showing a line indicating the possibility of snmpv3, but none of the actual configurations that would make it happen.

I'm actually talking with a guy whos talking with the maintainer

Joking aside, do you mean if I compile my own image (while both snmpd and openssl are selected) then it will work?

I think you mean usm when you say v3, but thats not really the privAuth (ie encryption with authorization) that I'm looking for..

You know there's SNMPv3 over TLS and thats for sure not supported on LEDE/Openwrt.. but the plain privAuth.. I'm still unsure.

You know I copied config files from desktop machines and ran snmpd directly from command line, and never got v3 to work (v2c and v1 yes though), with v3 its always errors like (unknown user, unknown engineID..etc). Even when exact same config works on linux box..