IoT设备协议的开发尝试(二)

为两周前的IDCCP协议写了一个配套的cli工具,专门用于测试和发包。

相较于写一个daemon,这样一个命令行工具写起来就容易得多,一方面是协议设计已经完成,只是套逻辑即可;二是发包工具的demo本来就更容易开发,还能直接复用已有的idccp.h。

代码量很小,直接放出完整代码,并简单阐述一下我的想法。

QQ20260906-115838.png

QQ20260906-115857.png

QQ20260906-115922.png

QQ20260906-115932.png

接收用户的参数,并且根据这些参数构造数据包,最后采用for循环进行简单的三次冗余发包。

这里的话,其实遇到了一个困难:我的daemon去重表是通过ip,端口和req_id实现去重的,也就是说,这个req_id必须能够实现自增才行;

但是,作为一个发包工具,idccp_cli并不像daemon进程那样具备留存后台的能力,这意味着它无法长久地保存一个数据,必须要其他的文件来配合。

联想到近期逆向那个vrp程序时的共享内存,起初我其实是打算通过共享内存,也就是类似ftok,shmget,shmat的机制来实现,这样每次调用cli工具都会去读取共享内存里的已有计数,实现req_id的保存。

但现实阻碍在于,共享内存是内存,是断电易失的,总不能每次开机都重新计数吧?那样会造成的最显而易见的问题,就是如果某一次开机,使用cli工具发包的个数小于64个,再次启动时就会重新计数,从0开始,直接造成命令重放。

最后迫不得已,还是选择了使用一个文件来专门存储数据,并通过flock确保多个cli进程不会出现竞争。

最后放一下wireshark的抓包结果:

QQ20260906-122052.png

QQ20260906-122703.png

QQ20260906-130109.png

QQ20260906-130150.png

可以看到已经成功发包,并且mkdir ~/Desktop/hello_world执行成功。

目前其实还有一些小问题,比如cli工具的req_id没有做回绕,去重表需要重新设计,报文应该进行简单的加密,等等,后续慢慢改进。

评论