问题背景：
米尔开发板和网迅1GE网卡联调，通过I2c_8直连。网卡smbus配置的主从切换模式。
网卡对应的sr文件也参考社区文档，修改了endpoint的mediumtype，选择主从切换模式。
但从测试结果以及抓线结果来看，ubmc在发送完报文后（是自发现后ubmc自动发送的一个报文）貌似没有切换到slave，发送完blockwrite后就接着发了一个blcokread，这和mediumtype为128的情况是一样的（固定master模式）。
图片左边是ubmc发送的报文内容，右边是紧接着的blockread请求以及网卡的响应。
网讯网卡csr格式版本是多少，在app.log和framework.log里查下smbus看看有什么报错
网卡csr格式版本是5.0的。相关测试基于米尔开发板进行，通过mdbctl setprop命令修改Connector对象的Presence属性重新触发自发现，同时tail -f追踪app.log，然后搜索smbus，发现第二张截图的内容。
目前已定位到主从切换耗时高导致未接收到响应的问题，已经与1月修复，预计在330版本带上该修改。
我们本地尝试了下集成runtime_accessor联调包后出包，提示keyerror：pwd，回退hwproxy组件版本后成功出包。但是测试时发现交互失败：
1、sr文件中Endpoint对象Mediumtype属性配置128，ubmc发送报文内容正常，网卡可以成功接收并解析，但是网卡给ubmc发送报文时，找不到对端；并且ubmc后面还会继续发送block read请求。
2、sr文件中Endpoint对象Mediumtype属性配置2，ubmc发送报文内容异常。多了三个byte内容。
想问下是还有哪里的代码需要修改下吗？
128是固定主从的，BMC做主，网卡做从。所以是BMC发一个写，再发一个读。
配置成2时ubmc发出的报文内容不对，第二张截图里的报文就是修改成2后抓的。
我拿个环境测试下
根据我昨天打印封装的数据结果来看，并没有多余的字节，打印内容：
92 0F 0A 21 01 00 08 C9 00 8A 01 00 09 C8
CSR配置：
"MctpBinding_1": {
"BmcSMBusEid": 8,
"BmcSMBusPhyAddr": 16
},
"Endpoint_1": {
"TargetEid": "${Slot} |> expr($1 + 8)",
"TargetPhyAddr": 73,
"MessageType": 4,
"MediumType": 2,
"RefChip": "#/Chip_SSD"
}
咨询下你们mctpd、hwproxy、runtime_accessor这几个组件的版本是什么，以及这个网卡在哪个链路下，硬件是怎么连接的？
mctpd/1.100.9@openubmc/stable
hwproxy/1.90.33@openubmc/stable
runtime_accessor/1.90.41@openubmc/stable
开发板通过I2c_8与网卡iic直连。
这个打印的封装数据结果是在什么时候打印的？会不会后续又被加了一层header？
组装数据是在mctpd做的，后续hwproxy将数据转发到驱动，理论上应该没有哪里会再加一层，驱动应该也不会额外封装数据。不过我记得我修复主从切换的版本，runtime_accessor的版本号应该是1.110.6。
对了，Chip_SmbusChip的配置是什么样的
那可能是做了什么处理吧。
我看是设备树加载的，配置的是csr2.0（格式版本5.00），可以试下用csr1.0（格式版本3.00）。
尝试了下修改sr文件FormatVersion和DataVersion为3.00。修改后ubmc发出的报文确实没有再出现多内容的情况，但是还有点问题。
上电后通过setprop set Connector手动加载网卡，网卡侧抓线有抓到两个报文，一个ubmc发出的请求，一个网卡回复的响应。但是ubmc发出的报文中slave_addr字段不对，和sr文件中配置的BmcSMBusPhyAddr属性不匹配，实际发送的报文是广播。所以网卡回复时也是广播。（抓线波形如下）后续有继续尝试，但是没再复现这种情况，可以通过修改sr文件中BmcSMBusPhyAddr属性为0去复现。
后面复位devmon组件和hardware组件后重新加载网卡（使用同一个sr文件），这次抓线波形中slave_addr字段和sr文件配置匹配，但是网卡回复时寻址无响应。（抓线波形如下）
发送数据里，source addr（01）对应的是 BmcSMBusPhyAddr << 1 | 1，如果BmcSMBusPhyAddr 填0，发送的mctp报文里source addr也是0
这个之前在社区看到过，所以我们正常情况下BmcSMBusPhyAddr都是配置的16，这次也是偶然抓到了一个slave_addr为0的报文，后面同样的环境重复尝试了多次也没有再触发过这种情况（除非手动在sr文件中将其修改为0）
在root.sr对应的i2c配置下这个属性，和BmcSMBusPhyAddr 保持一致，BmcSMBusPhyAddr 是16，这里就填32。试试呢？
