无线与路由技术动态 2026-03-24
本期摘要Linux 7.0-rc5 发布,内核进入稳定收尾期;FCC 将外国消费级路由器列入禁止授权清单,引发路由器行业重大政策震荡;Open RAN 能耗研究与 MWC 2026 Wi-Fi 路线图共同勾勒出下一代无线网络的演进方向。
Linux 动态Linux 7.0-rc5 发布Linus Torvalds 发布了 7.0-rc5 预发布版本,本轮 RC 补丁量较前几个版本有所收窄,但相比历史同期 rc5 仍偏大。Linus 表示”情况开始平稳下来”,主线合并窗口后的修复工作正逐步走向尾声,正式版发布可期。
🔗 原文
BPF 程序睡眠上下文追踪新方案开发者 Puranjay Mohan 提交补丁集,拟允许 BPF 程序在可睡眠上下文中临时获取锁,同时进入原子(atomic)上下文。当前内核严格禁止可睡眠 BPF 程序进入原子区;此补丁若合入,将大幅拓宽 BPF 在内核中的应用边界,也对 eBPF 网络程序的设计产生影响。
🔗 原文
稳定版内核 6.19.9 与 6.18.19 发布Greg Kroah-Hartman 同步发布两个稳定分支更新,包含树内多处重要修复。两 ...
WPS EasyMesh组网 & 一键桥接自适应
背景在无线组网场景下,STA(客户端/下级节点)需要通过 WPS 完成入网,并自动判断上级 AP 是否支持 EasyMesh。若支持,则走 Multi-AP 组网流程成为 Mesh Agent;若不支持,则降级为普通桥接模式。本文基于一份真实的 pcapng 抓包,完整分析 WPS 握手过程、EasyMesh 探测机制。
一、WPS M1–M8 完整握手流程WPS 握手分两个阶段:M1–M4 完成密钥协商与身份验证,M5–M8 完成凭证传递。
消息字段详解
消息
方向
关键字段
M1
STA → AP
Version, UUID-E, MAC, EnrolleeNonce, Public Key (DH), Auth Type Flags, Encr Type Flags, Multi-AP Extension (0x1048, 若支持 EasyMesh)
M2
AP → STA
RegistrarNonce, Public Key (DH), EncrSettings, Multi-AP Extension (回应 EasyMesh, 若支持)
M3
S ...
使用 Hexo + GitHub Pages 搭建个人博客
简介本博客基于 Hexo 搭建,使用 Butterfly 主题,部署在 GitHub Pages 上。Hexo 是一款快速、简洁且高效的静态博客框架,使用 Markdown 写作,一键生成静态页面,非常适合技术博客。
本文记录从零搭建到日常使用的完整流程。
环境准备依赖
Node.js >= 18
Git
安装 Hexo CLI12345# 全局安装(需要权限)sudo npm install -g hexo-cli# 验证hexo --version
初始化博客123hexo init my-blogcd my-blognpm install
目录结构如下:
12345678my-blog/├── _config.yml # 站点主配置├── package.json├── scaffolds/ # 文章模板├── source/│ └── _posts/ # 博客文章├── themes/ # 主题└── public/ # 生成的静态文件(自动生成)
安装 B ...
RTOS上移植mqtt broker(mosquitto)
mqtt broker简介和选型MQTT Broker(mqtt代理服务器),负责管理和转发消息,关于细节不在赘述。关于broker选型,需要考虑使用场景、性能、易用性和支撑的特性等。
目前主流的mqtt broker有mosquitto、EMQX、HiveMQ、VerneMQ、Amazon AWS IoT Core等,由于需要跑在RTOS上,只需要简单转发消息即可,故选择mosquitto。
移植过程中需要考虑的问题
问题1,根据使用场景,优先裁剪config文件
问题2,仅保留mosquitto原文件和调用lib文件,删除多余app、test等文件
问题3,解决类型匹配,RTOS中头文件类型可能有冲突
问题3,由于mosquitto只支持用epoll和poll机制,而ECOS只支持select,故使用select分装poll函数
问题4,mosquitto是配置文件的方式传入配置信息,考虑配置文件加载
问题6,mosquitto中存在信号机制,考虑相关RTOS是否支持信号
移植梳理每个目录,修改删除不必要的文件,如:test、doc、docker等目录。顶层Make只需要编译sr ...
驱动学习-环境搭建
背景工作中经常遇到驱动相关问题,之前对驱动开发也是现学现买。准备系统接触linux驱动驱动和kernel,刚开始主要熟悉linxu驱动框架,不涉及相关硬件(后续可能回学习ARM或RISC-V)。打算在自己的主机上编译kernel模块,直接调试加载。
环境
ununtu 24.04
kernel版本
12$ uname -r6.8.0-31-generic
源码和分析第一个简单的驱动以hello.c命令,代码中只有module init和module exit.
1234567891011121314151617181920#include <linux/module.h>#include <linux/cdev.h>int hello_init(void){ printk("hello world! init.\n"); return 0;}void hello_exit(void){ printk("hello world! exit.\n"); return;& ...
netif_receive_skb简介
netif_receive_skb简介netif_receive_skb作用:
把接收帧传给每个协议分流器
把接收帧传给skb->protocol所关联的L3协议处理函数。
负责L2必须的功能处理
如果某接收帧数据没有关联skb->protocol,而且L2没有处理该帧,kernel不知道如何处理该帧数据,会将起丢弃。
skb->protocol:一般由驱动接收程序赋值,从L2层设备驱动程序的角度看,就是用在下一个较高层的协议。如:IP、IPv6以及ARP等;值在include/linux/if_ether.h中。由于每种协议都有对应的处理函数,因此驱动程序使用该字段告诉上层程序对应协议。
netif_receive_skb() 是主要的接收数据处理函数。它总是成功。 缓冲区可能会在拥塞控制处理期间或被协议层丢弃。此函数只能从软中断上下文调用,并且应启用中断。
如果桥接代码或者入口流量控制没有处理该帧数据,则该帧会传给L3协议处理函数(通常每种协议只有一个处理函数,但是也可以注册多个)。
至此,接收部分已经完成。
L3对封包的处理:
传递 ...
ecos内存分布
简介站在内存管理的角度看eCos操作系统,就是一个进程。eCos系统中只有线程概念(任务),并没有进程概念。整个内存规划简单看就是一个进程的内存分布。
既然一个进程,内存中会有text、data、bss、heap段等。
💡 eCos线程的栈就是一块buf(内存),可以是全局buf,也可以从heap上申请。
eCos查看内存1234567891011121314151617181920212223 mbuf twork stack mbuf stats: mbufs 69, clusters 2360, free clusters 56 Failed to get 0 times Waited to get 0 times Drained queues to get 0 timesVM zone 'ripcb': Total: 32, Free: 31, Allocs: 88, Frees: 87, Fails: 0VM zone 'divcb': Total: 2, Free: 2, Allocs: 0, Free ...
一次处理四川移动IPTV问题总结
背景国内三大运营商宽带布局普遍使用光猫+路由器的方式(FTTR虽然运营商在主推,目前并不普及)。光猫无线能力较弱或者不支持无线,路由器将承载用户主要上网需求。但是普通家庭网线只布置一条(光猫放弱点箱,路由器在电视柜),上网和IPTV同时支持需要光猫配置单线复用。
一条网线同时支持上网和IPTV业务,国内通常上网业务不带vlan tag,IPTV业务带vlan tag。此时路由器可以通过vlan tag区分业务流,将IPTV业务转发到路由器IPTV口。目前运营商送的路由器都支持该功能,国内主流厂商家用路由器也支持该功能。
拓扑
问题描述电视盒子播放电视过程中,概率出现PC有线接入LAN1/LAN2后IPTV停止播放,
问题分析
PC连接网线后会主动发送IGMP加组报文,路由器接收到后,会通过WAN口请求加组,该加组报文由于是LAN1或LAN2输入,并不会携带tag。
光猫收到没有带tag的IGMP报文,会导致原有的IPTV组播流从带tag下发变成不带tag下发。(问题根源)
路由器由以前带tag报文通过vlan tag来识别IPTV业务流,此时,路由器并没有对应的组播路由来转发 ...
