Hi

把遇到的一次智能家居设备（我主要基本都是米家设备）离线的问题分析讲一下 因为不想写太长，所以涉及的名词请自行搜索了解……不作科普 解决方式 该问题应该普遍存在于ASUS包括刷了merlin固件的ASUS路由器 关闭“系统管理->开启 WAN 中断的浏览器导页通知”，可以完全避免触发该Bug 问题现象 有时从手机客户端发现智能设备离线，但从路由器管理界面能看到智能设备的WiFi正常链接，从同局域网内Ping该设备也正常 从路由器端使用tcpdump抓包，发现设备发送DNS请求解析域名，但路由器应答了10.0.0.1，导致设备后续的连接服务器均失败 问题原因 当使用路由器中的“开启 WAN 中断的浏览器导页通知”功能时，在 WAN 中断时（如每48小时重新拨号等），路由器内的firewall会修改iptables（代码地址：O网页链接），将所有的DNS请求REDIRECT到18018端口，wanduck监听18018，对所有DNS请求都应答10.0.0.1用于引导用户访问到路由器断网的提示页面（代码地址：O网页链接） 当 WAN 恢复时，上述iptables规则会被删除，按设计预期流量应正常通过路由器访问互联网，但可能程序猿忘了个事情…… REDIRECT涉及到conntrack，只需要一个链接的第一个包匹配iptables规则，接下来无论iptables规则如何变化，只要conntrack内的对应条目仍然有效，REDIRECT就会起效，而 wanduck 是一个持续运行的程序，即使 WAN 正常，只要有DNS请求发到18018端口，它就会应答，再加上智能家居设备因为连不上服务器会不断的发送DNS解析请求。而对于conntrack来说，它看到了智能设备的DNS请求，也看到了wanduck的DNS应答，那么它认为链接是活动状态REDIRECT则一直生效。 于是只要 WAN 中断时，有设备发送了DNS解析请求，wanduck应答了DNS解析，设备发现自己连不上真正的服务器于是不断的尝试重新解析，重复得到错误DNS应答，导致该REDIRECT关系永远不会过期移除，设备也就永远跳不出这个死循环了（其实只要此时两边有一方停下来一段时间，或者 WAN 恢复时谁来flush conntrack就好）

很早前买了个小兴看看Memo，但是它明明支持RTSP功能却通过一些方式加密了播放地址 用Wireshark抓包后可看到请求视频地址的方式 GET /common_page/GetVideoURL_lua.lua?codecType=1&_=1532614414122 HTTP/1.1 Accept: application/xml, text/xml, */*; q=0.01 X-Requested-With: XMLHttpRequest Referer: http://192.168.50.21/ Accept-Language: zh-Hans-CN,zh-Hans;q=0.5 Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko Host: 192.168.50.21 Connection: Keep-Alive Cookie: CurStreamID=1 HTTP/1.1 200 OK Server: Mini web server 1.0 ZTE corp 2005. Accept-Ranges: bytes Connection: close Cache-Control: no-cache,no-store Content-Length: 423 Content-Type: text/html; charset=utf-8 <ajax_response_xml_root><IF_ERRORPARAM>SUCC</IF_ERRORPARAM><IF_ERRORTYPE>SUCC</IF_ERRORTYPE><IF_ERRORSTR>SUCC</IF_ERRORSTR><IF_ERRORID>0</IF_ERRORID><OBJ_GETVIDEOURL_ID><Instance><ParaName>_InstID</ParaName><ParaValue>IGD</ParaValue><ParaName>webURL</ParaName><ParaValue>rtsp://192.168.50.21:554/live/ch00_0?token=vixcufLSMixBQwsC</ParaValue></Instance></OBJ_GETVIDEOURL_ID><codecType>1</codecType></ajax_response_xml_root> 本地简单利用的话就是构造一个GET请求，然后解析返回的xml即可，这里得到的地址是： rtsp://192.168.50.21:554/live/ch00_0?token=vixcufLSMixBQwsC 要注意的是这个地址只能播放一次，下次需要重新获取新地址

Windows下也有自带命令可以计算文件的MD5\SHA1等 certutil -hashfile filename MD5 certutil -hashfile filename SHA1 certutil -hashfile filename SHA256

先删除掉之前安装的奇怪的东西 apt-get remove apache2 apt-get remove php5 apt-get remove mysql-server mysql-client 然后依次执行下面这些，有Yes打Yes，有Y打Y，有回车按回车…… apt-get update apt-get install software-properties-common add-apt-repository ppa:nginx/stable add-apt-repository ppa:ondrej/php apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://mirrors.tuna.tsinghua.edu.cn/mariadb/repo/10.1/ubuntu trusty main' apt-get update apt-get install nginx-extras apt-get install php7.0-fpm php7.0-gd php7.0-mysql php7.0-mcrypt php7.0-mbstring php7.0-curl apt-get install mariadb-server 注意最后一行执行时会要求输入密码，选一个强度高的密码作为数据库密码 然后来配置数据库，执行后输入密码回车 mysql -u root -p 进入新的控制界面输入下面三行，注意替换掉自己的密码，3处的wordpress字符可以自己替换成想要的名字，作为数据库名和用户名 CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; GRANT ALL ON wordpress.* TO 'wordpress'@'localhost' IDENTIFIED BY '你的密码'; FLUSH PRIVILEGES; 全部完成后应该提示如下：...

不是我懒得写全称，是感觉全称太敏感，看的人懂意思就行。 ss作为目前主要的手段，目前不支持非TCP和非UDP协议，libev版本对于UDP透明代理也是支持的不怎么好。 又想到OpenVPN可以基于TCP建立连接，只是目前被干扰的非常严重所以没法用，所以想到可以把TCP连接建立在ss上。 网上一搜很容易搜到教程。主要还是在OpenVPN客户端配置文件加上 socks-proxy ss客户端IP ss客户端端口 route 服务器IP 255.255.255.255 net_gateway 这样再拨号时候就不会被干扰啦，而且也能比较完善支持各种协议玩耍了，对于游戏之类的会有比较显著改善。 当然你得拥有一条至少质量稳定的链路，不然所有数据包都基于TCP的话，拥塞控制是要死人的。

之前一直想着博客与ss可以放在一起，这样一方面比较省钱，一方面也少管理个东西。 然而现实却是国际出口越来越恶化，Softlayer的路由也玩出新花样，不得不考虑选一个比较贵的VPS作为ss服务器，一个比较便宜的作为博客。 选来选去，阿里云目前香港B区和新加坡都不错，来回均走CN2国际出口。 新加坡流量价格0.5元/G比香港要便宜一半，然而由于因为在广东的原因，香港具有显著的延迟优势。 现在高峰时刻也能保持在50Mbps的速率了，麻麻再也不用担心我卡了。 而博客则放在了对中国极其不友好的DigitalOcean上，主要还是比较便宜（相对Linode）而且KVM方便做些实验。 为了让偶尔的一两个访问者打开博客不至于太慢，基本把所有静态资源都搬到了七牛CDN上，而且去掉了所有Google Fonts之类的东西，国内那些反代实在是不靠谱。

锐速是啥可自行百度。本来在服务器上安装了锐速，虽然线路良好不过想着反正没有负面作用就一直开着。 直到我发现有时候速度会特别特别的慢，只能建立一个连接却跑不出速度。 后来通过在服务端抓包，发现一个奇怪的现象，就是服务端每次都只发送260字节的包。 这个行为看起来就像是服务端知道客户端的window size是260一样，但是明明这里window size是非常大的(60000+) 发现260这个数字实际就是的未计算window scale时的window size，也就是说有一个程序导致服务端忽略了window scale这个参数。 于是把锐速停了，现象消失，网络恢复。

目前上海电信大力推行4K IPTV，办宽带基本都白送，不过正常使用方法是用送的光猫一体机拨号，然后IPTV盒子插上面，电脑也插上面。 然而电信光猫一体机作为路由功能来说稳定性和性能都太差，自由度也远远不如刷了Openwrt的路由器，所以在没有IPTV的时候就破解了光猫用Bridge模式，自备路由器接后面进行PPPoE拨号。 现在电信送了IPTV以后麻烦事来了，目前的OTT 4K IPTV不再是以前单纯划分一下VLAN就能正常使用的了，现在的IPTV使用俗称双平面的方式，也就是在公众互联网和IPTV专网内都会进行访问。 于是如果自备路由器进行拨号的话，难题就在于你接光猫一体机上获得不了公众互联网访问（因为光猫自己没PPPOE拨号），如果接自备路由器上则要划分VLAN连上IPTV专网以及实现DHCP的Option 125。 网上教程也很多，接在自备路由器上时，将路由器WAN口、CPU口、接IPTV的口 一起新建一个VLAN 85，3个端口全部为tagged DHCP Option的话建议是先抓包看看DHCP Offer的包里的Option 125内容 然后在路由器dnsmasq配置文件里写上相应的（我的光猫是HG220G，IPTV是HG680-J） dhcp-option-force=125,00:00:00:00:1b:02:06:48:47:57:2d:43:54:03:05:48:47:32:32:31:0a:02:20:00:0b:02:00:55:0d:02:00:2e 这些全部做完以后，用中兴之类的IPTV盒子应该就能正常使用了，但用HG680的盒子却不能成功，抓包分析主要是DHCP完成后，盒子不会再进行任何网络操作（接光猫一体机时，DHCP完成后会检测网络连通性、申请认证什么的） 分析一下原因，光猫的DHCP Offer和路由器的DHCP Offer内容还是略有差别。主要是多发了一些 广播地址、域名 等等。 所以还要加一步，我加入了下面这些到dnsmasq dhcp-option=15 dhcp-option=28 这样禁用了广播地址和域名的Option，IPTV盒子在公众网的DHCP完成后就会马上通过VLAN 85再去Discover IPTV专网的DHCP了

由于我是想做个旁路劫持一类的软件，所以肯定不允许抓包有很大延迟（如果包比正常包还要晚到达客户端直接会被丢弃） 这里我们要开启立即模式 inactive.SetImmediateMode(true) 构造链路和网络层没什么好说的，传输层构造TCP后要记得设置该层对应的上层协议，不然无法计算checksum，仍然会被客户端丢弃 tcp.SetNetworkLayerForChecksum(&ipv4) 在序列化成字节的时候使用gopacket.Payload可以直接追加字节内容到要发送的包里 gopacket.SerializeLayers(buf, opts, ð, &ipv4, &tcp, gopacket.Payload([]byte(data))) 据说PF_RING具有更高性能，但似乎gopacket的pfring没有支持SetImmediateMode的API，所以会抓到的每个包有200ms延迟时间，不适合做旁路劫持等延迟敏感的应用

目前而言Youtube视频分为三类，各有不同保护措施 第一类：最开放的，直接可获取真实地址 第二类：版权保护的，无法从第三方站点播放的视频，也可通过直接获取youtube播放页获取真实地址 第三类：签名保护的，这类地址需要通过转换一个key来获取真实地址 首先，youtube播放页关于视频信息是一段javascript，从ytplayer.config = 到;ytplayer.load为止。 其中args的adaptive_fmts是各种分辨率的视频和音频（注意Youtube目前音视频分离）地址。对于第一和第二类，直接解析adaptive_fmts内容即可，每个视频以及音频之间是以逗号为分隔，URL编码。 重点在于第三类视频，这类视频可以发现通过上述方法获取到的地址中，缺少signature这个URL参数，而且提供了名为s的一个参数。 阅读html5player.js后可以发现Youtube针对这类视频是通过javascript将s参数转换为signature，附加到URL后的，而Youtube为了增加被解密的难度，通常几天就会更换一次播放器的js，如本文编写时，地址是https://s.ytimg.com/yts/jsbin/html5player-zh_CN-vflU-xyD7/html5player.js 其中的html5player-zh_CN-vflU-xyD7会经常变化表示不同的播放器版本，除了修正Bug新增特性外，几乎每次都会更换加密的几个参数。所以如果编写Youtube视频解析地址工具，不应该将参数写死在代码中，而应该通过获取javascript内容解析执行。 对于Python而言可通过pyexecjs这个库方便的办到这个事情。 Python代码如下（不保证今后可用） https://gist.github.com/nightcoffee/dad38232a532b36a61b6 修改VIDEO_ID为你的视频ID（就是播放页后跟着的那个字符串） 执行结果 Using javascript interpreter: JavaScriptCore Title: [MV/HD 4K] SECRET (시크릿) – YOOHOO (유후) video/webm; codecs=”vp9″ |3840×2160 60fps|611.41MiB |https://r4—sn-nwj7knl7.googlevideo.com/videoplayback…… video/webm; codecs=”vp9″ |2560×1440 60fps|261.93MiB |https://r4—sn-nwj7knl7.googlevideo.com/videoplayback…… video/mp4; codecs=”avc1.64002a” |1920×1080 60fps|138.53MiB |https://r4—sn-nwj7knl7.googlevideo.com/videoplayback…… video/webm; codecs=”vp9″ |1920×1080 60fps|107.17MiB |https://r4—sn-nwj7knl7.googlevideo.com/videoplayback…… video/mp4; codecs=”avc1.4d4020″ |1280×720 60fps|82.11MiB |https://r4—sn-nwj7knl7.googlevideo.com/videoplayback…… video/webm; codecs=”vp9″ |1280×720 60fps|63.44MiB |https://r4—sn-nwj7knl7.googlevideo.com/videoplayback…… video/mp4; codecs=”avc1.4d401f” |854×480 30fps|27.45MiB |https://r4—sn-nwj7knl7.googlevideo.com/videoplayback…… video/webm; codecs=”vp9″ |854×480 30fps|19.84MiB |https://r4—sn-nwj7knl7.googlevideo.com/videoplayback…… video/mp4; codecs=”avc1.4d401e” |640×360 30fps|14....