MRMCD2026 - Trespassing the Walled Garden: Teaching Linux to Speak Apple's Low-Latency WiFi

A warm welcome from my side to this last slot at MMCD 26. [snorts] This talk is titled trespassing the world garden teaching Linux to speak Apple's low latency Wi-Fi. Before we begin talking about this link layer protocol, a quick note on myself. I'm a PhD student at the House of Platner Institute in Potam and I'm researching at the chair of Hiska Classen um at the chair of mobile and wireless security. Besides that, I'm a fellow researcher at OpenUAS. We publish information, give conferences and webinars on European and German cyber security regulation. So if you know anything about UNUNIS tour or UCR, UNCCCS, all of these European directives, then visiting our website might be a worthwhile thing to do. Last year in December 2025, I already gave a talk on the internals of low latency Wi-Fi and which concepts are making it a low latency protocol. The question that arose after this talk was of course how do we bring this knowledge now to open platforms and how we can can we reimplement this protocol in order to enable people using Linux for instance to use low latency Wi-Fi. Now before we begin elaborating on this question, let me give you a short recap about what low latency Wi-Fi actually is. So suppose you own an iPhone or an iPad and a Mac. Then in the Apple ecosystem, you can do a bunch of cool stuff like mirroring your um Mac screen to an iPad and use it as an external monitor. You can also use your mouse and keyboard input in order to remote control your iPad from the keyboard input attached to your Mac. If you own an iPhone, you can use your iPhone's camera with continuity camera as a webcam on your Mac. And with iPhone mirroring, you can remote control your iPhone that is out of proximity from your Mac. Now all of these features mostly transmit video data. They operate under real-time constraints and they use this link layer protocol called low latency Wi-Fi. low latency Wi-Fi in this deck here as I've just mentioned is located on the link layer and therefore deals with some concepts we already know from the ITLE E 80211 amendments E N and AC and to give you a quick oversight of um what these concepts are about I would like to elaborate more on the enhanced distributed channel Access EDCA classifies network traffic into four different access categories and from background to [snorts] voice network traffic the priority for channel access ascends. So low latency Wi-Fi yeah uses this access category with the highest priority for channel access which makes it very fast on a technical level. This um works as follows. So suppose your device has control frames available and um needs to send them over the medium. Uh what it does is it waits for a very short amount of time for a short interframe spacing and um yeah starting from when the medium becomes idle and once this duration elapses it can send for instance acknowledgement frames. Now, in case your device has voice traffic available in the queue, it doesn't just wait for this very short um short interframe spacing, but for an arbitration interframe spacing, which is the short interframe spacing plus two more slots. Once this AFS elapses, it elaborates um and checks if the medium is still idle and then initiates a random backoff timer. This is needed because other devices on the network could of course also have uh voice traffic cued and if devices would then immediately start sending data um they would um collide on the medium and uh the data would be corrupted. So this is why we need these random backoff timers um to be initialized and yeah once the um timer there elapses and the medium is still idle the device can then start sending data on the mech layer for as long as a transmission opportunity allows it to send. Now the these parameters the AFS the back the random backoff timer and the transmission opportunity are all very specific to the access categories in ITLE E 80211E. And when we compare the parameters across all of the different access category is it becomes clear that the traffic in the access category voice has uh the shortest duration until it can send traffic at least on average and therefore it also gains uh the channel access fastest on average. Low latency Wi-Fi complies with these parameters as it turns out and in newer revisions it could also send data for longer. However, this is currently not used in recent implementations. There are of course a couple of different other concepts from the ILE ED211 standards. I won't cover them here now but if you are interested in them feel free and go ahead and watch my talk from 39C3. I would like to highlight one more uh hardware capability that low latency Wi-Fi builds upon and this is called real simultaneous dualband. This allows devices to establish on the link layer two separate links on two dedicated frequency bands. So devices um your device could have one um link to your access point for regular Wi-Fi communication and then another one um for communication um with with another peer device that uses uh low latency Wi-Fi. The question of course is how do we configure the wireless chip on a Linux device so that it uses RSDB and all these different concepts um from the ITE E211 standards such as EDCA and the journey here begins by identifying suitable trace points on Mac OS in order to trace the communication between Mac OS and the firmware which which we want to know more about. Now with a little bit of knowledge of how Mac OS is structured, we can very quickly identify what we need to trace exactly in this operating system. In user space, we have a bunch of different binaries that for instance implement uh the application layer of sidecar display. And these binaries call into a data structure called the dwaret cache which contains a lot of frameworks. Frameworks that for instance can also handle network related tasks and frameworks that call then into the kernel cache into the kernel space. In recent Mac OS implementations, the network stack has moved out of the kernel space into a dedicated domain in user space. And this is the part that is very interesting for us when we want to trace the communication with wireless chips. So this driver kit process is not only um responsible for managing interfaces and cues and it e211 concepts and states but it is also responsible for configuring wireless chips. The great advantage here is that the driver kit process is a user space process which enables us to attach it to any regular debugger like LLDB which in turn is much more flexible than usual means of kernel debugging. So using LLDB we can basically trace any address in this driver kit process we want and especially interesting here are functions that issue so-called IOAS IOS are um means of communication between an operating system and Broadcom wireless chips and we will take a look um at IOAS and how they work on a technical level in just a second but I think you get the basic idea um of how we can now trace the communication between um Mac OS and the wireless chips on both the receiving side and the sending side during a sidecut play session just by attaching this process to a debugger like LLB. This already brings us to tracing wireless chip configuration. Very interesting here are as I already said the so-called IVAs. Iovas are basically just strings the host sends to the firmware attached and um appended by some payload and in combination with the string the firmware then knows what to do exactly and what to configure about its antennas. This IVA interface create is especially interesting here because by default wireless chips of course have one interface enabled by [snorts] default. For instance here um for communication with your access point. So on the operating system you would have then an interface and this interface would then be used by the chip um to accept data and send data to your access point. um using its internal interface. Interface create now creates a second interface of type two and type two tells the Broadcom chip that this interface is dedicated to AWDL and low latency Wi-Fi communication just because it's baked into the firmware. AWDL is another proprietary protocol by Apple that is used in features like um AirDrop. So this is a very special interface and it's explicitly created and on Mac OS you could access this um interface using interfaces like AWDL0 and LLW0 in order to send data to nearby Apple devices for instance. So as you can see AWDL and low latency Wi-Fi seem to be highly intertwined and not really distinguishable from each other at least when it come when it comes to the implementation in firmware. What happens on a technical level here is that Mac OS issues so-called message buff messages. There are two rings available for that so-called control rings. one for the submission side from the host to the firmware to the device and one in the opposite direction um which is called then the completion ring. So in case Mac OS has an IO over available um that should be transmitted to the firmware, it would just place a so-called um I octal messages onto the control submission ring, allocate a dedicated buffer where it places the IVA and its payload in the shared memory. The firmware then reads this Iova, creates the interface and informs the Mac OS host via the completion ring that the interface has been successfully created. As just mentioned, these control rings are used for um issuing I octals and Iovas and more. We will come to that later on. Another very interesting I over is HP2P. HP2P stands for high priority peer-to-peer. And as it appears, Google has leaked what HP2P actually does in um drivers and Broadcom drivers for the Android platform. And as you can see, HP2P seems to configure anything and everything what we know about the internal concepts of low latency Wi-Fi. So this is basically the IVA that configures what makes low latency Wi-Fi fast in firmware. As you can see, we have configuration parameters for the transmission opportunity length, the contention window or the random backoff timer and more frame aggregation mechanisms like AMDU and AMSDU uh which I talked about in my talk at uh 39C3. Of course, there are a bunch of other different IOS. The important takeaway here is that these IOAs help us learn what Mac OS teaches the firmware to do. And secondly, these IOAs build the foundation for bringing low latency Wi-Fi to Linux. Because in an ideal world, we would just take the communication we observed on Mac OS and replay it as it yeah as we observed it on Mac OS on Linux. However, Linux is a bit more complicated. There are different wireless chips. Even if Broadcom chips are installed on Linux systems, then um they might be different wireless chips. Different wireless chips in turn mean different firmware and different firmware means that there's probably no support for these priority proprietary IOS we just saw. So at this point this is a real road blocker. However, there's a solution to this which is called Azah Linux. Azah Linux has the great advantage that it runs on Apple hardware which makes it ideal for tracing IOS on the same platform where we also are testing our implementation for low latency Wi-Fi and Aahi Linux uses Mac OS's firmware and this enables us to really replay the Iova communication we saw on Mac OS under Linux and we can be sure about that the firmware that the wireless chip will accept and behave exactly as we observed it on Mac OS. For this purpose, we extended the Broadcom Fmec driver. Um, as you can see, there are dedicated files now for AWDL and low latency Wi-Fi files that hold the communication recorded under a Mac OS. I won't go into much further detail into how and which functions we added but I want to highlight one thing about um what we extended in the Broadcom driver the Broadcom fullme driver. So recall again that in um the communication between Mac OS and the firmware or now also on Linux there are so-called control rings used for configuring the wireless chip for instance for IO over communication but also to create data structures that are called flow rings. Flow rings also existed um previous to um our amendments. So flow rings are usually used um to transmit packet data. So once um user space wants the kernel to transmit packets, these packets and um data about these packets um sent to the wireless chip and the wireless chip then can transmit the packet data via its internal interface. Our implementation now adds more flow rings. Flow rings for the AWDL traffic and low latency Wi-Fi traffic. As you can see for low latency Wi-Fi there's only one flow ring a flow ring for the access category voice and for AWDL there are more flow rings as AWDL can also transmit traffic in other access categories. As you can see this one flow ring has in parentheses uh the T7. T stands for traffic identifier and these traffic identifiers map to the access categories we observed um in the um EDCI parameter set. So for instance um AWDL can transmit data that is um flagged with the traffic identifier 0 to six and low latency Wi-Fi is this protocol dedicated to the access category voice with the traffic identifier 7 and this is why there's only one flow ring um attached uh and linked with this traffic traffic identifier 7. Of course, there are more submission rings uh more completion rings from the firmware side. One uh transmission completion ring for confirming to the host that data was sent over the medium, one ring for informing the host that data is available for reception. And as it seems right now, there are dedicated rings for low latency Wi-Fi specifically um for transmission and reception. However, there is um these rings um we could only observe on Mac OS. On Linux, these rings are currently not used. rings. We also added uh rings for debug information because um this these rings were also leaked in the Google source code. So in essence, we add four very static completion and submission rings and flow rings that are allocated dynamically for AWDL traffic and low latency Wi-Fi traffic. Let's give you some examples for how sending and receiving traffic. now works for low latency Wi-Fi. So suppose user space has packet data available to be sent via the network. The packet therefore arrives at um kernel space is put into this shared memory flagged with the traffic identifier 7. The firmware then picks at first the um the host informs the firmware that data is available in the flow ring. Now the firmware then picks the packet data up, transmits it via the interface of index 2 and informs the host that the packet data was successfully sent. Receiving traffic is also quite straightforward. So when packet data arrives at the host uh at the firmware, the packet data is put into the shared memory and using the receive uh completion ring the host is um yeah informed that data is now available in shared memory and the formula also flags this packet data with more information. uh this information in this case is that the data was received via this second interface. This already helps the host to distinguish whether this is meant for access point communication or for communication via AWDL and low latency Wi-Fi. However, this information is not sufficient in order to make out whether this is meant for low latency Wi-Fi or AWDL specifically. And this is where the traffic identifier becomes important at the receiving side because using this traffic identifier 7 now um the device knows that incoming traffic is meant for low latency Wi-Fi and traffic with the traffic identifier um below 7 belongs to AWDL. To wrap this up a quick demo. So here we have um on the left hand side uh a device that listens for incoming Bluetooth low energy um messages. The devices therefore discover each other via Bluetooth low energy and uh the right hand side machine now runs um yeah a burst of ICMP packets via the interface for low latency Wi-Fi also one on uh AWDL0 for AWDL and as you can see the current performance in relatively quiet environments is that we get yeah a loss of um 3% of packets. So right now we have working uniccast and broadcast traffic for low latency Wi-Fi and AWDL with driver and kernel level support on Azahi Linux. And what's still ahead is that we want to bring interoperability between Azahi Linux and Apple platforms um for low latency Wi-Fi and AWDL. Of course, there needs to be um there yeah we need to make some adjustments to the um state machine on Linux currently because the setup is very static. So we want it to become more dynamic and adapt to the dynamic AWDL um state machine which is necessary in order to participate in master election that is done also on Mac devices. And of course, support for other Broadcom chips is desirable um but will probably not happen with firmware adjustments, but uh more likely using a softmack approach. We would like to thank the NLET Foundation for funding this project and if you have any input today, feel free to talk to me. Thanks. [applause] question. >> Thank you so much for this. Is there any attempt of doing this without portcom? >> Uh, currently not. >> Thanks. >> Yes. About these traffic identifiers, are they something specified by Apple or are they part of the >> They they are standardized. They are standardized in the le e211 standards. Yeah. >> So does any other uh any other device use these traffic identifiers? >> Yes. In case uh EDCA is used uh traffic identifiers are also used. Yes. >> They are part of the frame format. >> Are there further questions to the speaker? Uh you mentioned that you found some of the uh information you needed uh by um looking into the Android source code. Is this in any way related to the uh recent support for Airdrop in Quick Share? >> Um I don't know that exactly. So there are certainly references to AWDL as well um in the source code. But I guess as this um part of the code likely also comes from Broadcom because it's their driver for Android, it's probably just um that Broadcom put it in there and forgot to leave it out. That's my take. Yeah. >> Further questions. Um, while we're on the subject of reverse engineering things to make them compatible, um, do you also think like you maybe able to like stumble more easily into things related to supporting OWE on some Broadcom chipsets uh, on Linux? >> Owe opportunistic wireless encryption. >> Ah, okay. Um, I haven't looked into this, so uh, probably not. Thanks. further questions. So, thanks again for your contribution here and uh applause. [applause]