尧图网页设计 
wifit3芯片发现机制源码走读SUPPORTED_IDS为何不能导入driver【免费下载链接】wifit3Wifite but USB-only cross-platform.项目地址: https://gitcode.com/GitHub_Trending/wi/wifit3wifit3 是一个仅通过 USB、跨平台的 802.11 无线审计工具可理解为 Wifite, but USB-only cross-platform。它不依赖系统无线驱动而是用自己的 Python 芯片驱动直接对话 USB 无线网卡完成 AP 扫描、握手/PMKID 捕获、WPS 攻击等 802.11 审计工作。而这一切的起点是芯片发现机制当你把一张 USB 无线网卡插进电脑wifit3 如何知道这张卡我认识、该用哪个驱动答案就藏在每个芯片包的SUPPORTED_IDS里。本文带你走读这套机制并回答一个源码里的关键设计问题为什么芯片包的__init__.py只声明SUPPORTED_IDS却绝不能直接import driver芯片发现是怎么跑起来的一次 pkgutil 遍历wifit3 支持 20 多个芯片目录Realtek、Ralink、Mediatek、Atheros……但它没有中央注册表。发现流程完全靠 device/manager.py 中的supported_ids()函数完成核心逻辑只有三件事用pkgutil.iter_modules遍历 src/wifit3/chips/ 下的每个子包芯片目录只导入每个包的轻量__init__.py读出它的SUPPORTED_IDS列表把所有(vid, pid)→ 芯片包的映射缓存成一张Claim字典。之后每次扫描 USB 总线devices()拿在位设备的 VID:PID 去这张字典里查一下命中即表示认识这张卡。SUPPORTED_IDS 里装的是什么一份 VID:PID 硬件目录SUPPORTED_IDS是一个DeviceID数据类列表定义见 models/device_id.py每项对应一个 USB 厂商 ID:产品 ID 组合附带芯片型号、品牌、产品名等人类可读信息。以 chips/mt76x0u/__init__.py 为例整个文件只有 14 行SUPPORTED_IDS从constants.py的 VID:PID 表构建出的目录条目import_driver()一个延迟导入函数被调用时才from .driver import MT76x0UDriver。注意一个容易踩坑的细节docs/porting/METHODOLOGY.md 和 AGENTS.md 都专门强调过SUPPORTED_IDS住在__init__.py里而不是驱动类上驱动类自己只声明SUPPORTED_CHANNELS见 chips/driver.py。目录是身份牌能力是驱动的事两者刻意分开。核心问题为什么不能直接 import driver这是整套架构最精妙的一处。__init__.py里如果写from .driver import MT76x0UDriver看似方便实则会带来三个问题1️⃣ 启动速度20 个驱动一次性全加载driver.py及其依赖链transport、firmware、rx/tx、constants……才是真正的重模块。发现阶段要遍历所有芯片包若每个包的__init__.py都顺手把 driver 导进来wifit3 启动时就要把 20 多个完整驱动的整个依赖图全部装入内存——而实际上用户可能只插了其中一张卡。只读轻量的__init__.py让设备发现几乎零成本完成。2️⃣ 故障隔离一个坏包不拖垮全家supported_ids()遍历时会逐个importlib.import_module。如果某个芯片的驱动代码有导入错误缺依赖、语法问题直接导入 driver 会让整个发现字典构建失败所有芯片都不可用而轻量__init__.py只依赖DeviceID和一个元组表几乎不可能出问题。3️⃣ 懒加载命中才加载加载只一次只有当 USB 总线上真的出现匹配的 VID:PIDdriver_for() 才会调用claim.import_driver()触发那次重导入且整个进程只导一次supported_ids()上有functools.cache。目录常驻驱动按需——这正是import_driver()这个函数存在的意义。进阶一个 VID:PID 撞上两个驱动怎么办现实中确实会撞。manager.py 里有两套仲裁机制DKMS 家族_DKMS_BY_DIR比如 RTL8821AU 同时存在 mainlinertl8821au和 DKMSrtl8821au_dkms两个包都认领0bda:0811。环境变量如WIFIT3_RTL8821mainline决定谁胜出落败的包在遍历时被整体跳过rtl8821au_dkms/__init__.py 的文档字符串明确说明了这一点。VID:PID 家族_VIDPID_FAMILIES同一个 VID:PID 背后可能是不同的芯片如2357:0137既可能是 MT76x2U 也可能是 RTL8822CU此时靠读取设备描述符的端点特征bulk-IN 0x85 Mediatek现场裁决。如果未来出现两个包认领同一 VID:PID 却没有任何家族定义遍历处的assert会直接炸出来提醒你补规则——设计上是防呆的。新手实践给 wifit3 添加新芯片只需两步理解了上面的机制添加新芯片就非常简单完整流程见 docs/porting/METHODOLOGY.md新建src/wifit3/chips/name/在__init__.py声明SUPPORTED_IDSimport_driver()顶部不要导入 driver.py实现driver.py继承 Driver 抽象类声明SUPPORTED_CHANNELS等。没有第三部——没有中央注册表要编辑pkgutil 遍历会自动发现你的新包。支持硬件清单可参考 docs/SUPPORTED-HARDWARE.md。小结机制作用SUPPORTED_IDS在__init__.py轻量硬件目录VID:PID → 芯片包import_driver()懒加载入口命中才触发重导入supported_ids()functools.cachepkgutil 遍历 进程级缓存DKMS / VID:PID 家族同名撞车仲裁环境变量或端点特征裁决一句话记忆SUPPORTED_IDS是身份证目录driver 是重型武器——目录必须永远读得起武器只在开火时才加载。这也是 wifit3 能在 Windows / macOS / Linux 上快速完成设备发现的底层原因。延伸阅读chips/mt76x0u/MT76X0U.md 等每个芯片目录都配有移植参考文档是深入各驱动细节的最佳入口。【免费下载链接】wifit3Wifite but USB-only cross-platform.项目地址: https://gitcode.com/GitHub_Trending/wi/wifit3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 wifit3芯片发现机制源码走读：SUPPORTED_IDS为何不能导入driver
wifit3芯片发现机制源码走读SUPPORTED_IDS为何不能导入driver【免费下载链接】wifit3Wifite but USB-only cross-platform.项目地址: https://gitcode.com/GitHub_Trending/wi/wifit3wifit3 是一个仅通过 USB、跨平台的 802.11 无线审计工具可理解为 Wifite, but USB-only cross-platform。它不依赖系统无线驱动而是用自己的 Python 芯片驱动直接对话 USB 无线网卡完成 AP 扫描、握手/PMKID 捕获、WPS 攻击等 802.11 审计工作。而这一切的起点是芯片发现机制当你把一张 USB 无线网卡插进电脑wifit3 如何知道这张卡我认识、该用哪个驱动答案就藏在每个芯片包的SUPPORTED_IDS里。本文带你走读这套机制并回答一个源码里的关键设计问题为什么芯片包的__init__.py只声明SUPPORTED_IDS却绝不能直接import driver芯片发现是怎么跑起来的一次 pkgutil 遍历wifit3 支持 20 多个芯片目录Realtek、Ralink、Mediatek、Atheros……但它没有中央注册表。发现流程完全靠 device/manager.py 中的supported_ids()函数完成核心逻辑只有三件事用pkgutil.iter_modules遍历 src/wifit3/chips/ 下的每个子包芯片目录只导入每个包的轻量__init__.py读出它的SUPPORTED_IDS列表把所有(vid, pid)→ 芯片包的映射缓存成一张Claim字典。之后每次扫描 USB 总线devices()拿在位设备的 VID:PID 去这张字典里查一下命中即表示认识这张卡。SUPPORTED_IDS 里装的是什么一份 VID:PID 硬件目录SUPPORTED_IDS是一个DeviceID数据类列表定义见 models/device_id.py每项对应一个 USB 厂商 ID:产品 ID 组合附带芯片型号、品牌、产品名等人类可读信息。以 chips/mt76x0u/__init__.py 为例整个文件只有 14 行SUPPORTED_IDS从constants.py的 VID:PID 表构建出的目录条目import_driver()一个延迟导入函数被调用时才from .driver import MT76x0UDriver。注意一个容易踩坑的细节docs/porting/METHODOLOGY.md 和 AGENTS.md 都专门强调过SUPPORTED_IDS住在__init__.py里而不是驱动类上驱动类自己只声明SUPPORTED_CHANNELS见 chips/driver.py。目录是身份牌能力是驱动的事两者刻意分开。核心问题为什么不能直接 import driver这是整套架构最精妙的一处。__init__.py里如果写from .driver import MT76x0UDriver看似方便实则会带来三个问题1️⃣ 启动速度20 个驱动一次性全加载driver.py及其依赖链transport、firmware、rx/tx、constants……才是真正的重模块。发现阶段要遍历所有芯片包若每个包的__init__.py都顺手把 driver 导进来wifit3 启动时就要把 20 多个完整驱动的整个依赖图全部装入内存——而实际上用户可能只插了其中一张卡。只读轻量的__init__.py让设备发现几乎零成本完成。2️⃣ 故障隔离一个坏包不拖垮全家supported_ids()遍历时会逐个importlib.import_module。如果某个芯片的驱动代码有导入错误缺依赖、语法问题直接导入 driver 会让整个发现字典构建失败所有芯片都不可用而轻量__init__.py只依赖DeviceID和一个元组表几乎不可能出问题。3️⃣ 懒加载命中才加载加载只一次只有当 USB 总线上真的出现匹配的 VID:PIDdriver_for() 才会调用claim.import_driver()触发那次重导入且整个进程只导一次supported_ids()上有functools.cache。目录常驻驱动按需——这正是import_driver()这个函数存在的意义。进阶一个 VID:PID 撞上两个驱动怎么办现实中确实会撞。manager.py 里有两套仲裁机制DKMS 家族_DKMS_BY_DIR比如 RTL8821AU 同时存在 mainlinertl8821au和 DKMSrtl8821au_dkms两个包都认领0bda:0811。环境变量如WIFIT3_RTL8821mainline决定谁胜出落败的包在遍历时被整体跳过rtl8821au_dkms/__init__.py 的文档字符串明确说明了这一点。VID:PID 家族_VIDPID_FAMILIES同一个 VID:PID 背后可能是不同的芯片如2357:0137既可能是 MT76x2U 也可能是 RTL8822CU此时靠读取设备描述符的端点特征bulk-IN 0x85 Mediatek现场裁决。如果未来出现两个包认领同一 VID:PID 却没有任何家族定义遍历处的assert会直接炸出来提醒你补规则——设计上是防呆的。新手实践给 wifit3 添加新芯片只需两步理解了上面的机制添加新芯片就非常简单完整流程见 docs/porting/METHODOLOGY.md新建src/wifit3/chips/name/在__init__.py声明SUPPORTED_IDSimport_driver()顶部不要导入 driver.py实现driver.py继承 Driver 抽象类声明SUPPORTED_CHANNELS等。没有第三部——没有中央注册表要编辑pkgutil 遍历会自动发现你的新包。支持硬件清单可参考 docs/SUPPORTED-HARDWARE.md。小结机制作用SUPPORTED_IDS在__init__.py轻量硬件目录VID:PID → 芯片包import_driver()懒加载入口命中才触发重导入supported_ids()functools.cachepkgutil 遍历 进程级缓存DKMS / VID:PID 家族同名撞车仲裁环境变量或端点特征裁决一句话记忆SUPPORTED_IDS是身份证目录driver 是重型武器——目录必须永远读得起武器只在开火时才加载。这也是 wifit3 能在 Windows / macOS / Linux 上快速完成设备发现的底层原因。延伸阅读chips/mt76x0u/MT76X0U.md 等每个芯片目录都配有移植参考文档是深入各驱动细节的最佳入口。【免费下载链接】wifit3Wifite but USB-only cross-platform.项目地址: https://gitcode.com/GitHub_Trending/wi/wifit3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考