前言
项目需求：
使能ntp为客户端模式，能监服务端广播模式发出的ntp报文，计算出服务端的时间与客户端的时间偏差并上报。
开发状况：
交叉编译ntp源码，将修改后的ntpd进程部署到设备上作为客户端完成项目需求
如何操作？
首先应该知道ntp客户端广播监听模式处理逻辑
ntp客户端监听广播ntp处理逻辑：
找到如下资料：
总结一下：
ntp客户端模式下监听广播ntp，先被动接收报文，接收第一个报文后进行一次单播，算出网络延迟，后续一直处于监听状态。
也就是说，要想实现ntp广播监听，先要保证单播监听能正常使用
首先查看单播监听能否使用：
配置ntp.conf为最简单的单播客户端：
server 192.168.1.52
restrict 127.0.0.1
restrict ::1
设置ntp服务端为单播模式，将客户端ntpd进程运行至前台查看解析情况：
用tcpdump监听发现客户端能收到数据，但是解析数据时发现T1时间不一致的情况，报错如下
这就要了解一下单播原理了
单播原理:
计算原理：
wireshake上对应关系：
单播不再过多阐述了。使用tcpdump在客户端抓取ntp包，并查看分析问题到底出现在了哪里：
通过抓包发现，客户端时间戳T1在发送给服务端后被更改了，导致客户端收到包后发现T1更改后，认为这个是个无效包，将报文丢掉。
原因：
客户端发送请求时会将自己的时间搓T1封装到发送报文里，服务端接收到数据后，发送报文给客户端后，客户端会先检查原来的T1有没有被更改，若被更改，那么该包会被丢弃
上述我遇到的情况，是客户端请求的时候T1与wrieshake中抓到的T1报文不一样，导致客户端收到服务端报文的时候发现T1对不上，将包丢掉导致单播失败
原因是ntp应用层发送的时间系统为了提高精度，在OS层被改掉了，导致T1对不上，
解决方法：
更改源码#define M_ISEQU 对比宏定义，比较逻辑，秒上时间相等就通过，不再比较秒下时间了
至此单播模式便能使用了
广播模式配置：
客户端单播监听没问题就能实现广播了
客户端配置为广播模式最简单的conf配置如下：
broadcastclient
restrict 127.0.0.1
restrict ::1
服务端启动广播模式，开始查看客户端监听log日志，果然出了问题，广播模式只监听不做上述单播请求
经过对日志结合源码的分析发现：
问题出在没有配置身份验证，ntp源码receive函数对接收到的报文会先判断一下报文类型，具体在receive函数中的switch(retcode)模块下的case AM_NEWBCL语句下会检查广播报文是否有身份验证，没有验证则直接退出，我这边代码中这个身份验证默认是开启的。
解决方法：
要么配置身份验证，要么不做身份验证，我的是在init_proto函数中将sys_authenticate置0也就是不检查身份验证信息
修改好后再次启动ntpdf发现广播监听成功！
客户端被动接收服务端报文信息，接收服务端报文后进行一次单播，主要是算出网络延迟，后续一直进入广播被动接收
至此我的ntp客户端使能广播监听成功。
源码重要函数补充：
ntp_proto.c文件中：
receice(struct recvbuf*rbuf) 此函数用于接收ntp报文做一些判断，查看报文是否符合要求
process_packet() 这个函数非常重要receive函数内部校验完毕后会在内部调用一此此函数，此函数主要是根据t1 ~t4算出偏差等信息，只要报文能进入这个函数，基本就说明监听成功了transmit() 此函数用于发送报文
peer_xmit() 此函数用于封装报文，在transmit内部被调用，封装好报文后发送
)
