111–118 of 118 posts
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.
Earlier quoted context omitted.
Wow I didn't know about that undocumented ability to change Airport prefs! 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.plist It doesn't take the awdl0 inter…
> I was able to somewhat disable AWDL by doing this like you suggest: > 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 prefsI (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.
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.
Earlier quoted context omitted.
I thought we’d gotten over this thing where people thing they appear smart because they copy & paste instead of using curl?
It's not about being "smart". It's a completely unnecessary complication in this case.
This attack requires a malicious server, but it’s still bad practice.
Earlier quoted context omitted.
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.
I took a peek at the script and I don’t think I want anyone who writes code like that coming anywhere near my machine if I can help it.
Earlier quoted context omitted.
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.
Their actual solution for disabling AWDL is running this script in the background: while true; do if ifconfig awdl0 |grep -q " 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,…
I've been having this problem for months. The solution I settled on was a root cronjob that just does `ifconfig awdl0 down` every minute. 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.
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.
# 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