虽然我也不那么喜欢 cmake ，但更不喜欢 GNU Makefile ，因为我需要兼顾 BSD 系统（ BSD Makefile 稍有不同），所以最后还是要用 cmake 兜底

@YGBlvcAK 这种情况只能继续使用专门路由条目或者防火墙规则。setfib 只对 FreeBSD 机器里面运行的程序有效。

@zx900930
1. 对于 FreeBSD 是否受影响，既是，亦否：
https://forums.freebsd.org/threads/ssh-cve-2024-6387.94018/
“And no, the RCE that makes this an actual threat does not apply to FreeBSD (or other BSDs and illumos), but only to systems using gnu libc”

直接下定论说“FreeBSD 可是完全在影响范围内的”为时过早，甚至未必是正确结论（如果事后证明该漏洞没有 impact 到 FreeBSD 的话）。
昨天 opnsense 社区已经有人提到了 FreeBSD Security Team 为什么会发布漏洞，简单来说单纯就是“没发现冲击，不管怎样，先升级了再说”：
https://forum.opnsense.org/index.php?topic=41342.0
“There's no confirmation yet on FreeBSD, however the security team there decided they'll patch first and ask questions later - as Colin explained it on Twitter shortly after the vulnerability bacame public.”

对应推特原文：
https://x.com/cperciva/status/1807703216567865471
“unclear if exploitable on FreeBSD but we have an advisory out just in case.”
没错，just in case ，就是这么简单粗暴

于是才有了
https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc


2. 我原文写的是“这就是为什么 OpenBSD 本身没事”，这么清楚的描述还能理解成“连带 Linux 都没事”，我觉得实在是匪夷所思。

@tool2dx 这个“花活”算不算花那要看系统吧。在 openbsd 就不算花了。大家都忘了一个前提，openssh 原本只是 openbsd 的内置组件，只不过顺手放出来给其他系统拿来用。

他们做开发做测试的时候必然优先考虑 openbsd 自家的规则。至于同样的写法在其他平台会出现什么怪事，或者冲突，或者 openbsd 属于正常的代码到了别的平台属于不规范的代码，应该都是能跑就行，没出事就不管，出事了再说。就像现在这样。

@proxytoworld 准确地说，是 glibc 的 malloc 、free 函数并非异步安全。

我多次明确写出 glibc 就是这个缘故，祸根来自于 glibc

自己接软路由，IPv6 用起来会更完善，比那些低端功能残缺的 WiFi 路由好得多

我看你是来引战的吧，看看其他帖子，大把的人不但需要宽带，更需要使用高优先级宽带，比如 CN2：
/t/1054447

你要不要去这些帖子底下问问为什么需要这么高级别的宽带？

@acess https://www.wiz.io/blog/cve-2024-6387-critical-rce-openssh
https://sploitus.com/exploit?id=1CF00BB8-B891-5347-A2DC-2C6A6BFF7C99
已经有人分析过了，造成这次爆漏洞，是因为 glibc 的 free()属于 async-signal-unsafe 函数，只要其他系统的 free()不是这样搞就不怕。
这就是为什么 OpenBSD 本身没事。像是 Windows 和 macos 、FreeBSD 之类的应该也不会有事。异步 free 其实不算罕见。FreeBSD 那边也不觉得这个漏洞会影响到自己，但还是先升级了版本再研究。

@juzisang 打洞用的。可以参考 natter 的描述：
/t/879549
/t/1030967

@acess Windows 内置的 OpenSSH 不受影响
目前只有 glibc / Linux 才会受影响

@weeei FreeBSD 已经发布了紧急更新，需要用 freebsd-update 来升级，不能用 pkg 管理器来升级

看了下 OpenSSH 的公告，发现这个 Bug 几乎就是 Linux-Only ，更进一步地说，是仅限于 glibc 的 Linux 系统受影响

而 OpenSSH 的发源地——OpenBSD ，完全不受影响

这有没有可能是 glibc 的的间接 bug 呢

全键盘路过，Home End PageUp PageDown Delete 刚需，小键盘刚需（用来输入 IP 地址非常方便）

最适合的方式是，目标系统是什么，开发系统就用什么。
假如，目标系统是 CentOS ，那你也用对应版本的 Linux ，可以是同版本的 CentOS ，也可以是 Rocky Linux

有个办法绕开 UDP 限速，但不保证 100%有效

首先建议给 UDP 测速，看看 UDP 流量是一开始就被限速，还是过一段时间再被限速的。
遇到限速后，再在同一条宽带建立新的连接，重新再试。
整个最好用另一条闲置线路去测，不要直接用现有的繁忙的业务线路，这样准确点。

如果是过一段时间才遇到限速，并且建立新连接后发现限速解除，新连接再过一段时间又限速，那就说明运营商做的限速是基于端口的限速。这种情况就可以试下这个办法。

办法很简单：
服务器侧监听一大段端口，客户端连接这里面的端口都能通。
客户端建立连接后，每隔一段时间就再建立新的 connection ，连上服务器侧的另一个端口，把现有通讯转过去。

为什么客户端要建立新连接？因为这样可以保证客户端的源地址也会改变。

这个办法就是我写的工具 UDPHop 的基本原理，做起来相对简单

不觉得性能过剩，编译项目时最明显，新 CPU 编译速度远超 5 年前的同价位产品

何必攀比呢，说真的，现在 OP 仅仅属于开始焦虑而已，而且是没必要的攀比

等到真的出现公司倒闭、找不到下家，那可真就崩溃了