Bug 1873614

Summary:	[OSP16][RHEL8.2] some nodes do not support Cipher Suite 17 in lanplus mode
Product:	Red Hat Enterprise Linux 8	Reporter:	camorris@redhat.co <camorris>
Component:	ipmitool	Assignee:	Pavel Cahyna <pcahyna>
Status:	CLOSED MIGRATED	QA Contact:	Jeff Bastian <jbastian>
Severity:	low	Docs Contact:	Šárka Jana <sjanderk>
Priority:	low
Version:	8.2	CC:	asimonel, astupnik, bfournie, christopher.martin2, dtantsur, fkrska, gfialova, jridky, lmanasko, mburns, mchappel, pcahyna, rpittau, rvr, sjanderk
Target Milestone:	rc	Keywords:	MigratedToJIRA, Triaged
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Known Issue
Doc Text:	.`ipmitool` is incompatible with certain server platforms The `ipmitool` utility serves for monitoring, configuring, and managing devices that support the Intelligent Platform Management Interface (IPMI). The current version of `ipmitool` uses Cipher Suite 17 by default instead of the previous Cipher Suite 3. Consequently, `ipmitool` fails to communicate with certain bare metal nodes that announced support for Cipher Suite 17 during negotiation, but do not actually support this cipher suite. As a result, `ipmitool` aborts with the `no matching cipher suite` error message. For more details, see the related link:https://access.redhat.com/solutions/5931381[Knowledgebase article]. To solve this problem, update your baseboard management controller (BMC) firmware to use the Cipher Suite 17. Optionally, if the BMC firmware update is not available, you can work around this problem by forcing `ipmitool` to use a certain cipher suite. When invoking a managing task with `ipmitool`, add the `-C` option to the `ipmitool` command together with the _number_ of the cipher suite you want to use. See the following example: ----- # ipmitool -I lanplus -H myserver.example.com -P mypass -C 3 chassis power status -----	Story Points:	---
Clone Of:
Clones:	1876620 (view as bug list)		Environment:
Last Closed:	2023-09-21 22:08:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description camorris@redhat.co 2020-08-28 18:37:06 UTC

Description of problem:
When using lanplus and forcing the cipher to be used we found that some nodes do not support Cipher Suite 17 in lanplus mode. It seems like in 16.0/8.1 the ipmitool version defaulted to C 3 but in 16.1/8.2 its defaulting to 17.  In the previous examples you can see I was using -l lan and not lanplus. 


Version-Release number of selected component (if applicable):
ipmitool-1.8.18-14.el8.x86_64

How reproducible:
Everytime

Steps to Reproduce:
1. Try to inspect a node or run the correct ipmitool command

Actual results:
Fails

Expected results:
Inspection successful

Additional info:

I peeled two from an existing OSP13 cluster to prep wider deployment. The two nodes import perfectly fine in 16.0 running on the same networks, but it fails in 16.1

Comment 3 Dmitry Tantsur 2020-08-30 10:55:44 UTC

Could you show the error that actually happens without the -C flag? I suspect your hardware does not support the cipher discovery, which is now mandated by ipmitool. Moving to ipmitool for investigation.

I do agree that specifying cipher suite could be handy - could you open an RFE for that?

Comment 10 Dmitry Tantsur 2020-09-18 10:50:46 UTC

Hi Vaclav,

We're receiving an increasing number of reports about hardware that claims to do negotiation but actually refuses to use the negotiated cipher 17 (even people from CERN have reported that upstream). Would it be possible for ipmitool to detect the cipher error and fall back to cipher 3 (unless an explicit one is requested)?

We have landed a work-around in ironic to provide an ability to pick a suite, but I don't think this approach scales well. It also won't help any other consumers of ipmitool.

Comment 23 Pavel Cahyna 2021-07-08 07:14:39 UTC

Also, as a workaround seems to be implemented in ironic now (bz1876620), is it still a priority for OpenStack? And I suppose it should not be a blocker of bz1876620 anymore.

Comment 45 RHEL Program Management 2023-09-21 21:31:37 UTC

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 46 RHEL Program Management 2023-09-21 22:08:16 UTC

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.