This reverts commit 89e3d5671b.
As pointed out, there are several problems with that commit:
1. The new semantics, while useful for clients where multiple
threads use separate contexts, breaks clients which correctly
share a single one
2. Change in semantics would require a library version bump
3. It doesn't build with GCC
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
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
