分享 排查一个智能设备掉线的问题

afkkk

家里智能设备不少，但从装好之后一直不太稳定，最开始以为是路由器的问题，翻来覆去折腾ASUS的路由器，AP模式下不能绑定MESH接入节点的都用nvrm set的方法搞定了，但还是很不稳定，网关、Wi-Fi直接接入的灯具都不定时的掉线 -- 包括从Aqara/Xiaomi等app和hass中掉线。
终于在昨天定位问题，全网没找到有人提过，因此分享一下。

小米电视、极米投影仪的投屏包含DLNA协议，DLNA协议是基于UPnP协议的。当设备开机时，会不断向239.255.255.250:1900广播（Multicasting）自己的状态，网关/路由器会把这个包转给LAN下所有地址。在我的环境下抓包观察，这个消息流量大概是单台电视每秒15个左右，叠加在一起智能家居设备就承受不了。这个和单台电视导致终端不稳定，多台电视开启网关几乎彻底掉线的表现相吻合。

解决方案：
1. 对我来说，似乎DLNA协议没有需求，我就在小米电视的设置中直接关掉了
2. 极米投影仪没有这项设置，而且这货造成的压力比小米电视更大一点，因此我单独甩了一个电信送的Wi-Fi路由器给它，暂时绕过了问题

后续疑问：
1. DLNA keep-alive的消息其实30 - 60s发一个就可以了，暂时不知道为什么小米电视、极米投影仪在我这里会产生spamming，有类似环境的朋友可以tcpdump抓包验证一下 sudo tcpdump -n port 1900
2. 40 qps左右和自己无关的消息能压垮Aqara M1S / CameraHub G3 / Yeelight吊灯等一大票设备，真是没想到。ESP8266 / ESP32级别的芯片感觉应该比这好点呀

ravenhassio

看来我也得回去把dlan关了，我家也是50几个WiFi设备总是随机掉两三个，看看会不会有好转

ghostist

这才是网络问题
任何标准在国内都很难好好遵守，前有安卓app为了后台保活各种整活儿，后有国产设备dlna作妖
前者是实时，后者确实是我带着有色眼镜猜测的
要么是为了手机搜索dlna的时候更快被发现
要么是开发不规范
要么是测试不严谨

不喜欢这种氛围

relliky

不抓不知道，一抓吓一跳

咋我的macbook和亚马逊电视棒都在拼命发？

08:28:53.234733 IP 192.168.1.36.57545 > 239.255.255.250.1900: UDP, length 449
08:28:53.891663 IP 192.168.1.32.46746 > 239.255.255.250.1900: UDP, length 291
08:28:53.891665 IP 192.168.1.32.46746 > 239.255.255.250.1900: UDP, length 301
08:28:53.940106 IP 192.168.1.32.46746 > 239.255.255.250.1900: UDP, length 347
08:28:53.989366 IP 192.168.1.32.46746 > 239.255.255.250.1900: UDP, length 345
08:28:54.005239 IP 192.168.1.32.9925 > 239.255.255.250.1900: UDP, length 384
08:28:54.009303 IP 192.168.1.32.9925 > 239.255.255.250.1900: UDP, length 393
08:28:54.009312 IP 192.168.1.32.9925 > 239.255.255.250.1900: UDP, length 440
08:28:54.009314 IP 192.168.1.32.9925 > 239.255.255.250.1900: UDP, length 438
08:28:54.017271 IP 192.168.1.32.9925 > 239.255.255.250.1900: UDP, length 448
08:28:54.017277 IP 192.168.1.32.9925 > 239.255.255.250.1900: UDP, length 450
08:28:54.040083 IP 192.168.1.32.46746 > 239.255.255.250.1900: UDP, length 355
08:28:54.061647 IP 192.168.1.192.53792 > 239.255.255.250.1900: UDP, length 176

relliky

我没有把iot的网络和手机电视的网络分成两个vlan - 因为麻烦。但这次给了我一个动力去做这个事情。
-------------------------------------------------

刚刚研究了一下，我一直把电视棒自带的投屏功能关了，用的乐播投屏。

所以在乐播投屏里找到“局域网服务发布"选项，关掉后就电视就没有向1900发消息了。只不过以后就只能向电视扫码投屏了。

所以确实是乐播投屏这个软件的问题，拼命发 - - 比其他设备发的频繁多了。

relliky

>> 2. 40 qps左右和自己无关的消息能压垮Aqara M1S / CameraHub G3 / Yeelight吊灯等一大票设备，真是没想到。ESP8266 / ESP32级别的芯片感觉应该比这好点呀

不一定是网关的问题，我的网络设备更多一些，我是70个wifi设备（包括一堆网关，两个yeelight吊灯，wifi灯泡等）10个有线设备。都是带得动的，我的路由器是一个Unifi的UDM，两个UNIFI的AP。我一直没觉得电视手机设备有问题，所以我怀疑是你的路由器性能的问题

afkkk

relliky 发表于 2022-11-9 16:53
>> 2. 40 qps左右和自己无关的消息能压垮Aqara M1S / CameraHub G3 / Yeelight吊灯等一大票设备，真是没想 ...

您说得很对。我进一步做了一些研究。

在用shell下简单构造了一个multicasting炸弹

 for i in (seq 1 200);  echo 1 | ncat -u 239.255.255.250 1900& end

复制代码

；可以从ping值观察到密集的组播对接入设备的影响：
1. 观察到multicasting对Ethernet没有影响；
2. 观察到multicasting对5G接入的Wi-Fi设备似乎没有影响或影响很轻微；
3. 观察到multicasting对2.4G接入的Wi-Fi设备影响很严重；
4. 即使没有监听239.255.255.250组播地址的2.4G设备，也同样受到影响

结合2/3/4来看，合理的解释似乎就只剩下：2.4G带机量更大，设备量 x 消息数更大，产生的网络占用更明显。

找了一下Wi-Fi路由器的设置，里面有一项“组播速率(Mbps)”的配置，之前按优化教程一直保持原始的“自动”，换成最大的“ OFDM 54”可以明显的解决这个问题。目前还不知道这么做有没有其他副作用，继续观察一下。

relliky

afkkk 发表于 2022-11-10 03:25
您说得很对。我进一步做了一些研究。

在用shell下简单构造了一个multicasting炸弹 ；可以从ping值观察到 ...

合理。

如果能在路由器里把广播给1900端口的流量改到某个更窄的网段下，然后把需要被广播的设备都丢到那个网段就好了。我回头研究下看看路由器里的路由表有没有这种搞法。不过像一般的非专业路由器，可以控制的地方不算很多，主要以傻瓜功能为主，不知道搞不搞的了。

还有2.4ghz wifi一般一个信道最多接不超过30个设备。最好压制在20个以内。然后如果有多个ap，分开到1,6,11信道会改善2.4ghz 网络。

relliky

afkkk 发表于 2022-11-10 03:25
您说得很对。我进一步做了一些研究。

在用shell下简单构造了一个multicasting炸弹 ；可以从ping值观察到 ...

还有一个解决方法。换个不发这么频繁的第三方投屏app。我发现乐播投屏开机就发，而且还关不掉，但用国外的第三方app，只有手动打开app才会开始发，而且发的远远没有乐播频繁。

我说的第三方app叫airscreen，你可以搜搜看看能不能改善这个问题（如果你需要投屏的话）
-------------------------------EDIT-----------------------

把乐播删了好像还在发，回头再研究一下是哪个app。

shane000

这么阔怕