Jacek, It's hard to tell, since send and receive responses are mixed in the verbose output. IMHO it seems that your BMC responds with the response to the Get Channel Auth Capabilities twice, this might resulting in a session handshake out of order error in ipmitool. ipmitool should recover from this (see ipmi_lan_poll_recv() in lanplus.c), but I'm not sure if it realy does.
The RAKP Resonse packets itself (which get decoded during receive) look OK to me. Holger > > More debug: > $ ipmitool -I lanplus -H 192.168.10.11 -P pass -vv sol > activate IPMI LAN host 192.168.10.11 port 623 > > >> Sending IPMI command payload > >> netfn : 0x06 > >> command : 0x38 > >> data : 0x8e 0x04 > > >> sending packet (23 bytes) > 06 00 ff 07 00 00 00 00 00 00 00 00 00 09 20 18 > c8 81 00 38 8e 04 b5 > << Received data (30 bytes) > 06 00 ff 07 00 00 00 00 00 00 00 00 00 10 81 1c > 63 20 00 38 00 01 86 06 03 00 00 00 00 18 ==> Initial Response to Get Channel Auth Capabilities > >> SENDING AN OPEN SESSION REQUEST > > >> sending packet (48 bytes) > 06 00 ff 07 06 10 00 00 00 00 00 00 00 00 20 00 00 00 00 00 > a4 a3 a2 a0 00 00 00 08 01 00 00 00 > 01 00 00 08 01 00 00 00 02 00 00 08 01 00 00 00 > << Received > data (30 bytes) > 06 00 ff 07 00 00 00 00 00 00 00 00 00 10 81 1c > 63 20 00 38 00 01 86 06 03 00 00 00 00 18 > IPMI Request Match NOT FOUND ==> Doublicate Response to Get Channel Auth Capabilities ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
