2 年后优酷盒子无线网卡坏了，固件也没更新了，连论坛也消失了。。。这个挂羊头卖狗肉的优酷盒子，看电影直接提示不支持电视端播放。

呵呵，现在的互联网企业信誉太差劲了。

有没有戴什么东西可以抵抗噪音的。

经常去巡车间，那机器的噪音，当时发现几个模具车间的年轻人被诊断为耳聋。。。工伤啊。

android /ios 都是有防火墙软件的。android firewall 以前酷市场有个蓝色界面的，只是在有些系统下可能运行不正常。有点 iptables 经验的话，玩这个还是蛮省流量的，因为它可以 根据不同的 3g/wifi 网络 白名单 指定特定的应用访问网络，那么就能有效的控制流量了。

不然只能打开 3g 时来一波消灭进程操作，但是有些后台进程还是没办法的。

去 stunnel.org 看看。3 张证书的加密过程。。。加密链路 /服务器验证客户端身份 /客户端验证服务器身份 ，偶尔线路不能访问的时候去掉 客户端验证服务器身份 就正常了，这难道就是传说中的 中间人 攻击？因为是基于 pki 的，所以可以动态变换证书。反正觉得蛮安全的。

客户端配置
cert = 1.pem
verify=2
CAfile = stunnel.pem

服务器端
requireCert=yes
verifyChain=yes
verifyPeer=yes

优酷路宝是我最喜欢的路由 128m 内存带 tf 接口，就是少了个 5g。树莓派早吃灰了，没时间折腾这么多设备，openwrt 有接近 4000 个包，功能上也很强大。

搬瓦工用了 3 年了，我觉得还马马虎虎。平时只是用它查 google，用 stunnel 跟 l2tp 多。
当然有些特殊的连接比如 softether 自身的协议，一用那就是断网，然后重新 pppoe 获得新 ip 又复活了。所以我用的路由每天都是定时更换新 ip 的。

正在 Ping 198.181.56.83 具有 32 字节的数据:
来自 198.181.56.83 的回复: 字节=32 时间=167ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=162ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=338ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=163ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=161ms TTL=50
请求超时。
来自 198.181.56.83 的回复: 字节=32 时间=166ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=239ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=163ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=163ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=175ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=163ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=163ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=163ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=271ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=163ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=163ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=295ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=163ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=258ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=161ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=321ms TTL=50
来自 198.181.56.83 的回复: 字节=32 时间=163ms TTL=50

wifi 有所谓的无线弱信号原理。也就是信号最差得那个客户端决定了所有用户的连接速度，即便你就坐在 ap 50 厘米距离内，仍然受 15 米距离外前台我 wifi 连接影响，掉包高延迟情况依旧。

我有个 mtk7620 路由，一台笔记本连接时可以全速 10mb/s，一堆的不受控制的，不知道客户端在哪里终端连接时，速度可能掉到 300kb/s。于是我又使用了自动踢除弱信号脚本，保持 5mb/s 速度还是有保障的。

至于越近这个概念，根据脚本的输出，20 厘米距离内，手机一黑屏依然高达-80dbm，然后脚本一踢又变成-50dbm，所以近只是相对的概念信号好坏才是关键。一堆的手机黑屏影响我无法测试，但是 Windows 电源节能选项关于电池模式下的 wifi 中等性能确定很容易造成掉包高延迟情况。

有时候挺感叹的手机都 4g 内存了，想当服务器用吗。问题是那么多程在后台还是要吃电啊。所以 root 消灭不必须进程还是最绿色的方式。

呵呵呵，信不信由你，自从用了 ubnt uap 以后人都变傻了，一方永远说 uap 是神器，一方说它就是垃圾。它家的论坛是有审核机制，它家的 qq 群也没人想说话。tplink 再垃圾我可以每天定时 curl 登录 reboot 保证它 24 小时之内的稳定性。没错我描述得非常准确半小时内掉 n 次线，长达一年时间没出个稳定固件。什么方法我没用过自动踢除弱信号，cron reboot，禁止广播包，压根就是个用技术无法解决的神器。

其实一直是 ubnt 黑粉，ubnt 有多稳定自己去
http://bbs.ubnt.com.cn 看看就知道了。什么客户要求 uap 有定时重启功能，什么连 erx 都需要 cron rebooot 需求。
用过一年的 uap lr，从粉转黑。我只能说 ubnt 的设备是神用的，完全就不是靠技术就能解决的。长达一年的时间没推出一个可以稳定 24x7 在线的固件。半小时掉 N 次网的设备连 tplink 都不如。这么多 ddwrt openwrt 用在 atheros 芯片的固件都至少可以 uptime 30 天。为什么 uap 连半小时都撑不住，整天电话被员工打爆，一年后离职，接手的全部换成有线。从此无视 ubnt 的设备。

至今不知道无缝是什么东西？手机系统其实是非常高级的，一些手机的 wifi 高级选项里都有类似信号阈值切换选项，所以在这些同 ssid 的伪无缝环境可以做到自动切换就近连接到附近信号好的 ap 上。这已经属于客户端主动漫游了。
但是以前在使用 realtek 无线网卡 win8 系统使用 Windows 自带的无线管理软件，在手机可以自动切换的 5 ap 同 ssid 环境，Windows 却是傻傻分不清，永远主动去连接最后一次连接成功的 ap，不管它有多远信号有多差，其实设备根本不认识人眼识别的 ssid 而是 bssid。最后无奈，只能去下了第三方的可以识别 bssid 的无线管理软件，才能知道哪台 ap 才是自己想连的。
也就是有很多条件才能达成伪无缝，保证网络设置一致，无线 ap wireless mac 地址一致，同样 ssid，是否需要同样信道。

郁闷女人想看贡献了三张票，其实这些年好看的电影从来不是在电影院看的。我们这里是个小地方，票不好买也说明了它的火爆，没什么感觉就像看超人一一样一直在噪音中看，吵得受不了，也没什么好思考的。

淘宝上乐光 大功率的设备装过，实际效果不理想。无线是基于收 /发过程的。虽然 2 楼装 AP。1,2,3,4 都能覆盖，而且在 1 楼的笔记本上还显示信号非常好，实际可能发回的信号接收不到，最后高延迟掉包情况明显，适合勉强一用。想高速传送文件就不好说了。
大功率的设备就是瞎广告。最后一楼又买了一个覆盖解决。
当时有考虑过直接在 2 楼穿透地板通过 5 米长的平板天线来覆盖，最后因为没工具去打洞也就不考虑这种问题了。

传真是据说唯一具备法律意义的，扯皮的时候有用吧。

我们公司就用得一个 100 块钱的传真猫+eastfax,非常不错的电子传真软件，直接以文件方式打印虚拟传真件，清晰度非常高。接收到垃圾传真直接删除。

有种听不懂的感觉，是只有 lan1 口行 lan2 lan3 lan4 正常？还是所有 lan 口都不正常。
1 重装 win7 只信 msdn vol 版一步步安装，而不是 ghost 版。曾经遇到一台 hp 康柏笔记本有花屏现象，人家的金牌维护的建议竟然是重装正版系统。。。
用驱动人生在线更新驱动
2 给路由器洗脑，包括更新固件，更新完以后 web 界面做恢复出厂设置重新配置。
3 能 ping 通说明 nslookup qq.com 相应的 dns 查询过程也是正常的。
4 找到路由器里有关 mtu 的设置它应该是 1454 不行就改动成 1492
5 开启 asus 的 telnet，追加一句 iptables 解决 mtu 问题，
iptables -t mangle -I FORWARD -o ppoe-wan -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu

先 ifconfig，tomato 的 ppoe 应该不叫 pppoe-wan

通常就能解决 baidu 亚马逊，所有都不行还从来没遇到过。