Hi everybody, first of all, thank you for all the feedback and sorry for the delay in my answer.
On 12/16/2014 04:35 PM, Albert Chu wrote: > I just tried this on some of my systems and it works perfectly. I have a > speculation that it may be specific to your machine. Thank you for trying this out on your side. > After setting the new password on the remote system, I bet that it has > begun using the new password for all of it's internal hashing mechanisms, > leading new authentication hashes and what not. Either the remote system > is no longer accepted new packets from FreeIPMI b/c it's sending "bad > packets" w/ the wrong hashes, or perhaps the system is sending FreeIPMI > "bad packets" and FreeIPMI is dropping them. Eventually leading to the > session timeout. Got it. > If it happens to be the latter case, the FreeIPMI workaround > "noauthcodecheck" could alleve your situation. Use that workaround at your > own discretion, I hope it's obvious what it does. If it's the former, I > think it's a bug that has to be reported to the vendor. It should still be > using the originally information from when the session was created. The no-auth code did the trick ! > Another possibility might be to use other authentication mechanisms, and > see if they work. Perhaps some of the IPMI 2.0 ones (-D lan20 and -I w/ > various cipher suites) were implemented better. I should have tried that by myself. Using -D lan20 (and using the default cipher suite) also work. Thank you for your help. Jean-Baptiste _______________________________________________ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
