自从感觉到 chatGPT 基本能覆盖技术的方方面面, 就不太愿意写博客了. 但是记录一下路由器的设置和操作, 还是很有必要的, 主要方便自己以后重新设置方便.

一开始搬到这边后, 只有一个移动的光猫. 但是在另外一个房间, 总是信号不好. 于是买了一个华为的穿墙路由器, 通过网线连接到移动光猫. 过了半年, 感觉离路由器较远的一个房间还是信号不好, 小孩上网课会卡顿. 于是又买了一个小米的路由器, 改成小米路由器通过网线连移动光猫, 然后华为路由器通过桥接连小米路由器. 这样终于信号不错了. 再后来, 公司的 Proxy 不能用了, 即便在公司电脑上. 于是想在路由器上假设透明代理. 查了下, 发现小米路由器可以ssh, 于是折腾开始了.

给小米路由器装openWRT

有人做了全自动的破解安装ssh, 和安装 openWRT: https://github.com/openwrt-xiaomi/xmir-patcher. 一个 run.sh 或者 run.bat 完全搞定.

openWRT 的基本设置

修改网段

openWRT 的默认网段是 192.168.1.x. 移动路由器也是 192.168.1.x, 虽然一个是在lan, 一个是在wan口, 理论上没影响, 但还是把openWRT上的 192.168.1.x 改成了 192.168.31.x. 这也是小米最初的设置.

修改时区和NTP server

System -> System
时区 -> ntp.aliyun.com, ntp.tencent.com 等.

修改wifi通道

Network -> Wireless -> 选择 SSID -> Edit -> Operating frequency & Country Code

修改 DNS

安装完之后, 刷小红书视频有时候会卡住, 不知道为什么, 猜测可能是openWRT 的默认英文版本里面的 DNS 是国外的, 于是修改 DNS 配置. 在 /tmp/resolv.conf.d/resolv.conf.auto 里面添加国内的 DNS servers

公共 DNS 服务

运营商 DNS

恢复系统

很多时候, 发现安装某个软件之后, 网络就慢,或者有问题, 可以从头再来. System -> Backup / Flash Firmware -> Flash new firmware image. 这个image 可以从 https://openwrt.org/inbox/toh/xiaomi/ax3000t 安装部分(Installation) -> Firmware OpenWrt Upgrade URL 下载.

早上刚打开 MAC 笔记本 5分钟, 就提示我电池快没电了, 于是感觉给它供电. 紧接着, 就听到风扇呼呼作响, 于是查看 Activity Monitor, 发现有个 Python 进程几乎占用一个CPU, 感觉有 bug, 也许是项目的那个代码没写好. hmm, 生产环境不会也是这样吧?

先确定进程信息

有了进程号, 进程很容易确定.

% ps aux  | grep 24315
xiatian          24315  99.3  0.0 36938856   9804   ??  R    Mon10PM 1044:13.73 /usr/local/Cellar/python@3.11/3.11.11/Frameworks/Python.framework/Versions/3.11/Resources/Python.app/Contents/MacOS/Python /Users/supra/work/projects/agent-ui/main.py

再做 CPU profiling

py-spy 是一个非常流行的采样 profiler，可以在不修改代码的情况下分析任何正在运行的 Python 程序。

pip install py-spy
py-spy record -o profile.svg --pid 24315

火焰图如下:

前面三行都是 Python 自带 python3.11/threading.py 里面的代码. 最后一行是 concurrent/futures/thread.py) 的代码, 代码如下:

    try:
        while True:
            work_item = work_queue.get(block=True)
            if work_item is not None:
                work_item.run()
                # Delete references to object. See issue16284
                del work_item

                # attempt to increment idle count
                executor = executor_reference()
                if executor is not None:
                    executor._idle_semaphore.release()
                del executor
                continue

            executor = executor_reference()
            if _shutdown or executor is None or executor._shutdown:
                # Flag the executor as shutting down as early as possible if it
                # is not gc-ed yet.
                if executor is not None:
                    executor._shutdown = True
                # Notice other workers
                work_queue.put(None)
                return
            del executor
    except BaseException:
        _base.LOGGER.critical('Exception in worker', exc_info=True)

看上去从 work_queue.get(block=True) 拿 item , 每次拿到的都是 None. 那么下一个问题就是这个 work_queue 从哪里来的, 为什么会以极快的速度返回一个 None?

交叉验证

要回答上面的问题, 就要深入内存去看这个 work_queue 从哪里来的, 它引用了那些对象, 哪些对象还在引用它. 这样才能确定这个 work_queue 有什么问题. 但是, 在此之前, 我们可以去production 看一下, 看看在prod 的 Linux 上是不是有类似的问题, 结果发现完全没问题, 并且它运行的时间更长.

于是猜测, 这个问题难道只是个 MAC 有关? 或者和 MAC 休眠有关?

最近又因为这件事情折腾半小时, 索性记录下来.

1. 因为公司电脑有防火墙或者公司电脑访问策略的问题, 不能使用 git 协议访问 github.com 的 push/pull, 所以只能使用 https 协议, 比如: https://github.com/int0x03/samples.git
2. github.com 已经禁止使用账户加密码来操作 git push/pull, 看这里: https://docs.github.com/en/get-started/git-basics/about-remote-repositories#cloning-with-https-urls

3. 如果使用用户名 + 密码会出现下面的错误:

   git push origin master
   Username for 'https://github.com': int0x03
   Password for 'https://int0x03@github.com':
   remote: Support for password authentication was removed on August 13, 2021.
   remote: Please see https://docs.github.com/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
   fatal: Authentication failed for 'https://github.com/int0x03/samples.git/'

4. 所以要先添加 personal access token 然后把 token 做密码来访问. 具体路径是: github.com 右上角点头像, 进入 Settints -> Developer setttings -> Personal access tokens -> token classic 添加.
5. 添加完成, 选择生产 token, 这个token 可以设置终止日期的.
6. 可选把 token 放到 iTerm 的password 里面.

这篇是比较好的一篇文章: https://docs.chainlit.io/guides/sync-async

1. sync -> sync -> ok
2. sync -> async -> asyncio.run() | asyncio.get_event_loop().run_until_complete(async_func())
3. async -> sync -> ok | await asyncio.to_thread(sync_task)
4. async -> async -> await
5. Python 的 asyncio 库是标准库中用于编写异步 I/O 代码的核心框架，自 Python 3.4 引入后成为构建高性能网络应用和并发程序的重要工具. asyncio 是 Python 异步编程的基石，适合需要高效处理 I/O 并发的场景。通过事件循环和协程机制，开发者能以同步风格编写异步代码，显著提升程序性能.
6. Asyncer 是一个用于简化 Python 异步编程的第三方库，它通过更优雅的语法和高级功能让异步代码更易编写和维护. 相比标准库 asyncio，Asyncer 通过更高层次的抽象降低了异步编程门槛，适合需要快速开发高并发应用的场景.
7. Python 的 anyio 库是一个​​跨异步框架的统一接口库​​，旨在简化异步编程的复杂性，同时兼容主流异步模型（如 asyncio 和 trio）。

最近重新阅读 一书. 之前都是从前往后看, 这次选择从后往前看. 最后一章有一节专门讲 Java 获取随机数的相关类和这些类的对比和使用. 其实内容不仅仅局限于 Java, 而是从整个操作系统层面来看这个问题.

一边阅读, 一边查阅相关资料. 以我的理解它的进化大概有下面几个过程:

1. 最早想, 无非就是一个随机数吗, 于是就有了一个随机函数, 随机函数怎么增加随机性呢? 那就加一个种子, 种子的值不确定.
2. 接着发现代码别人是知道的, 所以随机函数就是公开的, 那么唯一的就剩下种子. 但是连续获得多个随机数后, 种子也是可猜测的. 需要找真正的随机数.
3. 于是发现机器本身能获得一些随机值. 比如: 移动鼠标的性质, 磁盘转动的性质, 网络的性质等. 但是获得这些需要时间, 有时候很慢, 就是要block 的.
4. 然后发现可以结合真随机值和伪随机数, 两者结合可以就可以做到别人猜测不到. 唯一的问题是有时候要等系统的真随机数还是需要点时间.
5. 于是就有了获得真随机数的后台持续运行的 deamon 线程, 它可以做到持续的获得, 等到用的时候, 随时给.
6. 到后来又进化到某些硬件支持.

具体到 Linux 操作系统上面, 就是 /dev/urandom 和 /dev/random 设备和 rngd 守护进程.

为了让理解这个进化更细致, 下面是 Deepseek 的联网回答. 结构很好, 也很有逻辑关系. 唯一的不足感觉就是有点浅.

Linux随机数生成机制的演化与优化历程

在Linux系统中，随机数生成机制经历了从简单伪随机算法到复杂熵源管理、硬件加速的漫长优化过程。这一过程的核心矛盾在于随机性质量与性能效率之间的平衡，同时需满足密码学安全的高标准要求。以下是其关键发展阶段及技术动因分析：

一、早期阶段：伪随机数生成器（PRNG）的局限性

技术背景

早期Linux系统依赖伪随机数生成算法（如线性同余法），其核心问题在于种子可预测性。若攻击者获取初始种子，即可推导出完整随机序列。例如，系统时间常被用作默认种子，但时间戳的有限精度（如秒级）导致种子空间狭小，易被暴力破解。

缺陷暴露

• 安全性不足：SSH、TLS等安全协议依赖随机数生成密钥，伪随机数的可预测性直接威胁加密强度。
• 确定性缺陷：相同种子生成相同序列，导致测试环境复现问题，但生产环境无法接受此类漏洞。

二、熵源驱动的随机数生成：从理论到实践

熵源的引入

Linux内核通过收集系统事件（如键盘敲击、磁盘I/O延迟、硬件中断）的物理随机性构建熵池（Entropy Pool）。例如：

• 鼠标移动：用户操作的时间戳和坐标变化具有不可预测性。
• 磁盘寻道时间：物理磁盘的机械延迟受环境因素影响，产生微小随机波动。
• 中断计时：硬件中断的到达时间间隔因电路噪声而呈现随机性。

熵池管理机制

• 熵值计量：内核通过熵估算算法（如Linux内核的rng-core模块）量化熵池的随机性强度，熵值越高，随机数质量越优。

• 阻塞与非阻塞模式：

  • /dev/random：严格依赖熵池，熵不足时阻塞，确保高安全性（如密钥生成）。
  • /dev/urandom：熵不足时切换为伪随机算法（如SHA-256），牺牲部分安全性以提升性能，适用于非安全敏感场景。

技术瓶颈

• 熵源竞争：多进程并发读取熵池时，可能导致熵值快速耗尽，引发阻塞问题。
• 启动阶段熵饥饿：系统冷启动时熵源未激活，早期加密操作可能面临低熵风险。

三、算法与架构的优化：从被动收集到主动预测

算法升级

• Yarrow算法：Linux内核早期采用Yarrow架构，结合熵池与密码学算法（如HMAC-SHA1）生成随机数，平衡安全性与性能。
• ChaCha20替代：为应对SHA-1碰撞攻击，Linux内核逐步迁移到ChaCha20算法，提升抗侧信道攻击能力。

熵池结构优化

内核将熵池细分为多个子池（如input_pool、blocking_pool），分别处理不同类型熵源，并通过动态权重分配优化熵混合效率。

硬件随机数生成器（TRNG）支持

现代CPU和主板集成硬件熵源（如Intel RDRAND指令、TPM芯片），Linux通过/dev/hwrng直接接入硬件随机数，显著提升生成速度与质量。

四、系统级抽象与守护进程的引入

统一接口：getrandom()系统调用

2014年Linux 3.17引入getrandom()，统一用户态接口：

• 自动选择最优熵源（优先硬件TRNG，其次熵池）。
• 阻塞行为可控：通过标志位选择是否等待熵池初始化完成。

守护进程优化

• rngd后台服务：持续监控熵池状态，通过混合熵源（如网络抖动、环境传感器数据）维持熵池活跃度，避免低熵场景。
• 自适应速率控制：根据熵池负载动态调整伪随机算法的调用频率，平衡性能与随机性质量。

五、现代挑战与前沿方向

量子计算威胁

传统随机数生成算法可能被量子计算机高效破解，Linux社区正探索抗量子算法（如基于格的随机数生成方案）。

容器化环境适配

容器共享宿主机熵池导致随机性竞争，解决方案包括：

• 容器内嵌轻量级熵源（如基于CPU时间戳抖动）。
• 增强宿主机熵源分发机制，通过cgroup隔离熵资源。

标准化与审计

Linux内核引入随机数生成器的形式化验证（如FIPS 140-2认证），并定期公开熵源统计报告，增强透明度和可信度。

总结：从“伪随机”到“真随机”的演进逻辑

Linux随机数生成机制的迭代本质上是安全性需求驱动下的工程妥协：

1. 早期：以性能优先的伪随机算法为主，牺牲部分安全性。
2. 中期：引入熵池和硬件熵源，构建混合生成模式。
3. 现代：通过算法优化、守护进程和硬件加速，实现安全与性能的动态平衡。

未来，随着量子计算和容器技术的普及，Linux随机数生成机制将更注重抗量子攻击、轻量化与跨平台兼容性。