老版本本地自己加log自己用Rte_read和Rte_write来收发没有问题可以打印出链路上的收发信息的log。之后再加log烧上去串口看没有打印。这是为什么呢因为目下是soc给我们mcu在发那发的就是soc-mcu里面的array_input里面的内容对应的就是接口定义表的里面的那些STA control下的那些接口而根据EthProxy的代码这些一大坨的接口在统一Rte_read读完了后会Rte_write出去。那我们可以通过sizeof打印的方式或者直接追到Rte_type.h里面看Rte里面的读进去后读进去的结构实际是多大。我们直接来到后面的control那一坨找这个结构Rte_Write_STA_CONTROL_UDP_MSG_STA_CONTROL_UDP_MSG然后我们在Eth的代码里搜到它在注释里是这样写的* Std_ReturnType Rte_Write_STA_CONTROL_UDP_MSG_STA_CONTROL_UDP_MSG(const UInt8 *data)* Argument data: UInt8* is of type rt_Array_UInt8_4132我们去到Rte_type.h里面追到了这个发现是# define Rte_TypeDef_rt_Array_UInt8_4132typedef UInt8 rt_Array_UInt8_4132[4132];也就是说它被定义成了一个Uint8的容量为4132的结构。那么它的容量就可以确定是4132然后我直接来到应用层和我们联调的soc发送的脚本那里执行发送脚本然后用tcp dump命令抓下来一个数据包。具体操作检查ip route show:nvidiategra-ubuntu:/ota/ws_usharing$ ip route showdefault via 192.168.72.1 dev mgbe3_0.72172.16.0.0/24 dev mgbe3_0 proto kernel scope link src 172.16.0.11192.168.14.0/24 dev mgbe3_0.14 proto kernel scope link src 192.168.14.11192.168.16.0/24 dev mgbe3_0.16 proto kernel scope link src 192.168.16.11192.168.61.0/24 dev mgbe3_0.61 proto kernel scope link src 192.168.61.11192.168.62.0/24 dev mgbe3_0.62 proto kernel scope link src 192.168.62.11192.168.64.0/24 dev mgbe3_0.64 proto kernel scope link src 192.168.64.11192.168.65.0/24 dev mgbe3_0.65 proto kernel scope link src 192.168.65.11192.168.68.0/24 dev mgbe3_0.68 proto kernel scope link src 192.168.68.11192.168.69.0/24 dev mgbe3_0.69 proto kernel scope link src 192.168.69.11192.168.71.0/24 dev mgbe3_0.71 proto kernel scope link src 192.168.71.11192.168.72.0/24 dev mgbe3_0.72 proto kernel scope link src 192.168.72.11接下来nvidiategra-ubuntu:/ota/ws_usharing$ sudo tcpdump -i mgbe3_0.16 -w 123.cap[sudo] password for nvidia:tcpdump: listening on mgbe3_0.16, link-type EN10MB (Ethernet), snapshot length 262144 bytes^C8493 packets captured8644 packets received by filter0 packets dropped by kernel然后直接把生成在ubuntu内当前文件夹的.cap文件拖入wireshark。在wireshark里查看的时候需要在“分析”--“已启用的协议”里面勾选上所有some/ip相关的协议。接下来wireshark里面就可以直接识别出捕获的.cap里面的someip报文并且标记出报文id,长度等等内容。根据其展示的内容对照发现它大小实际只有1400多。而回到之前本地自测的时候直接调用Rte_type.h里面的Rte的读写接口的时候从Rte_type.h这个里面发现它在Rte里面实际应该是4132。所以这里等于是完整的信息被someip层wrap的时候被截断了。但是someip的特征就是它严格规定长度和大小一段不一致就会直接导致通讯异常。所以当someip封装和rte有冲突的时候就会导致通讯Log压根不会打出来通讯不会进行。所以我们需要找德赛他们在wrap someip的时候截断是有问题的需要和接口要求对齐。更新没问题实际wireshark里面的包被分成了几个segment把他们大小再加起来就是了