Just my 2 cents, but with SSL involved time is important: could you check the date is accurate on the two hosts ?

having the output of the following commands might help too:

• stat /etc/stunnel/xapi-stunnel-ca-bundle.pem
• openssl x509 -in /etc/stunnel/xapi-stunnel-ca-bundle.pem -noout -text

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):

• User: user1
• auth: AES with password123
• priv: AES with 321drowssap

From 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 ?

Bonjour,

Apparemment, la valeur vient de la xapi :

$ xe host-list params=uuid,software-version
uuid ( RO)                : 9940971b-45f6-4225-aaef-ddb0668e3734
    software-version (MRO): product_version: 8.3.0; product_version_text: 8.3; product_version_text_short: 8.3; platform_name: XCP; platform_version: 3.4.0; product_brand: XCP-ng; xapi: 26.1; build_number: 8.3.0; git_id: 3; hostname: localhost; date: 20260430T09:28:41Z; dbv: 0.0.1; xapi_build: 26.1.3; xen: 4.17.6-6; linux: 4.19.0+1; xencenter_min: 2.21; xencenter_max: 2.21; network_backend: openvswitch; db_schema: 5.793


uuid ( RO)                : 5f16a481-103e-4ca8-a0e2-b708d2c26437
    software-version (MRO): product_version: 8.3.0; product_version_text: 8.3; product_version_text_short: 8.3; platform_name: XCP; platform_version: 3.4.0; product_brand: XCP-ng; xapi: 26.1; build_number: 8.3.0; git_id: 3; hostname: localhost; date: 20260430T09:28:41Z; dbv: 0.0.1; xapi_build: 26.1.3; xen: 4.17.6-6; linux: 4.19.0+1; xencenter_min: 2.21; xencenter_max: 2.21; network_backend: openvswitch; db_schema: 5.793

qui prend l'information depuis le fichier /etc/xensource-inventory (sur le host):

# grep BUILD_NUMBER /etc/xensource-inventory
BUILD_NUMBER='8.3.0'

Ce fichier est mis à jour par le script de post-config du package rpm xcp-ng-release (voir le script utilisé ici)

La valeur a été mise à jour la dernière fois en 2023 (voir le changelog pour 8.3.0-13).
La valeur acutelle est définie dans la variable BUILD_NUMBER rpm variable du package.

Cela veut dire que le host avec Build number = cloud ne semble pas à jour ? Pouvez-vous vérifier la version installée du package xcp-ng-release, en utilisant la commande rpm -q xcp-ng-release ?

Yes, if the file is empty, it is expected to the openssl x509 command to fail.
Does is it the same on the master ?

Just my 2 cents, but with SSL involved time is important: could you check the date is accurate on the two hosts ?

having the output of the following commands might help too:

• stat /etc/stunnel/xapi-stunnel-ca-bundle.pem
• openssl x509 -in /etc/stunnel/xapi-stunnel-ca-bundle.pem -noout -text

please note that blacklisting ESP modules will break IPsec, and encrypted private tunnels rely on it.

Bonjour,

Apparemment, la valeur vient de la xapi :

$ xe host-list params=uuid,software-version
uuid ( RO)                : 9940971b-45f6-4225-aaef-ddb0668e3734
    software-version (MRO): product_version: 8.3.0; product_version_text: 8.3; product_version_text_short: 8.3; platform_name: XCP; platform_version: 3.4.0; product_brand: XCP-ng; xapi: 26.1; build_number: 8.3.0; git_id: 3; hostname: localhost; date: 20260430T09:28:41Z; dbv: 0.0.1; xapi_build: 26.1.3; xen: 4.17.6-6; linux: 4.19.0+1; xencenter_min: 2.21; xencenter_max: 2.21; network_backend: openvswitch; db_schema: 5.793


uuid ( RO)                : 5f16a481-103e-4ca8-a0e2-b708d2c26437
    software-version (MRO): product_version: 8.3.0; product_version_text: 8.3; product_version_text_short: 8.3; platform_name: XCP; platform_version: 3.4.0; product_brand: XCP-ng; xapi: 26.1; build_number: 8.3.0; git_id: 3; hostname: localhost; date: 20260430T09:28:41Z; dbv: 0.0.1; xapi_build: 26.1.3; xen: 4.17.6-6; linux: 4.19.0+1; xencenter_min: 2.21; xencenter_max: 2.21; network_backend: openvswitch; db_schema: 5.793

qui prend l'information depuis le fichier /etc/xensource-inventory (sur le host):

# grep BUILD_NUMBER /etc/xensource-inventory
BUILD_NUMBER='8.3.0'

Ce fichier est mis à jour par le script de post-config du package rpm xcp-ng-release (voir le script utilisé ici)

La valeur a été mise à jour la dernière fois en 2023 (voir le changelog pour 8.3.0-13).
La valeur acutelle est définie dans la variable BUILD_NUMBER rpm variable du package.

Cela veut dire que le host avec Build number = cloud ne semble pas à jour ? Pouvez-vous vérifier la version installée du package xcp-ng-release, en utilisant la commande rpm -q xcp-ng-release ?

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):

• User: user1
• auth: AES with password123
• priv: AES with 321drowssap

From 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