get_sensor_reading() Returns 'CompletionCodeError cc=0xcc desc=Invalid data field in Request' #172
Comments
|
Additionally, here is an example of using iptmitool and then pyipmi to read the same sensor. ipmitool -I lan -H 192.168.201.140 -U "" -P "" -t 0x82 -l 0x1 raw 0x04 0x2d 0x02 Code:interface = pyipmi.interfaces.create_interface(interface='rmcp', Output:[test]$ python3 ipmix.py |
|
But then seems work when I change interface to 'ipmitool'. So, how am I supposed to use this tool? I thought 'rmcp' was the way to go? My intent is to build this in a threaded application to monitor about 100 VadaTech chassis. Can someone in this community help me out with the library's use? Code: Output: |
|
Meanwhile, back to trying the RMCP interface, I'm getting closer to getting it to work. But even though I can see in wireshark that my vadatech device returns the sensor reading to my request, pyimpi throws error while decoding it. See code below, see req/rsp in wireshark below. Some help would be much appreciated. Error: Code:
|
|
@hthiery ? |
|
Did you try to decode the response message? In this example you used a bridge message with SendMsg. Do you realy need to do that? How is the BMC/IPMC instrastructure of the devices you want to query? |
|
It looks like the rs_lun does not match https://github.com/kontron/python-ipmi/blob/master/pyipmi/interfaces/ipmb.py#L241 rs_sa=0x82, rs_lun=0x01, rq_sa=0x20, rq_lun=0, rq_seq=5, netfn=0x04, cmdid=0x2d |
|
First, thank you @hthiery for taking the time to reply.
For example, in ipmitool: Wireshark output from command above:
So if this is true, which I can see that it is by decoding the netFn/rsLUN for the req/rsp then why are the other tools not choking on this? And what now? Reach out to the vendor and tell them that there device is responding to request incorrectly? |
Ok .. it looks that the carrier manager "merges" the sensors of the connected devices to an own representation. Then it makes sense that you need to specify the lun for the request. In this case it is exepected that the carrier manager answers with the correct lun. Seems to be problem from the implementation. You could test if in case you remove the lun check from the rx_filter if it works. Another option is to setup the correct bridged message (routing information) to directly query the device you want (power module). Here the carrier manager is responsible to transfer the request to the specified bridged device and returns the unmodified message from the device (power module). in this case the lun should be 0.
|
|
you can have a look at for an example: https://github.com/kontron/python-ipmi/blob/master/pyipmi/__init__.py#L132 |
|
The routing is very hard to figure out. I can see a difference in the hex bytes but I can't find anything in the ipmi spec about how these routed messages get built. ipmitool: ipmitool -I lan -H 192.168.201.140 -U "" -P "" -T 0x82 -t 0xa8 raw 0x04 0x2d 0x10 ipmi.target = pyipmi.Target(ipmb_address=0xa8, routing=[(0x81, 0x20, 0), (0x20, 0x82, None), (0x20, 0xa8, None)]) pyipmi: Traceback (most recent call last): |
|
try to use the ipmitool interface type and check again please |
|
Ok. at first I got this error: But then I changed a None to a zero in the middle tuple and it worked. But then I switched back to the rmcp interface and it did not work: |
|
Looks to me like the difference between a message created with ipmitool vs pyipmi is a 0x28 and 0x14 in the message. ipmitool sends this: And we receive this: While pyipmi sends this: But the device ACTUALLY responds with this: And pyimpi complains here: So what does the 5th octet mean? If it still means netFn/LUN then those definitely are not matching up between req/rsp |
|
Ah I see .. the response message from the device is encapsulated in a the send message response. This encapsulated response is currently not supported by pyipmi. There are 2 options to implement send message
you could try to add this support in pyipmi like it is done e.g. in ipmitool and fallback to the ipmitool interface type supported by pyipmi. |
|
Ok. I understand what you are saying. Is the encapsulated response something that is left up to the vendors/implementors to decide if they should do it or not? Like the ipmi specification leaves that part optional? |
As far as I remember .. yes. But it is a long time ago when I last worked on that. |
|
Just checked the code again. Could you please try this? Currently only one encapsulated response is supported, but in your case it is a double bridged command and therefore there a double encapsulated response. Maybe this will help?! |
oh .. damn .. sorry. this is already done by |
|
|
one last thing to test please: |
|
Yup that works: python3 ipmix.py Code: logging.basicConfig(filename='ipmi_debug.log', filemode='w', level=logging.DEBUG) if name == 'main': |
|
I added a new feature quirk to can configure the behavior to ignore the sequence number But as you mentioned, this looks like a bug in the carrier manager implemenation of the vendor. So you could also get in contact with them and clarify. |
|
Thank you @hthiery . I will try this out in a few. 13.8 IPMI LAN Message Format describes this for a request: ipmitool sent out this message, which has more octets than what is described in 13.8. This part of the message [a8 10 48 20 28 2d 10 7b 44 e3] looks like: However, this part [20 18 c8 81 28 34 40 82 18 66 20 28 34 40] is hard to break down. Do you have any insight on this part of the message? |
|
The extra things are related to the SendMessage. Check this in the IPMI spec. And the additional bytes at the end are the corresponing checksums. |
I am trying to use this ipmi library to read sdr and sensor data from VadaTech devices. Currently I can read data using ipmitool and freeipmi library. And I can create a session to the device following your online example below. However, I cannot read any sensors or LEDs. I assume that it has something to do with bridging/routing, but I do not know since ipmitool does not require any bridging info. But freeipmi on the other hand does require this switch, '--bridge-sensors'
interface = pyipmi.interfaces.create_interface(interface='rmcp',
slave_address=0x81,
host_target_address=0x20,
keep_alive_interval=1)
ipmi = pyipmi.create_connection(interface)
ipmi.session.set_session_type_rmcp(host='192.168.201.140', port=623)
ipmi.session.set_auth_type_user(username='', password='')
The text was updated successfully, but these errors were encountered: