It makes shared clipboard not work as well with my iPhone, but at least I get 180Mbps/70ms on the work VPN instead of 4mbps/70-700ms.
The interface stays down till the laptop sleeps, so most of the time it's a no-op.
sudo /usr/libexec/airportd en0 prefs AWDLEnabled=YES
(Edit: see varenc's reply below)Or you could create a kext (using deprecated KPIs) that continuously blocks the interface from coming up:
errno_t awdlblock_ioctl_handler(void *cookie, ifnet_t interface, protocol_family_t protocol, unsigned long ioctl_cmd, void *ioctl_arg) {
if (SIOCSIFFLAGS == ioctl_cmd) {
struct ifreq *ifr = (struct ifreq*)ioctl_arg;
if (ifr && ((ifr->ifr_flags) & IFF_UP) != 0) {
return EJUSTRETURN;
}
}
return ENOTSUP;
}
kern_return_t awdlblock_start(kmod_info_t * ki, void *d)
{
struct iff_filter filter = { 0 };
errno_t err = ifnet_find_by_name("awdl0", &p_ifnet);
if (err) {
printf("interface awdl0 not found\n");
return KERN_SUCCESS;
}
filter.iff_name = "AWDLBlock";
filter.iff_ioctl = awdlblock_ioctl_handler;
iflt_attach(p_ifnet, &filter, &p_filter);
return KERN_SUCCESS;
}I was able to somewhat disable AWDL by doing this like you suggest:
sudo /usr/libexec/airportd en0 prefs AWDLEnabled=YES
And then restarting airportd so that it picks up the change: sudo launchctl kickstart -k system/com.apple.airportd
This worked without having to disable SIP and modify com.apple.airportd.plistIt doesn't take the awdl0 interface down, and I still see some traffic on it, but I can confirm that it disables some awdl features like "Unlock with Watch" and Screen Sharing over awdl. (Screen Sharing will work over your wifi network instead, but normally it'll prefer a direct awdl link)
> sudo /usr/libexec/airportd en0 prefs AWDLEnabled=YES
Wait, why AWDLEnabled = YES? Is it like with those Cisco routers, where "do X" was usually done by negating "do inverse-of-X"? E.g. "no interface up foo" to bring down interface "foo".
Also you can check what your current prefs by just not passing any args after `prefs`:
sudo /usr/libexec/airportd en0 prefsThat prevents it from doing any WiFi direct things, but otherwise would leave it functional.
Yes, Bonjour name resolution, which Screen Sharing uses, can also run over AWDL, but of course it does not have to.
There was a bug in OS X Yosemite and older versions of iOS which caused any AWDL activity to severely increase network jitter and latency; this sounds like a regression.
https://medium.com/@mariociabarra/wifried-ios-8-wifi-perform...
[1] https://owlink.org/wiki/ — note, not exhaustive ex: tethering also leverages awdl.
Intersting!
Starting a few weeks ago, I was screen sharing from a Monterey macbook to a Ventura Beta MacBook, using drag & drop to copy an app over for testing. Both macs were on WiFi. Worked great (~100MB/second).
But about every 5th time, the file transfer rate would drop from 100MB/S to under 100KB/S and stay there. No idea why.
I finally bought a USBC ethernet dongle and put both machines on Ethernet and the problem went away.
I'm now wondering if this is what I was seeing?
Edit to add: The WiFi is Peplink AP One Mini, in case vendor is relevant.
Here's an example of SOF solution: https://apple.stackexchange.com/a/413735
But if you search around the internet you will see different solutions proposed for it, none worked for me except for this script.
This popping up on HN gives me hope that next versions give you at least a tool to disable Wifi direct.
Note that setting AirDrop to "No One" doesn't fully disable awdl. It's used for other things like screen sharing, AirPlay, bonjour device/service discovery, etc. Though perhaps disabling AirPlay is enough to stop the WiFi issues. You can sniff awdl traffic with `sudo tcpdump -i awdl0`