Load MIB files during startup. The default directory is
/usr/share/snmp/mibs, but one or more directories can be configured via
the "mib directory" option.

OK tb@

tiny markup fix: add missing Ic before `group' in the `agentx' rule

OK martijn@

improve the Nd lines such that the format is consistent for the
various *d, *conf, *ctl files (where relevant) and simple;

also makes "man -k routing" more useful;

help from claudio and florian
ok

improve the Nd lines such that the format is consistent for the
various *d, *conf, *ctl files (where relevant) and simple;

also makes "man -k routing" more useful;

help from claudio and florian
ok claudio florian millert

show more ...

(Re)add support for agentx in snmpd
Current omissions in protocol support are notifications,
index (de)allocation, and agent capabilities.

Help testing sthen@
Feedback/tweaks/OK jmatthew@

Introduce a blocklist backend and keyword.

This allows the admin to specify a full region of the OID tree to be
blocked and simply returns NOSUCHOBJECT/ENDOFMIBVIEW.

This deprecates filter-pf-addre

Introduce a blocklist backend and keyword.

This allows the admin to specify a full region of the OID tree to be
blocked and simply returns NOSUCHOBJECT/ENDOFMIBVIEW.

This deprecates filter-pf-addresses in favour of:
blocklist pfTblAddrTable

OK tb@

show more ...

man pages: add missing commas between subordinate and main clauses

jmc@ dislikes a comma before "then" in a conditional, so leave those
untouched.

ok jmc@

Allow snmpd(8) to send SNMPv3 traps.

OK jmatthew@

For the snmpv2c example, use a community which is something more like
the sort of thing which should actually be used (a proper random string
rather than a common word, and especially not a common wo

For the snmpv2c example, use a community which is something more like
the sort of thing which should actually be used (a proper random string
rather than a common word, and especially not a common word that is the
default for much SNMP software). The example here is restricted to
127.0.0.1 but it's easy to adapt to something where it's more unsafe
so better not to give the example. ok martijn@

show more ...

Simplify and be more concise with the listen on flags description.

Suggested by schwarze@

Allow "any" to be used as a listen on address.
This is a convenient shorthand for
listen on 0.0.0.0
listen on ::
and was already the default behaviour if no listen on statement is present.
This way i

Allow "any" to be used as a listen on address.
This is a convenient shorthand for
listen on 0.0.0.0
listen on ::
and was already the default behaviour if no listen on statement is present.
This way it's easier to add additional listeners to the default (like trap
receivers).

Manpage feedback sthen@ schwarze@
Manpage OK jmc@
OK sthen@

show more ...

Type-O in previous.
Diff by jmc@, who can't commit right now.

Thanks.

Allow setting the engineid.

The previous engineid was based aronud the engine boottime and a random
value, which gives problems when sending/receiving unacknowledged PDUs
(trapv2) over SNMPv3 with a

Allow setting the engineid.

The previous engineid was based aronud the engine boottime and a random
value, which gives problems when sending/receiving unacknowledged PDUs
(trapv2) over SNMPv3 with authentication enabled, which need a consistent
engineid across restarts to determine the correct user from the sender.

The new default engineid takes a sha256 hash (chosen for its longer output)
of gethostname(3) and places the first 27 bytes after the new format number
129. This should give us a very low probability of collisions, assuming
all machines have a unique name.

The other formats as specified in SNMP-FRAMEWORK-MIB (RFC3411) are also
supported as well as arbitrary formats in the range 128-255 for other
private enterprise numbers in hex format.

OK jmatthew@

show more ...

Switch default snmpd and snmp auth back to hmac-sha1.

Practical experience on several machines after updates suggests the snmp
world isn't really ready for hmac-sha2-256, and the HMAC construction d

Switch default snmpd and snmp auth back to hmac-sha1.

Practical experience on several machines after updates suggests the snmp
world isn't really ready for hmac-sha2-256, and the HMAC construction doesn't
require collision resistance (which is the weakness of MD5/SHA1; see e.g.
"New proofs for NMAC and HMAC: Security without collision-resistance",
Bellare 2014).

Feedback from martijn@ (who would prefer to keep using the sha2 hmac),
deraadt@, tb@.

show more ...

mention that "system services" value is in decimal. ok martijn@

Change default user auth to hmac-sha256 and enc to aes.
The old defaults are just not sane anymore.

OK sthen@

Tighten default security for snmpd(8). This is done by doing several
things:
- Only allow SNMPv3 by default. SNMPv1 and SNMPv2c can be enabled by
setting the new snmpv* flags on the "liston on" sta

Tighten default security for snmpd(8). This is done by doing several
things:
- Only allow SNMPv3 by default. SNMPv1 and SNMPv2c can be enabled by
setting the new snmpv* flags on the "liston on" statements.
- Remove the default community names. They're not secure to use.
- Change the default seclevel to enc.

Initial idea, help from and OK sthen@

show more ...

snmpd.conf(5): fix typo/plurals and tweak wording. ok jmc martijn

Fix some old phrasing on how to set up a trap handler which aren't correct
anymore after moving it from its own subprocess to snmpe.

feedback and OK jan@

Remove the traphandler process, which was nothing more then a sham.
It did nothing more then receive a message over UDP, do some basic ber
and ASN.1 parsing and forward the packet to the parent proce

Remove the traphandler process, which was nothing more then a sham.
It did nothing more then receive a message over UDP, do some basic ber
and ASN.1 parsing and forward the packet to the parent process. snmpe can
do/does the same thing but with a far more thorough ASN.1 validation.
Because we move trap receiving to snmpe we get trap over tcp for free.

However, to make sure that a normal snmp port doesn't automatically start
handling traps a new set of "listen on" flags are introduced: read, write,
and notify. To enable trap handling either let snmpd listen on port 162
without flags, or add the notify flag. Only a flag without port results in
listening on port 162.

To keep current behaviour copy all UDP-based "listen on" lines without port
and add the notify keyword:
listen on 127.0.0.1 port 666
becomes
listen on 127.0.0.1 port 666
listen on 127.0.0.1 notify

This change also enforces snmpd to honor trap community on receiving a
trap, where previously no community was checked before handling a packet.

OK denis@, rob@

show more ...

double word blunder; from sean davies

Move the tcp/udp keyword before <address>. This allows for easier adding
of different protocols in the future. The old syntax is still supported for
for now, but will generate a deprecation warning a

Move the tcp/udp keyword before <address>. This allows for easier adding
of different protocols in the future. The old syntax is still supported for
for now, but will generate a deprecation warning and will be removed in a
future release.

While here add support for specifying a tcp/udp port. This will be used for
snmp services, "trap handle" will still only run on port 162.

Feedback and OK denis@

show more ...

Remove agentx and control socket support.

snmpctl has been removed two releases ago, which makes the control
interface obsolete.

agentx support has always been quirky at best, but got completely br

Remove agentx and control socket support.

snmpctl has been removed two releases ago, which makes the control
interface obsolete.

agentx support has always been quirky at best, but got completely broken
with the BER_MAX_OID_LEN increase in ber.h. This change resulted in the
oid length on the snmp side being left uninitialized because of size
difference, resulting in weird behaviour. No one reported the breakage,
even after 6.7 was released.

This change requires users to remove the socket keyword from their
snmpd.conf.

OK denis@

show more ...

briefly mention /etc/examples/ in the FILES section of all the
manual pages that document the corresponding configuration files;
OK jmc@, and general direction discussed with many

When many prefixes are stored in pf tables it is not sensible
to export them via snmp.
Introduce option filter-pf-addresses similar to filter-routes which
prevents exporting below the OPENBSD-PF-MIB:

When many prefixes are stored in pf tables it is not sensible
to export them via snmp.
Introduce option filter-pf-addresses similar to filter-routes which
prevents exporting below the OPENBSD-PF-MIB::pfTblAddrTable oid.
Other pf table statistics are uneffected by this and still available.
With this I can do a bulkwalk starting at pfMIBObjects without hitting
timeouts and without spinning the cpu at 100% for days to export 300k
prefixes.
man page input kn
OK claudio, sthen. martijn is also fine with it going in.

show more ...

Replace snmpctl(8) references with snmp(1).