I (used to) work in academic IT and I hate articles like this.
People would assume there is a serious problem, turn off a bunch of services, run a bunch of random-ass shell scripts, and then forget that they'd done all that and at some random point in the future discover that some feature wasn't working, and blame me.
I swear I really wish there were a way to output an entire OS's "diff" from default settings. Every preference pane, every terminal setting, every changed system file.
So that you could both discover, in cases like this, what's changed -- but also simply so you could export your settings in a space-efficient way and (selectively) re-import on a new OS install.
I don't know why people are dismissing this as non-viable or complex.
For example, a typical Windows deployment is 15-20GB after being extracted from an ISO image that's essentially static. There's monthly updates, which are also monolithic multi-GB patches that wholesale replace system files.
This is basically like a Docker image, but with the Kernel and drivers included in the base layer...
.. but without any of the niceties of dockerfiles, such as precisely tracking what differences have been applied!
The Windows registry could be split into a "system base hive", a "patch hive", and then a "customisations hive" on top.
Similarly, Linux filesystems could keep a base copy of the "/etc" directory and then any changes on top in something like a unionfs or docker image like overlayfs.
Modern phone operating systems more-or-less work like this, so it's definitely possible.
In the distant past of 40MB hard drives, this approach would have been wasteful. In the era of 5GB patches... does it really matter?
This is especially true on macOS Catalina or later with SIP enabled. The entire operating system is mounted read-only [1] and your local changes are effectively contained within your user directory.
Just an update for curious to bare windows OS size
9.0G Oct 27 06:54 win2016_core.qcow2
12G Oct 27 06:30 win2016.qcow2
7.4G Oct 27 06:31 win2019_core.qcow2
12G Oct 27 07:02 win2019.qcow2
6.9G Oct 27 07:03 win2022_core.qcow2
11G Oct 27 06:56 win2022.qcow2
This has gotta be some sort of HN meme at this point but... NixOS gives you this (with the tradeoff of course of a really steep learning curve and very opinionated packaging structure)!
Tbh in the hypothetical scenario where all of a company's configuration were handled via nix, you'd be staring at tens to hundreds of thousands of lines of company-custom .nix files where one single line might cause the bug you are encountering.
This reminds me of the general idea behind Tripwire[1] for macOS. I last looked into it back in 2005 (we went with other approaches), so it may have changed since then, but it monitors for changes, and allow you to revert them or deploy them to other computer (as in a lab, etc).
I compare previous to current settings using a pattern like this.
# backup defaults to a file in the home directory with the current timestamp
alias backup.defaults='defaults read > ~/.backups/defaults_$(date +%Y%m%d-%H%M%S).txt'
# compare the most recent defaults backup file to the current defaults config
alias diff.defaults='diff -u <(cat ~/.backups/$(ls -1 ~/.backups | grep defaults | tail -1)) <(defaults read) | delta'
This would be great. In principle, this should be a `diff -ur` of /etc against the default /etc of the OS. Some complications ensue as the user’s own dotfiles might override some things, too.
With regular snapshots you can at least eliminate new installed software as the root cause of an issue. Doesn't solve the issue with preferences though.
The amount of changes that your OS goes through (downloading applications, applications creating files, applications changing files) is too much to update on a diff file.
Although, for the major changes I feel the major OS's should add the ".diff" file called updates.diff and describe the major updates in your laptop.
This should also happen each update, we need to know what updates are going to be installed, and what is the purpose of doing this?
That's honestly the main thing that made me fully switch to Linux - I use a tool called aconfmgr to do (the equivalent of) that on Arch, or NixOS would be even better now that exists.
(The main or second main thing now would be window management, the period I was using both made me like i3 now sway more and more, and grow to find macOS even with yabai or similar much more difficult and messy to use.)
I just spent the last week diagnosing catastrophic Wi-Fi issues at a client location.
90% of macs wouldn’t connect to Wi-Fi, when they would association would take 45 seconds. Sometimes you couldn’t route or ping the gateway.
When you could you’d get disassociated within a minute. Turning off the airdrop/anirplay interface fixes it instantly.
sudo ifconfig awdl0 down
It took us 5 days to figure it out. We had no less than a dozen professionals on it. Each with at least a decade of experience. We combed the Wi-Fi and network config repeatedly to figure out what we did wrong. (It wasn’t till we had the hint that it was client side that we sniffed the nic to see the packet of death)
So I’m going to respectfully disagree. Articles like this are important. If I’d seen this last Monday it’d have saved me a week of hell and saved my client a week of vastly diminished productivity. Not to mention the tens of thousands of dollars spent diagnosing it and the millions of dollars of lost revenue from the deals they couldn’t close because calls kept dropping in the office (because enough people were on hotspots to saturate cell service in the area)
Information is important, but this post didn't have enough technical information about how to tell if this is your problem. How many people would say they haven't experienced “slow internet connection” or “drops in Zoom calls”? “entirely losing a WiFi connection” is less common but does that mean “it happened once and then it came back” or something like the hell you're describing.
That's important for the reasons the person you're responding to mentioned. I too have seen many problems caused by this kind of thing where someone had something they didn't like, made a ton of low-level config changes based on random blog posts, and then forgot about that when it broke something else.
We’ve seen this repeatedly across different types of spaces and have had teams spend similar amounts of time to get to know what’s going on underneath.
That script will be hanging around on people's laptops for years, if not decades (for people that migrate their macOS installations to new machines) at the end of the long tail.
This is a good point, we’ll make sure to update the post to note that the advice is no longer needed once Apple fixes things on their end. The script will get killed with a simple restart, so the odds of this hanging around are low.
For companies that decide to implement this or a similar solution using MDM,
`sudo pkill -f /tmp/disable_awdl.sh && sudo ifconfig awdl0 up` will also disable the effects of the script.
The problem is this is a real legit problem that I experience daily. I was having this issue where video and audio calls on my MacBook were degrading super badly. I’d reset the modem, I reset the router, reset everything.
Reconfigured everything I could. Nothing helped.
I ran a packet loss test online. Link below.
It was showing huge delays in packets.
I came across an article somewhere. Forget where now. Disabling the awdl0 interface fixed the issue entirely for me. Packet loss tests worked perfect every time.
Turn the interface back on? Problem reappeared immediately.
That said, I manually turn it on and off as needed and don’t set things up to disable all the time. But it’s a real issue that was causing me a great deal of problem at work. So it’s not just some bug to me. It’s a serious one and you seem to be saying it’s not and people turning it off and forgetting is a big deal. I suppose it could be but don’t reject that it does fix a real issue.
Including all the tech-savvy computer people with decades of experience, who figure the modern hardware and software has so many complex interactions that it's often better to try any plausibly looking solutions first, and only then figure out why it worked (or revert it if it didn't).
I mostly agree. But the article isn't the main problem, the sloppy script is. When I install such hot fixes, I have them check if the cause still exists (e.g. still running under Monterey?) and, additionally, add a timeout based on a date.
I messed with my Switch's netwotk settings based on a random Tweet some years ago for Smash, maybe something about packet size. So did a lot of other people. I wonder if I aught to clear that. Doesn't seem to hurt though.
From the first to the last day I worked in computer networking I encountered otherwise capable people who thought that if they randomly rebooted things… the problem was with the last thing they rebooted before “it worked again”.
It was an endless discussion about how restarting things can have second order effects, including impacting the equipment that really was the cause.
No-one should run these shell scripts unless they're 100% sure that they know what they're doing. The problem lies in the fact that anyone can run shell scripts which can break the OS or make the OS work.
Unfortunately, there's a very thin line between making it work and making it break.
Well then Apple shouldn't have shipped this bug then. Why blame individuals rather than the $2.3 trillion dollar corporation which can't get its act together.
People in the know are aware that this is just the tip of the iceberg with macOS bugs. Wifi bugs that everyone has to work around, APIs that promise Unicode NFC but aren't actually NFC, quadratic performance bugs caused by various always-on Apple services that trigger under mysterious circumstances, regressions every other minor version, the list goes on. Linux, which has orders of magnitude less money behind it, is somehow so much more robust.
But Apple won at capitalism, and the dream of most startup founders is to also win at capitalism, so this forum is filled with sycophants.
back in the day i used to support microsoft's ISA product (layer 7 firewall)
customers would just not know what configuration they had made.
so we had a bit of VBScript that would dump the entire config into a text file. amazing how many customers had left themselves open in bad ways in production systems and also how their perspectives of what was configured did or did not match reality.
That product was the worst. I remember they had a client that people wanted to install for some reason. In one case, the client would bypass some configuration that was supposedly critical and I got stuck in the middle of some crazy argument between security, network ops and support.
Their actual solution for disabling AWDL is running this script in the background:
while true; do
if ifconfig awdl0 |grep -q "<UP"; then
(set -x; ifconfig awdl0 down)
fi
sleep 1
done
That just checks the awld0 interface every second and turns it off if it's on. Apple really doesn't offer any other way to disable awdl?
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`
It appears the behavior has changed with Ventura. It now goes back active after a few seconds. I guess I will be doing something a bit more aggressive now.
This worked without having to disable SIP and modify com.apple.airportd.plist
It 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)
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".
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.
There unfortunately is not a way to disable awdl in the UI apart from disabling bluetooth as well, which most don’t want. An increasing number of Apple services leverage awdl[1], and it’s unlikely they envision anyone wanting to turn it off.
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.
Came here to say this. It's unfortunately not a new problem. I use Shadow Tech on my M1 Macbook to play windows games, and this has been bugging me ever since. The irony is that this problem is non-existent on old Macbook pros.
I stream at a pretty high bandwidth a remote system for gaming. I noticed this immediately. I disabled location sharing and it got a little better. I noticed that everytime my spouse started using his iPhone or opened his M2 Air to do something that my game stream seized. I guessed at something like this being the issue and disabled Airdrop. The problem immediately went away. I cursed about software quality in 2022 but also had a "HugOps" moment where, ... I get it. This stuff is hard stuff and most of the time I don't experience serious defects like this after upgrading OS X.
I still have an issue every now again and for whatever reason a reboot addresses it. I will ifconfig down the interface next time. I suspect that will resolve it.
That is absolutely the WRONG way to do this. You want people to download a shell script that then downloads another shell script, then runs that shell script via sudo? That second shell script could be changed at any time.
I was the IT manager for an all-Apple school, had just joined in 2014. First time overseeing that many users. New macOS and iOS versions came out. Hey guys, everyone can update! New versions out! Cool beans!
For half a year, it was WiFi and AirDrop hell. Update after update, it didn't matter, the issues were not being fixed. Finally, whichever update it was, fixed it 6 months later. I referred to it as the WiFi Apocalypse of 2014. After that, I always emailed everyone at the beginning of the school year to not install new versions of macOS and iOS when they came out. I would say that if they went against my recommendations and installed anyway, no guarantee that we'd be able to fix any problems they had, and this was their warning, so no complaining.
I would usually send an email about half a year later saying that people can update now if they like. I didn't care whether or not it looked fine within the first month or so. Never again. The WiFi Apocalypse of 2014 was hell. It's weird that this situation seems to be repeating itself.
I’ve been noticing this for a while. Both my laptop and my wife’s have this problem. Both are M1.
Both our iPhones seem to have similar issues.
I went mad trying to figure it out with my router/APs etc.
I was certain there is no way it could be Apple’s issue. But in hindsight this makes sense.
Especially so, if Apple is sharing some driver logic between M1 laptops and A16 SOCs on the phones.
Edit: I want to add that this most-noticably manifested as websites loading incompletely. Looking at the network tab, this would show some HTTP requests fail even before establishing a connection. Other requests were fine. So most sites were broken, or don't render correctly without css. Restart was the only fix.
More specifically, it tells your router to hold packets for a few milliseconds while it switches to another channel, then switches back and signals to resume sending. Unless you are saturating your wifi network from a single apple device this should nit be an issue.
AWDL has been around since, what, 2014? There may be new bugs but it’s hard to believe the principle stopped working as wifi got faster.
We have updated our post to make it easy to see the full source of the script involved, and we welcome PRs at https://github.com/meterup/awdl_wifi_scripts. We provide the curl command out of convenience, but we understand the trust that someone places in us when using this method. We’re also finding that IT teams are leveraging this script with tools like JAMF to address this for all of their company’s devices at once.
I really don’t like that the page asks users to blindly curl and execute a script that then curl and executes another script all to run a one line `ifconfig` command.
And a complication that is bad practice because a malicious party can detect the blind handoff to shell and serve malware.
e.g.
wget file.sh ; vi file.sh
and you get safe code
curl file.sh | bash
and you get malware.
This attack requires a malicious server, but it’s still bad practice.
I do encounter weird Wi-Fi issues on my M1 Pro MacBook Pro.
Not sure if it is related to this bug.
Sometimes I am just unable to load any web pages, but I can ping those sites. I have to reboot it regularly to reconnect to the internet. The issue is most likely to occur after waking from sleep.
The issue is so bad that I have to fall back to a Hackintosh at home. I originally was using an Intel-based WiFi card is great; later, I switched to a Broadcom card to enable handoff / AirDrop / AirPlay. After switching, it seems to degrade internet stability. The symptom seems like it has something to do with awdl0, so it might get helped from the post.
All my Windows computers work with no issues on the same network. I followed some instructions online to change the MTU [1] it seems to fix the issue somewhat.
This symptom was occurring to me because I was on a network with a Pi-Hole, had Safari's "Hide IP address from trackers" on (which I think uses the iCloud Private Relay to get some resources usually delivered by CDNs that track), but the Pi-Hole was configured with the 'BLOCK_ICLOUD_PR' option on. Safari would just hand when it attempted to get those resources.
> Sometimes I am just unable to load any web pages, but I can ping those sites. I have to reboot it regularly to reconnect to the internet. The issue is most likely to occur after waking from sleep.
I had that issue quite regularly on Windows and Linux back in the day, never figured out what the cause was.
I really really really wish that Apple would always use DHCP and get an open IP instead of assuming their last one is still good just so they can say they connect to WiFi 100 ms faster than anyone else. It is so infuriating and causes all the devices in my house to fight for their rightful slot.
Why are they fighting? Why is your router aggressively reusing the IPs as soon as the lease expires?
In my house, all of my devices end up with pretty stable IPs (even non-Apple ones) and I haven't done anything special to configure this. I assume my router holds onto previously-assigned IPs in case the device comes back as long as there's still unassigned IPs available to give out to new devices, though I haven't investigated it.
Clients will usually request their previous IP in the request, and servers will often prefer to give clients their previous IP even if they don't request it. It's also pretty common that the client still has a valid lease (as far as the server is concerned), which it makes sense for the server to reissue.
Is this true? I hadn't even noticed, because I assign every device a static DHCP assignment so I can categorize devices numerically. That is really messed up, and akin to what Google does with TCP/HTTP for connections to google.com in order to ensure it gets first byte faster. Companies are doing all sorts of "performance hacks" that just straight our break standards, and therefore break interop. I know for Apple devices I had to disable some standardize WiFi functionality on my access points because these devices cannot handle it despite claiming to support the standard.
The alleged violation is using the IP after the lease expires and before the issuance of a new lease. I don't know if that's true, since most DHCP clients request a new IP long before their lease expires to avoid this.
Perhaps this is more of a problem with some router manufacturers/firmwares than others? I've had a bunch of difference devices running several different OSes (including several Apple devices) connected to a Netgear router running stock firmware for the past year and some change and have had no trouble at all.
Quite likely. Google WiFi notoriously had problems with Apple devices which they never bothered to fix. Switching to Eero completely resolved the random ~45 second hangs we'd see a few times a day.
I see this a lot and it really rubs me the wrong way, but it makes a lot of sense from a usability standpoint.
I started pointing directly at the full commit SHA of the version I want to use when pointing dependencies at Github repos, as I have some naïve belief that it'll offer me a reasonable level of protection from the malicious takeover of a repo.
Docker tags (imagename:tag) aren't cryptographically secure and can be replaced by the server at any time if you aren't using imagename@sha256:<hash> format.
eh it's fine. sure, technically speaking you're giving your machine over to whoever wrote that script. they could do anything! but actually, the script is usually useful and safe. Like this one.
You know that, I know that, but the thousands of people getting desensitized and trained to run random terminal commands like this to "fix their wi-fi" usually don't.
The problem isn't even pasting curl output into sh – it's instructing non-technical users to run any terminal commands, in my opinion.
I'm glad Meter published this post as I've been fighting this issue for the last couple of weeks and wasn't able to find much information on the root cause.
I started getting packet loss recently, and after being unable to find the cause,
I tried upgrading my router. That somehow made things worse -- rather than intermittent packet loss, it would get into a completely unavailable state and not recover. I couldn't even switch to other networks without restarting wifi.
This affected multiple M1 machines and an iPhone, so I was quite sure it was an Apple issue, but wasn't able to find the root-cause. After some limited testing, I'm pretty sure this issue caused both my intermittent packet loss as well as complete downtime.
"Why isn't this happening at my home?
Unlike at home, in a commercial (office, warehouse, lab) environment there are many more demands placed on a Mac device’s WiFi radio as it is getting many more passive connection requests from other devices using the AWDL protocol. The more Apple devices you have on a network, the worse this issue gets."
Well, it might not happen to those rich Apple developers living in their mansions. It sure does happen to us plebes living in apartment complexes. Years ago my ThinkPad found 70 (!) WiFi networks next to me. AWDL is a nightmare here.
I found just disabling these kind of Wi-Fi direct / local sharing features on macOS solved some latency I was seeing during online games. For example: Universal Control when enabled would cause the connection to choke for a few seconds when waking my iPad nearby.
I had this issue today. Bandwidth was degraded to 1mbps download until I switched off Bluetooth. Repeated multiple times to ensure BT was the interference.
Then switching Wi-Fi to channel 11 seemed to stop interference and I had no problems after that.
I've been working out of WeWork in SF and wifi as been completely unusable for the past week. It's been super frustrating to debug because some people have been able to connect totally okay.
Now that I know this is an issue mainly introduced my Apple on their silicon machines, I have some apologies to make to the WeWork staff.
does this impact iOS wifi as well? My local HomeAssistant detects my phone on wifi for presence detection, and suddenly lately it's been all out of whack. it takes much longer to connect to wifi when I get home. and sometimes while home the presence status 'flickers', turning all the lights on/off. never used to happen
Could be. I've noticed my iPhone started to accidentally intermittently lose WiFi connection, only to reconnect again in ~3-5 seconds. I wasn't sure if this is iOS or UniFi AP bug, but I suppose it could be the former.
To add anecdata, I've been seeing the subject behavior on Meraki equipment across various firmware versions. I'm inclined to think this is an Apple-initiated issue.
As it happens, I'm also on a Unifi AP, so that's curious. Would not hesitate to assign blame there... Although, I have long since abandoned their automatic firmware updates which has really helped with stability, so I'm not sure what would've changed on the AP _recently_.
Apple really should just add a 2nd wifi hardware for these background tasks, a similar issue occurs when the location service enumerates local wifi networks, leading to stutter and freezes while streaming real-time video. A cheap one would do.
Any idea what the trigger is? This doesn’t happen normally so I’m wondering whether there some relationship with the vendor UCLA uses or some other network condition.
Lots of people in close proximity seemed to be the trigger for my terrible experience with this last week (talking several hundred sitting in desks next to each other)
People would assume there is a serious problem, turn off a bunch of services, run a bunch of random-ass shell scripts, and then forget that they'd done all that and at some random point in the future discover that some feature wasn't working, and blame me.