看起来是 bug 。

F40 changeset 里面有一些关于 NM 的改动，然后看打包情况 F40 现在是 1.46 ，而 F39 是 1.44 ，可能是中间某个版本引入的。

这个直接向上游 NM 反馈可能比较麻烦，可以试试先向 Fedora Bugzilla 报一下 bug 试试。

@bigbigeggs #11

你没有理解我的意思，我是说当你的设计目标是千万级的时候，这些优化一点都不重要。

当你考虑做成比如说十亿级别服务的时候，瓶颈就不在什么 hash 算法这些你关注的细节了。

过早优化是万恶之源。

假设 URL 的最大长度是 2KB ，一千万（ 10M ）条数据占用的内存不过 20GB 而已。

@XuYijie #18

可能是比较机械地执行等保规定吧……既然这样的话，按照对面的要求执行就是了。

如果直接用非对称加密，你只需要拉取公钥。如果用对称加密，你一样要拉取公钥，对称加密的密钥肯定是用非对称公钥加密保护一起传回去的。

不论哪种情况你都不需要保存私钥。

#3 @soar0712 说的就是标准做法。

现在不明确的是为什么要加密，防的是谁。谁让你这么干就问他，这么干的目的是什么，只有这么一种实现方式么，这么做能抵御哪些攻击。

提这个需求的大概率不懂，所以你也会跟着迷糊。你也可以试着思考一下，然后再过渡到为什么要存密钥，有没有必要存密钥，如果有必要存到哪里的问题。

当然我个人的意见是前端针对请求参数和返回值“加密”是没什么意义的（除非这个网页应用就是提供 e2e 加密的），搞“签名”还可以防机器人。

@crsmk01 #13

教育用户的成本比起开发一个诊断程序高太多太多了，这还不算技术跟客户沟通。这里的傻瓜化就是真把客户当傻瓜，我们甚至连压缩包都不发，就是直接发可执行程序下载链接。客户双击运行看完提示就万事。但是后来发现浏览器报可执行文件警告（包括国产魔改浏览器的非安全文件），还有 windows 自己的一个什么解锁。后来被迫买证书签名完事。

实际上吧，很多时候搞完这么一套，客户那边就没什么反馈了。因为多数网络问题都是临时性的，说不定什么时候就好了。

虽说标题里是找傻瓜工具，看正文这事解决起来可不是提供傻瓜工具就可以的。

我之前做过的项目里有过类似的需求，不清楚你这是什么情况，我就随便一说。

如果是客户端应用，最好开发自诊断模块，可以通过比较复杂的方式开启，也可以编译成特定版本。如果是 web 应用，可以考虑把诊断模块单独做，遇到问题的时候就发给客户运行。

这个诊断模块可以是自动上报的，如果客户有合规需求也可以生成诊断输出。记得做好鉴权，这种接口也要和线上生产接口一样对待，二进制程序发出去就控制不了了。不开玩笑，我见过异常的诊断程序一天刷了存储后端八万多个文件的事情……

当然这并不是说这个诊断应用就要集成一个抓包模块，主要靠基于日志的推理。把你自己代入到客户的位置上，你会做哪些排查，比如先采集系统环境，之后 ping 看网络通不通，再看 dns 解析是否正确，接着看 tcp 是否能连接，http 是否有反馈等等。所以我这边之前做的诊断程序就是一个执行脚本的工具，用户执行的时候会输入一个技术支持代码，其实就是拉取预设好的诊断脚本。

抓包这个事情除非有技术支持上门，我是不推荐的。一般来说，只有非常非常小概率才必须依赖抓包解决问题。

1. 不清楚你的使用场景，从不信任客户端的角度上说，单独在客户端做限速是可以被轻易绕过的。考虑一下变速齿轮，客户端获取到的系统时间是不可信的。

2. 看你的描述，应该是服务器出口流量分配的策略。比较 naive 的实现有可能在用户不饱和的时候难以有效利用带宽。

3. 限速模块尽量与主逻辑解耦，可以把限速委托给系统或者平台，比如 tc 配合防火墙，或者前置反代等等。主要是界定限速的目标是产品意义上的用户，还是软件意义上的客户端，限制来源可以有包级别，链接级别以及 session 级别等等。

4. 比较简单的限速策略容易在客户端和服务器端之间产生尖峰流量（锯齿状），不适合流媒体等场景。需要平滑速率曲线需要的不是限速（ throttling ）而是流量整形（ traffic shaping ）。

1. Pixel 设备的网络锁（ carrier lock ）的验证是通过 Google 服务器的。

2. 安卓设备本地记录这个状态是通过一个名为 get_unlock_ability 的标志位。这个标志位位于受 TEE 保护的存储区域。

3. 系统设置里的 oem unlocking 选项受前述标志位影响，标志位为 0 的时候 oem unlocking 就是灰色的。

4. 系统设置里的 oem unlocking 选项开启时执行的动作没有二次校验。

5. Pixel 软件里涉及 get_unblock_ability 的代码仅存在于 oobconfig 中（ oob 即 out-of-box ，一个初始化时运行的组件），只会从 0 写为 1 ，已经为 1 就不管了。

综合以上 1234 ，在不真正解锁网络锁的前提下，只需要系统级漏洞就可以解 oem unlocking 灰色锁。只要解锁一次，就再也不会变灰。基本上每个版本都有这么几个漏洞，这些漏洞离 root 差得远，但是把 ui 开关打开是够用了。


PS

咸鱼商家的软件就是 usb 重定向，与实际解锁过程无关。

咸鱼上大部分都是漏洞解，并没有解除网络锁，只是解了这个灰色锁。

特解某型号某运营商的一般是线下和上游走私商家合作，后门解锁，直接把解锁请求发到 Google 那边。这种线上基本见不到。

@ysmood #32

哈哈我一直在用你写的 rod ，非常棒！

@playboy0 #29

流量来源是分光设备，旁路直接进服务器的光口网卡。什么都不用配置，网卡开启 promiscuous 混杂模式抓包就行了。端口镜像应该一样的道理。


这个项目是挺久之前的了，某集团安全审计相关，要做全协议流量分析。内部接入比较复杂，有类似 PPPOE/PPP 之类的认证，VLAN 既有二层也有三层。所以直接从出口分光出来做的。

这个事情本身不是我负责的，我就是去救火的。因为这个事情后来又做了针对某些协议的 DPI ，这玩意后来对外好像卖了接近一千万……

原本有个 DPDK 的方案，是很早之前从别的地方采购的，没人能维护。配套服务器是双路 E5 ，核心倒是多，只是频率很低，系统又是 CentOS 7 。基本上就是抱着死马当活马医的想法，姑且用 Go 一试。

系统太老了不想维护，所以 PF_RING 指望不上，就拿 AF_PACKET 替代了，实际测试下来没啥问题。这个做到后面发现 AF_PACKET/MMAP 其实和 PF_RING 原理几乎一样的。如果现在做的话，可能都是用 AF_XDP 了，性能估计还能翻番。

当时还用的是 google/gopacket 而不是后来有人维护的 gopacket/gopacket 。不过影响不大，整个库的基础功能很完善了，除了当时没有的几个协议做了一下解析实现。


技术上这个只要懂原理的话没什么难度，内核里用 BPF 去抓包，MMAP 内存在内核和应用之间共享，AF_PACKET 设定好扇出，把网卡的数据写入 MMAP 的内存，用户空间的应用通过 ZeroCopy 方式读就可以了。核心部分代码可能没有一百行。

稍微跑个题，既然变更历史那么重要，有没有考虑过用 git 和文本文件做密码管理呢？

使用 git 你可以天然记录变更历史，同时可以任意 self host 或者利用各种公有设施实现分布式备份。

缺点是文本文件要加密。那就再套一层 gpg 加密好了，git 管理 gpg 加密后的文本文件。

剩下的事情就是写个 wrapper 把这个操作简化掉。

如果你认为这个思路合理的话，可以参考 pass - the standard unix password manager

https://www.passwordstore.org/

我已经用了十多年了，在各种平台都有开源可自编译的客户端或命令行工具。

@CC11001100 #2

盲猜一下，估计是那个认证服务器不在内网里，所以要给一段时间让你能够打开那个认证页面，2016 年那些系统还不成熟。

一般这种 captive portal 在出口处的防火墙默认阻止所有 ip 访问（非 mac ），通过认证的就让防火墙放行。然后一般为了减轻防火墙负担，已经建立的连接后续数据包就直接放行了。

反复 release/renew 让你的设备在系统看来是新设备加入，清空了之前防火墙记录，你的访问（ dns 请求，发起连接）能在系统预设的时间里发起，流量就能通过。

现在的系统基本上都是绑定到 mac ，比如星巴克用的，你可以跨店免认证接入。再就是认证服务器处于内网，通过旁路连接到中央计费后台。这样就没办法流量偷跑了。

厉害啊哈哈

@playboy0 #26

老 E5 单核 2G ，单个核心处理能力最高 100k pps 左右，包含业务逻辑。单纯解析时间中位数在 20us 左右。

由于整个内核 AF_PACKET 扇出数量和并发线程数是一致的，加上解析过程是 zerocopy ，几乎不会触发 gc ，内存占用没有印象了，应该非常稳定。

https://github.com/google/gopacket

我之前在 go 经验的帖子里写过，这个库配合一些手动内存管理的技巧，在 10Gbps 网络上做实时处理没什么问题。

如果是 pcap 离线文件，直接按照示例写就好了。

这个是不是考虑方向偏了？我觉得有必要明确区分 layout/session ，恢复 layout 是个容易的事情，但恢复 session 不是个很好的方向。

我个人的意见，session 很廉价，完全可以预先开很多 session （习惯通过 systemd service 管理），无论是 ssh 还是本地连接的时候直接 attach 到对应的 session 里面。

对于非重启环境，直接 detach 就可以了。对于重启环境，没想到要恢复 session 的应用场景。

@ChristopherY #18

用什么都可以，取决于你哪种语言比较熟练。C 版本的 libpcap 我没用过，考虑到是 tcpdump 在维护的，肯定是没问题的。Go 版本虽然两年没更新了，但协议这个东西又不会变……

另外我觉得你其实考虑复杂了，gopacket/libpcap 都是强在抓包，至于你是不是用它做解析不关键，用它做解析的原因就是它们把协议相关的数据结构都定义好了。

换个表达方式，你现在以字节形式读取到某个包（忽略到 pcap 文件格式解析），它一定是代表着某个多层嵌套的数据结构：

[ L1_Header : L1_Payload [ L2_Header : L2_Payload [ L3_Header : L3_Payload [ ... ] ] ]

然后假设 L1 是来自三层的，然后有 IP/ICMP/IGMP 几种协议，就拿 IP/ICMP/IGMP 的数据结构去套上面的字节流，匹配到就可以拆包了，L1_Payload 就是 [] 里面 L2/L3... 的内容，继续下一层解析就是了。

像 dpkt 这种数据不足，肯定是各种协议 Header 的数据结构定义不完善。scapy 我用过但是印象不深了，我估计慢的主要原因是它没法做到像 C/Go 这样可以手动分配内存，然后 one pass 把多层结构一次解析出来。但是 scapy 大概每次都要遍历匹配所有协议，来判断下一层是什么。

这个解析过程本质上和按照某个特定格式读取二进制文件没什么区别。

提高解析效率除了解析单个包层面的优化，主要是靠多线程。特别是实时抓包实时处理，靠内核 AF_PACKET 机制扇出，分配个多个线程来解析。如果是单线程肯定会非常慢。