sbwebb

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...

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...

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...

@hthiery ?

First, thank you @hthiery for taking the time to reply. > Did you try to decode the response message? Yes. I was trying. I was trying to compare the structure...

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...

Ok. at first I got this error: python3 ipmix.py Traceback (most recent call last): File "ipmix.py", line 35, in print(ipmi.get_sensor_reading(sensor_number=0x10, lun=0x00)) File "/usr/local/lib/python3.6/site-packages/python_ipmi-unknown-py3.6.egg/pyipmi/sensor.py", line 173, in get_sensor_reading File "/usr/local/lib/python3.6/site-packages/python_ipmi-unknown-py3.6.egg/pyipmi/__init__.py", line...

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: 20 18 c8 81 28...

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...

> oh .. damn .. sorry. this is already done by decode_bridged_message Okay, I will not try then. lol