Summary:
The ?: operator has a lower precedence than == and &&, so the result will always
be recorded as true. Found by gcc8.
Reviewed by: ngie, ae
Differential Revision: https://reviews.freebsd.org/D22427
bsnmpclient(3).
snmp_parse_server() function accepts string where some fields can be
omitted: [trans::][community@][server][:port]
"trans" field can be "udp", "udp6", "dgram" and "stream".
"community" can be empty string, if it is omitted, the default value
will be used. For read_community it is "public", for write_comminity
it is "private". "server" field can be hostname, IPv4 address or IPv6
address. IPv6 address should be specified in brackets "[]".
If port is omitted, the default value "snmp" will be used for "udp"
and "udp6" transports. So, now for bsnmpget(1) and bsnmwalk(1) it is
not required to specify all fields in argument of '-s' option. E.g.
# bsnmpget -s 127.1 sysName.0
# bsnmpget -s "udp::127.1" sysName.0
# bsnmpget -s "udp::public@127.1" sysName.0
# bsnmpget -s "udp::public@127.1:161" sysName.0
# bsnmpget -s "udp::[::1]" sysName.0
# bsnmpget -s "udp6::[::1]" sysName.0
# bsnmpget -s "[fe80::1%lo0]" sysName.0
PR: 236664
Reported by: olivier
MFC after: 1 month
This patch adds a new table begemotSnmpdTransInetTable that uses the
InetAddressType textual convention and can be used to create listening
ports for IPv4, IPv6, zoned IPv6 and based on DNS names. It also supports
future extension beyond UDP by adding a protocol identifier to the table
index. In order to support this gensnmptree had to be modified.
Submitted by: harti
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D16654
For developers gensnmptree can now generate functions for enums to convert
between enums and strings and to check the validity of a value.
The sources in FreeBSD are now in sync with the upstream which allows to
bring in IPv6 modifications.
open_client_* returns -1 on failure; 0 on success. Ensure that the return value is
0 -- otherwise exit snmp_open(..).
MFC after: 1 week
Sponsored by: Dell EMC Isilon
This doesn't fix the issue noted in the PR, but at the very least it
cleans up the error so it looks a bit more sane, and in the event
that bsnmp did wander off into the weeds, the likelihood of it
crashing with more sensible output is greater, in my opinion
MFC counter set high so I have enough time to resolve the real
underlying bug in bsnmpwalk
MFC after: 1 month
PR: 215721
- Call snmp_pdu_free on req and resp when done with the objects
- Call snmp_pdu_free on req before calling snmp_pdu_create on it
again
MFC after: 1 week
snmp_pdu_free: set pdu->nbindings to 0 to limit the damage that
could happen if a pdu was reused after calling the function, and
as both stack and heap allocation types are used in contrib/bsnmp
and usr.sbin/bsnmpd.
snmp_value_free: NULL out value->v.octetstring.octets after calling
free on it to prevent a double-free from occurring.
MFC after: 2 weeks
- Use inet_pton with AF_INET instead of doing longhand with sscanf.
- Use gethostbyname2 with AF_INET to ensure that the hostname isn't
accidentally parsed with another address family, e.g. AF_INET6.
NB: IpAddress per RFC-2578 is IPv4 only. Work is in progress to add
the InetAddress type and friends documented in RFC-4001 and
elsewhere (which supports IPv4, IPv6, and more).
MFC after: 2 weeks
