十亿个苹果的秘密酱料：苹果无线直连自组网协议One Billion Apples' Secret Sauce: Recipe for the Apple Wireless Direct Link Ad hoc Protocol

本文翻译自: https://arxiv.org/pdf/1808.03156

摘要

Apple Wireless Direct Link (AWDL) 是一个专有的、未公开的、基于 IEEE 802.11 的自组网（ad hoc）协议。Apple 于 2014 年左右首次引入 AWDL，此后将其集成到整个产品线中，包括 iPhone 和 Mac。我们发现 AWDL 驱动着超过十亿终端设备上的流行应用，如 AirPlay 和 AirDrop。然而，该协议本身以及潜在的安全和 Wi-Fi 共存问题尚未被研究。在本文中，我们通过二进制分析和运行时分析，揭示了该协议的工作原理。简而言之，每个 AWDL 节点会宣布一系列可用性窗口（Availability Windows, AWs），表明其与其他 AWDL 节点通信的准备状态。一个被选举出的主节点（master）负责同步这些序列。在 AW 之外，节点可以将其 Wi-Fi 无线电调谐到不同信道以与接入点通信，或关闭无线电以节省能源。基于我们的分析，我们进行了实验，研究了主节点选举过程、同步精度、跳频动态和可实现的吞吐量。我们还进行了初步安全评估，并发布了一个开源的 AWDL Wireshark 解析器，以促进未来的研究。

关键词： AWDL, 逆向工程, 自组网, IEEE 802.11, 专有协议, Apple, macOS, iOS

This article is translated from: https://arxiv.org/pdf/1808.03156

Abstract

Apple Wireless Direct Link (AWDL) is a proprietary and undocumented IEEE 802.11-based ad hoc protocol. Apple first introduced AWDL around 2014 and has since integrated it into its entire product line, including iPhone and Mac. While we have found that AWDL drives popular applications such as AirPlay and AirDrop on more than one billion end-user devices, neither the protocol itself nor potential security and Wi-Fi coexistence issues have been studied. In this paper, we present the operation of the protocol as the result of binary and runtime analysis. In short, each AWDL node announces a sequence of Availability Windows (AWs) indicating its readiness to communicate with other AWDL nodes. An elected master node synchronizes these sequences. Outside the AWs, nodes can tune their Wi-Fi radio to a different channel to communicate with an access point, or could turn it off to save energy. Based on our analysis, we conduct experiments to study the master election process, synchronization accuracy, channel hopping dynamics, and achievable throughput. We conduct a preliminary security assessment and publish an open source Wireshark dissector for AWDL to nourish future work.

Keywords: AWDL, Reverse engineering, Ad hoc networks, IEEE 802.11, Proprietary protocol, Apple, macOS, iOS

引言

Apple Wireless Direct Link (AWDL) 是一个专有协议，部署在大约 12 亿终端设备中，涵盖 Apple 的主要产品系列，如 Mac、iPhone、iPad、Apple Watch 和 Apple TV——实际上所有包含 Wi-Fi 芯片的近期 Apple 设备。Apple 并未公开宣传该协议，仅模糊地将其称为"点对点 Wi-Fi"技术。然而，它驱动着诸如 AirDrop 和 AirPlay 等流行应用，这些应用透明地使用 AWDL，用户甚至不会注意到。

我们认为，公开这一未公开协议的细节将带来以下好处：第一，由于 AWDL 基于 IEEE 802.11，存在潜在的性能和共存问题需要识别。这在受监管环境中尤为重要，因为 AWDL 使用多种信道并采用可能干扰企业 Wi-Fi 部署的跳频机制。第二，Wi-Fi 驱动程序（AWDL 实现的地方）是当前 macOS 版本中最大的二进制内核扩展。鉴于最近公开的 Wi-Fi 芯片固件漏洞可能导致系统完全沦陷，我们强烈建议对该协议及其实现进行安全审计，因为非标准化协议中的漏洞更可能发生。例如，协议模糊测试需要了解帧格式。第三，该协议的开源重新实现将允许与其他操作系统互操作，最终实现高吞吐量的跨平台直接通信。例如，在基于智能手机的紧急通信应用中就需要这种技术。

为了最大程度地发挥对研究界的影响，我们揭开了 Apple 生态系统中的一层，揭示了一个已有但鲜为人知的无线自组网协议。在本文中，我们通过二进制和运行时分析对 AWDL 进行了全面调查，并展示了其帧格式和操作。简而言之，AWDL 基于 IEEE 802.11 标准，并利用供应商特定扩展来允许自定义协议实现。每个 AWDL 节点周期性地发送自定义操作帧，其中包含一系列可用性窗口（AW），表明其与其他 AWDL 节点通信的准备状态。一个被选举出的主节点同步这些序列。在 AW 内，节点可以使用专用数据帧格式与邻居通信。在 AW 之外，节点可以将其 Wi-Fi 无线电调谐到不同信道以与接入点通信，或关闭无线电以节省能源。

主要贡献：

• 提供对 macOS 操作系统及其 Wi-Fi 驱动架构和调试工具的深入分析，以帮助未来的研究（第 3 节）
• 详细展示 AWDL 的帧格式和操作（第 4-6 节）
• 对 AWDL 进行实验分析，评估选举行为、同步精度、吞吐量和跳频策略（第 7 节）
• 讨论协议复杂性、能源效率，并进行初步安全评估，报告 macOS 内核扩展中的安全权限问题（第 8 节）
• 发布开源 AWDL Wireshark 解析器

此外，我们在第 2 节中给出了相关直接无线通信技术的背景，并在第 9 节中总结了本文。

Introduction

Apple Wireless Direct Link (AWDL) is a proprietary protocol deployed in about 1.2 billion end-user devices consisting of Apple’s main product families such as Mac, iPhone, iPad, Apple Watch, and Apple TV—effectively all recent Apple devices containing a Wi-Fi chip. Apple does not advertise the protocol but only vaguely refers to it as a “peer-to-peer Wi-Fi” technology. Yet, it empowers popular applications such as AirDrop and AirPlay that transparently use AWDL without the user noticing.

We believe that public knowledge of this undocumented protocol would be beneficial for the following reasons: First, since AWDL is based on IEEE 802.11, there are potential performance and co-existence issues that need to be identified. This is especially important in regulated environments as AWDL uses various channels and employs a channel hopping mechanism that might interfere with corporate Wi-Fi deployments. Second, the Wi-Fi driver (where AWDL is implemented) is the largest binary kernel extension in current versions of macOS. Given the recently published vulnerabilities in Wi-Fi chip firmware that might lead to full system compromise, we highly recommend a security audit of the protocol and its implementations as vulnerabilities in non-standardized protocols are even more likely to occur. For example, protocol fuzzing requires knowledge of the frame format. Third, an open re-implementation of the protocol would allow interoperability with other operating systems, eventually enabling high-throughput cross-platform direct communication. Such technology is required, for example, in smartphone-based emergency communication applications.

To maximize the impact for the research community, we have lifted a layer in Apple’s ecosystem and unveiled an existing yet obscure wireless ad hoc protocol. In this paper, we conduct a comprehensive investigation on AWDL by means of binary and runtime analysis, and present its frame format and operation. In short, AWDL is based on the IEEE 802.11 standard and makes use of vendor-specific extensions that allow custom protocol implementations. Each AWDL node periodically emits custom action frames containing a sequence of Availability Windows (AWs) indicating its readiness to communicate with other AWDL nodes. An elected master node synchronizes these sequences. Within these AWs, nodes are able to communicate with their neighbors using a dedicated data frame format. Outside the AWs, nodes can tune their Wi-Fi radio to a different channel to communicate with an access point, or turn it off to save energy.

We summarize our main contributions:

• We provide insights into the macOS operating system and its Wi-Fi driver architecture and debugging facilities to help future research endeavors (Section 3).
• We present the AWDL frame format and operation in detail (Sections 4 to 6).
• We conduct an experimental analysis of AWDL to assess election behavior, synchronization accuracy, throughput, and channel hopping strategies (Section 7).
• We discuss protocol complexity, energy efficiency, and perform a preliminary security assessment where we report a security permission problem in a macOS kernel extension (Section 8).
• We publish an open source AWDL Wireshark dissector.

Furthermore, we give background on related direct wireless communication technologies in Section 2 and conclude this work in Section 9.

背景

AWDL 已在多项专利中被引用，可归类为允许对等体直接相互通信的无线自组网协议。目前已经存在多种相关技术，我们在下文中进行总结。

IEEE 802.11 IBSS

IBSS 模式，通常称为"ad hoc"模式，创建了一个没有特殊控制器角色的分布式无线网络。IBSS 通过在特定信道上发送带有 SSID 和 BSSID 的信标帧来创建。加入网络的其他节点将使用相同的信息自行发送信标。由于所有节点都广播信标，该模式对节点离开网络具有较强的鲁棒性。节点无需进一步同步。然而，IBSS 从未得到广泛部署，主要是由于缺乏有效的节能机制，这对移动设备至关重要。有缺陷的实现是另一个常见问题。Android 不支持 IBSS，微软也宣布它可能在未来版本的 Windows 中不再可用。在 Apple 的操作系统上，加密不被支持，iOS 仅允许加入现有的 IBSS 网络。

Wi-Fi 对等网络（Wi-Fi P2P）

Wi-Fi P2P，以其认证名称 Wi-Fi Direct 闻名，允许多个设备在无基站的情况下直接连接。在运行过程中，一个节点承担组所有者（GO）的角色，该角色类似于基础设施（或 BSS）操作。GO 的角色不能迁移到其他设备：如果 GO 离开网络，则必须创建新网络。Wi-Fi P2P 连接通过在一个信道上监听并在所有信道上发送探测请求来建立。这在实践中延迟了连接过程。实验表明，建立连接需要 4 到 10 秒以上。设备发现过程因此非常快速地耗尽电池。

隧道直连链路设置（TDLS）

TDLS 是一个 IEEE 802.11 扩展，使同一 BSS 中的两个节点能够直接通信。在没有 TDLS 的网络中，即使两个通信节点在通信范围内，所有流量也经过接入点（AP）。TDLS 要求两个节点都连接到同一个 AP，因为控制帧通过 AP 隧道传输，因此不能在真正的自组网场景中使用。

邻居感知网络（NAN）

NAN，也称为 Wi-Fi Aware，通过邻近服务发现扩展了 IEEE 802.11。NAN 设计为能效高，允许在电池供电设备上持续运行。NAN 在 Android 8 中得到支持，但我们没有找到任何具有兼容硬件的设备。NAN 依赖于从选举出的主节点发送的信标帧，这些信标同步区域内所有设备的时序。在主节点设置的短暂发现窗口期间，设备可以打开无线电，交换服务和连接信息（例如 Wi-Fi P2P 的参数），然后再次关闭无线电。事实上，我们发现 AWDL 采用了与 NAN 类似的概念，但实际实现与 NAN 有很大不同。此外，NAN 没有用于传输用户数据的数据路径。

蓝牙

蓝牙是一个具有不同 PHY 和 MAC 层的独立标准，在 2.4 GHz 频段运行，与 Wi-Fi 相同，并且通常集成到 Wi-Fi 芯片中以共享同一天线。蓝牙低功耗（BLE）与经典蓝牙不兼容，专为低能耗优化，因此提供有限的带宽。BLE 4.2 的可用最大数据速率为 394 kbit/s。它通常在小电池供电设备中实现，如智能手表和健身追踪器。BLE 不适合大数据传输，但可用于引导高带宽链路，如 AWDL。

Background

AWDL has been referenced in several patents and can be classified as a wireless ad hoc protocol which allows peers to communicate directly with each other. There exist already a number of other technologies which we summarize in the following.

IEEE 802.11 IBSS

The IBSS mode commonly known as “ad hoc” mode creates a distributed wireless network without special controller roles. An IBSS is created by sending beacon frames with an SSID and BSSID on a particular channel. Other nodes joining the network will send out beacons themselves using the same information. The mode is robust to nodes leaving the network as all nodes broadcast beacons. The nodes do not require any further synchronization. However, IBSS has never become widely deployed, mostly due to lack of efficient power saving mechanisms, which are crucial for mobile devices. Flawed implementations are another common problem. IBSS is not supported on Android and Microsoft announced it might not be available in future versions of Windows. On Apple’s operating systems encryption is not supported and iOS only allows to join existing IBSS networks.

Wi-Fi Peer-to-Peer (Wi-Fi P2P)

Wi-Fi P2P, also known under its certification name Wi-Fi Direct, allows connecting multiple devices directly without a base station. During operation, one node assumes the role of a Group Owner (GO) which closely resembles infrastructure (or BSS) operation. It is not possible to migrate the role of the GO to another device: if the GO leaves the network, a new network must be created. Wi-Fi P2P connections are established by listening on one channel and sending probe requests on all channels. This delays the connection process in practice. Experiments show that establishing a connection takes from four to more than ten seconds. Discovering devices thus drains their battery very fast.

Tunneled Direct Link Setup (TDLS)

TDLS is an IEEE 802.11 extension that enables direct communication between two nodes in the same BSS. In networks without TDLS, all traffic passes the Access Point (AP) even when the two communicating nodes are within communication range. TDLS requires both nodes to be connected to the same AP since control frames are tunneled through the AP and, thus, cannot be used in real ad hoc scenarios.

Neighbor Awareness Networking (NAN)

NAN, also known as Wi-Fi Aware, extends IEEE 802.11 with proximity service discovery. NAN is designed to be energy efficient, allowing continuous operation on battery-powered devices. NAN is supported in Android 8, but we did not find any devices with compatible hardware. NAN depends on beacon frames sent from an elected master. These synchronize the timing of all devices in an area. During a short discovery window the master sets, devices can turn their radio on, exchange service and connection information (e.g., parameters for Wi-Fi P2P) and turn their radio off again. In fact, we found that AWDL employs similar concepts as NAN, but the actual implementation differs strongly from that of NAN. In addition, NAN does not feature a data path for transmission of user data.

Bluetooth

Bluetooth is a separate standard with different PHY and MAC layers. Bluetooth operates in the 2.4 GHz band as Wi-Fi and is often integrated into the Wi-Fi chip to share the same antennas. Bluetooth Low Energy (BLE) is incompatible with classic Bluetooth and is optimized for low energy consumption and, therefore, offers limited bandwidth. The usable maximum BLE 4.2 data rate is 394 kbit/s. It is commonly implemented in small battery-powered devices such as smartwatches and fitness trackers. BLE is not designed for large data transfers but can be used for bootstrapping high-bandwidth links such as AWDL.

方法论

逆向工程与其说是一门科学，不如说是一门艺术，因此很难写出通用的配方。尽管如此，我们以 macOS 操作系统为重点，构建了逆向闭源网络协议的方法论，以便用于相关研究工作。在下文中，我们描述了二进制和动态运行时分析如何协同工作，以完全揭示一个复杂无线网络协议的工作原理。之前的典范工作包括对 Skype 协议、Broadcom Wi-Fi 芯片固件和 Fitbit 生态系统的逆向工程。

二进制分析

我们分析了大量与 AWDL 相关的二进制文件，最终找到了实现该协议的部分。我们首先说明选择过程，然后讨论实现大部分 AWDL 协议栈的两部分 Wi-Fi 驱动程序。我们将分析重点放在 macOS 上，并假设其架构在原则上与 iOS 类似。我们使用反编译器来分析目标二进制文件。

二进制选择。 Apple 在其操作系统中大量使用框架和守护进程。因此，存在大量依赖关系，导致复杂的二进制选择过程。框架向其对应的单例守护进程提供 API，并可被其他守护进程和进程使用。我们从爬取系统中名称包含"802.11"、"Multicast DNS (mDNS)"或"sharing"的二进制文件开始。通过跟踪依赖关系，我们找到了更多相关目标。在图 1 中展示了部分已发现的依赖和交互关系。虽然存在面向用户的二进制文件，如 sharingd 守护进程，但最相关的二进制文件位于内核中，特别是通用 Wi-Fi 驱动程序 IO80211Family 和设备特定变体 AirportBrcm4360 与 AirportBrcmNIC。它们每个都包含数百个 AWDL 相关函数，表明协议栈的大部分在此实现。我们发现 IO80211Family 负责大部分 AWDL 帧的解析和创建以及维护 AWDL 状态机。设备特定驱动程序处理时间关键的功能，如同步。由于两个驱动程序部分都是 macOS 中最大的内核扩展之一，理解内部驱动程序结构是理解反编译代码的关键。

寻找感兴趣的代码段。 由于 macOS Wi-Fi 驱动程序的大小，我们需要快速找到实现 AWDL 协议部分的函数。幸运的是，Apple 没有从二进制文件中剥离符号名称，因此在符号表中搜索"awdl"（例如使用 nm）会产生大量结果。其中一些符号还包含"parse"和"TLV"（例如 parseAwdlSyncTreeTLV），帮助我们理解某些 TLV 字段的计算。此外，调试日志语句提供了有关函数内代码段目的的提示。因此，我们可以搜索调试字符串及其交叉引用，以找到诸如第 6.2 节中的错位阈值等细节。

泄露的 Broadcom 驱动源码。 作为另一个信息来源，我们使用了泄露的旧版 Broadcom Wi-Fi 驱动程序源代码。我们在源代码中发现了多处对 AWDL 的引用，但没有核心功能。我们怀疑 Broadcom 使用模块化固件概念，一个中央仓库用于广泛的功能。特殊功能如 AWDL 选择性地提供给其客户（如 Apple）。比 AWDL 引用更重要的是源代码中发现的一些 C 结构体，包括关键结构，如同步参数 TLV 和信道序列 TLV（详见第 5 节）。泄露的代码还包含 wl 工具的源代码，该工具提供驱动程序的调试功能，将在第 3.2 节中进一步讨论。

剖析结构体。 为了理解驱动程序的功能，我们需要重建底层数据结构。泄露的源代码显示，大多数 AWDL 相关函数使用 awdl_info 结构体作为第一个参数。wlc_dump_awdl 函数以可读格式打印内部数据，因此是重建内部结构的理想目标，如下所示：

bcm_bprintf(a2, "AWDL master home channel = %d\n",
            awdl_info->master_home_channel);

我们二进制分析的结果是一个完整的 AWDL Wireshark 解析器，我们也用它来进行协议的动态分析和评估实验。解析器如图 2 所示。

运行时分析

仅通过二进制分析很难完全理解协议操作。为了理解同步、选举、服务发现和数据路径的语义，我们用动态方法补充了静态分析。在本节中，我们讨论了专用的 macOS 日志和调试工具，这些工具有助于分析协议。特别是，我们使用了 Console 应用程序、ioctl 接口、泄露的 Broadcom wl 工具以及 Apple 未公开的 CoreCapture 框架。后者特别详细，但需要为 Wireshark 编写额外的解析器，因为它使用私有数据格式。

Apple Console。 Console 程序是 macOS 10.12 以来访问日志的中心位置，包含来自内核的调试消息。为了从 Wi-Fi 驱动程序获得详细输出，我们通过自定义启动参数提高了日志级别，这些参数是通过在 Wi-Fi 驱动程序中搜索对 PE_parse_boot_arg 函数的引用找到的。以下启动参数最大化驱动程序的调试输出：

nvram boot-args="debug=0x10000 \
      awdl_log_flags=0xffffffffffffffff \
      awdl_log_flags_verbose=0xffffffffffffffff \
      awdl_log_flags_config=1 wlan.debug.enable=0xff"

在提高日志级别后，Console 显示额外信息，如状态转换和当前信道序列：

IO80211Family <...> com.apple.p2p: AWDL ON: [infra
    (100) 72%], (6/44/44) [44 0 0 0 0 0 0 0 6 44
    44 0 0 0 0 0] Low Power

ioctl 接口。 ioctl 系统调用是 Unix 系统上设备通信的标准方式。Apple 使用 ioctl 来配置无线接口，如关联 AP 或创建 IBSS。Apple 为 macOS 10.5 提供了包含请求格式、可用请求类型和数据结构头文件。这些旧的头文件可以使用二进制分析中的信息更新到最新版本。apple80211VirtualRequest 方法包含所有处理函数的调用。72 个可用请求 ID 中有 40 个与 AWDL 相关。这些请求可以设置驱动程序中的多个参数。特别有用的是卡特定 ioctl，它允许将 Broadcom 特定的 ioctl 包装在 Apple ioctl 内，从而提供与 Broadcom 驱动程序的直接接口。请注意，自从 Apple 修复了我们报告的漏洞（第 8 节）后，不再可能发送 Broadcom 特定的 ioctl：驱动程序现在检查私有权限安全权限（com.apple.driver.AirPort.Broadcom.ioctl-access），需要由 Apple 私钥签名的二进制文件。应该可以使用内核扩展补丁框架覆盖驱动程序中的相应权限检查函数，以恢复无限制的 ioctl 访问。驱动程序补丁需要禁用 Apple 的系统完整性保护。

Broadcom wl 工具。 泄露源码中的 Broadcom wl 工具提供了多种访问 AWDL 操作内部信息的方法，这些方法与二进制分析期间发现的结构直接相关。虽然泄露的源码中缺少 AWDL 特定的驱动程序代码，但 wl 源码包含 AWDL 相关命令和结构。wl 允许我们使用诸如 dump awdl 和 awdl_advertisers 等命令查询当前 AWDL 驱动程序状态。后者显示有关邻居节点的信息，包括 RSSI。

CoreCapture 框架。 CoreCapture 是 Apple 在 iOS 和 macOS 上用于 IEEE 802.11 的主要日志和跟踪框架。CoreCapture 将原始协议跟踪与传统日志条目结合，并提供设备和驱动程序状态的快照。CoreCapture 未公开，但我们在驱动程序中发现的 dumpPacket 函数中引用了它。由于该框架输出大量具有自定义头格式的 PCAP 跟踪文件（以及其他日志和内存转储），我们编写了一个 CoreCapture 的 Wireshark 解析器并向公众开放。此外，我们在本文中发布了 CoreCapture 的使用手册。

Methodology

Reverse engineering is more of an art than a science and, hence, it is hard to write generic recipes. Nevertheless, we structure our methodology for reversing closed-source network protocols with a focus on the macOS operating system so that it can be used in related research endeavors. In the following, we describe how binary and dynamic runtime analysis in tandem can result in full disclosure of the workings of a complex wireless network protocol. Previous exemplary works have reverse engineered the Skype protocol, Broadcom Wi-Fi chip firmware, and the Fitbit ecosystem.

Binary Analysis

We analyzed numerous binaries related to AWDL to finally find those parts that implement the protocol. We first illustrate our selection process and then discuss the two-part Wi-Fi driver which implements most of the AWDL protocol stack. We focus our analysis on macOS and assume that the architecture is in principle similar to that of iOS. We used a decompiler to analyze the target binaries.

Binary Selection. Apple excessively uses frameworks and daemons in its OSes. Consequently, there are numerous dependencies which result in a complex binary selection process. Frameworks offer an API to their corresponding singleton daemons and can be used by other daemons and processes. We started off by crawling the system for binaries that had “802.11”, “Multicast DNS (mDNS),” or “sharing” in their names. We found more related targets by following dependencies. We show part of the discovered dependencies and interactions in Fig. 1. While there are user-facing binaries such as the sharingd daemon, the most relevant binaries reside in the kernel, in particular, the generic Wi-Fi driver IO80211Family and the device-specific variants AirportBrcm4360 and AirportBrcmNIC. Each of them includes hundreds of AWDL-related functions, suggesting that the bulk of the protocol stack is implemented here. We found that IO80211Family takes care of most of the AWDL frame parsing and creation as well as maintaining the AWDL state machine. The device-specific driver handles time-critical functions such as synchronization. As both driver parts are among the largest kernel extensions present in macOS, understanding internal driver structures were key to make sense of the decompiled code.

Finding Interesting Code Segments. Due to the size of the macOS Wi-Fi driver, we needed to quickly find functions that would implement part of the AWDL protocol. Fortunately, Apple does not strip symbol names from their binaries, such that searching for “awdl” in the symbol table (e.g., using nm) results in a number of hits. Some of those symbols additionally contain “parse” and “TLV” in their name (e.g. parseAwdlSyncTreeTLV) which helped us understand the calculation of some Type-Length-Value (TLV) fields. Furthermore, debug log statements give hints about the purpose of a code segment inside a function. Therefore, we can search for debugging strings and their cross-references to find details such as the misalignment threshold in Section 6.2.

Leaked Broadcom Driver Source Code. As another source of information, we used a dated Broadcom Wi-Fi driver whose source code was leaked. We found several references to AWDL in the source code but none of the core functionality. We suspect that Broadcom uses a modular firmware concept with one central repository for a wide range of features. Special features such as AWDL are made available selectively to their customers such as Apple. More important than the references to AWDL are some C structs found in the source code. These include key structures such as the Synchronization Parameters TLV and Channel Sequence TLV (more in Section 5). The leaked code also contains the source code for the wl utility, which provides debugging features for the driver and is further discussed in Section 3.2.

Dissecting Structures. To understand the driver’s functions, we needed to reconstruct the underlying data structures. The leaked source code shows that most of the AWDL-related functions use an awdl_info struct as a first parameter. The wlc_dump_awdl function prints internal data in a readable format and, thus, was an ideal target to reconstruct the internal structures as shown below:

bcm_bprintf(a2, "AWDL master home channel = %d\n",
            awdl_info->master_home_channel);

The result of our binary analysis was a complete Wireshark dissector for AWDL that we also used for the dynamic analysis of the protocol and for evaluating our experiments. We show our dissector in Fig. 2.

Runtime Analysis

The complete protocol operation was difficult to comprehend with the binary analysis alone. To understand the semantics of synchronization, election, service discovery, and data path, we complemented our static analysis with a dynamic approach. In this section, we discuss dedicated macOS logging and debugging facilities that helped to analyze the protocol. In particular, we used the Console application, the ioctl interface, the leaked Broadcom wl utility, as well as Apple’s undocumented CoreCapture framework. The latter is especially verbose but required us to write an additional dissector for Wireshark as it uses a private data format.

Apple Console. The Console program is the central place to access logs since macOS 10.12 and includes debug messages from the kernel. To receive verbose output from the Wi-Fi driver, we increased the log level using custom boot arguments which we found by searching for references to the PE_parse_boot_arg function in the Wi-Fi driver. The following boot arguments maximize the driver’s debug output:

nvram boot-args="debug=0x10000 \
      awdl_log_flags=0xffffffffffffffff \
      awdl_log_flags_verbose=0xffffffffffffffff \
      awdl_log_flags_config=1 wlan.debug.enable=0xff"

With the increased log level, Console shows additional information such as state transitions and the current channel sequence:

IO80211Family <...> com.apple.p2p: AWDL ON: [infra
    (100) 72%], (6/44/44) [44 0 0 0 0 0 0 0 6 44
    44 0 0 0 0 0] Low Power

ioctl Interface. ioctl system calls are a standard way to communicate with devices on Unix-based systems. Apple uses ioctls to configure wireless interfaces such as associating with an AP or creating an IBSS. Apple provides the header files with the request format, the available request types, and the data structures for macOS 10.5. These old header files can be brought up to date using information from the binary analysis. The apple80211VirtualRequest method contains calls to all handler functions. Out of the available 72 request IDs, 40 relate to AWDL. These requests can set several parameters in the driver. Especially useful is the card-specific ioctl. It allows wrapping a Broadcom-specific ioctl inside an Apple ioctl, providing us with a direct interface with the Broadcom driver. Note that it is no longer possible to send Broadcom-specific ioctls since Apple fixed our reported vulnerability (Section 8): the driver now checks for a private entitlement security permissions (com.apple.driver.AirPort.Broadcom.ioctl-access) which requires a binary signed with an Apple private key. It should be possible to overwrite the respective permission-checking function in the driver using a kernel extension patching framework to restore unrestricted ioctl access. Driver patching requires disabling Apple’s System Integrity Protection.

Broadcom wl Utility. The Broadcom wl utility found in the leaked source code provides several methods to access internal information about AWDL operations, which are directly related to the structures found during binary analysis. Although the AWDL-specific driver code was missing in the leaked source code, the wl source code contains AWDL related commands and structures. wl allows us to query the current AWDL driver status using commands such as dump awdl and awdl_advertisers. The latter shows information about neighboring nodes including RSSI.

CoreCapture Framework. CoreCapture is Apple’s primary logging and tracing framework for IEEE 802.11 on iOS and macOS. CoreCapture combines raw protocol traces with traditional log entries and provides snapshots of the device and driver state. CoreCapture is undocumented but was referenced in a dumpPacket function that we found in the driver. Since the framework outputs (among other logs and memory dumps) numerous PCAP trace files with a custom header format, we wrote a Wireshark dissector for CoreCapture that we make available to the public. In addition, we publish a manual for CoreCapture with this paper.

AWDL 协议概述

基于我们的分析，我们对 AWDL 的设计目标和决策提出了以下假设：(i) 利用现有硬件（Wi-Fi 芯片），因此在 IEEE 802.11 之上构建协议；(ii) 节约能源，特别是在移动设备上，因此同步并在空闲期间将 Wi-Fi 芯片置于省电模式；(iii) 允许直接通信和基于基础设施的通信无缝运行，因此实现同步信道跳频而不断开与 AP 的连接；(iv) 实现快速服务发现，因此将 DNS-SD 卸载到 Wi-Fi 帧。商用 Wi-Fi 芯片通常具有单个 RF 链，因此在任何给定时间只能使用单个无线信道。要使用多个信道，适配器需要切换信道，并在短时间内无法使用常规无线连接。这是漫游（在连接到网络时扫描可用网络）和节能功能（关闭无线电）的预期行为。为了利用这些短时间进行数据传输，设备需要一种发现和协调何时在哪个信道上见面的方法。我们在图 3 中描述了 AWDL 的主要阶段，并在下文中简要介绍。

协议架构

AWDL 协议栈由以下关键组件构成：

1. 用户空间守护进程： sharingd（处理 AirDrop）、airportd（Wi-Fi 管理）、mDNSResponder（多播 DNS 服务发现）
2. 框架层： CoreWLAN、Foundation（NSNetService）、WirelessProximity
3. 内核空间： IO80211Family（通用 Wi-Fi 驱动）、AirportBrcm4360/AirportBrcmNIC（设备特定驱动）

关键概念

可用性窗口（AW）。 节点在操作帧（AF）中公布其 AW 序列，AW 以时戳（TU，1 TU = 1.024 ms）为单位。

扩展可用性窗口（EAW）。 EAW 包含多个连续的 AW，允许更长的通信窗口。所有当前实现都专门使用 EAW。

主节点选举。 AWDL 节点通过分布式算法选举一个主节点，负责同步 AW 序列、维护信道序列、处理新节点的初始同步。

信道序列。 AWDL 定义一个包含 16 个时隙的信道序列。

AWDL 的五个主要阶段：

1. 激活 — Apple 将 AWDL 用作按需通信技术。这意味着 AWDL 默认处于非活动状态，但应用程序可以（临时）请求激活。例如，AirDrop 使用 BLE 进行激活，通过发送用户联系信息的截断哈希；AirPlay 接收器（Apple TV）通过 AWDL 持续宣布其存在；第三方应用程序可以通过 NSNetService API 间接激活接口来广告服务。
2. 主节点选举 — Apple 使用固定社交信道（6、44 和 149，取决于国家）通过周期同步帧（PSF）进行协调。启动 AWDL 接口的节点在社交信道上监听一段时间以发现范围内的其他节点。如果收到 AWDL 操作帧（AF），节点可以采纳现有的主节点。如果没有收到帧，它自己承担主节点角色。选举过程在第 6.1 节中详细说明。
3. 同步信道序列 — AWDL 围绕一系列时隙（可用性窗口 AW 和扩展可用性窗口 EAW）构建。对于每个时隙，对等方广播它们是否可用于 AWDL 数据以及将在哪个信道上。对等方将这些广告与自己的 AW 序列匹配。如果在特定 AW 中存在共同信道，则可以在该 AW 期间进行通信。同步机制对齐节点之间的序列。同步和信道对齐过程分别在第 6.2 节和第 6.3 节中详细说明。
4. 服务发现 — DNS 服务发现（DNS-SD），也称为"Bonjour"，可以卸载到 AWDL。AWDL 将 DNS-SD 响应直接附加到其 AF 上，以便在节点更改其广告时立即发现服务。由于篇幅限制，我们在本文中不详细说明服务发现组件。
5. 数据传输 — AWDL 使用供应商特定的帧格式头部传输用户数据，仅传输 IPv6 数据包。在向特定对等方传输用户数据时，节点需要计算两个节点都调谐到同一信道的 AW，并仅在这些 AW 期间传输帧。此外，AWDL 根据当前传出流量负载调整其信道序列。我们在第 7 节的实验评估中详细讨论了数据传输机制。

AWDL Overview

Based on our analysis, we formulate hypotheses regarding the design goals and decisions of AWDL: (i) leverage existing hardware (Wi-Fi chip), thus building the protocol on top of IEEE 802.11; (ii) conserve energy, especially on mobile devices, hence synchronizing and putting the Wi-Fi chip into a power-saving mode during idle times; (iii) allow seamless operation of direct and infrastructure-based communication, so enable synchronized channel hopping without disconnecting from an AP; and (iv) enable fast service discovery, thus offloading DNS-SD to Wi-Fi frames. Commodity Wi-Fi chips usually have a single RF chain and are, therefore, restricted to a single wireless channel at any given time. To use multiple channels, an adapter needs to switch channels and cannot use the regular wireless connection for short periods of time. This is expected behavior for roaming (scan for available networks while being connected to a network) and power saving features (switch off the radio). To use these short periods for data transfer, devices need a method for discovery and coordination when to meet on which channel. We depict the main AWDL phases in Fig. 3 and briefly introduce them in the following.

Protocol Architecture

The AWDL protocol stack consists of the following key components:

1. User-space daemons: sharingd (AirDrop), airportd (Wi-Fi management), mDNSResponder (multicast DNS service discovery)
2. Framework layer: CoreWLAN, Foundation (NSNetService), WirelessProximity
3. Kernel space: IO80211Family (generic Wi-Fi driver), AirportBrcm4360/AirportBrcmNIC (device-specific drivers)

Key Concepts

Availability Window (AW). Nodes announce their AW sequences in Action Frames (AFs). AWs are specified in Time Units (TU, 1 TU = 1.024 ms).

Extended Availability Window (EAW). EAWs contain multiple consecutive AWs, allowing longer communication windows. All current implementations exclusively use EAWs.

Master Election. AWDL nodes elect a master through a distributed algorithm, responsible for synchronizing AW sequences, maintaining the channel sequence, and handling initial synchronization of new nodes.

Channel Sequence. AWDL defines a channel sequence containing 16 time slots.

The five main AWDL phases:

1. Activation — Apple uses AWDL as an on-demand communication technology. This means that AWDL is inactive by default, but applications can (temporarily) request activation. For example, AirDrop uses BLE for activation by sending truncated hashes of the user’s contact information; AirPlay receivers (Apple TV) constantly announce their presence via AWDL; and third-party applications may activate the interface indirectly by advertising services via the NSNetService API.
2. Master Election — Apple uses fixed social channels (6, 44, and 149, depending on the country) for coordination using Periodic Synchronization Frames (PSFs). A node starting its AWDL interface monitors the social channels for some time to discover other nodes in range. If AWDL Action Frames (AFs) are received, the node can adopt an existing master. If no frames are received, it assumes the master role itself. We elaborate on the election process in Section 6.1.
3. Synchronized Channel Sequences — AWDL is built around a sequence of time slots (Availability Windows (AWs) and Extended Availability Windows (EAWs)). For each of these slots, peers broadcast if they are available for AWDL data and, if so, on which channel they will be. Peers match these advertisements with their own AW sequence. If there is a common channel in a particular AW, communication during this AW is possible. A synchronization mechanism aligns the sequences between nodes. We elaborate on the synchronization and channel alignment processes in Sections 6.2 and 6.3, respectively.
4. Service Discovery — DNS Service Discovery (DNS-SD) also known as “Bonjour” can be offloaded to AWDL. AWDL piggy-backs DNS-SD responses directly onto its AFs such that services are immediately discovered whenever a node changes its advertisements. For space reasons, we do not elaborate on the service discovery component in this paper.
5. Data Transfer — AWDL uses a vendor-specific frame format header for user data which exclusively transports IPv6 packets. When transmitting user data to a particular peer, a node needs to calculate the AWs during which both nodes are tuned to the same channel and only transmit frames during those AWs. In addition, AWDL adapts its channel sequence according to the current outgoing traffic load. We discuss the data transfer mechanisms in detail during the experimental evaluation in Section 7.

AWDL 帧格式

我们发现了 AWDL 使用的两种通用帧类型：用于协调的操作帧和用于直接数据传输的数据帧。我们将在下文中详细说明这些类型的帧格式。

操作帧（AF）

AWDL 使用 IEEE 802.11 供应商特定 AF，通常允许具有组织唯一标识符（OUI）的供应商实现具有任意负载的 IEEE 802.11 帧。AWDL 供应商特定扩展由固定大小的头部和多个 TLV 字段组成，如图 4 所示。TLV 由一个 1 字节类型字段，后跟一个 2 字节长度字段组成，该字段指示后续值字节字符串的长度。固定头部主要包括静态值，如 AWDL 特定的 BSSID、OUI、版本和类型。两个时间戳指示帧创建的时间（TTx,Target），因此其中包含的信息是最新的，以及帧实际排队传输的时间（TTx,PHY）。它们的差值近似发送方的传输延迟，用于同步目的。AWDL 有两种 AF 子类型：周期同步帧（PSF）和主指示帧（MIF）。这些帧类型以相同的固定头部开始，仅在包含的 TLV 集合上有所不同，因此大小也不同。我们在图 4 中展示了不包括帧末尾 FCS 的帧格式。我们首先解释子类型的目的，然后讨论 AWDL 中使用的 TLV。

周期同步帧（PSF）。 PSF 用于同步，在第 6.2 节中进一步解释。该名称来源于一项专利。其子类型为 0。如果所有参与设备都支持 5 GHz 频段，PSF 是唯一也在 2.4 GHz 频段上出现的帧类型。

广播主指示帧（MIF）。 MIF 用于多种目的，例如选举（第 6.1 节）和服务发现。它包含更多 TLV，并由网络中的所有设备定期发送。MIF 子类型为 3。

TLV。 TLV 包含实际的控制信息。不同类型可归因于以下目的之一：选举和同步、服务发现和用户数据传输。此外，版本 TLV 提供 1 字节版本号，可能取代固定头部中的版本字段（见图 4）。我们在表 1 中总结了所有 TLV，并在下文中简要讨论。名称取自二进制分析期间发现的函数名和调试字符串。我们在本文中仅详细讨论部分 TLV，完整规范请参考我们的 Wireshark 解析器。请注意，表 1 中缺少某些类型值（例如 1、3 和 8）。这些类型似乎已被弃用，因为在我们分析的 AWDL 版本中未积极使用。

选举和同步过程处理设备的整体协作。这些 TLV 中的数据决定，例如，哪个节点担任主节点角色以及使用哪些信道。奇怪的是，同步参数 TLV 包含自己的信道序列，因此单独的信道序列 TLV 似乎是冗余的。然而，在当前操作系统版本中，它始终被传输。这在第 6.1 节至第 6.3 节中进一步讨论。服务发现组件将 mDNS 和 DNS-SD 功能卸载到 AF。它们包含主机名（Arpa TLV）；以及 PTR、SRV 和 TXT 资源记录（服务响应 TLV）。用户数据传输组件用于协商设备之间直接连接的参数。例如，支持的 PHY 速率在 HT/VHT 能力 TLV 中宣布，这些类似于 IEEE 802.11n 和 802.11ac 修正案中引入的能力。此外，每个对等方在数据路径状态 TLV 中宣布其当前连接的 Wi-Fi 网络（BSSID）以及 Wi-Fi 芯片的真实 MAC 地址。我们认为这些信息可用于在双方对等方连接到同一网络时将 AWDL 连接卸载到基础设施网络。然而，这需要额外的可达性测试，因为网络策略如客户端隔离，并且我们在实践中未观察到此类行为。版本 TLV 包括 AWDL 版本（主版本号和次版本号各占半字节）以及设备类别 ID。我们发现 v3.x 用于 macOS 10.13 和 iOS 11；v2.x 用于 macOS 10.12 和 iOS 10（可能还有更早的 iOS 版本）。AWDL v1.x 用于 macOS 10.11，不支持版本 TLV。设备类别似乎指示节点的操作系统类型，例如 macOS (1) 或 iOS (2)。

数据帧

AWDL 使用 IEEE 802.11 数据帧进行用户数据传输。To-DS 和 From-DS 标志设置为零，类似于 IBSS，这意味着这些帧是直接寻址的，使用三个地址字段分别用于目的地、源和 BSSID。我们在图 5 中展示了 AWDL 数据帧格式。AWDL 帧中的 BSSID 始终为 00:25:00:ff:94:73，属于分配给 Apple 的 OUI 00:25:00。LLC 头部包含一个不同的 Apple OUI (00:17:f2) 和 SNAP 部分中的协议 ID。这些头部是 IEEE 802 标准的一部分，允许供应商在更高层实现自己的协议。实际的 AWDL 数据头部本质上由一个序列号和传输协议的 EtherType 组成。我们确定 IPv6 是 AWDL 使用的唯一协议。

高层协议的寻址

AWDL 与高层协议结合使用。因此，它需要某种方法通过高层网络协议来寻址 AWDL 节点。这尤其重要，因为 AWDL 实现了隐私增强的 MAC 随机化——这意味着它不是使用 Wi-Fi 芯片的固定 MAC 地址，而是每次接口激活时生成随机地址。在 IPv6 中，地址解析通常通过邻居发现协议（NDP）完成。然而，Apple 不对 AWDL 使用 NDP，而是从 AF 中包含的源地址字段（图 4）生成链路本地 IPv6 地址，使用 RFC 4291 附录 A 中描述的方法。该方法基于网络接口的 48 位 MAC 地址构造链路本地 IPv6 地址。特别是，给定一个 48 位 MAC 地址 o0:o1:o2:o3:o4:o5，相应的链路本地 IPv6 地址构造为：

fe80::o0^0x02:o1:o2:ff:fe:o3:o4:o5

使用这种标准化方法，节点可以在收到第一个 AF 后立即将其邻居添加到邻居表中，无需额外的地址解析协议（如 NDP 或 ARP）的开销。

Frame Format

We discovered two general frame types used by AWDL: action and data frames which are used for coordination and direct data transfer, respectively. We elaborate on the frame format of these types in the following.

Action Frames

AWDL uses IEEE 802.11 vendor-specific AFs which generally allow vendors with an Organizational Unique Identifier (OUI) to implement IEEE 802.11 frames with arbitrary payloads. The AWDL vendor-specific extension consists of a fixed-sized header and multiple TLV fields as shown in Fig. 4. A TLV consists of a 1-byte type field, followed by a 2-byte length field which indicates the length of the subsequent value byte string. The fixed header mostly includes static values such as AWDL-specific BSSID, OUI, version, and type. The two timestamps indicate when the frame was created and, therefore, at which time the included information was up-to-date (TTx,Target), and when it was actually queued for transmission (TTx,PHY). Their difference approximates the sender’s transmission delay and is used for synchronization purposes. There are two AWDL AF subtypes: Periodic Synchronization Frame (PSF) and Master Indication Frame (MIF). These frame types start with the same fixed header and differ only in the included set of TLVs and, hence, their size. We show the frame format excluding the FCS at the end of the frame in Fig. 4. We first explain the purpose of the subtypes and then discuss TLVs used in AWDL.

Periodic Synchronization Frame (PSF). The PSF is used for synchronization and is further explained in Section 6.2. The name was gathered from a patent. Its subtype is 0. If all participating devices support the 5 GHz band, the PSF is the only frame type also seen on the 2.4 GHz band.

Broadcast Master Indication Frame (MIF). The MIF is used for multiple purposes, e.g., election (Section 6.1) and service discovery. It includes more TLVs and is sent by all devices in the network regularly. The MIF subtype is 3.

TLVs. TLVs contain the actual control information. The different types can be attributed to one of the following purposes: election and synchronization, service discovery, and user data transmission. In addition, the version TLV provides a 1-byte version number which presumably supersedes the version field in the fixed header (see Fig. 4). We summarize all TLVs in Table 1 and discuss them briefly in the following. The names were taken from function names and debugging strings found during binary analysis. We discuss only some TLVs in detail in this paper, and refer to our Wireshark dissector for the full specification. Note that some type values (e.g. 1, 3, and 8) are missing in Table 1. These types appear to be deprecated as they were not actively used in the AWDL versions that we analyzed.

The election and synchronization processes handle the overall cooperation of the devices. The data in these TLVs determines, e.g., which node takes the master role and which channels are to be used. Curiously, the Synchronization Parameters TLV includes its own channel sequence, so the separate Channel Sequence TLV appears to be redundant. It was however always transmitted on current operating system versions. This is further discussed in Sections 6.1 to 6.3. The service discovery components offload mDNS and DNS-SD functionality to the AFs. They contain the hostname (Arpa TLV); and PTR, SRV, and TXT resource records (Service Response TLV). The user data transmission components are used to negotiate the parameters for direct connections between devices. For example, supported PHY rates are announced in the HT/VHT Capabilities TLVs which are similar to the ones introduced in the IEEE 802.11n and 802.11ac amendments. In addition, each peer announces in the Data Path State TLV the Wi-Fi network (BSSID) that it is currently connected to as well as the real MAC address of the Wi-Fi chip. We believe that this information could be used to offload an AWDL connection to an infrastructure network if both peers are connected to the same network. However, this would require additional reachability tests due to network policies such as client isolation, and we did not observe such behavior in practice. The version TLV includes the AWDL version (half a byte for major and minor version number each) as well as a device class ID. We found that v3.x is used in macOS 10.13 and iOS 11; and v2.x in macOS 10.12 and iOS 10 (and potentially prior iOS versions). AWDL v1.x is used in macOS 10.11 which does not support the version TLV. The device class seems to indicate the OS type of the node, e.g., macOS (1) or iOS (2).

Data Frames

AWDL uses IEEE 802.11 data frames for user data transmission. The To-DS and From-DS flags are set to zero, similar to IBSS which means that these frames are addressed directly, and three address fields are used for the destination, source, and BSSID. We depict the AWDL data frame format in Fig. 5. The BSSID in AWDL frames is always 00:25:00:ff:94:73 which belongs to the OUI 00:25:00 that is assigned to Apple. The LLC header contains a different Apple OUI (00:17:f2) and a protocol ID in the SNAP part. These headers are part of the IEEE 802 standard and allow vendors to implement their own protocols on higher layers. The actual AWDL data header essentially consists of a sequence number and the EtherType of the transported protocol. We identified IPv6 as the only protocol used with AWDL.

Addressing for Higher-Layer Protocols

AWDL is used in conjunction with higher-layer protocols. Therefore, it needs some way to address AWDL nodes via a higher-layer network protocol. This is especially important because AWDL implements privacy-enhancing MAC randomization which means that instead of using the Wi-Fi chip’s fixed MAC address, it generates a random address every time the interface is activated. In IPv6, address resolution is usually done via the Neighbor Discovery Protocol (NDP). Apple, however, does not use NDP for AWDL, but instead generates link-local IPv6 addresses from the source address field contained in the AFs (Fig. 4) using a method described in RFC 4291, Appendix A. This method constructs a link-local IPv6 address based on the 48-bit MAC address of the network interface. In particular, given a 48-bit MAC address o0:o1🅾️o3:o4:o5, the corresponding link-local IPv6 address is constructed as:

fe80::o0^0x02:o1:o2:ff:fe:o3:o4:o5

Using this standardized method, nodes can add their neighbors to the neighbor table immediately after receiving the first AF without the need or overhead of an additional address resolution protocol such as NDP or ARP.

AWDL 协议操作

我们展示了用于形成和维护 AWDL 集群的详细机制。特别是，我们讨论了如何选举主节点以及如何解决冲突；节点如何将其时钟同步到主节点；最后，宣布的信道序列如何映射到 AW 序列。

主节点选举

在本节中，我们解释选举过程和基于树的同步结构。我们特别关注使 AWDL 对主节点离开或加入集群具有鲁棒性的机制。

主节点的角色。 如前所述，AWDL 依赖于集群中所有参与节点的大致同步时钟。为实现这一点，集群中必须恰好有一个节点负责发出"时钟信号"。这是主节点的唯一角色（据我们所知也是唯一的）。集群中的所有其他节点称为从节点，应采纳此信号。在只有两个节点的简单场景中，一个节点是主节点，另一个是从节点。在更大的场景中，从节点可能与主节点相距一跳以上。在这种情况下，中间从节点将承担非选举主节点的角色，负责重复主节点的时钟信号。中间主节点包含在同步树 TLV 中，每个节点在其中宣布到"顶级"主节点的路径。无论如何，集群中只有一个顶级主节点。

主节点度量。 主节点选举基于度量字段，该字段包含在选举参数 v2 TLV 中。宣布最大度量值的节点将成为该集群的主节点。Apple 的专利声称这些度量可以基于可用能源资源、CPU 负载、信号强度等。然而，在实践中，度量只是随机选择的。激活 AWDL 接口的节点最初将其度量字段设置为 60，并在社交信道上监听现有主节点 2 秒。如果未找到主节点，则从预定义范围中抽取随机数并将其设置为其度量。我们发现此范围取决于 AWDL 版本，例如 v2.x 中为 405 到 436，v3.x 中为 505 到 536。我们假设这样做是为了向后兼容，以便主节点节点保证是集群中运行最新版本的节点，并且可以支持未来的协议扩展。

合并具有不同主节点的集群。 当两个已建立的具有不同主节点的 AWDL 集群移动到接近范围内时，它们需要合并，以便不同集群中的节点能够相互发现。在 AWDL 中，该过程很简单，因为所有节点在选举参数 TLV 中广告其当前主节点度量。如果两个具有不同主节点的节点相互发现，它们会收到对方集群的顶级主节点度量，并可以立即采纳具有更高度量的主节点。然后，"较低"集群中的其余节点在第一个节点广告新主节点度量后跟随。

环路预防。 当创建这样一个具有多级子主节点的选举树层次结构时，可能会出现环路。为了防止环路并限制选举树的最大深度，每个 AF 在同步树 TLV 中包含直到顶级主节点的所有节点列表。每个节点可以确保如果它已经在某个节点的路径中，就不会采纳该节点作为非选举主节点。

重新选举。 使用低度量初始化设备将防止大多数新设备加入时的随机重新选举。由于没有签退消息，离开网络的主节点只需停止发送 AF。因此，缺失的主节点只能由其他设备在一定的无主节点超时后检测到，该超时固定为 96 个 AW（约 1.5 秒）。然后另一个节点将取代旧主节点的位置。由于此节点已经与旧主节点同步，其他从节点不需要重新同步，只需采纳新主节点。换句话说，AWDL 对"主节点流失"具有鲁棒性，即离开的主节点不会中断通信，新主节点被无缝采纳。这与其他技术（如 Wi-Fi Direct）形成对比，后者相应主节点本质上充当 AP，负责在两个节点之间中继数据，离开的主节点将需要重新建立组。

RSSI 的作用。 接收到的 AF 的 RSSI 值用于过滤可能不稳定的连接。特别是，AWDL 节点在 RSSI 低于所谓的边缘同步阈值时丢弃帧，该阈值设置为 -65（如果使用 AirPlay 则为 -78）。来自当前主节点的帧以较低的 RSSI 被接受，这些帧获得 5 的额外从节点同步阈值。降低主节点帧的阈值允许 RSSI 的一定变化。我们假设这样做是为了减少"主节点抖动"，即节点频繁采纳新主节点，因为它经常丢弃帧并且无主节点超时发生。

同步

同步与选举过程紧密耦合，因为节点始终尝试同步到其选举的主节点。在本节中，我们描述 AWDL 中时间如何结构化，以及节点如何将其时间参考与主节点的时间参考对齐。我们介绍可用性窗口（AW）的概念，即通信可能发生的短固定长度时隙。这些窗口具有静态长度，但可以使用扩展窗口（EW）扩展。最后，我们展示如何使用同步参数 TLV 中的字段确定 AW 的开始。我们在图 7 中总结了关键概念和变量。

可用性窗口。 AW 指示设备可用于通信的时间段。这些窗口需要与集群中的所有节点同步，以便每个设备在同一时间开始 AW。AWDL 中的时序基于时间单位（TU），其中 1 TU = 1024 µs。在 AWDL 实现中，AW 始终设置为 16 TU 长。AW 的长度和本节中呈现的所有其他"静态"值包含在同步参数 TLV 中。理论上，不同的配置是可能的，但我们发现只使用了固定值。

存在模式和扩展窗口。 为了降低功耗，对等方可以指示它不在每个 AW 中监听。存在模式 p 为 4 是 Apple 的 AWDL 实现中使用的唯一值，意味着对等方仅每第四个窗口监听一次。如果节点正在传输或接收数据，它可以延长其在信道上花费的时间，这称为扩展窗口（EW）。存在模式 4 为三个 16 TU 的 EW 留出空间。此外，AWDL 允许配置不同数量的单播、多播和 AF EW，但这些字段当前始终设置为 3，因此与存在模式对齐。图 6 显示了同步参数 TLV 中传输的参数。鉴于静态配置，使用的有效最小时间单位是四个连续的 AW/EW。对于本文的其余部分，我们使用术语扩展可用性窗口（EAW）来指代这样的 64 TU 时隙。

计算可用性窗口的开始。 每个从节点需要将其时钟同步到主节点的时钟。为实现这一点，主节点宣布下一个 AW 的开始。在传输 AF 时，主节点包括到下一个 EAW 的 TU 数 tAW 以及当前 AW 或 EW 的序列号 i。我们在图 7 中以红色标记这些值。

由于这些值是在驱动程序中创建帧时设置的，因此帧实际通过 Wi-Fi 接口传输之前会经过一些时间。AWDL 尝试通过在每个 AF 的固定头部中包含两个额外时间戳来补偿此发送延迟：分别是 PHY 和目标传输时间 TTx,PHY 和 TTx,Target。理想情况下，TTx,Target 在创建帧时设置，TTx,PHY 在帧即将通过接口传输之前设置。然而，在 macOS 驱动程序中，两个时间戳都在 Wi-Fi 驱动程序中设置，因此不考虑由分布式协调功能（DCF）引起的延迟，DCF 控制介质访问。尽管如此，在时间 TRx 从其主节点接收 AF 的设备可以近似下一个 AW 的开始 TAW 如下：

TAW = tAW · 1024 − (TTx,PHY − TTx,Target) + tair + TRx

实际上，AWDL 忽略空中时间 tair，因为在典型的近距离 Wi-Fi 场景中它是亚微秒级的，并且可接受的同步误差为 3 ms。我们在第 7 节中实验评估了可实现的精度。

信道序列

AWDL 信道序列公告建立在同步的 AW 之上，指示节点是否实际可用于通信，以及如果可用，其无线电已调谐到哪个信道。在本节中，我们解释信道序列如何映射到 AW 序列。

信道序列将信道号映射到 AW 序列号。虽然图 8 所示的 TLV 中包含的信道序列包含固定数量的 c + 1 = 16 个信道条目，但序列可以通过 step 字段延长，类似于存在模式，使得一个信道条目可以跨越多个 AW 和 EW。将 step 设置为 1 意味着信道将在一个额外的 AW 中处于活动状态。然而，Apple 始终将此字段设置为 3，意味着信道将在四个 AW 或一个 EAW 中处于活动状态。因此，信道序列与同步参数 TLV 中的存在模式完全对齐。给定一个编码的信道序列和一个 AW 序列号 i，AWDL 节点可以根据以下计算为任何对等方计算当前活动信道 C：

C = i mod ((c + 1) · (step + 1))

由于 Apple 对 c 和 step 使用固定值，宣布的信道序列覆盖 (15+1)·(3+1) = 64 个 AW，大约需要一秒钟（64 AW · 16 TU/AW = 1048576 µs ≈ 1 s）。

Protocol Operation

We present the detailed mechanisms that are used to form and maintain an AWDL cluster. In particular, we discuss how a master is elected, and conflicts are resolved; how nodes synchronize their clock to the master; and, finally, how the announced channel sequence maps to the sequence of AWs.

Master Election

In this section, we explain the election process and the tree-based synchronization structure. In particular, we focus on the mechanisms that make AWDL robust to master nodes leaving or joining the cluster.

Role of the Master Node. As already mentioned, AWDL relies on roughly synchronous clocks of all participating nodes in a cluster. To achieve this, it is paramount that there is exactly one node in the cluster which has the responsibility of emitting a “clock signal.” This is the one (and as far as we know the only) role of the master node. All other nodes in the cluster are called slaves and should adopt this signal. In a simple scenario with only two nodes, one node will be the master and another a slave. In larger scenarios, slave nodes might be more than one hop away from the master node. In such cases, intermediate slave nodes will take the role of non-election masters, which have the responsibility to repeat the master’s clock signal. The intermediate master nodes are included in the Synchronization Tree TLV where each node announces the path to the “top” master. In any case, there is only one top master in a cluster.

Master Metric. The master election is based on a metric field which is included in the Election Parameters v2 TLV. The node that announces the largest metric value will become the master of that cluster. Apple’s patent claims that these metrics could be based on available energy resources, CPU load, signal strength, etc. In practice, however, the metric is simply chosen at random. A node that activates its AWDL interface initially sets its metric field to 60 and listens on the social channels for an existing master for 2 seconds. If no master is found, it draws a random number from a predefined range and sets this as its metric. We have found that this range depends on the AWDL version, e.g., 405 to 436 in v2.x and 505 to 536 in v3.x. We assume that this is done for backwards compatibility so that the master node is guaranteed to be a node running the most up-to-date version in a cluster and future protocol extensions can be supported.

Merging Clusters with Different Masters. When two already established AWDL clusters with different master nodes move into proximity, they need to merge such that nodes in the different clusters will be able to discover each other. In AWDL, the process is straight-forward as all nodes advertise their current master metric in the Election Parameters TLV. If two nodes with different masters discover each other, they receive the top master metric of the other cluster and can immediately adopt the master with the higher metric. The remaining nodes in the “lower” cluster then follow as soon as the first node advertises the new master metric.

Loop Prevention. When creating such an election tree hierarchy with multiple levels of sub-masters, loops may occur. To prevent loops and limit the maximum depth of the election tree, each AF contains a list of all nodes up to the top master in the Synchronization Tree TLV. Each node can then make sure that it does not adopt a non-election master if it is already in that node’s path.

Re-Election. The initialization of a device using a low metric will prevent most random re-elections when new devices join the network. As there is no sign-off message, a master leaving the network simply stops sending AFs. Therefore, a missing master can only be detected by other devices after a certain no master timeout which is fixed to 96 AWs (≈ 1.5 s). Another node will then take the place of the old master. As this node was already in sync with the old master, other slave nodes do not need to re-synchronize but simply adopt the new master. In other words, AWDL is robust to “master churn,” i.e., a leaving master does not interrupt communication, and a new master is seamlessly adopted. This is in contrast to other technologies such as Wi-Fi Direct, where the respective master node essentially acts as an AP which takes care of relaying data between two nodes and a leaving master would require a group re-establishment.

The Role of RSSI. The RSSI values of received AFs are used to filter out possibly unstable connections. In particular, AWDL nodes drop frames when the RSSI is below a so-called edge sync threshold which is set to -65 (or -78 if AirPlay is used). Frames from the current master node are accepted with a lower RSSI. These frames receive a bonus slave sync threshold of 5. Lowering the threshold for the master frames allows for a certain variance in the RSSI. We assume that this was done to reduce “master flapping” where a node frequently adopts a new master because it regularly drops frames and the no master timeout occurs.

Synchronization

Synchronization is tightly coupled with the election process since nodes always try to synchronize to their elected master. In this section, we describe how time is structured in AWDL and how nodes align their time reference with that of their master. We introduce the concept of Availability Windows (AWs), that is, short fixed-length time slots during which communication is possible. These windows have a static length, but can be extended using Extension Windows (EWs). Finally, we show how the start of an AW is determined using fields from the Synchronization Parameters TLV. We summarize the key concepts and variables in Fig. 7.

Availability Window. AWs indicate a period of time during which a device will be available for communication. These windows need to be synchronous for all nodes in a cluster such that every device starts an AW at the same time. Timing in AWDL is based on Time Units (TUs) where 1 TU = 1024 µs. In the AWDL implementation, an AW is always set to be 16 TUs long. The length of an AW and all other “static” values presented in this section are contained in the Synchronization Parameters TLV. In theory, different configurations are possible, but we found that only fixed values are used.

Presence Mode and Extension Windows. For reduced power consumption, a peer can indicate that it is not listening in every AW. A presence mode p of 4, which is the only value used in Apple’s AWDL implementation, means that a peer is only listening for every fourth window. If a node is transmitting or receiving data, it may extend its time spent on the channel. This is called an Extension Window (EW). A presence mode of 4 leaves space for three EWs of 16 TUs. In addition, AWDL allows to configure different numbers of unicast, multicast, and AF EWs, but these fields are currently always set to 3 and, thus, align with the presence mode. Figure 6 shows the parameters transmitted in the Synchronization Parameters TLV. Given the static configuration, the effective smallest time unit in use is four consecutive AWs/EWs. For the remainder of this paper, we use the term Extended Availability Window (EAW) to refer to such a 64 TU time slot.

Calculating the Start of an Availability Window. Each slave node needs to synchronize its clock to that of its master node. To achieve this, the master node announces the start of the next AW. When transmitting an AF, the master includes the number of TUs to the next EAW tAW as well as the sequence number of the current AW or EW i. We mark these values in red in Fig. 7.

As these values are set when the frame is created in the driver, some time passes until the frame is actually transmitted via the Wi-Fi interface. AWDL tries to compensate for this transmitter delay by including two additional timestamps in the fixed header of each AF: the PHY and target transmission times TTx,PHY and TTx,Target, respectively. Ideally, TTx,Target is set when the frame is created, and TTx,PHY just before the frame is transmitted via the interface. In the macOS driver, however, both timestamps are set in the Wi-Fi driver and, therefore, do not account for delays induced by the distributed coordination function (DCF) which controls medium access. Nevertheless, a device receiving an AF from its master at time TRx can approximate the start of the next AW TAW as follows:

TAW = tAW · 1024 − (TTx,PHY − TTx,Target) + tair + TRx

In fact, AWDL ignores the airtime tair since it is in the order of sub-µs in a typical close-range Wi-Fi scenario, and the accepted synchronization error is 3 ms. We experimentally evaluate the achievable accuracy in Section 7.

Channel Sequence

The AWDL channel sequence announcement builds upon the synchronized AWs and indicates whether a node is actually available for communication and, if so, on which channel it has tuned its radio. In this section, we explain how the channel sequence maps to the sequence of AWs.

The channel sequence maps channel numbers to AW sequence numbers. While the channel sequence included in the TLVs shown in Fig. 8 contains a fixed number of c + 1 = 16 channel entries, the sequence can be prolonged with the step field similar to the presence mode, so that one channel entry can span multiple AWs and EWs. Setting step to 1 means that the channel will be active for one additional AW. However, Apple always sets this field to 3, meaning that the channel will be active for four AWs or one EAW. Thus, the channel sequence is fully aligned to the presence mode in the Synchronization Parameters TLV. Given an encoded channel sequence and an AW sequence number i, an AWDL node can calculate the currently active channel C for any peer based on the following calculation:

C = i mod ((c + 1) · (step + 1))

As Apple uses fixed values for c and step, the announced channel sequence covers (15+1)·(3+1) = 64 AWs which takes about one second (64 AW · 16 TU/AW = 1048576 µs ≈ 1 s).

实验分析

我们在不同场景中分析 AWDL 的运行时行为，以 (i) 验证前几节的发现，以及 (ii) 评估协议的性能。首先，我们描述测试设置。然后，我们在没有数据传输的空闲场景中查看主节点选举和同步精度。我们进一步分析信道跳频行为和吞吐量性能。

测试设置

我们的测试设置包括一个监控设备和多台 Apple 设备。我们的监控设备是 APU 板，配备两个 Qualcomm Atheros QCA9882 Wi-Fi 卡，以支持在两个不同信道上同时嗅探，这两个信道分别调谐到 AWDL 的主要信道（44）和辅助信道（6）。两个 Wi-Fi 卡都支持硬件时间戳，这减轻了接收方操作系统堆栈中的可变延迟。为了同步嗅探 Wi-Fi 芯片的内部时钟，我们以校准阶段开始每个实验：我们将两个芯片调谐到共同信道，让它们记录多个帧。实验后，我们计算两个卡都接收到的帧的时间戳差。我们使用中位数差来校正时钟偏移并对齐两个跟踪。所有后续实验都在法拉第帐篷内进行，以最小化干扰。我们的测试设备包括 iPhone 8（iOS 11.2.2）、iPad Pro 10.5"（iOS 11.0.3）、iMac（Late 2012，macOS 10.12.6）和 MacBook Pro（Late 2015，macOS 10.12.6）。

主节点选举

在第一个实验中，我们分析了主节点选举过程。我们观察到 AWDL 集群处于空闲状态，意味着没有数据传输发生，唯一观察到的帧是 AF。我们使用由 iPhone、iPad、iMac 和 MacBook 组成的设置。我们通过在一个设备上选择共享面板来激活 AWDL 接口，这会导致 BLE 扫描并激活范围内其他设备的 AWDL 接口（在 iOS 上，仅当设备解锁时才有效）。为了获得更有趣的结果，我们让不同设备大约相隔 30 秒加入。

图 9 显示了每个节点当前选择的主节点。首先，iMac 创建 AWDL 集群，因此选择自己作为主节点。一旦 iPhone 加入，它接管主节点角色，iMac 采纳它。MacBook 运行与 iMac 相同的版本，因此，在发现 AWDL 集群后，它也采纳 iPhone 作为主节点。iPad 短暂采纳现有主节点，但随后立即接管此角色，因为它选择了比 iPhone 更高的自我度量：图 10 显示了每个节点随时间变化的当前自我度量。我们展示了初始值 60 和不同 AWDL 版本的实现范围。最后，所有节点依次离开集群（关闭 Wi-Fi），直到只剩下 MacBook。由于 iMac 和 MacBook 运行较旧版本的 AWDL，它们仅在集群中没有较新版本时被选为主节点。

这些结果大部分是预期的。然而，有趣的是，已经存在的主节点节点可以被运行相同 AWDL 版本的另一个节点"超越"。这表明 Apple 的 AWDL 实现相当简单：每个节点仅保持初始自我度量很短的时间，然后从版本依赖的范围中选择更高的随机值，无论它是否找到了现有主节点。

同步精度

我们想要评估 AWDL 的主节点选举和同步机制的工作效果。为此，我们监控多个不同节点之间的 PSF 和 MIF 交换。我们运行了另一个较长时间（20 分钟）的空闲实验，使用三个节点。图 11 显示了每个节点广告的 AW 序列号。虽然图 11 表明同步在原则上有效（所有节点都遵循相同的 AW 序列号增长），但我们可以看到 AW 序列号步长并不完全对齐。我们对此同步偏移的大小感兴趣。我们调整公式 (1) 来计算从节点 S 与其主节点 M 之间的同步误差 ξ。假设恒定空中时间 tair，并给定来自 S 和 M 的两个 AF，在嗅探器上分别在时间 TRx^M 和 TRx^S 记录，且在同一 EAW 中具有序列号，我们计算 ξ 为：

ξ = TAW^M − TAW^S
  = (tAW^M − tAW^S) · 1024 − (tTx^M − tTx^S) + (TRx^M − TRx^S)

对于所有 iS, iM，满足 ⌊iS/p⌋ = ⌊iM/p⌋。

在图 12 中，我们可以看到同步误差近似服从高斯分布，平均值为 -0.45，标准差为 0.98。图 12 还显示，在超过 99% 的情况下，最大同步误差 3 TU 的目标被满足。

虽然结果在目标区域内，但相对较大的同步误差导致结论：每个 EAW 中只有一部分可以可靠地用于通信，3 TU 必须用作保护间隔。在数字上，这意味着只有 1 − 2·3 TU / 64 TU ≈ 90.6% 的间隔可用于通信。同步误差的主要来源在于传输延迟 tTx 的计算。公式 (1) 假设 TTx,PHY 在帧通过 Wi-Fi 无线电传输的时刻精确设置，并且额外的 DCF 回退已过期。然而，我们发现在 macOS 中，TTx,PHY 在创建 AF 后立即在驱动程序中设置，在 DCF 运行之前。我们没有分析其他操作系统的实现，但假设在类似位置完成。

信道活动

我们想要找出 AF 通常在何时传输。为此，我们再次考虑第 7.2 节中的空闲场景。图 13 显示了不同节点在 EAW 期间何时传输帧（MIF 和 PSF）。每个 bin 代表一个单独的 AW（16 TU）。我们注意到 MIF 大多在整个序列的第一半和第二半的开始发送。我们还注意到 MIF 和 PSF 的发送行为存在明显差异。虽然 MIF 传输遵循广告的信道序列，但 PSF 在任何时间发送。这可能是由于同步参数 TLV 中的 AF 周期（见图 6），该周期设置为 110 或 440 TU，不与覆盖一个信道序列的 64 个 AW 对齐。我们对这一设计决策没有确切的解释，但怀疑它可以加速尚未同步到主节点的新节点的引导。作为缺点，这意味着节点不能在非广告时隙中真正进入省电模式，而我们假设这是 AWDL 的核心设计目标之一。另一个有趣的方面是 PSF 由所有节点发送，无论它们是否为主节点。这是能源效率不是 AWDL 主要目标的另一个指标。否则，只有主节点和子主节点会发送 PSF。

图 13 还显示，PSF 构成了一定的基线"噪声"，而 MIF 特别在一个 EAW 的中间发送。图 14 "放大"并描绘了单个 EAW 内的信道活动。我们看到 MIF 活动聚集在中心周围，而 PSF 在整个 EAW 中以相等概率发送。我们认为 MIF 被认为更重要，因为它们包含比 PSF 更多的信息（见表 1），并且在 EAW 中间发送增加了节点接收传输的机会，即使它们不完全同步。

吞吐量和信道跳频

我们想要评估 AWDL 的信道跳频对 TCP 连接吞吐量的影响。不幸的是，Apple 丢弃直接绑定到 awdl0 接口的常规 TCP 和 UDP 服务器的数据包。这意味着立即运行诸如 iperf 之类的测量软件是不可能的。作为解决方案，我们通过 NSNetService API 构建了一个 AWDL-TCP 代理，该 API 将广告端口列入白名单。本质上，代理服务器通过 DNS-SD 广告服务并监听传入的 TCP 连接。代理客户端组件连接到它。两个代理端点还允许通过环回接口的 TCP 连接，使得常规 TCP 服务可以简单地连接到环回接口，并通过 NSNetService 连接转发 TCP 流量。代理工具可在相关仓库获取。

TCP 吞吐量。 我们使用 iperf 在三种不同节点（MacBook、iMac 和 AP）和六种不同设置中测量吞吐量：(1) 从 MacBook 到 AP 的单个连接，不带 AWDL；(2) 从 MacBook 到 iMac 通过 AWDL 的单个连接，不带 AP；(3) 两个并发连接作为 (1) 和 (2) 的组合，AP 在信道 44 上运行；(4) 如 (3) 但 AP 在信道 36 上运行；(5) 另一个测量，其中 iMac 充当 AP，以查看使用相同硬件的 AWDL 和 AP 连接之间可能的吞吐量差异；(6) 与 IEEE 802.11 IBSS 模式的比较。我们在图 15 中展示了结果。误差条表示标准差。仅 AWDL 和仅 AP（iMac）设置产生相似的吞吐量，表明带宽仅受通信节点硬件能力的限制。请注意，仅 IBSS（iMac）设置比前两个设置性能低 10-12%：我们观察到 macOS 上 IBSS 的 MCS 选择机制不稳定，即使信噪比很高也不总是选择最大支持值。APU 中的 Qualcomm Wi-Fi 芯片仅支持两个流，因此最大带宽减少约 30%。当 AP 在信道 44（相同）上运行时，累积吞吐量与仅 AP 设置的吞吐量相似，而两个连接之间的带宽均匀分布。当 AP 在不同信道上运行时，累积吞吐量下降约 13%。这证实了直观的假设，即信道切换对吞吐量有负面影响。我们惊讶地发现带宽不再在两个流之间均匀分布。相反，AWDL 具有更高的吞吐量，这可能是由于 AWDL 使用所有三个可用流。

信道跳频。 我们发现 AWDL 根据接口上的流量量调整其信道序列。当没有流量时（如空闲场景），AWDL 分配至少 25% 的信道序列给社交信道（见图 13 中的时隙 1、9、10 和 11）。随着负载增加，AWDL 可能将所有 EAW 分配给自己。我们在表 2 中描述了各种信道分配状态。表格显示：(1) 至少 25% 的时间分配给 AWDL（低功耗状态），(2) 在时隙 9 总是切换到信道 6，可能是为了向后兼容，(3) 如果节点连接到 AP，则至少 25% 的时间保留给 AP 连接。在我们的吞吐量实验中，数据或数据+基础设施（50%）状态处于活动状态。

Experimental Analysis

We analyze the runtime behavior of AWDL in different scenarios to (i) validate our findings of the previous sections and (ii) assess the performance of the protocol. First, we describe our test setup. Then, we look at the master election and synchronization accuracy in an idle scenario without data transmissions. We further analyze the channel hopping behavior and throughput performance.

Test Setup

Our test setup consists of one monitoring device and a number of Apple devices. Our monitor device is an APU board equipped with two Qualcomm Atheros QCA9882 Wi-Fi cards to support simultaneous sniffing on two different channels which are tuned to AWDL’s primary (44) and secondary (6) channel. Both Wi-Fi cards support hardware timestamping which mitigates variable delays in the receiver’s OS stack. To synchronize the internal clocks of the sniffing Wi-Fi chips, we start each experiment with a calibration phase: we tune both chips to a common channel and let them record multiple frames. Post-experiment, we calculate the timestamp difference of frames that were received by both cards. We use the median difference to correct the clock offset and align both traces. All following experiments were conducted inside a Faraday tent to minimize interference. Our test devices include an iPhone 8 (iOS 11.2.2), an iPad Pro 10.5" (iOS 11.0.3), an iMac (Late 2012, macOS 10.12.6), and a MacBook Pro (Late 2015, macOS 10.12.6).

Master Election

In our first experiment, we analyze the master election process. We observe an AWDL cluster in an idle state, meaning that no data transmission takes place and the only observed frames are AFs. We use a setup consisting of an iPhone, iPad, iMac, and MacBook. We activate the AWDL interface by selecting the sharing panel in one device which causes a BLE scan and activates the AWDL interface of other devices in range (on iOS, this only works if the device is unlocked). To get more interesting results, we let the different devices join approximately 30 s after one another.

Figure 9 shows the currently selected master of each node. First, the iMac creates the AWDL cluster and consequently selects itself as the master. As soon as the iPhone joins, it takes over the master role, and the iMac adopts it. The MacBook runs the same version as the iMac and, thus, after having discovered the AWDL cluster, it also adopts the iPhone as the master node. The iPad briefly adopts the existing master, but then immediately takes over this role as it selects a higher self metric than the iPhone: Fig. 10 shows the current self metric of each node over time. We show the initial value of 60 and the implemented ranges for the different versions of AWDL. Finally, all nodes successively leave the cluster (Wi-Fi turned off) until only the MacBook remains. Since the iMac and the MacBook run an older version of AWDL, they are only selected as master if none of the newer versions are present in the cluster.

Most of these results were expected. What is interesting, however, is that an already existing master node can be “overtaken” by another node running the same version of AWDL. This indicates that Apple’s AWDL implementation is rather simplistic: each node keeps the initial self metric only for a short period of time and then selects a higher random value from the version-dependant range irrespective of whether it has found an existing master or not.

Synchronization-to-Master Accuracy

We want to evaluate how well AWDL’s master election and synchronization mechanism work. To this end, we monitor the PSF and MIF exchanges between a number of different nodes. We run another idle experiment over a longer period of time (20 min) with three nodes. Figure 11 shows the AW sequence number each node advertises. While Fig. 11 indicates that synchronization works in principle (all nodes follow the same AW sequence number incline), we can see that the AW sequence number steps are not perfectly aligned. We are interested in the magnitude of this synchronization offset. We adapt Eq. (1) to compute the synchronization error ξ between a slave S and its master M. Assuming a constant airtime tair and given two AFs from S and M with a sequence number in the same EAW recorded at the sniffer at time TRx^M and TRx^S, respectively, we calculate ξ as:

ξ = TAW^M − TAW^S
  = (tAW^M − tAW^S) · 1024 − (tTx^M − tTx^S) + (TRx^M − TRx^S)

for all iS, iM with ⌊iS/p⌋ = ⌊iM/p⌋.

In Fig. 12, we can see that the synchronization error approximates a Gaussian distribution with a mean value of -0.45, and a standard deviation of 0.98. Figure 12 also shows that the target maximum synchronization error of 3 TUs is met in more than 99% of all cases.

While the results are within the target region, the relatively large synchronization error leads to the conclusion that only a portion of each EAW can reliably be used for communication and the 3 TUs have to be used as a guard interval. In numbers, this means that only 1 − 2·3 TU / 64 TU ≈ 90.6% of the interval can be used for communication. The main source of synchronization error lies in the calculation of the transmission delay tTx. Equation (1) assumes that TTx,PHY is set exactly at the moment when the frame is being transmitted via the Wi-Fi radio after the frame has already been enqueued and additional DCF back-offs have expired. However, we have found that in macOS, TTx,PHY is set in the driver right after the AF is created and before DCF has been run. We did not analyze the implementation for other OSes but assume that this is done at a similar location.

Channel Activity

We want to find out when AFs are usually transmitted. For this, we consider the idle scenario from Section 7.2 again. Figure 13 shows when frames (MIF and PSF) are transmitted during an EAW by the different nodes. Each bin represents a single AW (16 TU). We notice that MIFs are mostly sent at the beginning of the first and second half of the entire sequence. We also notice that there is a distinct difference in the sending behavior of MIFs and PSFs. While MIF transmissions adhere to the advertised channel sequence, PSFs are sent at any time. This is probably due to the AF period in the Synchronization Parameters TLV (see Fig. 6) which is either set to 110 or 440 TU and does not align with the 64 AWs that cover one channel sequence. We do not have a solid explanation for this design decision but suspect that it could accelerate the bootstrapping of new nodes which have not yet synchronized to a master node. As a downside, this means that nodes cannot really go to a power-conserving mode in a non-advertised slot, which we assumed to be one of the core design goals of AWDL. Another interesting aspect is that PSFs are sent by all nodes, no matter if they are master or not. This is another indicator that energy efficiency was not a primary goal of AWDL. Otherwise, only the master and sub-masters would send PSFs.

Figure 13 also shows that the PSFs constitute a certain baseline “noise,” while the MIFs are sent especially during the middle of one EAW. Figure 14 “zooms in” and depicts the channel activity within a single EAW. We see that MIF activity is clustered around the center, while PSFs are sent with equal probability over the entire EAW. We think that MIFs are considered more important since they contain more information than PSFs (see Table 1) and sending in the middle of an EAW increases the chance that a node receives a transmission even if they are not perfectly synchronized.

Throughput and Channel Hopping

We want to evaluate the impact of AWDL’s channel hopping on the throughput of a TCP connection. Unfortunately, Apple drops packets for regular TCP and UDP servers that directly bind to the awdl0 interface. This meant that running measurement software such as iperf was not immediately possible. As a solution, we built an AWDL–TCP proxy via the NSNetService API which whitelists the advertised port. In essence, the proxy server advertises a service via DNS-SD and listens for incoming TCP connections. The proxy client component connects to it. Both proxy endpoints also allow TCP connections via the loopback interface such that regular TCP services can simply connect to the loopback interface, and forward the TCP traffic via the NSNetService connection. The proxy tool is available at the related repository.

TCP Throughput. We measure the throughput with iperf using three different nodes (MacBook, iMac, and an AP) in six different settings: (1) a single connection from MacBook to the AP without AWDL; (2) a single connection from MacBook to iMac via AWDL without the AP; (3) two concurrent connections as a combination of (1) and (2), while the AP operates on channel 44; (4) as (3) but the AP operates on channel 36; (5) another measurement where the iMac acts as the AP to see possible throughput differences between an AWDL and an AP connection using the same hardware; (6) a comparison to IEEE 802.11 IBSS mode. We show the results in Fig. 15. The error bars indicate the standard deviation. The only AWDL and only AP (iMac) settings result in similar throughput demonstrating that bandwidth is only limited by the hardware capabilities of the communicating nodes. Note that the only IBSS (iMac) setting performs 10–12% worse than the previous two settings: we observed that the MCS selection mechanism for IBSS on macOS is erratic and does not always choose the maximum supported values even when the signal-to-noise ratio is high. The Qualcomm Wi-Fi chips in the APU only support two streams, so the maximum bandwidth is reduced by approximately 30%. The cumulative throughput when the AP operates on channel 44 (same) is similar to the throughput of the only AP setting while the bandwidth between the two connections is uniformly distributed. When the AP operates on a different channel, the cumulative throughput drops by about 13%. This confirms the intuitive assumption that channel switching affects throughput negatively. We are surprised to see that the bandwidth is no longer uniformly distributed between the two streams. Instead, AWDL has a higher throughput which could be caused by AWDL resorting to using all three available streams.

Channel Hopping. We found that AWDL adopts its channel sequence according to the traffic volume on the interface. When there is no traffic (such as in the idle scenario), AWDL allocates at least 25% of the channel sequence to the social channels (see slots 1, 9, 10, and 11 in Fig. 13). As the load increases, AWDL may allocate all EAWs for itself. We depict the various channel allocation states in Table 2. The table shows that (1) at least 25% of the time is allocated for AWDL (low power state), (2) there is always a switch to channel 6 in slot 9 possibly for backward compatibility, and (3) at least 25% of the time is reserved for the AP connection if the node is connected to an AP. In our throughput experiment, either the data or the data+infra (50%) state was active.

讨论

在本节中，我们讨论 AWDL 的复杂性和开销、能源效率，并对 AWDL 及其操作系统集成进行初步安全评估。

复杂性和开销

AWDL 具有复杂的协议定义，支持使用 AW 和 EW 的各种配置。我们惊讶地发现，Apple 采用了静态且相对简单的配置，使复杂的概念变得过时。此外，我们发现了大量冗余信息，使 AWDL AF 的大小膨胀。

（扩展）可用性窗口。 在当前操作系统中实现的 AWDL 允许高度可配置的操作配置（参见图 6 中的同步参数 TLV）。然而，所有当前实现使用固定的信道序列长度 16，并且不区分 AW 和 EW，而是专门使用更长的 EAW（比较图 7）。Apple 偏好 EAW 的原因可能与 Wi-Fi 芯片中执行信道切换操作所需的时间有关。我们发现使用 wl 工具的 dump chanswitch，信道切换操作至少需要 8 ms（≈ 8 TU）。结合为应对 3 TU 可接受同步误差所必需的保护间隔，假设 EW 保留用于节能睡眠状态，这将仅留下 2 TU 的空中时间用于通信。当使用 EAW 时，时间效率从约 12.5% 增加到超过 78%，同时牺牲了节省能源的机会。我们在图 16 中可视化了这一差异。

冗余。 AWDL AF 包含冗余信息，例如当前主节点地址在同步参数、选举参数和选举参数 v2 TLV 中都有公告。服务响应参数 TLV 通常多次编码相同信息，例如 AirDrop 活动时，服务实例字符串和设备名称在单个帧中出现三次。

能源效率

我们的工作假设是能源效率是 AWDL 的主要设计目标之一（比较第 4 节）。从实验分析中获得的见解不支持这一假设。我们发现，即使在所谓的低功耗状态下，AWDL 也有至少 25% 的时间 Wi-Fi 芯片处于活动状态。此外，所有节点而不仅仅是主节点发送 PSF。我们怀疑能源效率被牺牲以换取更可靠的操作：独占使用长 EAW 使系统对同步误差更具鲁棒性。由于所有节点都发送 PSF，新节点可以更快地发现现有的 AWDL 集群。

安全性

AWDL 连接完全不受保护。然而，Apple 采用默认包过滤器，防止服务意外监听 AWDL 接口。我们还发现并报告了 macOS 驱动程序接口中的一个漏洞。

开放的 AWDL 连接。 我们发现 AWDL 连接不具备任何安全机制。所有操作帧和数据帧都以明文发送，无需认证。AWDL 将安全功能委托给传输层和应用层，例如 AirDrop 使用 TLS 1.2。这种方法似乎是实施应用依赖策略的明智决策：设备可能被信任通过 AirDrop 发送图像文件，但不能远程控制 Keynote 演示。

默认包过滤器。 虽然 AWDL 连接可以被认为是不安全的，但 Apple 确保其他服务（如文件共享）不会通过 awdl0 接口广告，否则将可被未经认证的附近攻击者访问。开发者需要显式使用专用 API（例如 NSNetService）来选择使用 AWDL，我们正是这样实现 TCP 代理的。包过滤器显然不是标准 macOS 防火墙的一部分，而可能是在 NSNetService 中实现的。此外，awdl0 接口仅在需要时激活，一旦不再注册流量就停用，从而最小化攻击的时间窗口。这可能被视为一种"意外"的安全机制，因为超时的主要原因可能是节能。

易受攻击的驱动程序接口。 第 3.1 节中描述的 ioctl 接口，特别是包括用于 Broadcom wl 工具的卡特定命令，可能被 macOS 上的任何本地用户使用。该问题于 2017 年 7 月 19 日报告给 Apple，并被分配 CVE-2017-13886。Apple 于 2017 年 12 月 6 日修复了此问题，并于 2018 年 5 月 2 日发布了 CVE 条目。

Discussion

In this section, we discuss AWDL complexity and overhead, energy efficiency, and conduct an initial security assessment of AWDL and its OS integration.

Complexity and Overhead

AWDL has a complex protocol definition that supports various configurations using AWs and EWs. We were surprised to see that Apple settled for a static and rather simple configuration, making the complex concepts obsolete. In addition, we found a lot of redundant information that bloats the size of the AWDL AFs.

(Extended) Availability Windows. AWDL, as implemented in current OSes, allows for highly configurable operation configurations (see Synchronization Parameters TLV in Fig. 6). However, all current implementations use a fixed channel sequence length of 16 and do not differentiate between AWs and EWs but exclusively use the longer EAWs (compare Fig. 7). The reason why Apple prefers EAWs might have to do with the time that is required to perform a channel switch operation in the Wi-Fi chip. We found that a channel switch operation takes at least 8 ms (≈ 8 TU) using dump chanswitch of the wl utility. In combination with a guard interval that is necessary to cope with the accepted synchronization error of 3 TU, this would leave only 2 TU airtime for communication assuming that the EWs are reserved for an energy conserving sleep state. When using EAWs, the temporal efficiency increases from about 12.5% to more than 78% while sacrificing opportunities to save energy. We visualize this difference in Fig. 16.

Redundancy. AWDL AFs contain redundant information such as the current master address which is announced in the Synchronization Parameters, Election Parameters, and Election Parameters v2 TLVs. The Service Response Parameters TLV often encodes the same information multiple times such that the service instance string and device name can be seen three times in a single frame when AirDrop is active.

Energy Efficiency

Our working hypothesis was that energy efficiency was one of the primary design goals of AWDL (compare Section 4). The insights obtained from our experimental analysis do not support this hypothesis. We have found that even in the so-called low power state, AWDL is active for at least 25% of the time during which the Wi-Fi chip is active. In addition, all nodes and not only the master send PSFs. We suspect that energy efficiency was sacrificed for a more reliable operation: the exclusive use of long EAWs makes the system more robust against synchronization error. As all nodes send PSFs, new nodes can discover an existing AWDL cluster faster.

Security

AWDL connections are completely unsecured. However, Apple employs a default packet filter that prevents services to listen on the AWDL interface accidentally. We further found and reported a vulnerability in the macOS driver interface.

Open AWDL Connection. We have found that AWDL connections do not feature any security mechanism. All action and data frames are sent in plain and without authentication. AWDL delegates security functions to the transport and application layer, e.g., AirDrop uses TLS 1.2. The approach appears to be an informed decision to implement application-dependant policies: a device might be trusted for sending an image file via AirDrop, but not for remote-controlling a Keynote presentation.

Default Packet Filter. While an AWDL connection can be considered insecure, Apple made sure that other services such as file sharing are not advertised via the awdl0 interface which would otherwise be accessible by unauthenticated nearby adversaries. Developers need to explicitly use a dedicated API (e.g., NSNetService) to opt-in for the use of AWDL which we did to implement our TCP proxy. The packet filter is apparently not part of the standard macOS firewall but probably implemented in NSNetService. Also, the awdl0 interface is activated only on demand and deactivated once no more traffic is registered, thus, minimizing the time window for an attack. This could be considered an “accidental” security mechanism because the main reason for the timeout was probably energy conservation.

Vulnerable Driver Interface. The ioctl interface described in Section 3.1, especially including the card-specific command used for the Broadcom wl utility, could be used by any local user on macOS. The issue was reported to Apple on July 19, 2017, and was assigned CVE-2017-13886. Apple has fixed this issue on December 6, 2017, and published the CVE entry on May 2, 2018.

结论

我们重建了 AWDL 的帧格式和操作，这是一个复杂的未公开协议，并以开源 Wireshark 解析器补充了我们的发现。我们认为，公开这种广泛使用的专有协议的公共知识对于协助无线网络运营商、允许独立安全审计以及激发应用层以下的创新和研究至关重要。我们实验评估了 AWDL，并表明同步精度平均约为 -0.45 ms。如果节点不主动使用基础设施网络，最大可实现吞吐量仅受设备支持的 PHY 数据速率的限制。当需要信道切换时，两个并发连接的累积吞吐量下降约 13%。我们发现了一个安全漏洞，允许任何本地用户访问 macOS Wi-Fi 驱动程序接口。鉴于最近可空中利用的 IEEE 802.11 实现，我们怀疑鉴于 AWDL 协议的复杂性，还有更多漏洞有待发现。作为未来工作，我们将致力于建立 AWDL 的能源模型，以了解在自组网通信应用中使用 AWDL 作为 BLE 或 IEEE 802.11 IBSS 的替代方案的影响。

Conclusion

We reconstructed the frame format and the operation of AWDL, a complex undocumented protocol and complemented our findings with an open source Wireshark dissector. We believe that public knowledge of such wide-spread proprietary protocols is vital to assist wireless network operators and to allow independent security audits as well as to stimulate innovation and research below the application layer. We experimentally evaluated AWDL and showed that the synchronization accuracy is about -0.45 ms on average. The maximum achievable throughput is only limited by the devices’ supported PHY data rates if the nodes are not actively using an infrastructure network. If channel switching is required, the cumulative throughput of two concurrent connections drops by about 13%. We have found a security bug which allowed any local user to access the macOS Wi-Fi driver interface. In the light of recent over-the-air exploitable IEEE 802.11 implementations, we suspect that there are even more vulnerabilities to be found given the complexity of the AWDL protocol. As future work, we will direct our efforts towards an energy model for AWDL to understand the implications when using AWDL as a drop-in replacement for BLE or IEEE 802.11 IBSS in ad hoc communication applications.