[Ipmitool-devel] Encapsulated "send message" , over lan: support for embedded resp onse in SendMessage response(data 2) ?

[Isabelle, F. <Fra...@ca...>]

Look at the following commands:

This is a straight GetDeviceId sent over lan:
 ./src/ipmitool  -I lan  -H 192.168.0.23 -L ADMINISTRATOR   raw 6 1
 20 81 05 03 51 bf 57 01 00 41 08 00 00 00 00

This is a implicitly bridged command sent over lan to a shelf manager,
directed to one of the blade
./src/ipmitool  -I lan  -H 192.168.0.23 -L ADMINISTRATOR  -t 0x8a raw 6 1
 04 80 04 23 51 bd 98 3a 00 8a 13 0b 00 00 00

This is a explicitelty bridged command sent over lan to a shelf manager,
directed to one of the AMC on an ATCA blade located at 0x8a
./src/ipmitool  -I lan  -H 192.168.0.23 -L ADMINISTRATOR  -t 0x8a  raw 0x06
0x34 0x47 0x7C 0x18 0x6c 0x20 0x00 1 0xDF
Unable to send RAW command (netfn=0x6 cmd=0x34)

As you can see the last command doesn't work, it I had -v -v -v -v
we get ...

<bunch of session stuff>  
RAW REQ (netfn=0x6 cmd=0x34 data_len=8)
RAW REQUEST (8 bytes)
 47 7c 18 6c 20 00 01 df
>> IPMI Request Session Header
>>   Authtype   : MD5
>>   Sequence   : 0x0000000a
>>   Session ID : 0x057d1a26
>> IPMI Request Message Header
>>   Rs Addr    : 8a
>>   NetFn      : 06
>>   Rs LUN     : 0
>>   Rq Addr    : 81
>>   Rq Seq     : 04
>>   Rq Lun     : 0
>>   Command    : 34
  MD5 AuthCode    : 26981788c9f0c735581d6a1b121e9439
send_packet (53 bytes)
 06 00 ff 07 02 0a 00 00 00 26 1a 7d 05 26 98 17
 88 c9 f0 c7 35 58 1d 6a 1b 12 1e 94 39 17 20 18
 c8 81 10 34 40 8a 18 5e 81 10 34 47 7c 18 6c 20
 00 01 df f4 fb
ipmi message header (38 bytes)
 06 00 ff 07 02 6c f4 e1 d5 26 1a 7d 05 76 6e e7
 63 59 4b db 0c 37 53 45 29 77 99 c5 9b 08 81 1c
 63 20 10 34 00 9c
<< IPMI Response Session Header
<<   Authtype   : MD5
<<   Sequence   : 0xd5e1f46c
<<   Session ID : 0x057d1a26
<< IPMI Response Message Header
<<   Rq Addr    : 81
<<   NetFn      : 07
<<   Rq LUN     : 0
<<   Rs Addr    : 20
<<   Rq Seq     : 04
<<   Rs Lun     : 0
<<   Command    : 34
<<   Compl Code : 0x00
IPMI Request Match found
Bridged cmd 34 resp:
9c00000000000000000000000000000000000000000000000000000000000000000000000000
ipmi message header (61 bytes)
 06 00 ff 07 02 6d f4 e1 d5 26 1a 7d 05 dc c3 90
 1e 5a 0d df cf 15 56 70 6a 9a f6 06 b4 1f 81 1c
 63 20 10 34 00 20 1c c4 7c 00 01 00 01 80 04 08
 51 29 98 3a 00 a1 0f 01 06 00 00 f3 9c
<< IPMI Response Session Header
<<   Authtype   : MD5
<<   Sequence   : 0xd5e1f46d
<<   Session ID : 0x057d1a26
<< IPMI Response Message Header
<<   Rq Addr    : 81
<<   NetFn      : 07
<<   Rq LUN     : 0
<<   Rs Addr    : 20
<<   Rq Seq     : 04
<<   Rs Lun     : 0
<<   Command    : 34
<<   Compl Code : 0x00
IPMI Request Match found
Bridged cmd 34 resp:
201cc47c000100018004085129983a00a10f01060000f39c0000000000000000000000000000
0000000000000000000000000000000000000000000000
send_packet (53 bytes)
 06 00 ff 07 02 0a 00 00 00 26 1a 7d 05 26 98 17
 88 c9 f0 c7 35 58 1d 6a 1b 12 1e 94 39 17 20 18
 c8 81 10 34 40 8a 18 5e 81 10 34 47 7c 18 6c 20
 00 01 df f4 fb
...

You can see 2 occurences of 
IPMI Request Match found
Bridged cmd 34 resp: 

The first one includes only the completion code (as per IPMI E315
Clarification - Section 6.12.4, Bridged Request Example).

The second one includes the replied data "20 1c c4 7c 00 01 00 01 80 04 08
 51 29 98 3a 00 a1 0f 01 06 00 00 f3" as returned by the AMC to the carrier
but IPMITOOL does not consider this response to match the request.
I noticed in lan.c the following test:
	
	/* bridged command: lose extra header */
      if (rsp->payload.ipmi_response.cmd == 0x34) {
			entry->req.msg.cmd = entry->req.msg.target_cmd;
			rsp = ipmi_lan_recv_packet(intf);
			continue;
	}

due to the encapsulated "send message" IPMITOOL fails to return the reply, I
tough that we might add a test fo the presence of data bytes in the
"Response Data" of the embedded SendMessage reply(See Table 18-9, Send
Message Command in IPMI v1.5 rev 1.0 ) , when the data is already inserted
in the reply, it means that you will not receive an additionnal response for
the command.

in fact something like:

	if (rsp->payload.ipmi_response.cmd == 0x34) {
	      if( rsp->data_len == 38 )
            {
                 entry->req.msg.cmd = entry->req.msg.target_cmd;
                 rsp = ipmi_lan_recv_packet(intf);
                 continue;
             }
	}
works. Although I can't tell why the value has to be 38 yet, maybe some
check on the response
payload part to see if it's bigger than 1 would be more appropriate.

Any advice for a decent fix would be appreciated.
===

A great thing would be to add support for an additionnal bridging level.
3 things are required
 1- channel where to bridge the request
 2- requester local address on the bridged channel
 3- responder target address on the bridged channel

so locally we would be able to do:
./src/ipmitool -B 0x7,0x20,0x7C raw 6 1
through IPMB
./src/ipmitool -B 0x7,0x20,0x7C -t 0x8a raw 6 1

or remotely
./src/ipmitool  -I lan  -H 192.168.0.23 -B 0x7,0x20,0x7C raw 6 1
or remotely to IPMB
./src/ipmitool  -I lan  -H 192.168.0.23 -B 0x7,0x20,0x7C -t 0x8a raw 6 1

==
is this feature or something similar already scheduled or in progress ?

Otherwise I will need to start working on it.


Francois Isabelle
Fra...@ca...
Concepteur de logiciel
Software designer 
Kontron Canada