Apple’s AirDrop makes weird latency spikes for Wi-Fi wonks, researcher finds Networking researcher Christoff Visser has found that Apple devices cause Wi-Fi networks to “jitter” due to traffic generated by the Apple Wireless Direct Link (AWDL) tech that powers the peer-to-peer AirDrop filesharing tool. Visser presented his findings on Tuesday at the RIPE 91 conference, the biannual internetworking …
Although this isn't and probably won't be an issue for a lot of the users of the Apple ecosystem right now, this is another example of where a vendor has decided that 'they know best' and are deliberately ignoring a users own preferences, causing an unnecessary issue and making the user experience worse. Mind you, Apple will say this isn't their fault, you've just configured your WiFi network wrong.
I have never used AirDrop, but I don't have a Mac. However it is Apple's "wifi direct" protocol that is doing this, which does more than just AirDrop. It also does screen mirroring, and I have used that on occasion to mirror my iPhone's screen to my Apple TV, and thereby onto the TV my Apple TV is connected to.
Or they build a channel list with the number of APs per channel, sort it, and instead of picking the channel with the least number of APs they pick the channel with the most because the sort order is back to front to what is expected elsewhere in the code or the wrong end of the array is picked...
.... to WiFi distortion field.
Apple engineers have a very strange idea of WiFi - there are multipe channels for a good reason, and there are advanced APs that can change channel dinamically to work on the less crowded one.
Also, on 2.4Ghz using the channel "everybody else" use is even worse.
That's not really a bug, just a missing feature/odd design decision.
Airdrop is a P2P connection using Apple Wireless Direct Link (AWDL), so it sets up a direct connection from a virtual network interface on the wifi modem (and on bluetooth). It doesn't use your actual network connection, but essentially a modified WiFi Direct connection.
I find this quite odd, considering AirPlay does work using both AWDL and regular networking (mDNS discovery, if i'm not mistaken).
It is an advantage that you don't need to be on the same network, but having the option to use your regular network would be a huge improvement.
More information can be found on the Open Wireless Link (OWL) Wiki, they reverse-engineered the AWDL protocol. In the table, the AP column also includes ethernet links if i'm not mistaken.
Nah, they're holding it wrong.
When I dock my laptop it goes onto wired ethernet, because that's better than wireless (it just is, don't try to tell me otherwise). Recently (as in last one or two major upgrades, I didn't really take note, it worked just fine for the previous 20 years) Safari gets the hump when both wifi and wired are up. Some apps seem to keep working just fine, I think terminal is ok, but Safari very definitely just spins its wheels. Don't even get a "you're not on the internet" message, pages just act like they are taking infinite time to load. Turn off wifi and it immediately starts working again, don't even need to press reload. If you're not ready for it then you start suspecting all sorts of crap for having blown up. Later you decide you want to airdrop something from your phone and are confused as to why the laptop doesn't appear as a target... Its a very sucky experience.
If AirDrop is indeed using BLE to 'listen' is it possible this latency isn't actually due to a WiFi channel switch but to going quiet whilst it listens on Bluetooth for other devices? The article isn't clear on this subtle distinction but it'd make sense.
In other words the scenario could be:
1. Every X milliseconds listen for announcements over Bluetooth
2. To ensure no local interference pause Wifi transmissions whilst listening
3. If needing to send via AirDrop transmit announcement over Bluetooth
4. If AWDL announcement or destination device detected switch Wifi to channel 6 and start talking
5. Resume normal Wifi activity
If you tcpdump the awdl0 interface on a Mac, you'll see periodic mdns advertisements from the local machine and other devices as soon as you pull up a share sheet that has the option to Airdrop on any device. You don't actually have to initiate Airdrop, this is how nearby devices show up as Airdrop targets.
If I turn BT off on my Mac, AWDL shuts down and I can see awdl0 leave the IPV6 multicast group. That interface stays absolutely silent even after turning BT back on... until something might want to Airdrop at which point it wakes up, joins the group, sends out mdns. If I let it sit long enough (about a minute) it will go silent again.
It seems AWDL's wifi component goes to sleep if not used until a BLE ping wakes it up. So if you're seeing wifi latency caused by AWDL taking over the radio, that could be due to other devices preparing to Airdrop, even if you don't actually do it.
That it causes 25 ms of latency. Switching channels for a moment shouldn't give you that big of a hit.
If this isn't some sort of bug and they don't fix it in another way now that they are designing their own wifi chips they could at least fix it in future iPhones/Macs by having it able to "check in" with the WifiDirect channel while simultaneously maintaining a connection on whatever channel your local wifi is using.
.. has anyone actually informed Apple (or at least tried to)?
For me that is a logical first step - if you find something that doesn't sit well with business infrastructure, go talk to the provider. I see no report of even an attempt at communication with Apple which, when not succesful, would then give rise to publication. I call that responsible discovery, akin to responsible disclosure.
Putting your findings on the internet IS informing Apple in the best way possible. Apple's PR department finding out about a bug that harms their image will get the issue addressed far sooner than an easily ignored quiet word to the engineering department that hasn't been allocated sufficient budget to test for bugs.
I had this issue with steam streaming (and moonlight) on wifi a couple a years back, and with help of google found the advice to bind my router wifi to the AWDL channel.
the situation made no sense where my steam deck gen 1 with shit wifi ran more stable than a newer mac with a better wifi chip.
setting the router to the admittedly already crowded channel was transformative for me - Apple levels of "it just works" when bending over backward to make it; hopefully i didnt crush my neighbors network(s)
/ i thought this was a known issue? should have i complained louder then?
So he wants to use a social service where you have to be on the channels that everyone else is on? But he wants to pick those channels that everyone else is on himself.
I really don't see the possible options here except what he said: don't use the service, use the service and allow it to occasionally check the "social" channels, or use the service and use the social channels yourself.
What other option is there? "I get to pick the social channels!" ? "I chose my channels, don't switch, and when airdrop doesn't see things being shared I'll bitch!" ? "Apple hardware *must* include a dedicated radio for this occasional service because 25ms over wifi is everything!!!" ?
>What other option is there? <
Changing the way the "social channel" work, e.g. having the device joining an ip multcast group which should be transparent to the WiFi part of the net and doesn't require to drop out of the user assigned frequency to monitor channels selected by Apple.
Not sure if that would work for this specific service as i am using option 1 (don't use the service).
Your average user will not be able to figure out why less used channels aren't working properly for streaming and will not be aware of the option to fix it by disabling a service they might not be using consciously. Apple should at least communicate more proactively that this is happening when the service is running if even network researcher are surprised by it.
This isn't technically possible.
You have a network cable running to the server closet, and you have a different cable running to the guest network router. You plug one device into one, another device into the other -- why can't they talk to each other?! They're in the same multicast group! --- but they're not on the same network, and aren't sharing a router.
Being on a different channel is being on a different network. Airdrop is peer-to-peer, there's no router or centralized point in between. Making it multicast is unrelated - it means that the central switch (not present?) will send the traffic to the correct ports/clients as needed, having received only one message from a source, as opposed to the source needing to repeat the message once for each receiver.
From the description, it's as though airdrop is using ad-hoc wifi - no wireless router necessary or used.
Umm, piss off Apple. I use a wifi analyzer and use channels that aren't impeded on by neighbouring wifi networks and I wouldn't appreciate that impedance. I'm pretty fussy about that. Moreover, my personal AP uses a different channel (along with attenuated TX power so it only covers my office) than the main wifi network. This is important configuration Apple is trying to dictate.
Nobody here uses Apple products, only visitors, and nobody is going to be air dropping anything or dropping "air print" jobs anyway, though. The printers (we buy Brother laser printers nowadays) are connected to ethernet with static IPs and have their wifi radios turned off. It's just the principle of the matter here that irks me.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
