Wi-Fi Direct 源码分析（14）：控制面进入 Linux 内核后发生了什么——nl80211、cfg80211、mac80211 与管理帧 TX/RX-北京尧图网络

Wi-Fi Direct 源码分析14控制面进入 Linux 内核后发生了什么——nl80211、cfg80211、mac80211 与管理帧 TX/RX摘要从 P2P Listen 与 Action Frame 两条真实路径追到 Linux Wireless 内核和 mac80211_hwsim补齐 Wi-Fi Direct 控制面进入驱动后的 TX/RX 闭环。文章目录Wi-Fi Direct 源码分析14控制面进入 Linux 内核后发生了什么——nl80211、cfg80211、mac80211 与管理帧 TX/RX1. 先分清四层nl80211、cfg80211、mac80211、mac80211_hwsim 不是同一层2. P2P Listen 的真实 userspace 入口wpas_start_listen() 不是直接调用 driver3. wpa_drv_remain_on_channel()wpa_supplicant 在这里才通过 driver ops 跨到 nl80211 backend4. 进入 kernelnl80211_remain_on_channel() 做的是校验与分发5. cfg80211 到 mac80211SoftMAC 路径由 ieee80211_remain_on_channel() 接手6. mac80211_hwsim_roc()虚拟 radio 怎样模拟“真的到了这个信道”7. ROC 为什么还要从 kernel 再返回 userspace8. 第二条路径P2P Action Frame 最终不是 P2P Core 自己“发到空气中”9. driver_nl80211把 P2P payload 包成真正的 802.11 Action Frame10. NL80211_CMD_FRAME 在 kernel 中怎样继续到 mac8021111. 到 mac80211_hwsim 后TX/RX 是怎样被“模拟出来”的12. 对端收到 Action Frame 后为什么又能回到 wpa_supplicant13. TX Status 如何从 hwsim 回到 GO Negotiation 状态机14. 把第 0214 篇连起来Wi-Fi Direct 控制面终于不再有“kernel 黑盒”关键源码索引资料来源[S1] hostap / wpa_supplicant 2.12P2P Listen、Action TX 与 nl80211 backend[S2] Linux master snapshotnl80211 userspace/kernel ABI[S3] Linux master snapshotmac80211 off-channel、Management TX/RX 与 TX pipeline[S4] Linux master snapshotmac80211_hwsim 虚拟 radio[S5] Linux Kernel / Linux Wirelesscfg80211 与 mac80211 官方文档第 0113 篇已经把 Wi-Fi Direct 的主要用户态机制闭环wpa_cli命令进入wpa_supplicantP2P Core 完成 Discovery、GO Negotiation、Group Formation、Teardown 与 Persistent Groupeloop、radio work、callback 和状态机也已经有了明确的运行模型。到这里还剩一个有意保留的黑盒wpa_supplicant ↓ driver_nl80211 ↓ Linux kernel / Wi-Fi driver ↓ 802.11 frame第 14 篇不把系列转成 Linux Wi-Fi 驱动教程也不逐文件阅读nl80211.c、cfg80211和mac80211。只选择 Wi-Fi Direct 最有代表性的两条控制面路径继续向下追踪P2P Listenremain_on_channel怎样让 radio 临时停留在指定信道P2P Action FrameGO Negotiation Request/Response 等管理帧怎样真正 TX、怎样从另一块 radio RX并把 TX status / RX event 返回wpa_supplicant。这两条链已经足以解释 Wi-Fi Direct 进入 Linux Wireless Stack 后做了什么。[S1][S2][S3][S4]版本边界userspace 继续固定为 hostap/wpa_supplicant 2.12 commit831364bf02710ad09c2f27d3efa92abeeb5634c0。内核源码改为 upstream Linuxmaster的可复现快照72d3fcf802c45d00b300f25b848a93c3a2bd7c7eLinux 7.3-rc52026-09-27。master会继续前进因此正文与随附源码包都绑定这个 commit需要跟随最新master时可重新执行源码包中的 sparse-checkout 命令。[S1][S2][S5]1. 先分清四层nl80211、cfg80211、mac80211、mac80211_hwsim 不是同一层Linux Wireless 中最容易出现的误解是把下面几个名称都笼统叫成“驱动”。实际上它们承担不同职责。[S5]层在本实验中的职责是否 Wi-Fi Direct 专用nl80211userspace 与 kernel 之间的 802.11 Generic Netlink ABI否cfg80211Linux 802.11 配置/API 层校验请求并通过cfg80211_ops调用具体实现否mac80211SoftMAC framework在内核中实现大量 802.11 MAC 处理并向 SoftMAC driver 提供ieee80211_ops否mac80211_hwsim虚拟 SoftMAC radio driver用内存中的 frame clone 模拟无线介质否wpa_supplicant P2P CoreWi-Fi Direct Discovery、Negotiation、Group lifecycle 状态机是Linux Kernel 文档对cfg80211的定位很直接它是 Linux 的 802.11 configuration API并通过nl80211向 userspace 提供统一接口SoftMAC 设备则通常由mac80211实现这些cfg80211callbacks再调用底层 driver。[S5]因此本实验中的控制链可以先压缩成这张图最重要的边界是Wi-Fi Direct 的协议决策仍在wpa_supplicant进入 kernel 以后Linux Wireless Stack 执行的是“切换/停留信道、发送/接收 802.11 frame、返回状态”等无线操作。2. P2P Listen 的真实 userspace 入口wpas_start_listen()不是直接调用 driver第 08 篇已经追到 Find 回环会进入 Listen。第 14 篇从这里继续而不重新展开 P2P Search/Listen 状态机。P2P Core 初始化时第 04 篇已经确认 callback 被绑定为p2p.start_listenwpas_start_listen;因此 P2P Core 决定进入 Listen 后会通过这个 callback 回到wpa_supplicant/p2p_supplicant.c。[S1]wpas_start_listen()没有直接触碰 nl80211。它先保存freq、duration与 Probe Response IE然后提交一个名为p2p-listen的 radio workif(!radio_add_work(wpa_s,freq,p2p-listen,0,wpas_start_listen_cb,lwork)){wpas_p2p_listen_work_free(lwork);return-1;}这一步延续了前文已经建立的 radio scheduler 模型同一 radio 上的 scan、listen、off-channel TX 不能彼此无条件并发先进入 work queue由 radio work 获得执行权后再真正操作硬件。wpas_start_listen_cb()获得执行权以后先做两件与 Listen 语义直接相关的准备配置 Probe Response IE要求 driver 上报 Probe Request。然后才进入本篇第一条关键边界if(wpa_drv_remain_on_channel(wpa_s,lwork-freq,duration,NULL)0){p2p_listen_failed(wpa_s-global-p2p,lwork-freq);wpas_p2p_listen_work_done(wpa_s);return;}因此P2P Listen在 userspace 中并不是一个“while 等待 Probe Request”的阻塞循环而是P2P Core 决定 Listen ↓ 提交 p2p-listen radio work ↓ work 获得 radio ↓ 请求 remain-on-channel ↓ 返回 eloop 等待异步事件这与前面整个系列的 Event/Callback 模型保持一致。[S1]3.wpa_drv_remain_on_channel()wpa_supplicant 在这里才通过 driver ops 跨到 nl80211 backendwpa_drv_remain_on_channel()本身只是一个很薄的 wrapperif(wpa_s-driver-remain_on_channel)returnwpa_s-driver-remain_on_channel(wpa_s-drv_priv,freq,duration,filter_addr);第 03 篇已经解释过wpa_s-driver当前工程通过-Dnl80211选择 nl80211 backend因此此函数指针最终落到wpa_driver_nl80211_remain_on_channel()这里第一次出现真正发送给 kernel 的 nl80211 command。[S1]hostap 2.12 构造的核心 attributes 是NL80211_CMD_REMAIN_ON_CHANNEL NL80211_ATTR_WIPHY_FREQ freq NL80211_ATTR_DURATION duration并通过 libnl 将 Generic Netlink message 发送给 kernel。kernel 回复时会带回一个cookiedriver_nl80211保存到drv-remain_on_chan_cookie这个 cookie 很重要。ROCRemain On Channel是异步操作发送请求成功只代表 kernel 接受了请求后续“已经到达该信道”和“停留结束”需要使用同一个 cookie 对应回原请求。[S1][S2]到这一层可以把职责分开对象此时负责什么P2P Core为什么要 Listen、在哪个阶段 Listenp2p_supplicant.c把 P2P Listen 转成 radio work 与 driver requestdriver_nl80211.c把freq/duration编码为 nl80211 messageGeneric Netlink负责 userspace ↔ kernel message transportnl80211解释这个 message 的无线语义Generic Netlink 本身并不知道 Wi-Fi Direct也不知道 P2P Listen它只负责把nl80211family 的 message 送到正确的 kernel handler。4. 进入 kernelnl80211_remain_on_channel()做的是校验与分发当前 Linuxmaster快照中NL80211_CMD_REMAIN_ON_CHANNEL对应net/wireless/nl80211.c的staticintnl80211_remain_on_channel(structsk_buff*skb,structgenl_info*info)这个函数不会实现“radio 怎样切频道”。当前master还把 cookie 的分配前移到 cfg80211/nl80211 公共层再把 cookie 作为值传入具体cfg80211_ops。它主要完成三类工作[S2]检查NL80211_ATTR_WIPHY_FREQ、NL80211_ATTR_DURATION等输入检查当前 wiphy 是否支持 remain-on-channel以及 duration 是否在设备支持范围内将频率解析成cfg80211使用的 channel/chandef然后调用具体cfg80211_ops。关键跳转可以缩成cookiecfg80211_assign_cookie(rdev);errrdev_remain_on_channel(rdev,wdev,chandef.chan,duration,cookie,rx_addr);这里的rdev是 cfg80211 注册的无线设备rdev_remain_on_channel()最终调用该设备注册的cfg80211_ops.remain_on_channel所以nl80211是 userspace ABI 与 kernel handler不是直接操作无线硬件的 driver。5. cfg80211 到 mac80211SoftMAC 路径由ieee80211_remain_on_channel()接手在 SoftMAC 设备上mac80211 自己注册了一套cfg80211_ops。当前 Linuxmaster快照的 ops table 中明确存在[S3].remain_on_channelieee80211_remain_on_channel,.cancel_remain_on_channelieee80211_cancel_remain_on_channel,.mgmt_txieee80211_mgmt_tx,因此本实验继续进入net/mac80211/offchannel.c ieee80211_remain_on_channel()该函数继续调用ieee80211_start_roc_work()这里 mac80211 建立ieee80211_roc_work保存 channel、duration、cookie、interface并统一管理多个 ROC 请求。[S3]mac80211 还会判断 driver 有没有实现ieee80211_ops.remain_on_channel如果没有硬件/driver ROC callbackmac80211 可以使用软件 off-channel work如果 driver 提供了 callback则通过drv_remain_on_channel()继续进入具体 SoftMAC driver。当前mac80211_hwsim使用 channel-context ops并把 callback 绑定为[S4].remain_on_channelmac80211_hwsim_roc,.cancel_remain_on_channelmac80211_hwsim_croc,到这里已经从Wi-Fi Direct Listen转换成了让这个虚拟 radio 在指定 channel 上进入一段 ROC 时间窗P2P 语义到这里已经基本退出内核主线。6.mac80211_hwsim_roc()虚拟 radio 怎样模拟“真的到了这个信道”mac80211_hwsim没有真实 RF、PLL、PHY 或 firmware因此它不能真的让射频前端切到 2412 MHz。它模拟的是 Linux Wireless 期望看到的 driver 行为。[S4]mac80211_hwsim_roc()保存hwsim-roc_chan hwsim-roc_duration随后调度roc_startdelayed work。hw_roc_start()执行时把hwsim-tmp_chan hwsim-roc_chan并调用ieee80211_ready_on_channel()告诉 mac80211driver 已经进入请求的 channel。duration 到期后hw_roc_done()调用ieee80211_remain_on_channel_expired()并清理tmp_chan。所以 hwsim 中一次 ROC 的本质不是“睡眠 duration 毫秒”而是两个异步通知之间的一段状态窗口mac80211_hwsim_roc() ↓ roc_start work ↓ tmp_chan requested channel ↓ ieee80211_ready_on_channel() ↓ [ROC active window] ↓ roc_done work ↓ ieee80211_remain_on_channel_expired() ↓ tmp_chan NULL真实 SoftMAC driver 会在相同 callback 契约下操作真实 radio/firmwarehwsim 则只模拟状态与事件。7. ROC 为什么还要从 kernel 再返回 userspacewpa_supplicant在发出 ROC 请求后不能自行假设“radio 已经切到目标信道”。真正 ready 的时刻由 driver/mac80211 确认。回程链路是[S1][S2][S3][S4]mac80211_hwsim ieee80211_ready_on_channel() ↓ mac80211 ↓ cfg80211_ready_on_channel() ↓ nl80211 multicast event ↓ driver_nl80211 event socket ↓ mlme_event_remain_on_channel() ↓ EVENT_REMAIN_ON_CHANNEL ↓ wpa_supplicant_event() ↓ wpas_p2p_remain_on_channel_cb() ↓ P2P Core / Listen state continues结束事件同样沿ieee80211_remain_on_channel_expired() ↓ cfg80211_remain_on_channel_expired() ↓ nl80211 event ↓ EVENT_CANCEL_REMAIN_ON_CHANNEL返回driver_nl80211后还会比对 cookie不是当前请求的 ROC event 不会误推进这次 Listen。这正好把前面几篇不断出现的“异步 callback”从 userspace 继续延伸到了 kernel/driver状态机没有在remain_on_channel()调用点阻塞等待而是提交请求、返回 event loop再由 driver event 推动后续状态。8. 第二条路径P2P Action Frame 最终不是 P2P Core 自己“发到空气中”第 09 篇已经追过 GO NegotiationP2P Core 构造 GO Negotiation Request 后通过初始化阶段绑定的p2p.send_action wpas_send_action回到wpa_supplicant。[S1]在 radio work 获得执行权后wpas_send_action_cb()调用offchannel_send_action()offchannel_send_action()处理一个关键问题这个 Action Frame 要发送的 channel是否就是 radio 当前已经所在的 channel如果 driver 支持直接 off-channel TX可以直接通过wpa_drv_send_action()请求如果当前不在目标 channel还可能先发起 ROC再等EVENT_REMAIN_ON_CHANNEL到达后发送 pending Action Frame。[S1]因此 ROC 与 Action TX 并不是两个互不相关的知识点Action Frame 要在 channel X 发送 ↓ radio 当前不在 X ↓ Remain On Channel / off-channel scheduling ↓ radio ready on X ↓ 真正发送 Action Frame这就是为什么第 14 篇把 Listen 与 Management Frame TX 放在同一篇而不是拆成两个独立内核专题。9.driver_nl80211把 P2P payload 包成真正的 802.11 Action FrameP2P Core 交给wpas_send_action()的 buffer 从 Action Frame 的 Category 字段开始并不是一整个完整的 802.11 MAC frame。hostap 2.12 的wpa_driver_nl80211_send_action()会分配24-byte IEEE 802.11 management header P2P Action payload并设置frame type Management frame subtype Action addr1 destination addr2 source addr3 BSSID然后通过nl80211_send_frame_cmd()形成NL80211_CMD_FRAMEmessage 交给 kernel。[S1]所以真正跨 userspace/kernel 的已经不是抽象的GO Negotiation Request object而是接近最终空口格式的IEEE 802.11 Management Action Framewpa_supplicant/P2P Core决定 Action body 的 P2P 协议内容driver_nl80211补上通用 802.11 management header 并提交给 Linux Wireless Stack。10.NL80211_CMD_FRAME在 kernel 中怎样继续到 mac80211当前 Linuxmaster快照中NL80211_CMD_FRAME进入nl80211_tx_mgmt()它检查 interface type、channel、off-channel 条件、wait duration 等 attributes把 userspace 的 message 转成struct cfg80211_mgmt_tx_params然后调用[S2]cookiecfg80211_assign_cookie(rdev);errcfg80211_mlme_mgmt_tx(rdev,wdev,params,cookie);对于 mac80211 SoftMAC这个 cfg80211 callback 最终进入ieee80211_mgmt_tx()ieee80211_mgmt_tx()接收上层已经分配好的 cookie创建 skb设置是否需要 TX status、是否禁止 CCK rate以及当前 frame 是否需要 off-channel。[S3]两个分支最值得记住当前 channel 可以直接 TX ↓ ieee80211_tx_skb_tid() ↓ mac80211 TX path以及需要 off-channel TX ↓ ieee80211_start_roc_work(..., txskb, IEEE80211_ROC_TYPE_MGMT_TX) ↓ ROC ready ↓ 发送这个 skb因此 mac80211 自己也把ROC 与 management TX 放在同一个 offchannel framework中。userspace 的offchannel_send_action()与 kernel 的ieee80211_start_roc_work()分别解决两层不同的调度问题但心智模型是一致的先保证 radio/channel 条件成立再发 frame。11. 到mac80211_hwsim后TX/RX 是怎样被“模拟出来”的mac80211 完成 TX handlers 后会通过ieee80211_ops把 frame 交给具体 SoftMAC driver。本实验的 driver ops 中.tx mac80211_hwsim_tx最终进入mac80211_hwsim_tx_frame_no_nl()。[S4]在默认没有wmediumd的模式下hwsim 会遍历已经启用的虚拟 radios只把 frame 复制给满足当前 channel/group/netgroup 条件的 radiosource hwsim radio ↓ TX skb ↓ 检查 peer radio 是否正在运行、是否在兼容 channel ↓ skb_copy() ↓ mac80211_hwsim_rx(peer_radio, ...) ↓ ieee80211_rx_irqsafe(peer_hw, skb)这一步非常适合建立“空口”的实验心智模型mac80211_hwsim没有真正把电磁波发出去而是把一块虚拟 radio 的 802.11 skb 复制成另一块虚拟 radio 的 RX skb再从对端ieee80211_rx_irqsafe()重新进入 mac80211 RX pipeline。[S4]如果目标 MAC 能匹配hwsim 还会把本次发送标记为可 ACK并通过ieee80211_tx_status_irqsafe()把 TX status 送回 mac80211。这就是为什么双 hwsim radio 能测试 GO NegotiationP2P frame 内容仍然是真实的 hostap/mac80211 逻辑只是“无线介质”被内核内存中的 frame delivery 替代。12. 对端收到 Action Frame 后为什么又能回到 wpa_supplicant对端 hwsim 调用ieee80211_rx_irqsafe()后frame 进入 mac80211 RX handlers。对于 userspace 已注册关注的 Action Framemac80211 会通过 cfg80211 management RX API 上送当前 Linuxmaster快照中这一段仍通过cfg80211_rx_mgmt_ext()上送。[S3]随后cfg80211 ↓ nl80211 management-frame event ↓ driver_nl80211 event socket readable ↓ NL80211_CMD_FRAME ↓ mlme_event_mgmt() ↓ wpa_supplicant_event(... EVENT_RX_MGMT ...) ↓ P2P RX Action handler因此 GO Negotiation Request 的完整跨设备方向终于可以闭环Device A P2P Core ↓ Action body ↓ driver_nl80211 / NL80211_CMD_FRAME ↓ Linux kernel / mac80211 ↓ mac80211_hwsim radio A ↓ [virtual wireless medium] ↓ mac80211_hwsim radio B ↓ mac80211 RX / cfg80211 ↓ nl80211 NL80211_CMD_FRAME event ↓ Device B driver_nl80211 ↓ Device B P2P CoreP2P state machine 仍然只存在于 userspacekernel 不解析“这个 Action Frame 是 GO Negotiation Request所以应该进入哪个 P2P state”。kernel 负责把 802.11 frame 正确送达和上报。13. TX Status 如何从 hwsim 回到 GO Negotiation 状态机第 09 篇已经看到 Action TX 后还要等待 ACK / NO_ACK / FAILED。现在可以补上它在 kernel/driver 中的来源。hwsim 在完成一次 TX 后调用ieee80211_tx_status_irqsafe()mac80211 根据这个 skb 是否请求 nl80211 TX status把结果关联到 management TX cookie再通过 cfg80211/nl80211 上报NL80211_CMD_FRAME_TX_STATUShostap 2.12 的driver_nl80211_event.c由mlme_event_mgmt_tx_status()解析 frame、cookie、ACK 信息最后生成EVENT_TX_STATUSwpa_supplicant/events.c再把它交给 off-channel TX 状态处理并最终回到wpas_p2p_send_action_tx_status() ↓ p2p_send_action_cb()P2P Core 才在这里根据 TX success / no-ack 等结果继续 GO Negotiation 状态机。[S1][S3][S4]所以这里也不能把send_action() 返回 0理解成对端已经收到 Action Framesend_action()返回成功只说明发送请求已被接受真正的 TX 结果通过后续异步 status event 到达。14. 把第 0214 篇连起来Wi-Fi Direct 控制面终于不再有“kernel 黑盒”此前系列已经知道wpa_cli ↓ control socket ↓ wpa_supplicant ↓ P2P Core ↓ scan / listen / action frame第 14 篇补上后可以继续向下P2P Core ↓ wpa_supplicant glue / radio work ↓ wpa_driver_ops ↓ driver_nl80211 ↓ Generic Netlink ↓ nl80211 ↓ cfg80211 ↓ mac80211 ↓ mac80211_hwsim / real SoftMAC driver ↓ 802.11 management frame TX/RX回程则是RX / TX status / ROC ready / ROC expired ↓ driver / mac80211 ↓ cfg80211 / nl80211 event ↓ driver_nl80211 ↓ wpa_supplicant_event() ↓ P2P callback / state machine到这里已经足以理解 Wi-Fi Direct 控制面进入内核和 SoftMAC driver 后“做了什么”。继续深入 Generic Netlink internals、mac80211 rate control、AMPDU、firmware command、DMA ring 或 PHY不再是理解 Wi-Fi Direct 的必要条件。还剩最后一个不同性质的问题Group 已经建立以后普通 TCP/UDP payload 不再走这条 P2P control path那么它到底怎样从 Socket 变成 802.11 Data Frame再从对端回到recv()这就是第 15 篇的主线。关键源码索引关键对象 / 符号本文位置Git 源码wpas_start_listen()/wpas_start_listen_cb()P2P Listen 入口hostap 2.12p2p_supplicant.cwpa_drv_remain_on_channel()driver wrapperhostap 2.12driver_i.hwpa_driver_nl80211_remain_on_channel()nl80211 backendhostap 2.12driver_nl80211.cnl80211_remain_on_channel()kernel ROC handlerLinux master snapshotnl80211.cieee80211_remain_on_channel()cfg80211 → mac80211Linux master snapshotoffchannel.cmac80211_hwsim_roc()hwsim ROCLinux master snapshotmac80211_hwsim_main.coffchannel_send_action()Action Frame 入口hostap 2.12offchannel.cwpa_driver_nl80211_send_action()Action Frame 封装hostap 2.12driver_nl80211.cnl80211_tx_mgmt()kernel management TXLinux master snapshotnl80211.cieee80211_mgmt_tx()mac80211 management TXLinux master snapshotoffchannel.cmac80211_hwsim_tx_frame_no_nl()/mac80211_hwsim_rx()hwsim TX/RXLinux master snapshotmac80211_hwsim_main.cmlme_event_mgmt_tx_status()TX Status 回程hostap 2.12driver_nl80211_event.c资料来源[S1] hostap / wpa_supplicant 2.12P2P Listen、Action TX 与 nl80211 backend类型目标版本源码用户提供源码快照版本hostap_2_12/ commit831364bf02710ad09c2f27d3efa92abeeb5634c0公开源码https://chromium.googlesource.com/chromiumos/third_party/hostap//refs/tags/hostap_2_12/关键文件/符号wpa_supplicant/p2p_supplicant.cwpas_start_listen()、wpas_send_action()wpa_supplicant/offchannel.coffchannel_send_action()wpa_supplicant/driver_i.hwpa_drv_remain_on_channel()src/drivers/driver_nl80211.cwpa_driver_nl80211_remain_on_channel()、wpa_driver_nl80211_send_action()src/drivers/driver_nl80211_event.cmlme_event_remain_on_channel()、mlme_event_mgmt_tx_status()使用位置第 23、79、1213 节支撑内容P2P callback 到 radio work、ROC/action command 的 userspace 生成以及 kernel event 返回 P2P Core 的路径。[S2] Linux master snapshotnl80211 userspace/kernel ABI类型upstream Linux 源码基线mastersnapshot72d3fcf802c45d00b300f25b848a93c3a2bd7c7eLinux 7.3-rc52026-09-27文件net/wireless/nl80211.c关键符号nl80211_remain_on_channel()、nl80211_tx_mgmt()、cfg80211_assign_cookie()、NL80211_CMD_REMAIN_ON_CHANNEL、NL80211_CMD_FRAME使用位置第 34、7、10、1213 节支撑内容ROC / management TX attributes、cookie、cfg80211 dispatch 与 nl80211 event 边界。[S3] Linux master snapshotmac80211 off-channel、Management TX/RX 与 TX pipeline类型upstream Linux 源码基线mastersnapshot72d3fcf802c45d00b300f25b848a93c3a2bd7c7e文件net/mac80211/offchannel.c、net/mac80211/tx.c、net/mac80211/rx.c、net/mac80211/cfg.c关键符号ieee80211_start_roc_work()、ieee80211_remain_on_channel()、ieee80211_mgmt_tx()、cfg80211_rx_mgmt_ext()使用位置第 5、7、10、1213 节支撑内容cfg80211 callbacks 如何进入 mac80211、ROC 与 management TX 的共享调度、Action RX 上送与 TX status 回程。[S4] Linux master snapshotmac80211_hwsim 虚拟 radio类型upstream Linux driver 源码基线mastersnapshot72d3fcf802c45d00b300f25b848a93c3a2bd7c7e文件drivers/net/wireless/virtual/mac80211_hwsim_main.c关键符号mac80211_hwsim_roc()、hw_roc_start()、hw_roc_done()、mac80211_hwsim_tx_frame_no_nl()、mac80211_hwsim_rx()使用位置第 57、11、13 节支撑内容hwsim 的 ROC 模拟、同频 radio 间 frame clone、ieee80211_rx_irqsafe()与ieee80211_tx_status_irqsafe()。[S5] Linux Kernel / Linux Wirelesscfg80211 与 mac80211 官方文档类型官方内核文档URL/文档cfg80211 subsystem、Linux 802.11 Driver Developers Guide、About mac80211使用位置版本边界、第 1、5、14 节支撑内容cfg80211 作为 Linux 802.11 configuration API、nl80211 userspace interface以及 mac80211 作为 SoftMAC framework 的职责边界。

Wi-Fi Direct 源码分析（14）：控制面进入 Linux 内核后发生了什么——nl80211、cfg80211、mac80211 与管理帧 TX/RX

相关推荐

达梦数据库-报错-14-EMFILE error! The per-process limit of open file descriptors has been reached.

基于Spark的汽车销售数据的分析与处理大数据系统（源码+讲解视频+LW）

Linux 下 Jira 7.13.3 安装与配置实战：Docker MySQL 数据库、中文化与首次初始化

更多资讯

OpenShell深度体验：跨平台终端统一与插件开发实战

Open Shell 使用指南：让 Windows 11 找回经典开始菜单

STM32与Simulink Real-Time半实物仿真平台搭建：从架构到在线调参

Java到底是编译型还是解释型？从字节码到JIT的完整链路解析

OpenClaw部署踩坑全记录：从WSL验证到Ollama本地模型接入

文本替换专家批量改稿：编码、正则与备份避坑指南

今日更新

Multisim仿真NE555 PWM控制器：从搭电路到调占空比全流程

S32K312 AUTOSAR BSW开发实战：从配置踩坑到烧录交付

双目视觉三维人脸重建：从视差图到点云粗配准全流程解析

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？