wifit3芯片发现机制pkgutil遍历与VID:PID轻量导入的零注册表设计【免费下载链接】wifit3Wifite but USB-only cross-platform.项目地址: https://gitcode.com/GitHub_Trending/wi/wifit3wifit3 是一款纯 Python、跨平台的 USB 无线网卡审计工具其芯片发现机制用pkgutil.iter_modules一次遍历chips/目录只导入每个芯片包的轻量名片SUPPORTED_IDSimport_driver在内存中构建VID:PID → 驱动的索引表——全程不写注册表、不装系统驱动插卡即识别。为什么需要零注册表的芯片发现传统做法是让操作系统为网卡绑定内核驱动Linux 的 DKMS 模块、Windows 的 NDIS/WinUSB但 wifit3 的设计目标是内置无线协议栈绕开驱动版本地狱见 README.md 的 Why 章节。因此它必须自己回答一个问题现在总线上插着的 USB 设备是不是我支持的无线芯片如果是该用哪个驱动类答案藏在一个文件里manager.py。它的模块 docstring 一句话概括了整套设计The map is built by apkgutilwalk overchips/*that imports only each packages light__init__(SUPPORTED_IDS import_driver), never the driver itself. —— manager.py#L1-L7第一步pkgutil 遍历 chips/ 目录所有芯片驱动都放在src/wifit3/chips/下每个芯片一个子包如 chips/ar9271_v2/、chips/rtl8822bu_dkms/。核心函数supported_ids()用pkgutil枚举这些子包for mod_info in pkgutil.iter_modules(chips_pkg.__path__, chips_pkg.__name__ .): if not mod_info.ispkg: continue ... mod importlib.import_module(mod_info.name) for entry in getattr(mod, SUPPORTED_IDS, None) or (): mapping[(entry.vid, entry.pid)] Claim(entry, key, mod.import_driver)—— manager.py#L127-L152三个关键设计点pkgutil.iter_modules自动发现新增一个芯片包放进chips/遍历自动把它纳入索引无需修改任何中央清单文件。结果被functools.cache缓存整个 VID:PID 映射表只在进程内构建一次之后每次总线扫描都是 O(1) 字典查询。冲突即断言如果两个包声明了同一个 VID:PIDassert slot not in mapping会立刻让问题暴露而不是静默覆盖。第二步轻量导入——__init__.py只是名片每个芯片包的__init__.py刻意做得极轻只声明它认领的 VID:PID 目录SUPPORTED_IDS和一个import_driver()函数绝不导入真正的 driver.py。以 AR9271 为例ar9271_v2/init.py_IDS ( (0x0CF3, 0x9271, AR9271, None, AMBIGUOUS_AR9271), (0x0846, 0x9030, AR9271, None, Netgear.N150), ... ) SUPPORTED_IDS [DeviceID(vid, pid, chipset, vendor, product) for ...] def import_driver(): from .driver import AR9271V2Driver return AR9271V2Driver—— ar9271_v2/init.py#L9-L38这就是轻量导入的含义遍历 20 个芯片包时每个包只付出几行数据 一次DeviceIDdataclass 构造的成本。真正动辄数千行、内含固件加载与寄存器序列的driver.py直到某个设备实际匹配上才通过import_driver()被惰性导入driver.py#L79-L83 定义的from_usb_device契约即在此时兑现。VID:PID 索引表里装了什么索引的值是一个Claim三元组manager.py#L65-L69字段含义entryDeviceIDvid/pid/chipset/品牌/型号UI 展示用key驱动族 key如rtl8822bu用于定位 setup 流程import_driver惰性导入函数匹配命中时才执行品牌与型号的静态目录集中在 products.py 中按厂商分 Enum 组织如TPLink.ARCHER_T4U_PLUS共覆盖数十个品牌数百张零售网卡。完整的硬件支持矩阵见 SUPPORTED-HARDWARE.md。第三层两类撞号的仲裁真实世界里同一个 VID:PID 可能对应不同芯片wifit3 用两个仲裁表处理 DKMS 族同一芯片、两个驱动包如rtl8821au_dkms与rtl8821aumainline 移植都支持同一批 VID:PID。_DKMS_BY_DIRmanager.py#L100-L112为每族指定默认赢家可用环境变量如WIFIT3_RTL8821mainline切换遍历中落选包直接跳过。 共享 VID:PID不同芯片、同一编号最著名的是2357:0137——TP-Link Archer T4U 同一编号下有 MT7612U 与 RTL8822CU 两种方案。_VIDPID_FAMILIESmanager.py#L88-L117在扫描时读取设备的实际 USB 描述符端点0x85是否为 bulk-IN来现场裁决def _resolve_2357_0137(dev): for intf in dev.get_active_configuration(): if any(ep.bEndpointAddress 0x85 for ep in intf): return mt76x2u # bulk-IN 0x85 Mediatek return rtl8822cu总线扫描一次 O(1) 查表识别流程最终在devices()manager.py#L236-L256中闭环libusb 枚举总线上所有设备 → 用(idVendor, idProduct)直接查supported_ids()字典 → 命中即为受支持网卡。没有任何设备树解析、注册表读写或驱动安装动作——零注册表体现在整条链路里发现阶段只读__init__.py级数据Windows 上未绑定 WinUSB 的卡也能通过 PnP 枚举被预告出来manager.py#L259-L274由 setup 层事后安装 WinUSB还有一条平行的zerocd_ids()遍历manager.py#L155-L169收集伪装成 U 盘的 ZeroCD 网卡编号供弹射手处理。打包也能自检supported_ids() 非空检查因为依赖动态pkgutil遍历PyInstaller 打出的单文件包必须把chips/下所有子包收集进去否则应用能启动却看不到任何网卡。wifit3 在main.py#L36-L40 内置了打包自检supported_ids()is non-empty: the pkgutil chip-discovery walk only enumerates drivers PyInstaller actually collected, so an empty map means the bundle shipped with no drivers.即启动自检会主动调用一次芯片发现映射表为空则判定打包损坏——发现机制的注册表就是 Python 包结构本身连自检都无需额外清单。一图总览三层轻量设计层次机制成本目录发现pkgutil.iter_modules遍历chips/*仅一次带functools.cache名录读取每包只导入轻量__init__SUPPORTED_IDS几行数据 dataclass 构造驱动加载import_driver()惰性导入driver.py仅匹配命中时延伸阅读设备层核心manager.py驱动契约chips/driver.py设备标识模型models/device_id.py硬件支持矩阵docs/SUPPORTED-HARDWARE.md移植新芯片的方法论docs/porting/METHODOLOGY.md一句话总结wifit3 把驱动注册从操作系统层面搬进了 Python 包结构层面——pkgutil负责发现__init__.py负责名录import_driver()负责按需加载三者合力实现了零注册表、零配置、插卡即识别的芯片发现机制。【免费下载链接】wifit3Wifite but USB-only cross-platform.项目地址: https://gitcode.com/GitHub_Trending/wi/wifit3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考