1.交换机出问题的可能性比较低，但不是没有。比如交换机电容坏了。其它的就是其它设备产生的网络广播导致的端口拥塞，一般通过 1 根根的拔线相应端口的灯的闪烁状态基本能判断是哪根导致的。

既然是 3 个二级网络，还能有连上 wifi 的感觉，不像是广播风暴。
windows 一般的做法就是通过 cmd /c ipconfig /all 查看当前客户端分配的 ip
然后 ping 网关，看延迟是低，还是高延迟掉包情况。高延迟掉包有可能是无线干扰也有可能是广播拥塞导致的。
可以拔除其它 2 个 AP ，只留下 1 个进行 ping 。再不行，只能通过断电交换机来看是否真的是交换机的问题。

另外华硕不是什么好东西被反应 dmesg 会 boom 的用户不少，tplink 也不是什么好设备。
一般建议做为 AP 的话有条件就是 1 天 1 重启，反正总有一天会因为内存导致程序崩溃死机，不如 1 天 1 重启。这么多年遇到的能够无限恢复内存只有 dlink 600 B1 刷 ddwrt 。其它的 AP 的建议就是 1 天 1 重启可以解决很多问题，像 realtek 的流量掉到 10KB 以下，像内存不足导致的 dnsmasq DHCP 失效之类的问题。

没仔细审题，单纯的 socks 是过不了墙的。所以早些年都是用 stunnel 进行加密，直到后来 stunnel 也自带 socks5 并使用 TLS 加密。

; **************************************************************************
; * Global options *
; **************************************************************************
debug = 6
;output = r:\stunnel.log
;compression = zlib
RNDbytes = 1024
;RNDfile = d:\stunnelrnd.txt
RNDoverwrite = yes
; **************************************************************************
; * Service defaults may also be specified in individual service sections *
; **************************************************************************
;sslVersion = all
;sslVersion = TLSv1.2
sslVersionMax = TLSv1.3
sslVersionMin = TLSv1.2
;options = NO_TLSv1.3
;options = NO_TLSv1.2
;options = NO_TLSv1.1
options = NO_TLSv1
options = NO_SSLv3
options = NO_SSLv2

socket = r:TCP_NODELAY=1
socket = l:SO_LINGER=1:60
socket = r:SO_OOBINLINE=yes
;socket = a:SO_REUSEADDR=yes
TIMEOUTconnect = 120

options = SINGLE_ECDH_USE
options = SINGLE_DH_USE

;ciphers = ECDHE-RSA-AES128-GCM-SHA256
;ciphers = ECDHE-RSA-AES256-GCM-SHA384
;ciphers = ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384

cert = 1.pem
;failover = rr

; **************************************************************************
; * Service definitions (at least one service has to be defined) *
; **************************************************************************

[server4]
CAfile = stunnel.pem
verifyChain = yes
;verify= 2
;verifyPeer = yes
;verify= 3
client = yes
accept = 0.0.0.0:1085
connect = vpsip:80
connect = vpsip:8443
checkHost = www.apple.com
checkHost = www.microsoft.com
checkHost = www.symantec.com

;stunnel 的中继实现
[TLS_proxy_listener]
accept = 1992
connect = 1085
CAfile = stunnel.pem

E-mailrelay 就是这么多年找到的最好的 smtp 客户端

先通过 stunnel 连接 qqmail 到 127.0.0.1:10025
[gmail-smtp]
;sslVersionMin = TLSv1.2
client = yes
accept = 127.0.0.1:10025
connect = smtp.qq.com:465
verifyChain = yes
CAfile = ca-certs.pem
checkHost = smtp.qq.com
OCSPaia = yes

windows 或者 linux 调用相似的命令就可以将需要帐号登录的 smtp 转换为无需帐号登录的实现，供 weKan 调用。

start "emailrelay" "d:\Program Files (x86)\E-MailRelay\emailrelay.exe" --client-auth "d:\Program Files (x86)\E-MailRelay\conf\emailrelay.auth" --close-stderr --forward-to 127.0.0.1:10025 --immediate --log --log-address --log-file "d:\Program Files (x86)\E-MailRelay\Run-time\emailrelay-log-%%d.txt" --log-time --pid-file "d:\Program Files (x86)\E-MailRelay\Run-time\emailrelay.pid" --remote-clients --spool-dir "d:\Program Files (x86)\E-MailRelay\spool" --verbose

不懂要干嘛

如果单纯解决 smtp 发信客户端问题，目前最好的是 E-MailRelay 。
Stunnel 提供了一个 gmail 的中继实现，我用它将 qqmail 加载到搬瓦工，然后配合 E-mailrelay 就可以无需用户登录配合 wekan 进行 smtp 使用 qqmail 发信

一般常见的，真打不开，网管主动屏蔽网站
其它的就是因为 mtu 分包导致的问题，平时 android 使用 socks 在本地形成 tun 接口，设置 mtu 为 1396 也是 ok 的。

充耳机我就非常小心，好不容易翻出以前 600ma 的充电器。当然华为的充电家也是有专门的触发小电流充电的方法。

哈哈，海边的人再去厦门，哎，感觉就是逛街。唯一新奇有些海产品没见过。
土楼嘛，也没细逛
武夷山，妈呀山上的小路才只能容纳 2 人都没，上去就别想下来了，除了人还是人。。。

公司交换机用的是一个华为的 s5720s li ，可能存在的问题 l3 在 if 接口的实现并不能全速，存在做减法的可能，有感知没认真测试过，必竟只是个 li 。

至于 openwrt 网关承担的作用
1.静态路由带各 vlan 上网
2.用 dnsmasq 承担了所有 vlan 的 dhcp 分发
3.qos 抓取所有 vlan ip ，对流量超标 ip 进行动态 qos
4.使用 iptables+ipset 对 ip 进行基于互联网的访问控制。

routeros
我不会用，但我会很不屑它比不上 openwrt ，哈哈。玩了 linux 再来看 routeros ，它就是个把 linux 再转义的版本，同样的命令给它一转少了几个参数。至今不知道 linux 的 tc 命令怎么用 routeros 实现。脚本也没 shell 灵活吧。

爱快
同样很不屑，不知道现在的版本有 ssh 嘛？这种 web 管理的路由，看官方的文档根本分不清实现 1 和实现 2 的具体区别。。。

openwrt
在用它之前，用的是 ddwrt/tomato 。每每一些新奇的东西只能等别人编绎好。用它最大的好处可以根据需求剪减固件，自己做路由器固件。web+ssh+shell 原来路由器也是可以编程控制的。目前 100mbps 带 220+终端，主要实现静态路由+qos+vpn+ipset 访问控制，非常不错！！！

Panabit
不知道啥玩意，当年有人跟我争论 qos 过滤的时候就把 Panabit 的 dscp 捧上天。其实不能做 l7 精确流量控制浪费 cpu 资源，依然可以用目的端口进行流量分级控制，实际效果出乎意料的好。qos 真正的关键竟然是流量的分组实现，根本不是什么 l7 识别，这种适合做 acl 访问控制。

小时候看人家有双阿迪达斯的很是羡慕。那应该是 1994 年的事情了。。。

在穿托鞋差点把命都没了，开始买李宁的羽毛球鞋为的就是雨天抓地不怕滑。300 左右的，一直穿穿个 2-3 年没问题吧。

100 的回力就算了，造型是不错，可是那鞋底走起路来就是直接拍地的声音，没有缓冲的过程。特别是那种 1 天站立 11 小时的工作，没双缓冲的鞋，脚是真的受罪。

没穿过高级的，李宁我认为是很有性价比了，想把它鞋底穿出洞来还是有点难度的。

曾经买来一个 moto 。擦擦干净，准备套壳的时候，它从桌子滑到地面，直接背面着地，背部玻璃都裂开了。。。当然至今能用，幸好不是正面。。。

现在买手机保护壳，全部是四角气囊防摔型，昨天又从小电驴上摔到地上，是角着地皮的。感叹这种手机壳真好，好几次了还没见玻璃碎的情况发生。

四角气囊防摔手机保护壳是我见过最好的手机保护壳了。。。

这个狗屎问题，在之前 update 封装系统时经常碰到，按网络上的解决方案也不好解决。

个人认为是别在每月的高峰期 update ，选择 20 以后者月初 8 号之前？别选在 update 刚出来那段时间。

公司买了 4 个飞利蒲的，还行，没坏。好像同事自己买的坏了，当时就是参考她的 typec 接口型号买的。

一直买 moto ，中途用了一回坚如磐石的 asus zenfen ，摔得外麦都坏了。后来继续 moto 。。。目前 moto x30 。
大牌还是大牌，品质要求肯定不低。记得近年小鲜肉评测 moto 属于山寨小厂，笑。。。当年 android 第一个双核手机，华为还没手机呢。哈哈，好汉不提当年勇。。。

至于耐用，可以选择 4 角的气囊保护的手机壳，不怕摔。

这道题有点难解，到底需要的是路由还是 AP 。。。

公司 100mbps 用的 erx 刷 openwrt 21.02.5 ,
# cat dhcp.leases|wc -l
229

# free
total used free shared buff/cache available
Mem: 251988 52144 153908 21228 45936 141688
Swap: 125948 0 125948

# uptime
14:33:43 up 35 days, 21:26, load average: 1.03, 0.66, 0.56


mtk7621 还不烂。

AP 有华为的 s5762-12+uap mesh