哈哈，我也一样学业不精却要一本正经的在这里胡说八道。。。就像别人一样 mp/ap/802.11s/802.11kvr 分不清，被网络上各种小白文搞得一团乱 78 糟。

openwrt 下的 802.11s+batman adv mesh
1.batman adv mesh 的漫游特性是唯一写在 paper 上的，也是被很多 mesh 社区固件认同的用于私网的漫游协议
https://www.open-mesh.org/projects/batman-adv/wiki/Client-roaming
一堆又一堆看也看不懂的描述
https://www.open-mesh.org/projects/batman-adv/wiki

2.openwrt 下的 mesh 就是 br-lan 桥接 mesh point 接口，对于交换机来说就是 mp1 的 br-lan 桥接到交换机端口+mp2 的 br-lan 桥接到交换机端口+mp1 和 mp2 那个和 br-lan 桥接的 wlanx 又通过 mesh point 接口建立无线连接

3.真实的路径是 br-lan+mesh point 两个接口，只是 mesh 自己会择优选择 br-lan ，也就是所谓的有线 mesh 。只有偶尔在 poe 交换机出现问题，比如网管交换机自动关闭端口。此时这台 mp1 就会通过 mesh point 无线接口从邻近的 mp2 借路。这也是 mesh 比 ap 更厉害的地方，条条大路通罗马。

4.我不知道什么叫有线 mesh 路由。我只玩过通过 vpn 方式将 2 楼的 mesh point 接口桥接到 vpn 接口实现 mesh 网络扩展到 3 楼，仅仅是实验意义。因为每每说到 mesh 一定有个 mesh point 接口的存在。

5.这个 mesh point 无线接口从经验上来说它也是一个坑队友，如果你遇到无线因为最弱的客户端信号影响的话。有条件尽量不同 mp 之间都可视。

一般家庭组网仍然建议，交换机承载网络交换，如果有 3 层功能，它能做到更多的功能。mesh 我的认知它和 ap 呑吐相当漫游更快。。。

光纤猫
路由器
交换机
mesh

至于 3 图这个 mesh 主路由是什么，它可能仅仅是一个管理的设备，摇身一变就成有线 mesh 路由。

batman adv mesh 这种无中心，无 ac 的设备到底如何做到自我管理，大家可以欣赏一下。

BusyBox v1.28.4 () built-in shell (ash)

_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 18.06.9, r8077-7cbbab7246
-----------------------------------------------------
root@1L1:~# batctl
Error - no command specified
Usage: batctl [options] command|debug table [parameters]
options:
-m mesh interface or VLAN created on top of a mesh interface (default 'bat0')
-h print this help (or 'batctl <command|debug table> -h' for the parameter help)
-v print version

commands:
interface|if [add|del iface(s)] display or modify the interface settings
orig_interval|it display or modify orig_interval setting
ap_isolation|ap [0|1] display or modify ap_isolation setting
bridge_loop_avoidance|bl [0|1] display or modify bridge_loop_avoidance setting
distributed_arp_table|dat [0|1] display or modify distributed_arp_table setting
aggregation|ag [0|1] display or modify aggregation setting
bonding|b [0|1] display or modify bonding setting
fragmentation|f [0|1] display or modify fragmentation setting
network_coding|nc [0|1] display or modify network_coding setting
isolation_mark|mark display or modify isolation_mark setting
multicast_mode|mm [0|1] display or modify multicast_mode setting
loglevel|ll [level] display or modify the log level
log|l read the log produced by the kernel module
gw_mode|gw [mode] display or modify the gateway mode
routing_algo|ra [mode] display or modify the routing algorithm

debug tables: display the corresponding debug table
neighbors|n
originators|o
gateways|gwl
translocal|tl
transglobal|tg
claimtable|cl
backbonetable|bbt
dat_cache|dc
nc_nodes|nn
mcast_flags|mf

statistics|s print mesh statistics
ping|p <destination> ping another batman adv host via layer 2
traceroute|tr <destination> traceroute another batman adv host via layer 2
tcpdump|td <interface> tcpdump layer 2 traffic on the given interface
throughputmeter|tp <destination> start a throughput measurement
translate|t <destination> translate a destination to the originator responsible for it
root@1L1:~# batctl o
[B.A.T.M.A.N. adv openwrt-2018.1-13, MainIF/MAC: mesh5/b4:fb:e4:f6:a1:16 (bat0/6a:5f:e9:e9:d0:22 BATMAN_IV)]
Originator last-seen (#/255) Nexthop [outgoingIF]
b4:fb:e4:f6:a1:45 0.660s (163) b4:fb:e4:f6:a1:4b [ mesh5]
* b4:fb:e4:f6:a1:45 0.660s (247) b4:fb:e4:f6:a1:45 [ mesh5]
* b4:fb:e4:f6:a1:62 0.620s (192) b4:fb:e4:f6:a1:4b [ mesh5]
* b4:fb:e4:f6:77:b1 0.990s ( 56) b4:fb:e4:f6:a1:45 [ mesh5]
* b4:fb:e4:f6:9c:bf 0.580s (136) b4:fb:e4:f6:a1:4b [ mesh5]
b4:fb:e4:f6:a1:4b 0.540s (170) b4:fb:e4:f6:a1:45 [ mesh5]
* b4:fb:e4:f6:a1:4b 0.540s (252) b4:fb:e4:f6:a1:4b [ mesh5]
* b4:fb:e4:f3:dd:10 0.050s ( 41) b4:fb:e4:f6:a1:45 [ mesh5]
* b4:fb:e4:f6:a0:6b 0.170s (171) b4:fb:e4:f6:a1:4b [ mesh5]
root@1L1:~# batctl n
[B.A.T.M.A.N. adv openwrt-2018.1-13, MainIF/MAC: mesh5/b4:fb:e4:f6:a1:16 (bat0/6a:5f:e9:e9:d0:22 BATMAN_IV)]
IF Neighbor last-seen
mesh5 b4:fb:e4:f6:a1:45 0.530s
mesh5 b4:fb:e4:f6:a1:4b 0.410s
root@1L1:~# batctl tg
[B.A.T.M.A.N. adv openwrt-2018.1-13, MainIF/MAC: mesh5/b4:fb:e4:f6:a1:16 (bat0/6a:5f:e9:e9:d0:22 BATMAN_IV)]
Client VID Flags Last ttvn Via ttvn (CRC )
* ea:5b:55:b3:36:5c 0 [....] ( 0) b4:fb:e4:f6:a0:6b (143) (0x9e90e512)
* de:7c:86:51:3d:71 0 [....] (183) b4:fb:e4:f3:dd:10 (204) (0x7c0c16b6)
* ee:ee:ed:a2:bd:f4 0 [....] ( 90) b4:fb:e4:f6:9c:bf (151) (0x3bfd9e8b)
* ba:ea:ba:54:36:30 0 [....] ( 0) b4:fb:e4:f6:a1:45 ( 45) (0xa6b58d99)
* 5e:6b:e4:51:18:93 0 [....] ( 63) b4:fb:e4:f6:77:b1 ( 83) (0xa41c645e)
* ba:7c:e4:ed:89:bc 0 [....] ( 31) b4:fb:e4:f6:a1:4b ( 98) (0xb3018cf9)
* 96:a1:0e:86:55:45 0 [....] ( 0) b4:fb:e4:f6:a1:62 ( 65) (0xdfe92d5e)
root@1L1:~# batctl tl
[B.A.T.M.A.N. adv openwrt-2018.1-13, MainIF/MAC: mesh5/b4:fb:e4:f6:a1:16 (bat0/6a:5f:e9:e9:d0:22 BATMAN_IV), TTVN: 225]
Client VID Flags Last seen (CRC )
48:8a:d2:bd:e0:9c -1 [......] 180.080 (0xc4678fbf)
3c:33:00:59:b5:1d -1 [......] 77.930 (0xc4678fbf)
b0:52:16:28:30:d9 -1 [......] 71.210 (0xc4678fbf)
d4:d5:1b:b8:ac:60 -1 [......] 19.710 (0xc4678fbf)
6a:5f:e9:e9:d0:22 0 [.P....] 0.000 (0x8cd32694)
3c:33:00:59:cb:d3 -1 [......] 115.240 (0xc4678fbf)
18:40:a4:b1:b3:be -1 [......] 0.030 (0xc4678fbf)
2a:ac:4b:0b:bc:73 -1 [......] 341.780 (0xc4678fbf)
60:d4:e9:af:14:af -1 [......] 101.990 (0xc4678fbf)
12:c4:69:42:a9:0f -1 [......] 54.600 (0xc4678fbf)
6a:5f:e9:e9:d0:22 -1 [.P....] 0.000 (0xc4678fbf)
5a:90:4c:93:c1:ac -1 [......] 157.650 (0xc4678fbf)
c2:6a:fc:4f:0f:7b -1 [......] 216.030 (0xc4678fbf)
be:8e:17:3f:68:3b -1 [......] 406.820 (0xc4678fbf)
48:13:f3:01:57:a8 -1 [......] 580.070 (0xc4678fbf)
e2:2c:31:43:7d:2e -1 [......] 414.660 (0xc4678fbf)
12:cf:44:d4:a4:b3 -1 [......] 40.070 (0xc4678fbf)
74:60:fa:75:fa:82 -1 [......] 50.060 (0xc4678fbf)
70:d9:23:1b:b7:cc -1 [......] 124.870 (0xc4678fbf)
44:23:7c:31:a6:cc -1 [......] 33.220 (0xc4678fbf)
58:fb:84:49:ee:77 -1 [......] 65.730 (0xc4678fbf)
ae:d1:90:7a:58:e0 -1 [......] 55.130 (0xc4678fbf)
a6:ca:9c:82:bf:00 -1 [......] 329.660 (0xc4678fbf)
40:a5:ef:f4:82:6a -1 [......] 19.840 (0xc4678fbf)
b4:cd:27:f7:26:b8 -1 [......] 317.350 (0xc4678fbf)
02:fb:30:b3:90:e0 -1 [......] 393.140 (0xc4678fbf)
1e:ff:3f:2c:1e:5b -1 [......] 73.100 (0xc4678fbf)
9c:7f:81:ce:bb:a4 -1 [......] 9.870 (0xc4678fbf)
4c:f2:02:f8:40:0c -1 [......] 5.630 (0xc4678fbf)
8e:92:7a:0c:b4:c8 -1 [......] 268.780 (0xc4678fbf)
3a:0c:a2:4f:25:54 -1 [......] 0.860 (0xc4678fbf)
14:e6:e4:1e:64:88 -1 [......] 0.250 (0xc4678fbf)
ea:25:fc:87:9b:e7 -1 [......] 101.990 (0xc4678fbf)
92:27:f7:1f:92:83 -1 [......] 241.330 (0xc4678fbf)
64:b0:a6:19:f5:a1 -1 [......] 15.810 (0xc4678fbf)
98:54:1b:2a:5a:ee -1 [......] 92.760 (0xc4678fbf)
42:5d:2a:d4:69:0b -1 [......] 81.590 (0xc4678fbf)
72:93:fb:c5:dc:94 -1 [......] 70.170 (0xc4678fbf)
72:74:98:8b:46:d8 -1 [......] 437.880 (0xc4678fbf)
52:d7:0d:e3:e2:44 -1 [......] 33.560 (0xc4678fbf)
52:ec:3c:10:f5:15 -1 [......] 292.910 (0xc4678fbf)
ba:b9:1c:77:52:26 -1 [......] 590.180 (0xc4678fbf)
22:7a:ca:74:82:1f -1 [....W.] 3.550 (0xc4678fbf)
62:7f:24:c1:fb:ee -1 [......] 122.110 (0xc4678fbf)
2c:97:b1:d2:52:60 -1 [......] 2.660 (0xc4678fbf)
98:54:1b:2a:6a:c5 -1 [......] 19.400 (0xc4678fbf)
52:d7:ac:a4:f6:45 -1 [......] 1.560 (0xc4678fbf)
9c:b2:b2:c9:61:52 -1 [......] 87.480 (0xc4678fbf)
f4:60:e2:42:9d:8c -1 [......] 35.000 (0xc4678fbf)
ac:88:fd:81:19:53 -1 [......] 54.180 (0xc4678fbf)
8e:f0:25:8f:2e:71 -1 [......] 24.660 (0xc4678fbf)
f6:f2:ff:4b:f3:2d -1 [......] 35.530 (0xc4678fbf)
02:92:74:b7:1b:9a -1 [......] 185.960 (0xc4678fbf)
root@1L1:~#

这就是 qos 的好处，可是能玩 qos 的路由器还是挺少的。

水星这种路由我是看不上，你说这是一个能刷 openwrt 的路由还差不多。

常见的网络包处理叫先进先出，qos 则是高优先级出列，就像排队插队。根据 tcp 握手特性更早出去的包带来更先到来的流量。以前上海电信 20mbps 大概在 130kb/s 。

一般我自己的 qos 用的 htb 目的端口分级，目前在 100mbps ，250+终端在线 htb 的优先级还是比 hfsc 有用。
1 10%给游戏 prio0
2 10%给低延迟服务 prio1
3 30%给 web prio2
4 30%给 p2p prio3

根据之前的电话 adsl 观察，当前上行只有总流量的 60%总体延迟很低，下行流量很大。当超过 80%时，下行流量不升反而降低，延迟开始上升。
所以做了仰制 3/4 最多只能使用 80%的上行，实际光纤可以达到 95%。
所以网络上常见的一个大多人认为对，我却认为错的方法，就是通过 speedtest 测试出带宽上行，再将上行数值设置为 80%的总上行。根据观察此时带宽依然会呈现总上行 80%×80%这样一种延迟变化。
当年人家无意提到的这个 60/80 变化，

1.流量分 4 级，让游戏拥有绝对优先级出列，延迟小于 19ms
2.抑制 web+p2p 总上行不超过 80%，互相抢夺带宽，p2p 自动让步，p2p 延迟接近 600ms
3.每个流量分组依然注意 60/80%带宽占用问题，之前玩的 cs 也就 6kb/s 不到的带宽，延迟没问题。

这种 qos 没有高深的学问，一切尽在 60/80 的带宽抑制如何实现。

电信电信还有限制啊？至少电信移动之间对 openvpn 没有任何和过墙一样的 tcp reset 限制，softether 建立也是稳稳的 2.5MB 。

也许只是没有做 qos ，端口没有提权，上行流量被其它流量占用。

像我们这种有情怀的只买 Motorola 现在叫 moto ，联想产。中途用了一回 zenfone 摔得内外放都没声音了，又回到 moto 。

今年一上班就传出微信图片打转，由于没变动过网络，百思不得其解。事实情况是同样的网络，有些同事有问题有些没，上网一搜索还不好解决。
1.对我的文档微信目录备份，然后清空。看是不是配置目录问题，不好解决。
2.使用 tcpview ，当遇到问题时，将 wechat.exe 关闭连接，微信就会尝试连接新服务器，不知道能不能解决。。。

至今原因不明，做了很多尝试，包括抓了很多微信服务器，至今不清楚解决了没。

简单，你不恋她。
和朋友的聊天记录也从 2019 记录至今。看来今天就用 Swift backup 备份一下

。。。哎 100 步笑 50 步，连上星期天就 2 天。。。

本地的朋友圈似乎没问题。
外地的朋友圈，刚前几天我就问朋友屏蔽我了嘛，答没。
但我点进去不是没有三天内的信息，是那种一条线，等她发又有了。这个问题我应该问她两次了。。。我觉得她不应该屏蔽我的。。。

看来这个是会出问题，我记得当初一个朋友就是这样被我拉黑的，目前我能想的就是不同地区，因为维稳问题，就是现实中的网格化管理。。。我记得当初谁有讲过这样的事。大意像我这样的平头老百姓传播的信息，只能限制在某种区域。

自己摔倒自己站起来嘛

又或者学会赞扬别人

又或者饿了就会吃

看来养小孩对于很多人属于烦人的事，当然也会遇到有爱心有耐心同时还有时间的家长。

有些东西是可以改的，就看想不想做一个文明人。我当初就是在高中时一出口就反省。。。
环境也有关系，似乎目前的公司没碰到这样的人。

当初建议财务用 hd ，结果买到叠瓦盘。。。好处出问题，用数据恢复软件可以恢复。坏处就是一卡一卡的。。。

u 盘的文件删除我是不懂怎么恢复的，更不知道 ssd 是否可以恢复。

我之前查的时候也以小于多少来判断它的风险，想想也就 4mm 不到。
可是朋友的家人比我更小 3mm ，7 年前就有，年年体检，小医院说没问题。一直到了北京专门治肿瘤的才确认。被这么一说，我多查了一下肿瘤，怕了。。。

不知道真能用激光直接烧坏它嘛。现在知道了该吃啥吃啥，成病原理都不清楚，只能放宽心活着。

是 3mm ，7 年了一直 3mm 。。。然后举不起手去大医院才确认已经晚期了，连院都不给住，吃药。关键这睡不着，多处肿，家人不得不 24 小时揉。

7500 学费，毕业要 1 万吧。

看来买硬盘也是看人品的。。。
我就是那个只买希捷，可恨出了什么叠瓦盘，移动硬盘和家用硬盘一卡一卡。对于这种混杂型号的无良行为只能认了。

看这对比直接西数，不知道什么时候又出了个监控硬盘名词，更不可靠的代名词不是更可靠吧。据说是什么东西不检验才叫监控硬盘，显然监控数据不属于重要数据。

正常的 cmr 都是非常耐用的，当然也见过不正常断电，全盘操毁。企业级也是有坏道，只是 10 年前的企业级出了很多坏道，依然坚挺。

硬盘都是被叠瓦盘玩坏了。

前几天查了一下普通 75 寸彩电 3 千块，maxhub 2 万

主要差别
白板功能
可触屏系统，基本就是白板一个功能，所以像是 1.7 万买了个白板。

其它的无线投屏设备也就 500 块。感觉真不值。。。其它品牌便宜的也不知道是否有坑。

朋友的反应是 7 年大小一直没变化，但是这次新冠后身体就出现手举不起来的情况，结果到北京一查就晚期了，而且是到处扩展，都进骨头了。现在就是睡觉疼痛，1/2 小时就醒过来。只能靠揉。

妈呀，当时也觉得大家都有结节，没啥。据说这个东西会演变成癌。。。
朋友家人之前就测到这个，大小也一直没变化。小医院一直说没事，现在全身扩散晚期。

据说有激光烧死它的方法，真的有这么夸张嘛。。。我的小命啊 4mm 。