最近做智能家居，需要知道智能家居网关（wifi转zigbee，以下简称网关屏）的ip（DNS动态分配）
一开始想的办法是遍历子网内所有机器，每个机器都尝试链接其5005端口，能连上就算找到了，但明显效率太低
还想出个办法是获取路由器上的主机列表，考虑到每个路由器的登陆方式都不尽相同，扩展性差，放弃
最后想着写个广播自身ip的程序，然后上传到网关屏上，上电自动执行，这样客户机就收到了。但没成想网关屏的arm工具链不是gnu的，交叉编译的程序运行不正常，放弃
在调试上面说的广播程序时，想到除了工具链问题外，机器本身对广播的禁止响应也是因素之一？于是在网管屏上ping广播地址
ping 192.168.0.255
结果只有路由器回应了我，客户机并没有回应，难道客户机没收到？搜索ping的相关资料，原来ping命令发出的广播icmp消息到链路层被放到以太网的广播地址，就是
ff:ff:ff:ff:ff:ff
这个消息在客户机的tcp/ip协议栈向上传递的过程中，默认是被过滤掉的，这就是为什么局域网里广播ping时，只有路由器搭理你的原因
不过这倒给了我一个灵感：如果让网关屏也搭理我，那ping命令返回的主机就只剩下2个，除了NPC路由器外，剩下的一定是网关屏了，直接就找到了！
想要网关屏搭理你也很简单，修改网关屏的内核参数即可。修改方法
echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
修改后，从客户机ping广播地址
[email protected]:~$ ping -b 192.168.0.255 WARNING: pinging broadcast address PING 192.168.0.255 (192.168.0.255) 56(84) bytes of data. 64 bytes from 192.168.0.100: icmp_req=1 ttl=64 time=0.953 ms 64 bytes from 192.168.0.1: icmp_req=1 ttl=255 time=1.90 ms (DUP!) 64 bytes from 192.168.0.100: icmp_req=2 ttl=64 time=0.361 ms 64 bytes from 192.168.0.1: icmp_req=2 ttl=255 time=0.531 ms (DUP!) 64 bytes from 192.168.0.100: icmp_req=3 ttl=64 time=0.346 ms 64 bytes from 192.168.0.1: icmp_req=3 ttl=255 time=0.523 ms (DUP!) 64 bytes from 192.168.0.100: icmp_req=4 ttl=64 time=0.350 ms 64 bytes from 192.168.0.1: icmp_req=4 ttl=255 time=0.523 ms (DUP!) ^C --- 192.168.0.255 ping statistics --- 4 packets transmitted, 4 received, +4 duplicates, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.346/0.685/1.900/0.495 ms
可以看到，路由器（192.168.0.1）和网关屏（192.168.0.100）都给ping命令应答了
另外，修改内核参数的命令最好放到网关屏的rc启动脚本里，这样每次上电都是自动响应广播的
版权声明：本文为博主原创文章，未经博主允许不得转载。
时间： 2024-11-05 20:33:01