Offline
after testing (with net-snmp-utils 5.9.3), I have no problem with snmpv3 and SHA/AES.
On my testing host, snmpd server (OpenBSD):
user1password123321drowssapFrom XCP-ng 8.3, with net-snmp-utils 5.9.3:
$ snmpbulkwalk -v3 -a SHA -A password123 -l authPriv -x AES -X 321drowssap -u user1 192.168.1.80
so the net-snmp client itself seems fine with SHA/AES.
could you share more elements ?
after testing (with net-snmp-utils 5.9.3), I have no problem with snmpv3 and SHA/AES.
On my testing host, snmpd server (OpenBSD):
user1password123321drowssapFrom XCP-ng 8.3, with net-snmp-utils 5.9.3:
$ snmpbulkwalk -v3 -a SHA -A password123 -l authPriv -x AES -X 321drowssap -u user1 192.168.1.80
so the net-snmp client itself seems fine with SHA/AES.
could you share more elements ?
SHA`is SHA1. so I assume it is that.
And it seems to be still accepted in authProtocol parameter.
@Mitchel-APD SHA1 ? I am looking if it is still supported/activated-by-default. I saw that 5.8 added SHA-2 family for RFC-7860 compliance
@Mitchel-APD how do you auth on SNMP ? v1, v2, v3 ? and if v3, which authProtocol/privProtocol do you use ?
Having help from OpenBSD side could be the way to go.
Please forward your report to bugs@openbsd.org (with a link to this post too)
For the record, I am able to reproduce it too (on XCP-ng 8.3 too, using OpenBSD -current).
when a new host join an existing pool, it starts by configuring the management interface. so the first bound created is the management one (as bond0) even if the master of the pool has it as bond1.
while doing some tests with 8.3 I got problems too, but not systematically (as you, it seems).
I will send to you a PM regarding xensource.log
@afmart_dei could you share the /var/log/xensource.log of the joining host ? ideally the whole part after the host started (you could look at the file before rebooting and strip all lines before the last line you saw)