Hide Forgot
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
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?
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.
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.