在 MAC 层访问无线接口 (802.11) (Linux)

Question

我在最后几天阅读了手册页、文档和其他任何 google 提出的内容，但我想我现在比刚开始时更加困惑。

这是我想做的事情：我想在使用 C/C++ 的 Linux 系统上通过无线接口 (802.11) 使用我自己的第 3-x 层协议发送和接收数据包。 到目前为止，一切都很好。我不需要信标、关联或任何与 AP/SSID 相关的东西。但是，对于数据传输，我希望 MAC 层表现得“像往常一样”，这意味着单播数据包被 ACK、重传、退避等。我还想享受扩展的 QoS 功能（802.11e 有 4 个队列和不同的访问类别）。另一方面，混杂模式不是问题，我只需要广播数据包和发送到特定站点的数据包。

正确的方法是什么？大多数关于原始套接字访问的文档似乎都集中在网络嗅探上，这无济于事。我一直在玩 monitor mode 一段时间，但从我目前所读到的内容来看，在监控模式等下接收到的数据包没有被确认。 如果没有监控模式，还有什么替代方案？使用 ad hoc 模式 和 unix 原始套接字？还是我必须摆弄司机？

我不是在寻找一个完整的解决方案，只是一些好的想法，从哪里开始。我通读了 socket(2)、socket(7) 和 packet(7) 的手册页，但这对 MAC 层在不同模式下的行为没有帮助。

提前致谢。

Answer 1

802.11 是第 2 层（和第 1 层）协议规范。它的设计方式允许更高层协议将其视为以太网。寻址和行为通常是相同的。因此，对于第 3 层协议，您根本不应该关心 802.11，而是像期望它在以太网网络上运行一样编写代码。

要使其正常工作，您应该首先连接到某种无线网络（这在概念上等同于将电线插入以太网卡）。在这里，您可以选择 ad-hoc（又名 IBSS）或基础设施（又名 BSS）网络（或 PBSS，一旦 802.11ad 获得批准；）。

操作卡与网络没有任何关联（只是在空中吐出数据包）不是一个好主意，原因有几个。最重要的是，它非常依赖硬件且不可靠。您仍然可以在一侧使用 RF mon（AKA 监控模式）接口，在另一侧使用数据包注入（使用 radiotap 标头），但我不建议这样做。即使您有一组相同的卡片，您也很可能在某些时候遇到难以解释的随机行为。 802.11 NIC 不是为这种操作而设计的，并且在固件内部保持不同的状态挂载（阅读有关 FullMAC 与 SoftMAC 卡的信息）。甚至 SoftMAC 卡也有很大的不同。例如，理论上在监控模式下，正如你所说，卡不应该 ACK 接收到的数据包。虽然有些卡片将 ACK 接收到的帧，因为它们的决定完全基于所述帧是发给它们的事实。有些卡片甚至可能会尝试确认他们看到的所有帧。重传也会发生类似的事情：有些卡只会发送一次注入的数据包（这就是它应该工作的方式）。在其他网卡中，重传由硬件（和固件）处理，驱动程序无法将其关闭，因此即使注入数据也会自动重传。

坚持使用第 3 层并使用现有模式（如 ad hoc），将为您提供所需的所有功能以及更多功能（QoS 等）。您发送到接口的以太网帧将被内核“转换”为带有 QoS 映射等的 802.11 格式。

如果您想了解 MAC 在各种模式下的行为，您必须阅读 mac80211 代码或 802.11 标准本身。 http://linuxwireless.orgwiki 我帮你做一些事情，但是内核黑客通常忙于在代码中编写除 cmets 之外的文档;)

L3 协议实现本身也可以在内核或用户模式下完成（使用原始套接字）。像往常一样，内核端会更难做，但更强大。

Answer 2

因为要创建自己的网络层协议（替代IP），所以关键字是：“raw ethernet socket”。所以忽略“原始 IP 套接字”的东西。

这是开始的地方：

int sockfd = socket( PF_PACKET, SOCK_RAW, htons(XXX) ); 

正确的手册页是：packet(7)。

通过搜索关键字查找更多信息。 一个很完整的例子here。

编辑：该示例的链接目前似乎已断开：another examples

Answer 3

你可能想要libpcap之类的东西。

Libpcap 允许您从/向网络接口读取/注入原始数据包。

Answer 4

首先，在尝试传输原始 802.12 帧时，您应该注意一些事项 - 设备驱动程序必须支持数据包注入。

您提到了监控模式，它在高级别的 rx 等效于注入能力——它不是“模式”，而是一种能力/特性。我这样说是因为 Linux 上的一些 892.11 设备驱动程序：

1. 支持监控模式和帧注入
2. 支持监控模式和不帧注入
3. 都不支持

除了尝试帧注入和嗅探另一台设备上的空气以确认它被看到之外，我不知道任何直接的方法来检查驱动程序是否支持帧注入。

通过使用sudo wlan0 set monitor 并查看返回码和/或输出是什么，通常很容易检查监控模式。

我从事这项工作已经有几年了，但当时，很少有设备支持“开箱即用”的监视器模式和帧注入。许多只支持带有修改版本的供应商或内核驱动程序的监控模式

您需要确保您的设备有一个完全支持两者的驱动程序。这种任务（帧监控和注入）对于倾向于使用 Kali Linux 的渗透测试人员来说很常见，Kali Linux 实际上只是一个 Ubuntu 发行版，其中预装了一堆“黑客”工具和（修改的）802.11 设备驱动程序并在其存储库中。通过使用搜索引擎查找推荐给 Kali 用户的设备和驱动程序，您通常可以节省查找支持良好的卡的时间

我明确提出了这种监控/注入功能，因为几年前我第一次从事类似项目时，我需要使用官方内核驱动程序的补丁版本来支持监控模式——它是一个 rtl8812au 芯片组.当时，我做了一个错误的假设，即驱动程序中的监控模式支持意味着完全注入支持。我花了 2 天时间把头撞在墙上，确信我的框架没有在我的应用程序中正确构建，导致没有框架离开卡片。结果我需要一个更新的driver 分支来获得完整的注入支持。该驱动程序现在特别支持监控模式和帧注入。诊断该问题最令人沮丧的是，在尝试传输帧时，我没有收到来自系统调用或内核消息的任何错误——它们只是被默默地丢弃在某个地方，大概是在驱动程序中

关于如何执行此操作的主要问题 - 如果您使用 C/C++ 编写应用程序，答案几乎肯定是 libpcap，因为 libpcap 不仅提供数据包捕获 API，还提供数据包注入 API

如果您使用 Python 进行操作，scapy 是一个很好的选择。 Python/scapy 的好处在于

1. Python 代码的编写速度比 C 快得多
2. scapy 提供了大量的类，您可以使用这些类直观地逐层创建帧
3. 由于图层是作为类实现的，因此您还可以扩展和“注册”现有类，以使某些帧更易于创建（或在收到时解析）

您可以直接使用带有原始套接字的 UNIX 套接字 API 在直接 C 中执行此操作 - 但您必须处理 libpcap 存在的东西以从您那里抽象出来 - 例如进行原始帧传输时可能需要的底层系统调用，除了标准的socket()、send()、recv() 调用。我推测您可能至少需要一些 ioctl 调用，特定于内核 802.11x 子系统/框架-并且这些 ioctl() 调用及其值可能无法在不同的主要内核版本之间完全移植.我承认我最终没有使用纯 C（没有 libpcap）的方法，所以我不能 100% 确定这个潜在的问题。如果您打算在没有 libpcap 的情况下执行此操作，那么您应该更多地研究它。除非您有充分的理由，否则我不推荐它

Answer 5

听起来你把媒体和传输层搞混了。

802.11 是通常所说的“链路”、“物理”或“媒体”层，这意味着它只处理原始数据报的传输。

ACK、重传、退避（流量控制）等概念适用于“传输”层，这些特定术语与 TCP/IP 密切相关。

从头开始实现您自己的完整传输层非常困难，而且几乎肯定不是您想要做的。相反，如果您想在您自己对 802.11 的自定义解释之上使用现有的 TCP/IP 堆栈，那么您可能需要创建一个虚拟网络接口。这将充当 TCP/IP 和媒体层之间的中介。

希望这可以为您提供更好的上下文和关键字来寻找。