Linux

树莓派通过 USB 连接便携式 Wi-Fi 时的网络行为分析

一、问题背景 某台树莓派通过 USB 连接了一台便携式网络设备。该设备支持通过 USB 向树莓派暴露一个共享网络接口，但在未插入可用 SIM 卡时，本身并不具备实际的外网接入能力。与此同时，树莓派还通过自身的无线网卡连接家庭无线网络实现上网。 因此，系统中出现了这样一种结构： 这类结构的关键问题在于：系统如何识别这些网络接口，它们何时会变成 UP，何时会保持 DOWN，以及后续是否可以把 USB 连接作为备用链路使用。 二、当前网络接口状态的含义 通过 ip a 查看系统网络接口时，可以看到几类典型状态： 1. 回环接口 回环接口用于本机内部通信，通常始终处于可用状态。 2. 有线网口 物理有线网口即使被系统启用，只要没有插入网线，也会出现如下特征： 这说明：网口本身存在，但底层链路没有建立。 3. 无线网卡 当无线网卡已经成功连接到无线接入点并获得地址后，通常会看到： 这说明： 4. USB 暴露出的虚拟网卡 便携式网络设备通过 USB 共享网络时，Linux 会将其识别为一个额外网卡，通常接口名类似于 enx…。在未形成有效共享链路时，可能会看到： 这表示： 三、为什么 USB 接口当前是 DOWN USB 暴露出的网络接口之所以存在，是因为系统已经识别到该设备支持网络共享模式。但接口是否真正可用，不取决于“是否插着 USB 线”这一点，而取决于更完整的条件链。 典型条件包括： 如果上述条件不完整，即使接口名已经出现，该接口仍可能保持 DOWN。 …

Linux

Ubuntu Server 下的树莓派双网卡接入实践：有线保底，Wi-Fi 按需启用

一、需求背景 在一台运行 Ubuntu Server 的树莓派上，已经存在稳定可用的有线网络连接。与此同时，还希望接入无线网络，以满足以下需求： 这一需求本质上不是“桌面式自动联网”，而是“服务器式可控联网”。 二、系统现状判断 首先需要确认系统中可用的网络工具，以及当前的网络管理方式。检查结果显示： 这说明该环境属于典型的 Ubuntu Server 风格： 因此，后续方案不采用 NetworkManager，不依赖图形界面，而是基于以下工具链完成： 三、总体策略 本次实践最终形成了如下结构： 1. 有线网络长期保留 有线接口始终保持可用，作为系统的远程管理保底入口。 这样做的意义很大： 2. 无线网络按需启用 无线不作为系统的开机自动连接项，而是在需要时手动触发： 3. 当双接口同时在线时，设为 Wi-Fi 优先 这是通过调整默认路由 metric 实现的： 最终实现的逻辑是： 有线常驻保底，Wi-Fi 按需启用；启用后 Wi-Fi 优先，有线备用。 四、工具安装与基础验证 为了支持命令行下的无线操作，需要安装以下工具： 安装完成后，需要验证几个关键点： 实际验证结果表明： 这说明系统层面已经具备无线接入能力。 五、扫描附近 Wi-Fi 在命令行环境下，第一步是先拉起无线接口，然后扫描附近无线网络。 扫描结果中能够看到多个 SSID，说明： 值得注意的是，扫描结果中个别中文 SSID 可能以转义形式显示。这并不意味着扫描失败，只是终端编码显示方式不同。 六、为什么不直接修改系统主配置 在服务器环境中，最常见的做法之一，是直接将 …

Linux

一次 Linux LVM 根卷组重命名后的启动链路修复记录

背景 某台 Linux 主机使用 LVM 管理根分区，系统原本可以正常启动。后续为了统一命名规范，对卷组名称进行了重命名。重命名本身成功，LVM 层状态正常，但随后出现了两个典型问题： 这类问题的本质并不在于 LVM 重命名失败，而在于启动链路中的历史引用没有被同步更新。也就是说，LVM 元数据已经变了，但 GRUB、内核命令行、initramfs、fstab 等位置仍然残留旧名字。 本文记录一次完整的排查与修复过程，并总结出一套可复用的方法。 现象 在卷组重命名之后，LVM 状态看起来已经正常，例如： 但是执行以下命令时会出错： update-initramfs -u -k all 报错类似： cryptsetup: ERROR: Couldn’t resolve device /dev/mapper/旧卷组-rootcryptsetup: WARNING: Couldn’t determine root device 继续执行： update-grub 又会报错： /usr/sbin/grub-probe: error: failed to get canonical path of `/dev/mapper/旧卷组-root’. 这说明系统运行态已经基于新逻辑卷工作，但启动配置里仍然有旧名字残留。 问题本质 LVM 的卷组名变更，只会修改 …

Linux

Linux lo 回环接口与互联网第一条消息 “LO” 的关系

在学习 Linux 网络结构时，几乎每个人都会看到一个特殊的网络接口： lo 它通常对应地址： 127.0.0.1localhost 与此同时，在互联网历史中也存在一个非常著名的记录：1969 年互联网（ARPANET）发送的第一条消息是 “LO”。 由于两者在字母上完全相同，很多人会产生一个疑问： Linux 中的 lo 接口，是否与互联网历史上的 “LO” 有关联？ 结论是： 两者没有任何历史或技术上的关系，仅仅是字母上的巧合。 本文对这两个概念进行简单说明。 一、Linux 中的 lo 接口 在 Linux 网络系统中： lo = loopback interface 即 回环网络接口。 回环接口的作用，是让一台计算机能够在 不经过任何物理网络设备 的情况下，与自身进行网络通信。 常见地址： 127.0.0.1 或主机名： localhost 可以使用以下命令测试： ping 127.0.0.1 数据包不会离开计算机，而是在 操作系统内核的网络协议栈内部循环处理。 回环接口的特点 lo 接口具有几个重要特点： 1 永远存在 无论系统是否连接网络，lo …

Linux

Ubuntu 24.04（ARM / R2S）APT 换源实录：从 ports.ubuntu.com 切换到国内 ubuntu-ports，并关闭 proposed

适用对象：ARM64 设备（如 R2S / 树莓派等）上运行 Ubuntu 24.04（noble），APT 默认指向 ports.ubuntu.com，更新速度慢或链路不稳定。目标：保持“官方仓库内容等价”的前提下，切换到国内镜像加速，并移除不适合生产环境的 -proposed 测试仓库。 1. 背景现象：APT 命中 ports.ubuntu.com 在 ARM64 Ubuntu 上执行 apt update，常见输出类似： 其中 ports.ubuntu.com 是 Ubuntu 官方用于 非 x86 架构（ARM 等） 的主仓库入口。它是“源站”，内容权威，但在亚洲链路上经常出现吞吐偏低的问题。 2. 关键点：ARM 的“国内镜像”必须是 ubuntu-ports 镜像 很多人换源失败，是因为误用只同步 x86 的镜像路径（如普通 ubuntu/），而 ARM 设备应使用 ubuntu-ports。 镜像等价关系如下： 3. 配置现状确认：使用传统 sources.list（而非 ubuntu.sources） Ubuntu 24.04 …

Linux

Linux（R2S/ARM小主机）流量统计与实时监控：vnStat + bmon/nload/iftop 全流程与排障记录

目标：在一台 ARM 小主机（双网口场景常见，如 R2S 一类）上，完成1）长期累计流量统计（按天/月/年）2）终端实时图形化监控（看瞬时带宽、看谁在跑流量）并解决“vnstat 显示 No data/查不到数据”的典型问题。 1. 为什么需要两类工具：累计统计 vs 实时观察 网络监控分两类，作用不同： 1.1 长期累计（趋势、账单、限额） 选型：vnStat优点：轻量、低开销、重启不丢（数据库在本机保存）。 1.2 实时观察（当前状态、排障、抓异常） 选型：bmon / nload / iftop其中： 2. 基础概念：RX / TX 是什么 所有工具里都绕不开： 在转发型节点（隧道/代理）里，经常出现一个明显特征： RX ≈ TX（接收多少就转发多少） 而在普通客户端（浏览网页、下载）上更常见： RX >>> TX 3. 长期累计：vnStat 的正确用法与常见误解 3.1 vnStat 的工作机制（决定了“能不能看历史”） vnStat 不会回溯系统历史流量。它的机制是： 因此： 这也是很多人第一次用 vnStat 时最容易误解的点：看到 “since …

Linux

NanoPi R2S 远程节点 SD 卡灾备方案设计与实践（可启动热备 + 异地配置备份）

摘要 本文记录一次远程边缘节点的灾备体系设计过程。 目标环境为长期运行的 ARM 小型网络节点，其物理设备位于异地，日常仅通过 SSH 远程维护。系统运行在 SD 卡上，一旦存储介质损坏，将导致节点完全离线，因此需要构建一种： 的 SD 卡灾备方案。 本文最终采用： 首次整盘克隆（dd） + 后续文件级同步（rsync） + 异地配置备份 的分层灾备结构。 一、问题背景 边缘节点通常具有以下特点： 一旦 SD 卡损坏，将出现： 因此核心问题变为： 是否可以提前制作一张备用 SD 卡，使其在原卡损坏后直接替换启动？ 二、系统结构特点（R2S 与树莓派的差异） 许多 Raspberry Pi 迁移方案基于如下结构： 系统仅依赖单一 root 分区，因此可以通过 rsync 复制后修改 UUID 启动。 但 NanoPi R2S 采用 Rockchip 启动结构： 关键差异： 因此： 仅复制文件 …

Linux

Arch Linux 系统升级失败：PGP Signature Marginal Trust 问题完整排查记录

一、问题背景 在一次常规的 Arch Linux 系统升级过程中，执行： 升级流程在 checking package integrity 阶段全部通过，但随后出现大量错误： 最终导致： 系统无法完成升级。 值得注意的是： 表面看似软件包损坏，实际上问题完全不同。 二、错误本质 核心关键词： 这并不表示软件包损坏，而是： Pacman 无法确认签名者在本机 PGP 信任链中具备足够信任等级。 Arch Linux 的软件包安全机制依赖： 升级流程为： 当本机 keyring 状态异常时，即使： ✅ 包真实✅ 签名正确✅ 来源官方 Pacman 仍会拒绝安装。 因此出现： 实际上是 信任验证失败。 三、常见触发原因 实践中主要有以下几类原因： 1️⃣ archlinux-keyring 过旧（最常见） 长期未升级系统时： 导致签名无法建立信任路径。 2️⃣ 本地 pacman-key 数据损坏 可能来源： 3️⃣ …

Linux

跨地域服务器间 V2Ray 文件迁移实践：SCP 与 Rsync 的行为分析与优化记录

一、背景 在一次跨地域服务器迁移过程中，需要将既有系统中的 V2Ray 运行文件迁移至一台新设备。迁移对象主要包括以下内容： 日志文件不参与迁移，因为目标系统会自动重新生成。 迁移环境具有如下特征： 因此，本次迁移的核心问题并非“如何复制文件”，而是： 如何在跨境高延迟网络下稳定、高效、可恢复地完成文件同步。 二、初始方案：SFTP / SCP 拉取 最初采用的方式为： 该模式存在两个问题： 数据路径实际变为： 这种结构会导致： 实际测速仅达到几十 KB/s。 三、方向调整：改为 Push 模式 随后调整为： 即： 跨地域网络中，一个经验规律是： 让网络质量更好的节点主动发送数据。 方向切换后，传输速率立即提升。 四、引入 Rsync 相比 SCP，Rsync 具备以下关键优势： 1. 差异同步（Delta Transfer） Rsync 不会无条件复制文件，而是： 即使文件体积较大，只要修改较少，传输量也会显著降低。 2. 断点续传能力 跨境链路中断十分常见。 默认 SCP： 而 Rsync 可通过参数实现安全续传。 五、最终使用命令 迁移采用如下形式： 参数说明： 参数 作用 …

Linux

Linux 环境下 FRP 客户端（frpc）长期稳定运行的 systemd 配置实践

一、问题背景 在基于 FRP 的远程连接或内网穿透架构中，客户端通常以 systemd 服务方式长期运行，以确保设备重启后能够自动恢复连接。 在实际部署过程中，经常出现以下现象： 这些问题多数并非 FRP 本身造成，而是 systemd 启动顺序与网络就绪状态之间的不匹配。 二、常见错误配置 部分配置中会出现类似写法： 该参数来源于容器编排系统，并 不属于 systemd 支持的语法。 结果是： 因此必须使用 systemd 原生参数。 三、核心稳定原则 长期运行类网络服务需要满足三个条件： systemd 中对应的关键机制为： 它表示： 四、推荐的标准 systemd 服务模板（脱敏） 以下为经过泛化处理后的通用配置示例： 说明： 项目 含义 Description 服务描述（任意名称） WorkingDirectory 程序工作目录 ExecStart 客户端启动命令 Restart=always 退出后自动重启 RestartSec 重启等待时间 network-online.target 等待网络就绪 五、为什么必须等待 network-online 典型系统启动流程如下： 此时服务会直接退出。 …