问题背景：

两台公版GK6320板子,在同一局域网下进行分布式图库连接功能的时候，必现连接失败现象。

 

定位过程&根因分析：

从日志分析来看，是OpenP2PConnection failed 了。

初步怀疑是软总线建链这边失败了导致连接失败。查看代码，发现分布式图库在连接时会先触发设备上线流程，然后这里会直接返回成功，软总线去异步创建连接。dfs这里的流程会继续正常往下走。

后续会在RepeatGetConnectionStatus方法中去执行50次GetConnectionStatus，总共耗时10S，若50次都没有读取到连接成功则返回失败。

而在GetConnectionStatus中，则是读取statusFile路径下的文件，日志中很明显没有读取成功的打印。那么问题很显然出现在这里。

继续去分析这里读取失败的原因。往上看日志，发现有以下报错。

那么显然前面读取的这个文件路径有问题。最终找到是问题是获取分布式文件系统节点失败导致，随后修改了分布式文件系统节点的构建方式。

重新编译镜像测试，发现还是连接失败，查看日志，报错还是与之前一样，但是日志中已经没有构建分布式文件节点的报错了。那么问题应该还是出现在读取文件去判断是否连接这一块。添加日志打印去读取的分布式文件节点为statusFile path: /sys/fs/hmdfs//17772503822081098401/status。

在连接过程中直接去cat /sys/fs/hmdfs//17772503822081098401/status文件

结合读取该文件的方法发现，此文件其他状态都显示是连接状态了，但是peers这个networkId不对。

查看源码发现确实是这个networkId在 /sys/fs/hmdfs//17772503822081098401/status文件中显示不对导致读取连接状态失败。

那么问题就出现在生成这个status文件的内核函数上。

最终发现在GK6320的内核写入status文件的方法中，没有写入peer_cid的值，比对了社区5.1.0的代码与GK6780(分布式图库功能正常)的代码，发现有差异，那么问题最终确认就是这个写入函数有问题，没有将netwokId写入到分布式节点文件中去。

 

解决方案：

将sbi_status_show方法修改与社区5.1.0保持一致，是能够写入peer—>cid，编译烧录后验证，分布式图库连接成功。

cat这个status分布式文件节点，能看出networkId能够记录进去。